Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Transparent images in RIVA?
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
Software Geek Extraordinaire
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.
Dean Roddey
Software Geek Extraordinaire
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. 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
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.
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.
Dean Roddey
Software Geek Extraordinaire
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.
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
Software Geek Extraordinaire
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.
Dean Roddey
Software Geek Extraordinaire

Possibly Related Threads...
Thread Author Replies Views Last Post
  Html 5 Riva potts.mike 9 5,282 09-15-2013, 04:22 AM
Last Post: bjkiller
  Thinking about the next step in RIVA Dean Roddey 6 4,700 01-22-2013, 06:15 AM
Last Post: brianmount
  Official RIVA thread Dean Roddey 382 71,293 07-25-2012, 02:58 PM
Last Post: Fonceur
  .Net RIVA Client Dean Roddey 146 41,102 02-06-2012, 06:53 PM
Last Post: Dean Roddey
  riva burkepaol4 1 6,190 12-17-2010, 11:39 AM
Last Post: Dean Roddey
  Riva screen blanker on CF.NET froop 3 5,357 08-06-2010, 10:34 PM
Last Post: froop
  RIVA Connection batwater 6 4,894 07-16-2010, 04:46 PM
Last Post: batwater
  Java based RIVA Client? batwater 10 6,769 04-03-2010, 05:35 AM
Last Post: wuench
  RIVA Client for Linux bryanb 22 9,353 07-16-2009, 09:11 PM
Last Post: bjkiller

Forum Jump:

Users browsing this thread: 1 Guest(s)