On Sun, Sep 5, 2010 at 10:57 PM, Martin Renold <[email protected]> wrote: > On Sun, Sep 05, 2010 at 09:07:57AM +0930, David Gowers wrote: >> I'm not yet 100% certain, but I am beginning to suspect that the >> transform 8bit <-> 16bit is asymmetrical, > > Not quite sure what this word means in this context, but last time I thought > about it I drew something like that: > > 8bit 16bit > +------ 32768.0 (= 1<<15) > | 255 > +------ 32703.75 > | > | 254 > | > +------ > | > | 253 > | > +------ > ... > +------ 129.75 > | > | 1 97.0 > | > +------ 64.25 > | 0 32.125 > +------ 0 > > I am not certain that it is what is implemented or what we actually want.
In order for dithering to behave in a reliable way, every 8bit value, when transformed ->16bit and back again, should be identical. That's what I mean by asymmetric. If the reverse transform causes off-by-one errors in any case at all, the dithering will be at least partially reapplied, hence nastiness. I don't see a test disproving this, so I'm inclined to think it is a possibility. (I'm not 100% sure on this, but I think this might require all 8bit inputs to map to exact 16bit outputs (with no fractional part.)) I haven't yet determined a way to do the reverse transform (16->8) with this guarantee, without using a horribly big (32k) lookup table. I should look at babl, yeah. Since it specifically measures that kind of error. David _______________________________________________ Mypaint-discuss mailing list [email protected] https://mail.gna.org/listinfo/mypaint-discuss
