Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Transparent images in RIVA?
You know, I have no clue why it's working correctly in my client, now that I look at it. It looks like it shouldn't. Well... looking more at it looks like what is happening is that the transparency color is actually in the PNG as well. The code that stores the image in the repository is putting it there.

I never actually implemented the code to get the transparency info and return it, but never noticed this because of the fact that it's also in the image and the default code for my image cache item is building on a more fundamental image cache class and that class looks for this image and pulls it out and sets the transparency color flag.

That's not technically right but it will basically work. I'll have to add the code to return the color based transparency flag and the transparency color in the actual message itself.
Dean Roddey
Explorans limites defectum
So you say that the transparent color is in fact hiding in the PNG file somewhere? Maybe I can pick it out of the file then. The file I sent you is the actual file sent to me by the image server. My graphics program doesn't see a transparent color in the file, but maybe you just tacked it onto the end or something nonstandard that the graphics program (and Apple's image libraries) don't see, but I could have my code pick out. Let me know if there's something I can do.
Don't bother. I'll update the server to correctly send the info separately like it's supposed to be doing. I'll fix it today so it'll be out in the next beta drop.
Dean Roddey
Explorans limites defectum
Well, actually it looks like you should do that. I see now why I wasn't returning that info, because it IS in the image, and in order to get it out, I'd have to expand out the raw buffer of data at the server, just to pull that one bit of info out before passing it on to the client. So it was kind of stupid to have wanted to return that info in the message instead of just letting the clients get it out of the PNG themselves. It's a lot of extra overhead to expand out the image just for that before turning around and passing it to you and you to then expand it out yourself.

The transparency color is in a 'private chunk' of the PNG file. PNG files, like most graphics files, are chunked formats, in which various bits of info can be stored in chunks that can be read if they are understood or skipped if they aren't. The data is in one, and there optional ones for the palette, default background color, gamma, etc...

There is a standard transparency color chunk, which has an id of 0x534E5274. I also store the value (in a form more useful to me) in a private chunk with the id 0x43426463. If you can extract chunks from the PNG file, then you should be able to extract this value. The standard one I think only deals with transparency based on RGB color. Mine handles either a pallete based color (if the image has a palette) or an RGB color, so mine is a 4 byte value which is either an encoded RGB value (as discussed in the protocol doc) or a palette index.

The palette index scenario is REALLY unlikely these days, so if you can just extract the standard RGB transparency chunk, then you should be ok. Your PNG class might have some dedicated methods for extracting known common chunks and the transparency color might be one of them.

Of course this now means that the values in the image start are meaningless, so I'll have to document that. I don't want to get rid of them and break anything, so I guess they'll just be changed to 'unused' and might be used for something else in the future.
Dean Roddey
Explorans limites defectum
I will look into that. Now is this only for PNG files? If I come across a GIF file, do I do any special processing, or just pass it to my (Apple's) image library to display as is?

I think the image start transparent color field is not meaningless in the case where the client indicates that they cannot handle an alpha channel. As I understand it, CQC converts the alpha channel to a transparent color and passes it along. If the image format is not one that supports specification of a transparent color, it would need to be passed in this field, correct?

In my particular case, where the PNG file does not have a standard transparent color defined, but you say that one is present in a chunk somewhere, will I expect to see your special custom transparent color chunk, but not a transparent color defined in the normal place? I'm assuming so, and that your code takes the transparent color chosen by the user in the Interface Editor and creates the custom chunk without modifying the regular chunks. If that's not the case, and your code also modifies the regular transparent color specification, then there may still be a problem, because I'm not picking it up.
Yeh, I guess it still is required for that case where the server pre-processes them for the client. And in that case it must expand the image anyway so there's no extra overhead involved anyway.

My stuff should set both the standard transparency color and my own transparency color in the PNG file, and yeh it would only be PNG files since all repository images are PNG and those are the only ones you'd ever be asked to display in a transparent way.
Dean Roddey
Explorans limites defectum
I guess worst case I can update the image repository to store that transparency info outside of the image as well, so that it can be delivered to the clients without them having to expand the image, and then the RIVA server (client of the image repository) can pass it on to you. But it's a lot of work to do if you guys can just get it out of the image.

How are you looking for the color? If you are scanning it yourself looking for the chunk info, keep in mind the data endianess of the values.

So you might actually be looking for 0x74524E53 and 0x63644243 instead of 0x534E5274 and 0x43426463.
Dean Roddey
Explorans limites defectum
I am not actually reading the image data at all myself right now. I am simply passing it to Apple's graphics framework, which in the case of the file I attached earlier does not see a transparent color enabled (whereas it does see a transparent color in other files). And similarly, when I open the file with Graphic Converter, the graphic file utility I use, it indicates that the file does not have a transparent color turned on (again, as opposed to other files downloaded from CQC, where it does see a transparent color). However, you are saying that, in fact, you have already rewritten the file to have the desired transparent color turned on. So something is amiss. When you open up the file I attached in whatever image editor you prefer, do you see the transparent color enabled (as opposed to defined but not enabled)? If so, I will attach another PNG that has a proper transparent color enabled as far as my systems are concerned, so you can see if you see any difference between the two files.
I dug deeper into this PNG chunk issue, and it looks like something may be wrong with the files the image server is sending, either because the files are malformed to begin with or because the image server is rewriting them improperly.

I downloaded and compiled the pngcheck program, which appears to have been written by the PNG developers. It's a command-line utility that scans through PNGs and prints chunk information. I tried it out on the five files in the attached zip file. According to my image editor, two of the PNGs (alpha1.png and alpha2.png) use 32-bit color with an alpha channel. One (good.png) uses 32-bit color with no alpha, and white marked as transparent. And two (bad1.png and bad2.png) use 8-bit color with no transparent color.

When I run pngcheck on alpha1.png, it prints out:

File: alpha1.png (7097 bytes)
chunk IHDR at offset 0x0000c, length 13
60 x 60 image, 32-bit RGB+alpha, non-interlaced
chunk gAMA at offset 0x00025, length 4: 0.44999
chunk IDAT at offset 0x00035, length 7024
zlib: deflated, 32K window, default compression
chunk IEND at offset 0x01bb1, length 0
No errors detected in alpha1.png (4 chunks, 50.7% compression).

The output for alpha2.png is similar. All seems to be in order. Now for good.png, pngcheck prints out:

File: good.png (6978 bytes)
chunk IHDR at offset 0x0000c, length 13
100 x 100 image, 24-bit RGB, non-interlaced
chunk gAMA at offset 0x00025, length 4: 0.45454
chunk tRNS at offset 0x00035, length 6
red = 0x00fe, green = 0x00fe, blue = 0x00fe
chunk cdBC at offset 0x00047, length 4
unknown private, ancillary, unsafe-to-copy chunk
chunk IDAT at offset 0x00057, length 6871
zlib: deflated, 32K window, default compression
chunk IEND at offset 0x01b3a, length 0
No errors detected in good.png (6 chunks, 76.7% compression).

I see both the standard tRNS chunk and CQC's own cdBC chunk. All reasonable. However, when I run pngcheck on bad1.png, it displays:

File: bad1.png (4906 bytes)
chunk IHDR at offset 0x0000c, length 13
100 x 100 image, 8-bit palette, non-interlaced
chunk PLTE at offset 0x00025, length 768: 256 palette entries
chunk gAMA at offset 0x00331, length 4: must precede PLTE
: 0.45454
chunk cdBC at offset 0x00341, length 4
unknown private, ancillary, unsafe-to-copy chunk
chunk IDAT at offset 0x00351, length 4037
zlib: deflated, 32K window, default compression
chunk IEND at offset 0x01322, length 0

The output for bad2.png is similar. In both cases, there's a cdBC chunk but no tRNS chunk, as if, when you rewrite the image file, you are inserting a cdBC but not a tRNS. Further, pngcheck complains that the gAMA chunk is coming after the PLTE chunk; it thinks gAMA must come first. I had to use the "force" command-line option to get it continue displaying chunk information; it thought that having gAMA after PLTE was a fatal error.

Dean, can you see exactly what your image rewriting code does? Is it possible that you are adding a cdBC but not a tRNS if the user specifies a transparent color? Does the Interface Editor behave differently with 8-bit PNGs than it does with 32-bit PNGs?

Sam Vimes, do you happen to have the original images that you imported into your template of devices (the aapl template at the moment)? If I could compare the original PNGs to the rewritten versions coming out of the image server, it might shed light on the exact effects of the rewriting process. Thanks.

Attached Files
.zip (Size: 36.69 KB / Downloads: 0)
Those errors would have been in the original images. I just pass through any chunks from the input to the output, in the order I find them, and don't do anything with these ones it's complaining about. The gamma order thing I could possibly cause, but it's just a warning really. I think I only add gamma myself if you adjust it to a non-default value during import into the repository. Otherwise, it would only be because it was already in the image I think, but I can check.

The private unsafe to copy one is probably my private transparency color chunk. I'm adding that one, not copying it. So it would only be unsafe to copy for some further downstream program that edited it, but there won't be one.
Dean Roddey
Explorans limites defectum

Possibly Related Threads…
Thread Author Replies Views Last Post
  Html 5 Riva potts.mike 9 14,201 09-15-2013, 04:22 AM
Last Post: bjkiller
  Thinking about the next step in RIVA Dean Roddey 6 11,336 01-22-2013, 06:15 AM
Last Post: brianmount
  Official RIVA thread Dean Roddey 382 226,533 07-25-2012, 02:58 PM
Last Post: Fonceur
  .Net RIVA Client Dean Roddey 146 122,649 02-06-2012, 06:53 PM
Last Post: Dean Roddey
  riva burkepaol4 1 8,492 12-17-2010, 11:39 AM
Last Post: Dean Roddey
  Riva screen blanker on CF.NET froop 3 8,383 08-06-2010, 10:34 PM
Last Post: froop
  RIVA Connection batwater 6 9,063 07-16-2010, 04:46 PM
Last Post: batwater
  Java based RIVA Client? batwater 10 13,401 04-03-2010, 05:35 AM
Last Post: wuench
  RIVA Client for Linux bryanb 22 21,041 07-16-2009, 09:11 PM
Last Post: bjkiller

Forum Jump:

Users browsing this thread: 1 Guest(s)