Transparent images in RIVA?

[Dean Roddey]

Actually, looking at that, there really aren't any errors. It's complaining that the gamms is before the palette. But that woudln't actually be a fatal error, it would just mean that the gamma wouldn't potentially get applied to the palette if the program processed the palette at the time it loaded it in, and probably even then most programs wouldn't get confused by that. But the spec says put it before the palette just in case.

I'm definitely inserting a transaprency color, both the regular one and the private one, otherwise my RIVA client wouldn't work. Now, perhaps we don't agree on the value of the tranparency chunk id.

There was a an error in like version 1.3.5 where it used a wrong chunk id, but that's that's long since been fixed.


Can you get it to display the chunk ids?

[Dean Roddey]

I moved my writing of the gamma above the pallete stuff, so when I do write a gamma it shouldn't cause that warning.

I looked at my transparency color stuff, and I won't write the regular transparency color if it's a palette based image. I think it's because I wasn't sure exactly how to deal with that. It's supposed to be an RGB color, but the colors in a palette based image are palette indices, and the same color could be in the palette at more than one index.

So the reading application couldn't really reliably read in an RGB color and look it up in the palette and get it right. And since it would be passing the image to a system call generally to display it, and it's a palette based image, the system will expect a palette index as well.

So I just deferred righting anything in that case, and just store my private transparency chunk, which can be a palette index in the case of a palette based image.

[brianmount]

You're right that specifying a transparent RGB color in a palette-based image could lead to ambiguity. But it looks like the authors of the PNG format recognized that, and that in fact the tRNS record is supposed to contain palette indexes for palette-based images. Below is what the PNG version 1.2 specification says about the tRNS chunk. Basically, tRNS should contain an RGB color for type 2 images, a grayscale value for type 0 images, and an array of palette alpha values for type 3 images. Assuming I understand correctly, would it be possible for you to set the tRNS chunk when rewriting palette images? Then we lazy client developers wouldn't have to do anything.


4.2.1.1. tRNS Transparency

The tRNS chunk specifies that the image uses simple transparency: either alpha values associated with palette entries (for indexed-color images) or a single transparent color (for grayscale and truecolor images). Although simple transparency is not as elegant as the full alpha channel, it requires less storage space and is sufficient for many common cases.

For color type 3 (indexed color), the tRNS chunk contains a series of one-byte alpha values, corresponding to entries in the PLTE chunk:

Alpha for palette index 0: 1 byte
Alpha for palette index 1: 1 byte
...etc...
Each entry indicates that pixels of the corresponding palette index must be treated as having the specified alpha value. Alpha values have the same interpretation as in an 8-bit full alpha channel: 0 is fully transparent, 255 is fully opaque, regardless of image bit depth. The tRNS chunk must not contain more alpha values than there are palette entries, but tRNS can contain fewer values than there are palette entries. In this case, the alpha value for all remaining palette entries is assumed to be 255. In the common case in which only palette index 0 need be made transparent, only a one-byte tRNS chunk is needed.

For color type 0 (grayscale), the tRNS chunk contains a single gray level value, stored in the format:

Gray: 2 bytes, range 0 .. (2^bitdepth)-1
(If the image bit depth is less than 16, the least significant bits are used and the others are 0.) Pixels of the specified gray level are to be treated as transparent (equivalent to alpha value 0); all other pixels are to be treated as fully opaque (alpha value 2bitdepth-1).

For color type 2 (truecolor), the tRNS chunk contains a single RGB color value, stored in the format:

Red: 2 bytes, range 0 .. (2^bitdepth)-1
Green: 2 bytes, range 0 .. (2^bitdepth)-1
Blue: 2 bytes, range 0 .. (2^bitdepth)-1
(If the image bit depth is less than 16, the least significant bits are used and the others are 0.) Pixels of the specified color value are to be treated as transparent (equivalent to alpha value 0); all other pixels are to be treated as fully opaque (alpha value 2bitdepth-1).

tRNS is prohibited for color types 4 and 6, since a full alpha channel is already present in those cases.

Note: when dealing with 16-bit grayscale or truecolor data, it is important to compare both bytes of the sample values to determine whether a pixel is transparent. Although decoders may drop the low-order byte of the samples for display, this must not occur until after the data has been tested for transparency. For example, if the grayscale level 0x0001 is specified to be transparent, it would be incorrect to compare only the high-order byte and decide that 0x0002 is also transparent.

When present, the tRNS chunk must precede the first IDAT chunk, and must follow the PLTE chunk, if any.

[Dean Roddey]

OK, let me give it a try. It looks like I'll have to find the lowest palette index that has the color they selected, then write 0xFF up to that point, and zero at that point, and let the rest just be assumed zero.

[brianmount]

Yes, I think that's it. You must already have code that finds the transparent palette index, because you said that's what you're writing in your custom chunk, correct? So it's just a matter of putting the same info into the tRNS chunk.

[Dean Roddey]

I haven't forgotten about this... I'm just currently in the first really heavy changes for the 4.0 driver architecture stuff. Also I kind of had to then dig my way back out of a dumb decision to remove something used in a lot of places, then figured out it was still needed and had to put it all back. Oh well...

[Dean Roddey]

OK, 3.4.12 is posted and has this change in it. Can't tell you if it'll work, but give it a shot. Of course it only happens upon import so you'd have to re-import any image that needs this.