The right way to support 8-bit is having 16-bit support for interim calculations, and the right way to support 16-bit is having 32-bit for interim calculations. Of course, when you're talking about workflow with complex transformations and multiple steps, "interim" is meaningless -- you need full support for the higher bit calculations. If an effort to support 16-bit is underway and is serious, there should be IMHO support for 32-bit. For example, to sharpen in the luminance channel of LAB mode, one would want to take a 16-bit image, decompose into 32-bit channels, apply the sharpening to the LAB channel, and recompose, at which point you would transform back into 16-bit. Such a procedure makes the channel transformation "lossless". Without 32-bit interim support, it's "lossy". (The same phenomenon renders all sorts of 8-bit transformations in complex workflows very poor in the current generation of gimp). My 2 cents. On Mon, Nov 11, 2002 at 08:13:53AM -0500, Patrick McFarland wrote: > Though, my method wouldnt break any plugins, however. Any plugin accessing the > data would get back 8bit values because the layers are still in 8bit mode, its > only a higher precision rendering engine that would be added. 8 bit goes in, > 8 bit comes out, but its 16 bit in the middle. (And yes, when dealing with 20+ > layers, all doing things other than Normal mode, and sometimes bringing the > darkest color below 0,0,0, and the lightest color above 255,255,255, it comes > in handy.)
