sorry but the intention of the tools is not to come up with another alround set for general image manipulations. The tools are basically for handling HIGHEST quality binary raw format from the scientific archives.
It doesn't matter what they are designed
for. 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.
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.
And if you want to know the sizes beforehand, install ImageMagic and you can have a (terribly slow) utility (identify) that tells you everything about the texture concerned.
Here is what you would get without any options applied:
> identify input.png
input.png PNG 5400x2700 5400x2700+0+0 DirectClass 8-bit 13.9479mb 1.440u 0:03
If you want to read out the texture size in a script, 'identify' can do this, too. Except, for monster textures for which my tools are designed (!), it will take longer than all the rest of the job
. I used 'identify' in my virtualtex script that MANY people have used in the past.
We don't need to install Imagemagick just to get access to the Identify tool.
We should be able to write a simple utility to interrogate the IHDR chunk in the PNG file to retrieve the height and width. 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".
If such a utility is provided - let's call it "pnginfo" - it would not use the arcane conventions of "Identify", but instead can be tailored to the conventions of F-TexTools. It needs to output height, width and bytes per pixel to stdout.
Users can then cut-and-paste the information into other parts of the script. Instead of guessing the correct values, they can call pnginfo and get that info directly.
Suppose pnginfo had the following format:
Height: 5400 Width: 2700 Channels: 3
Then we can do this:
png2bin < input.png | tx2pow2 `pnginfo input.png | cut ...` `pnginfo input.png | cut ...` | bin2png `pnginfo input.png | cut ...` 4096 > output.png
(I forget the parameters for the cut command but hopefully the intention is clear)
Or, if you do use a good shell script that supports variables, we can assign to variables the width and number of channels, and reference the variables instead of using `pnginfo input.png | cut ...` each time.
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? 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. 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?
I can manage without needing to have the size of the PNG value output; after all I can read the size of the PNG file from the IHDR chunk in the PNG file itself using a hex editor if I need to. However, figuring out the correct values for bytes per pixel is a bit more arcane and it may be helpful to provide a simple utility to determine this, or at least document briefly how this value is calculated from the Bit depth and Color type bytes.
http://www.libpng.org/pub/png/spec/1.2/ ... tml#C.IHDR