Bryan Hoyt | Brush Technology wrote:
> simply save as 16 bit per channel and let the image viewer worry about
> If 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
- 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).