Often users find ways of applying software tools in ways the designers didn't expect. With just a little work, these tools can be incorporated into a script that can split up a texture of a fixed size into several levels of textures, all placed in the correct level directories, complete with a CLX file as well. If I can do that using the limited capabilities of a DOS script, it's not hard to do it in a shell script as well.
Yes, but I just meant to say that I will NOT invest any time into this.
People have written already convenient scripts based on the F-TexTools/nmtools that allow to generate a complete /monster/ VT setup (64k!) with just a few mouse clicks, based on /scientific binary/ raw data.
That's what I had in mind. It has become a popular issue these days.
To add small custom extensions officially, means comparatively much effort. My tools are always released with binaries for 3 operating systems
, of which I only have access to two.
Now we don't really need to figure out the width of the image. Other tools can do this as well. But the F-TexTools do also require the users to know the number of bytes per pixel and this is not easy to find out.
We also need to include the capability to retrieve the colour type as well and convert it to the "channels" required in many places in the suite. Knowing the colour type is crucial to the correct operation of the F-TexTools suite but unless I missed something in the documentation at present the only way to determine the colour type using the F-TexTools suite is by trial and error. And when you're working with humungous texture files that take a while to process, users may get frustrated if they need to try it more than once. In fairness, there are likely to be only two values to try: "3" and "4".
The bpp value = number of channels should be obvious before any work is started. It 's really trivial. See further below...
We don't need to install Imagemagick just to get access to the Identify tool.
ImageMagic should be a standard installation in ANY OS for anyone who wants to do something with images. Are you really addressing your efforts to people who would NOT know the size of the texture they are planning to work with?
There are MANY display programs for any OS, where the required image info can be determined with a simple click initially (GIMP, PS, xnview, Irfanview, ...) . People who have NONE of these standard applications installed might again prefer another solution.
We should be able to write a simple utility to interrogate the IHDR chunk in the PNG file to retrieve the height and width.
At the code level it's trivial, of course. Libpng offers all required methods.
The one weakness of the F-TexTools script is the need to pass the number of channels to most of the commands. How do we work out this number from a PNG file?
But the number of channels (bpp=bytes per pixel) is really trivial:
grayscale=1, RGB=3 and RGB with alpha channel = 4 (RGBA).
In all relevant formats, after the header part, follows a certain number of bytes associated with each subsequent pixel of the image. In a grayscale image there is 1 byte value for each pixel. It's the brightness value of each pixel. For a RGB image, we have a triplet of bytes, one for the redness, the greenness and the blueness of each pixel. In RGBA images a 4th byte follows the three RGB bytes and characterizes the alpha value (opaqueness, transparency,...). But of course a general PNG image can be much richer than what I described. Only for Celestia texture work it's not needed.
Users who don't know what kind of textures they are working with, might rather want to use other tools
. Bpp = 1, 3, 4 are equally important in practice.
For instance for work with spec-files = watermaps/landmaps or nighttime-lights, one encounters bpp=1 (grayscale) textures. My tools allow to mount such grayscale spec-maps as alpha channel on top of the RGB base texture. That's how 3+1 =4 channels arise. This saves memory which is important for large textures.
But we don't need any kind of programs to tell us the bpp value
Really I don't see why one has to spoil users to an extent that they don't need to know the initial size of their textures!
But what if the users don't know the initial size, or, more to the point, the number of channels used by the texture?
Then they might want to learn
how to do this...
I have NO motivation to prepare my tools for use by people who either don't have any basic knowledge about images they want to work with or are unwilling to learn! This community chronically lacks much other elementary know how that is required for using command-line tools. They typically don't know e.g. how to use/locate the standard
'cmd' shell under Windows, let alone any more sophisticated shell to run such scripts....
So next you will get involved into a tutorial "how do I find and use the Windows cmd shell of my computer"?
. I went through most of this repeatedly
I simply don't have the time and devotion to get involved once more with this sort of stuff.
While "identify" provides the width of the texture in an obvious format, I doubt many people would be able to use it to work out how many bytes are used per pixel.
But identify also provides the bpp property:
identify -format "%r" grayscale.png => DirectColorGrayMatte
identify -format "%r" rgb.png => DirectColorRGB
identify -format "%r" rgba.png => DirectColorRGBMatte
Just map the output strings to 1,3,4 in your script and you are done, if you REALLY want to do this...