Bryan Hoyt | Brush Technology wrote:
simply save as 16 bit per channel and let the image viewer worry aboutIf we're concerned about filesize, wouldn't this be even worse than a bit of dithering?
Apparently you're right, I just expanded my test program to also output 16 bit and get the following results (output is ppm, converted to png using imagemagick and optimized using pngcrush, both using the default settings): - 8 bit undithered: 40.3 KB - 8 bit dithered: 241 KB (6x) - 16 bit undithered: 418.7 KB (10x) - 16 bit dithered: 656.0 KB (16x) This is using triangular dither (random) and on just one example (a circular gradient used in an about screen a while ago), so take the results with the obligatory grain of salt.
Two things are interesting in these numbers, first of all you're right that 16 bit rendering takes even more space, secondly the difference dither makes likely depends on how "steep" the original gradient was, as it makes much less difference in the 16 bit case (where the gradient is steeper, relative to the smallest representable value).
So perhaps it is a good idea to add dither after all... But where? Dithering gradiens themselves is definitely not always a good idea (as I explained earlier this can wreak havoc, especially with filters), but dithering afterwards might not always be desired either (as it might dither more than is needed/desired, shapes with constant color for example).
I guess there are some interesting things to be done in this area, but in the short term it might be easiest to either try to enable 16 bit rendering and add dither afterwards or to add a simple dither to gradient rendering (would definitely need to be optional, possibly on a per-shape basis). This should probably be done in Cairo or pixman though (not sure which takes care of gradient rendering).