2012/1/28 Bogdan Szczurek <thebodzio@xxxxxxxxx>: > 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" _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gimp-developer-list
