On Thu, Aug 30, 2012 at 8:08 PM, Elle Stone <l.elle.st...@gmail.com> wrote: > On 8/30/12, Øyvind Kolås <pip...@gimp.org> wrote: >> I'll only reply to the question in the topic, repeating quite a bit of >> the information I put in a write up two weeks ago: >> http://gimp.1065349.n5.nabble.com/GIMP-GEGL-storage-precision-and-color-management-td34899.html >> >> When operating in 8bit precision is that a GEGL powered GIMP assumes >> that 8bit precision data is stored with sRGB gamma (this will probably >> be changed to apply to 16bit integer as well), data with higher >> bit-depths are stored with a linear gamma ramp in the layer buffers. > > > But this is a ***very wrong*** assumption. Many people work with 8-bit > images that are NOT sRGB images and DON'T use the sRGB TRC (AppleRGB, > ColorMatch, LStar, etc).
sRGB, AppleRGB and other 8bpc representations are a work-around for the limited values expressable in 8bit - you are better off doing the actual processing in linear light RGB and not permitting these arbitrary working spaces; this reduces this other spaces to be a space efficient way of packing the color data into 8bit. >>Note that babl's built in floating >> point representations have unbounded gamuts thus can represent all of >> sRGB / ProRGB / AdobeRGB and data with other 8bit profiles. Using the >> sRGB for 8bit and 16bit integer precisions means that (web destined) >> JPG and 8bit/16bit PNGs without associated profiles should be possible >> to directly manipulate. > > In point of fact the extended scRGB does NOT cover all of the > ProPhotoRGB color space or the CIE 1931 color space. scRGB leaves out > a good chunk of the all-important greens. > Quoting from Wikipedia, which has a very nice picture that everyone > ought to go take a look at: http://en.wikipedia.org/wiki/ScRGB > > "Negative numbers enables scRGB to encompass most of the CIE 1931 > color space while maintaining simplicity and backward compatibility > with sRGB ***without the complexity of color management***. The cost > of maintaining compatibility with sRGB is that approximately 80% of > the scRGB color space consists of imaginary colors." > > The point of scRGB is MicroSoft's and Hewlett-Packard's attempt to yet > again not deal with color management. But color management is part and > parcel of all high end image editors, and well-integrated with Linux. > So why on earth would any Linux image editor want to follow in the > MS/HP footsteps and use scRGB, with the attendant loss of ability to > represent all of the real world colors and the attendant requirement > of using very high bit depths to maintain image integrity? The "RGBA float" space of babl does not leave out greens, blues, purples or imaginary colors of any magnitude. The entirety of the tristrimulus gamuts expressable in any RGB triplet space can be expressed. (granted some parts of this 32bit floating point representation is not the most _useful_ real world colors, but no colors are being left out). > If you stick with normal, well-accepted working spaces like > ProPhotoRGB and BetaRGB, you can edit using 16-bits without banding. > If you force image data into the scRGB color space, to maintain the > same degree of accuracy/lack of banding you will ***need*** to go to > 32-bit/64-bit floating point, because of the way scRGB works. That is > the price you pay for having 80% of your working space occupied by > imaginary colors. That will place a huge and unnecessary overhead on > image editing with Gimp. You were yourself arguing for linear light processing earlier ;) To me this is about doing things more correctly and not rely on the legacy of 8bpc hacks. Moving the 8bpc hacks over to be properly color manages (having completely user defined arbitrary working spaces for operations like blur and compositing is not really a color managed workflow). All processing in a GEGLified GIMP is already happening in 32bit float, the additional overhead to pay by using single (or half (16bit)) precision float for storing image content is not a large price to pay for accurate color management. > Right now the default babl/base/util.h DOES NOT WORK with any 16-bit > image that doesn't have the sRGB TRC. Please see this page for an > example using Gegl blurring: > http://ninedegreesbelow.com/temp/gimp29-gegl-blur-prophoto.html > > My color conversion code is NOT involved in blurring, and to make > double sure, I replaced my lcms2 plug-in with the default Gimp lcms > plug-in. The Gegl blurring ONLY works with images that have the sRGB > TRC. Your assessments on what works when opening your image files has little bearing on correctness of what is going on. Your changes to babl is equivlent to declaring that black and white is the same thing and complaining about being run over by cars in a zebra crossing. ;) > With increasing dismay, but still with warmest regards, > Elle Stone I do hope you stick around, we need people able to understand color and the implications of controlling it properly. But it seems like you think we're 98% done with dealing with color in the brave new world of geglified GIMP while the truth is that we're probably ~20% there. Very few things are expected to work correctly right now and the rest can be figured out as we're gaining more solid ground. /Ø _______________________________________________ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
