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

[Martin Nordholts <enselic gmail com>]

2012/1/28 Bogdan Szczurek <thebodzio gmail com>:
> Now… excuse me if I sound a bit heretic or provocative (I simply don't know
> how to ask that question in other way), but… what exactly is GIMP's vision?

I'm sorry, I indented to reference the vision in the previous mail but
it got lost. Here it is:
http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision

I maintain my position that big images requires bit amounts of RAM,
and that limitations on the output should be enforced by output
filters and export mechanisms. An image mode, as present in GIMP 2.6,
is an unnecessary burden and complexity for the user, not to mention
cause of loss of data fidelity.


>> Maintaining support in GIMP for an internal image data format of 8 bpc
>> or adding support for an native image data format of 16 bpc is silly
>> because such formats is going to result in rounding errors and lack of
>> HDR support, which is not high-end.
>
> HDR or not it'll most of the time end up on (again: most of the time :)) 8
> bit driven display. Besides OpenEXR use exactly 16 bpc (mantissa 10 bits to
> be exact). HDR power is not in images that inherently look better but in
> greater capability of processing them (e.g. about +- 30 EV in OpenEXR!).

What you say is correct, an image on a 8 bpc display does not
automatically look better because its internal image data format
supported HDR. And that is not why GIMP should support HDR. GIMP needs
to support HDR because most scenes have greater lightning dynamic than
"black" and "white paper". An internal image data format of, say, 8
bpc means loss of information.


> Let's assume we have RGBA as internal sample format.
> Each channel is 32 bits fp. It means value of each channel is represented by
> (IEEE 745): 1 bit of sign, 8 bits of exponent, 23 bits of really significant
> value. Now, how do we interpret this value colorimetrically?

It is common to map RGB float 1.0, 1.0, 1,0 to sRGB white (RGB u8 255,
255, 255), Higher values, such as RGB float 1000.0, 1000.0, 1000.0
means "white, 1000 times more intense than sRGB white". This is what
GEGL currently does.


> Even if we'd disregard all else. Let's assume we use RGBA, 32 bits fp per
> channel and disregard "color mode" at all. What about some really useful
> color models, like Lab, XYZ, HSV, HSL

How data is stored is different from how it is presented to the user.
Converting between these color modes involves well defined
mathematical transformations, so I don't really see a problem. For
example, transformation to and from linear light RGB and CIE XYZ is a
simple 3x3 matrix multiplication where the matrix depends only on the
chromaticity of the RGB primaries and a selected white point. A color
picker in HSV (ew) for example would convert the selected color to RGB
before writing it to a RGBA buffer.


> CMYK and also "multichannel"?
> Especially in two latter, there are situations when you'd need to set "this
> channel" to "that value exactly". If all data is RGB, how we'd provide this
> possibility? We'd have to temporarily derive channel value from RGB, modify
> it, and convert back to RGB. And all that assuming that all operations are
> bijective between RGB and other color space which in practice simply *isn't
> true* most of the time.

Clearly, we can't store CMYK + other spot color data in RGBA buffers,
That would be weird. Exactly how to solve this is an open issue. Maybe
have GEGL Y float buffers for each spot color. In any case, high end
support for CMYK in GIMP will happen after we have proper support for
non-destructive high-bit depth RGB workflows.

/ Martin


-- 

My GIMP Blog:
http://www.chromecode.com/
"Single-window mode feature complete"