More Firefox color woe

[ewx]

I complained a while ago about Firefox's broken color management on Macs. It turns out it's even more broken than that, and not only on Macs.

My home page has a gray background, set to 808080 hex in CSS. Embedded in it are some PNG images, again with a background color of 808080. So they should blend seamlessly into one another, right (whatever properties the browser thinks the monitor has, supposing it has an opinion at all)?

Display that page in Firefox 2.0 on Linux and here's (zoomed in) what you get:

Picking over that capture in the Gimp reveals that:

• The CSS-configured background is actually rendered as a solid 848284
• The background gray in the image is actually rendered as a randomly dithered pattern composed of 847d84 and 7b827b - at this magnification it looks visibly pink and green to my eyes though it's just a (visibly) different shade of gray without magnification.

(I initially spotted this on a Mac last night but assumed it was the same problem as before, perhaps compounded by using different interfaces for drawing background and images, but if it happens on Linux then too then it must be something fundamental to Firefox's treatment of color, probably far away from where you'd put color management support if the program actually had any).

Comments

that the CSS renderer and the PNG renderer disagree

[ewx.livejournal.com]

It's not like matching up images and backgrounds is some unusual thing that nobody ever does on the web!

Re: that the CSS renderer and the PNG renderer disagree

[simont]

Yes, but you're asking for a certain amount of heuristic intelligence in the PNG renderer. On the one hand, it does want to dither most of the time, because its fundamental aim is to display the (typically 24-bit) image it's given as faithfully as possible on the limited-depth screen it has. But on the other hand, you're asking it to recognise that in some situations dithering isn't the best thing it could be doing, and to refrain from it at that point. Presumably this will involve a layering violation to tell the PNG renderer not only what colour background it's got (which it needs anyway for alpha blending) but also what colour background it was supposed to be; and then the PNG renderer has to look round the edges of the image to find the latter colour, and render it consistently as the former where it appears. I know that wouldn't appeal to me if I were writing either the PNG renderer or the top-level CSS renderer that called it.

The other alternative is to have the dithering done universally, so that the PNG renderer outputs 24-bit data all the time and some top-level piece of code deals in a uniform way with converting it to the available colour depth. That doesn't strike me as a nice answer either, because even on a 16-bit display it doesn't seem obviously right to dither the entire window without better cause than that.

Having mentioned alpha blending ... it suddenly occurs to me, actually, to ask why you're trying to match up those backgrounds at all. PNG has an alpha channel, so why haven't you just set the parts of the image which want to be the same colour as the surrounding page to transparent? That might perfectly well actually work better.

Re: that the CSS renderer and the PNG renderer disagree

[ewx.livejournal.com]

The last bit is easy to answer - at the time I draw the original versions of those images, IE didn't implement PNG's alpha channel correctly. It wouldn't be a bad time to check again I suppose.

Re: that the CSS renderer and the PNG renderer disagree

[covertmusic.livejournal.com]

IE5/6 don't by default, but you can subvert that with a little bit of browser-aware Javascript. I'll dig out the link if it's useful to you.

What it does is attach a proprietary filter, via CSS2 DOM events, to PNGs in IE only; this changes the particular renderer used for them to one which supports alpha channels. Grotesque, innit? :)

Re: that the CSS renderer and the PNG renderer disagree

[ewx.livejournal.com]

The good cause for following the 'other alternative' is precisely the need to match up images and backgrounds. Like I say, this isn't some obscure edge case I'm trying to use here, it's something pretty widespread on the web.

Whether the globally used mechanism is dithering or just picking the nearest available color is another question, but it should certainly be the same mechanism for different sources of color.

Firefox seems to have no compunction about using visually bad (but computationally cheap) methods of scaling images, so it's not like cheap-and-cheerful color approximation would downgrade something that was otherwise a good graphical display tool.

(I can't remember why I ended up with a 16-bit display on this machine; I'll see what goes wrong with 24 bits, or whether it likes 15 bits, at some point. But having a workaround doesn't mean that the implementation is OK.)

[simont]

(Thinking about it more carefully, I doubt 15 bits would be a huge improvement. There would still be a visible gap between the poor approximation to solid-808080 attained by rounding it up to solid-848484, and the better approximation attained by dithering between 848484 and 7b7b7b. You wouldn't get the various exciting off-greys any more, but the visible dividing line would still be there.)