GNOME.org
 

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

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:
http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision
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 in practice.
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!
thebodzio
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]