Yes, I guessed something like that was the reason. However, I'm not sure why
the image should be loadable by paint programs - in most cases it will look
unintelligible. As far as I can see, hand-editing of a HF_16 TGA in a paint
program is impossible for any practical purposes.
And what about using 24/32 bit precision? These would still be valid TGA
images, the 24 bit version would not increase file size and could also be
read as a 16 bit HF (if a program doesn't support 24 bit precision but can
recognize the image as a HF). Which brings me to the question: what
identifies the file as a HF_16 TGA? Surely not only the fact that the blue
channel is empty?

Margus

Alexander Enzmann wrote:
> 
> A reasonable question, with (I hope) a reasonable answer.
> 
> At the time I added 16 bit HF support for TGA images, I wanted to be
> able to load the images into viewer programs (this is something like 5-7
> years ago and PICLAB, CSHOW, etc were about the best around for use
> hobbyists).  16 grey isn't a valid form of TGA file (well, at least it
> wasn't considered so by the Truevision engineer I was corresponding with
> and no image programs would load it if you put 16 bits into a grey
> pixel).  So, I decided that I'd plonk the bits into the red and green
> channels of a 24 bit color image.
> 
> Note, if you look at the TGA file format specification (yes it is TGA,
> not Targa), you could interpret the use of field 3 and field 5.5 to mean
> that you can have 16 bit per pixel greyscale images (24 and 32 too).
> Most programs have problems with that.  Just like many programs have a
> problem with the use of a non-zero value in field 1.
> 
> Xander

Post a reply to this message