Re: [Gimp-developer] GIMP's future internal image data format

[Nathan Summers <rockwalrus gmail com>]

On Sat, Feb 4, 2012 at 7:07 PM, Bogdan Szczurek <thebodzio gmail com> wrote:
> -- cut for brevity's sake :) --
>
>
>> As an artist that does a lot of hand drawing i noticed the problems of
>> the 8 bit limit very quickly. Just use the smudge tool and you will see
>> any color, but not the intended colors (rounding errors=new colors).
>> Same goes for the blur brush. Ever tried to to blur larger areas with
>> it? Guess not, since it doesn't work. If the gradient is flat enough it
>> won't blur anymore, since it is just one step away from actually
>> switching a bit in the result. That are very common cases that really
>> would profit from higher color resolutions.
>
> Naah ;) you've misunderstood me – I wasn't defending the idea of "8bit as
> ultimate solution for all", just pointing out that example from linked
> article was a bit… flimsy ;).

Right.  This issue is whether "32 bits for all" is right for GIMP's
vision statement, or whether it should be one of perhaps several
options.  I'm not convinced that "32 bits for all" is the right way to
go, even though I do think a high end graphics program should offer 32
bits.  But there is a lot more to consider than just whether 32 bit
floating point offers more precision than other formats.

For instance, if you are targeting JPG as your final format, there is
probably no practical benefit from working in more than eight bits per
channel, since the JPG artifacts will overwhelm the last few bits of
eight-bit precision anyway.  If your target is eight bit per channel,
precision isn't a good argument for 32-bits per channel over 16-bits
per channel, since the chances of 16-bit roundoff errors showing up in
the final eight bit channel are fairly remote.

That said, even when there would be noticeable differences when using
a format with higher precision, there may be good reasons for a
knowledgeable user to choose to use a lesser-precision data format.
Even though the gap has narrowed, integer operations are still
significantly faster on modern processors.  A user may be happy to
trade off some precision in order to do an image operation in fixed
point and shave off a lot of time, especially if the target doesn't
have an enormous dynamic range anyway.

I also think that some on this list have underestimated how important
it is for a high-end image application to be able to handle gigantic
images.  The original GIMP authors went to a lot of work in the
transition between 0.60.x and 0.99.x largely in order to support huge
images more efficiently.  Saying that memory is cheap is not an excuse
to be wasteful with it, because data is cheap as well.  If program A
can handle an image of a certain size on a machine with maxed-out
memory, and program B can only handle one of a fourth the size because
B insists on converting all images to 32-bits per pixel, which program
is the high-end one?

Rockwalrus