I generally don’t use Fireworks. I want to learn to use it more, but I’ve been using Inkscape, and Sodipodi before that, long enough that I just haven’t had the need to learn another package yet. But Alex Walker’s post last month about alpha-indexed PNGs and browser compatibility made me add a copy of Fireworks to the budget.
While I have a love-hate relationship with the Fireworks interface, there’s no doubt that it does exactly what it is supposed to do. The following corner image from my previous post uses absolutely no IE-transparency hacks, and yet displays without the gray box in v5 or v6:
The image is also 3KB, versus the previous image’s relatively hefty 14KB. There’s a bit of dithering and banding in the grey, as you’ve gone from 24 color-bits per pixel to 8bpp. In this particular case (potentially being used on dozens or hundreds of products and being seen by thousands of web visitors), the 5x reduction in file size is probably worth the almost imperceptible banding. Especially when you consider the fact that you are also no longer having to hack IE to make them look decent.
But! There’s still a caveat here:
Even if you are working with PNG files, do not just use the “Save” command in Fireworks — you must use the “Export” option instead.
(One of my many pointed fingers is wagging at you, Ben Nadel.)
Let’s peek inside the iTunes corner image saved with “Save” first:
Look at that file size in the bottom left! 51KB! That is certainly not something you want to publish to the web. See all that “ancillary” data? Fireworks chucks it there as metadata for the next time you reopen the file inside Fireworks, but an image viewer is going to completely ignore the ancillary data. Why stream it to the browser if it’s not useful data?
(If you really want to quibble, some viewers will use some of those ancillary fields, such as DPI and colorspace, but for the most part they are ignored. They are not part of the PNG spec. And even the ones that are part of the spec can be relatively safely ignored by image viewers. Hence, you know, “ancillary”.)
Let’s look at the same file, this time saved with “Export”:
Notice that most of the ancillary data is now gone, and the filesize is down to something decent. Unless you intend to distribute a file that other people are going to open in Fireworks, use Export.
And yeah, it’d be really nice if you had options in Photoshop/Fireworks/ImageReady to decide which PNG chunks you wanted to include, such as automatically tagging all PNGs with an Author.
I’m going to segue for the rest of this post and dive into the mechanics of the the whole alpha-indexed transparency thing. It’s that tRNS chunk that is the magic behind alpha-indexed transparency. The PLTE chunk defines the color palette (61 colors * [1 red byte + 1 green byte + 1 blue byte] = 183 bytes), and then the tRNS defines the extra alpha value for each color in the palette (61 colors * 1 byte alpha = 61 bytes). It essentially extends the palette to be RGBA instead of just RGB.
If you read Alex’s article, you know that Photoshop (up to CS2, at least) doesn’t correctly handle alpha-indexed PNGs. In fact, it chokes pretty hard:
Fireworks knew when it saved the file that the shadow was just a black layer with an alpha channel, so the PLTE contains several black indexes, while the tRNS entry for each is what differentiates them. That ugly black band is there because Photoshop is reading the PLTE chunk correctly, but not the tRNS chunk. This is mildly ironic, as the Photoshop/ImageReady version of the Export feature does write out a tRNS chunk!
But if we open the Photoshop version of the PNG file with a hex editor, the entire tRNS block is set to one value (fully opaque, 0xFF) except for exactly one index, which is set to fully transparent (0x00):
Does anyone with CS3 know if this has been fixed? It’s pretty obvious that the file export codebases hadn’t been merged as of CS2/FW8, as Fireworks outputs the primary transparent color as the first index in the palette, while Photoshop/ImageReady output it in the last index.
Now we can also guess why MSIE shows what it does. It’s just doing the opposite of Photoshop — it can tell that the index is supposed to be partially transparent, but it’s throwing in the towel a bit too early and making the whole index transparent, presuming that’s the lesser of two evils.