Re: [Gimp-developer] GIMP's future internal image data format
- From: Bogdan Szczurek <thebodzio gmail com>
- Cc: gimp-developer-list gnome org
- Subject: Re: [Gimp-developer] GIMP's future internal image data format
- Date: Tue, 31 Jan 2012 00:31:34 +0100
W dniu 12-01-30 16:55, Martin Nordholts pisze:
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:
Thanks for the link! It explains a lot. In fact, I think this is so
important information, that it should make its way to the gimp's main
site ("about" section maybe?).
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.
I think in this matter we're bound to simply wait and see how it's work
I gave my arguments earlier and now, as a kind of summary, I'll say that
so called "image mode" is not only a burden, but also a means to provide
designer with conciously used safety mechanism protecting him from doing
something stupid by accident. Again: we'll see how "modeless" GIMP will
be. Frankly – I'm curious whether I'm wrong or right and to what extent :).
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".
And I'm OK with that. I'm only trying to say that "lowDR" still has its
important place in contemporary graphics design and all-along HDR
capable storage is a wasteful way of holding this kind of data. Not
"simply wrong", not "unaccteptable" but "wasteful".
An internal image data format of, say, 8
bpc means loss of information.
I'd rather say: a potential loss of precision. However I agree that we
sometimes need greater precision for the sake of proper handling
mentioned dynamic range of edited images. What I don't agree about is
that we need it *always*, but again… only time will tell :).
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.
It seems quite reasonable to me.
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.
Which is nice if we're converting from "tighter" color space to
"broader" one or between two equally "broad" ones. Luckily scRGB, being
chosen space of GEGL, should presumably take good care about most useful
colors. What concerns me and makes me wonder is how colors
irreproducible in scRGB will influence results in every day practice.
Maybe I'm just oversensitive in that matter after all… :)
It tempts me to experiment sometime and make a comparison between image
manipulation done with "mode dependent" and "modeless" image data
layouts. How will results vary?
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! That's my point! It would be "a kind of" possible but… you've
said it: 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.
What I hope to see soon.
To sum things up: thanks for interesting discussion! I hope it'll prove
useful for everyone. As for me I'm holding my further concerns until
such time as the mentioned functionalities will have the occasion to
prove themselves in every day use. I've spoken my mind, got the
impression I was properly understood and admit further "bugging" this
list will be counter-productive :).
My best regards!
] [Thread Prev