Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
I keep coming back to this question. If your goal is to convert all images to your linear light working space for image processing, why not do the conversion one time and be done with it? I did some preliminary checking. LCMS can do the conversion between your linear light profile and the monitor profile. At least I think it can, per this post: [Lcms-user] negative float clipping and gamma 1.0 http://sourceforge.net/mailarchive/message.php?msg_id=29167076 So it looks like LCMS can now convert from linear gamma built-in sRGB with negative values to XYZ space. I played with the transicc utility and sure enough, negative numbers were being transformed from linear sRGB to XYZ and back. I'm pretty sure any other profile with a linear gamma TRC will also work. Assuming the new LCMS capacity works the way I think it does, then you could use what Jon Nordby described in a previous post to this thread, and let LCMS take care of sending the properly transformed linear light information to the monitor display: On 8/30/12, Jon Nordby jono...@gmail.com wrote: This is actually one more conversion and one step earlier than we need to. Ideally the pipeline should look like this: GeglBuffer - | display filter stack | - sRGB in monitor profile - | Cairo | That way we only convert to the monitor profile as a last step. This would require GEGLifying the display filter stack and all the modules it uses. (I think sRGB in monitor profile probably means sRGB or monitor profile. Jon - yes? no?) This ability to use negative floating point numbers with a linear gamma profile (only a linear gamma profile, no other TRC) is a new LCMS capability. It would not have been around at all when you thought up your linear light profile, which perhaps MS/HP then borrowed from you. :) Perhaps the new LCMS capability would eliminate any need for constantly converting back and forth between sRTB TRC and linear gamma TRC. You should also note that babl's RGBA float format is not inspired by or defined by scRGB, but could more well be described as a linear light / physical color space, with the same RGB primaries as sRGB, a linear gamma curve, white at 1.0, 1.0, 1.0 - black at 0,0,0 extendable towards the limits of floating point representation negatively and positively. Your choice of white point (1,1,1) is intriguing, being at odds with the almost universally used D50 white point of XYZ=(96.420,100.000,82.489), and also the V2 sRGB D65. By the way, the lcms V4 matrix sRGB profile uses D50, in keeping with the V4 ICC profile specifications. Are the primaries for your linear light profile as defined in babl/extensions/CIE.c? /* sRGB/HDTV phosphor colours */ static const double pxr = 0.64F; static const double pyr = 0.33F; static const double pxg = 0.30F; static const double pyg = 0.60F; static const double pxb = 0.15F; static const double pyb = 0.06F; If so, I will experiment to see what happens using lcms utility transicc to convert from your linear light space with its unusual white point, to regular color spaces (including camera and monitor as well as working spaces), and back. Just a thought: If your linear space used the identity profile, with RGB primaries of (1,0,0), (0,1,0) and (0,0,1), I don't think you would need negative float values to cover the entire 1931 CIE XYZ color space, conversion computations would be drastically simplified, and I'm pretty sure you'd have less space devoted to imaginary colors. But this whole negative floating point values thing for ICC profiles is new territory to me. I've known about it theoretically for a long time, but until now never had the wherewithal (the new LCMS utilities/capabilities) or reason (your linear light color space) to acquire any practical understanding. Cheers, Elle Stone -- http://ninedegreesbelow.com Articles and tutorials on open source digital imaging and photography ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On Fri, Aug 31, 2012 at 7:37 PM, Elle Stone wrote: I keep coming back to this question. If your goal is to convert all images to your linear light working space for image processing, why not do the conversion one time and be done with it? Isn't it what Øyvind defined as a noble goal in his mail few weeks ago? :) Didn't he also say that the relevant part of code is more like 20% done and hence should not be treated as what the team had in mind for final design? :) Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
The ultimate goal of working in a linear light color space is both clear and noble. The purpose of the constant background converting back and forth between two tone curves, sRGB TRC and linear gamma, is not clear at all. In service of the noble goal doesn't explain *why* the conversions are done over and over again instead of just once. I really, really, really want to know why those relentlessly repeating background conversions between sRGB TRC and linear gamma are happening. But I will stop asking. And maybe some kind soul will send a private email giving an explanation that I can understand. I was excited to find out that the latest LCMS can do color conversions involving negative floating point numbers. If the Gimp code is only 20% finished, then perhaps the information I just gave about the new ability of LCMS to do conversions involving negative floating point numbers might be pertinent to crafting the remaining 80%. But if not, then I apologize for posting it. Elle On 8/31/12, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Fri, Aug 31, 2012 at 7:37 PM, Elle Stone wrote: I keep coming back to this question. If your goal is to convert all images to your linear light working space for image processing, why not do the conversion one time and be done with it? Isn't it what Øyvind defined as a noble goal in his mail few weeks ago? :) Didn't he also say that the relevant part of code is more like 20% done and hence should not be treated as what the team had in mind for final design? :) Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list -- http://ninedegreesbelow.com Articles and tutorials on open source digital imaging and photography ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
Elle Stone (l.elle.st...@gmail.com) wrote: The purpose of the constant background converting back and forth between two tone curves, sRGB TRC and linear gamma, is not clear at all. Well, it is not on purpose. It is basically a side-effect of trying to port Gimp to the new infrastructure without e.g. changing the visual output of e.g. layer modes, while avoiding changing the math (Or do it in an incremental manner while keeping the results consistent). In service of the noble goal doesn't explain *why* the conversions are done over and over again instead of just once. I really, really, really want to know why those relentlessly repeating background conversions between sRGB TRC and linear gamma are happening. Ok, for an example have a look at gimp/app/operations and grep the string R'G'B'. As you can see, a lot of them are designed to work in a R'G'B' mode, since this was the working assumption in our old 8 bit core. We need as-identical-as-possible results and the easiest way to port them to GEGL and adding support for the high-bit-depth modes is to let the operations work in R'G'B'A float and port the math in the most straightforward way possible. Now every time some of these operations is involved, the GEGL core needs to convert the RGBA u16 data as stored in the image to R'G'B'A float so that the operation can properly work in its expected working format. And of course before the new data ends up in the pixel storage it needs conversion back to RGBA u16. Of course this is not good and has a massive speed impact, ideally the operation should be able to work on RGBA u16 directly, but then the math becomes nontrivial (we need compatible results). This is optimization work that we have not even really started tackeling. I fully expect to have other problems like this on all kinds of different places and I don't know which of these point it actually is you're hitting with your test cases. With your elimination of the conversion in util.h you probably have introduced visually different results for these kind of operations (because e.g. the addition mode now adds up in a linear fashion, while it earlier worked in Gamma mode). Of course it is debatable how certain layer modes are supposed to work, but we also need to maintain some backwards compatibility, so that old XCF files in a new Gimp look the same as always. But I will stop asking. And maybe some kind soul will send a private email giving an explanation that I can understand. Please not, keep it on the list. These things are tricky and they deserve to be pulled into the open :) And don't stop asking. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On Fri, Aug 31, 2012 at 11:12 PM, Simon Budig wrote: At the same time new layer modes with the old names can be introduced. Or you could rename old ones to foobar-old and just use foobar for the new ones. Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On 30 August 2012 12:11, Jon Nordby jono...@gmail.com wrote: On 30 August 2012 01:01, Elle Stone l.elle.st...@gmail.com wrote: Regarding sRGB and rendering to the screen: On 8/29/12, Jon Nordby jono...@gmail.com wrote: On 29 August 2012 19:03, Elle Stone l.elle.st...@gmail.com wrote: Why does the /babl/babl/util.h code get executed from fast-float.c, float.c, model-rgb.c, model-gray.c, and several other files, resulting in endlessly performed conversions between linear and regular sRGB TRC in the background of all image processing? Rendering to to screen / the windowing system is done using sRGB. So anything that causes canvas updates when the image itself is not in sRGB will trigger such conversions. Could you explain more about what you mean by rendering to the screen is done using sRGB? What about the actual monitor profile? Cairo, the library used for rendering to the screen in GTK and GIMP expects its input as sRGB*. See app/display/gimpdisplayshell.c for example of how we use this library. The Babl format cairo-ARGB32 is short for R'aG'aB'aA u8: 8 bit unsigned integer gamma-corrected, pre-multiplied alpha. The LCMS plugin is used before this step to do the conversion with the actual monitor profile. Corrections : the LCMS display filter module is used, not the LCMS plugin. File: modules/display-filter-lcms.c The conversion is done _after_ the image has been rendered into the Cairo image buffer. See the call to gimp_color_display_stack_convert_surface in gimpdisplayshell-renderer.c -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On 8/30/12, Jon Nordby jono...@gmail.com wrote: On 30 August 2012 01:01, Elle Stone l.elle.st...@gmail.com wrote: Regarding sRGB and rendering to the screen: Could you explain more about what you mean by rendering to the screen is done using sRGB? What about the actual monitor profile? Cairo, the library used for rendering to the screen in GTK and GIMP expects its input as sRGB*. See app/display/gimpdisplayshell.c for example of how we use this library. The Babl format cairo-ARGB32 is short for R'aG'aB'aA u8: 8 bit unsigned integer gamma-corrected, pre-multiplied alpha. The LCMS plugin is used before this step to do the conversion with the actual monitor profile. So if I understand what you are saying (I don't think I do): First the lcms plugin converts the image to the actual monitor display profile. Then something converts the image to sRGB and sends the image to Cairo? And then Cairo sends the image to the screen? I don't think that is what really happens. If it were happening, all images displayed by Gimp would have a magenta color cast as displayed on my monitor. And they don't. Perhaps Cairo just sends RGB numbers to the screen (and doesn't care what these numbers mean), and Gimp is sending the monitor profile RGB numbers to Cairo. * It is unclear to me how strict this expectation is as this is not documented anywhere in Cairo. Perhaps someone here can shed some more light? An RGB30 (10 bits per channel) image format was added in Cairo 1.12 earlier this year. I don't know if any if the display backends used on Linux, Mac OSX or Windows handles this format yet. It could be the output it still clamped or converted to 8 bit per channel even on wide gamut displays. I highly suspect that would be the case on X11. Bit depth and ICC profile color gamut are two different things. Bit depth determines how many steps to get from min to max. For example, 8-bits gives you 255 steps to get from solid green (0,255,0) to solid yellow (255,255,0). 10 bits gives you 1023 steps to cross the same distance. But the meaning of solid green and solid yellow is determined by where the monitor profile (or any other ICC profile) locates solid green and solid yellow in an reference space (profile connection space) such as XYZ or Lab space. Kind regards, Elle ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On Thu, 2012-08-30 at 07:55 -0400, Elle Stone wrote: On 8/30/12, Jon Nordby jono...@gmail.com wrote: On 30 August 2012 01:01, Elle Stone l.elle.st...@gmail.com wrote: Regarding sRGB and rendering to the screen: Could you explain more about what you mean by rendering to the screen is done using sRGB? What about the actual monitor profile? Cairo, the library used for rendering to the screen in GTK and GIMP expects its input as sRGB*. See app/display/gimpdisplayshell.c for example of how we use this library. The Babl format cairo-ARGB32 is short for R'aG'aB'aA u8: 8 bit unsigned integer gamma-corrected, pre-multiplied alpha. The LCMS plugin is used before this step to do the conversion with the actual monitor profile. So if I understand what you are saying (I don't think I do): First the lcms plugin converts the image to the actual monitor display profile. Then something converts the image to sRGB and sends the image to Cairo? And then Cairo sends the image to the screen? I don't think that is what really happens. If it were happening, all images displayed by Gimp would have a magenta color cast as displayed on my monitor. And they don't. Perhaps Cairo just sends RGB numbers to the screen (and doesn't care what these numbers mean), and Gimp is sending the monitor profile RGB numbers to Cairo. Don't work under the assumption that anything in git master works as it should. It's safe to assume that *nothing* works as it should, and needs to be fixed. So if something doesn't seem to work, the bug could be in many places. --mitch ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On Thu, Aug 30, 2012 at 3:55 PM, Elle Stone wrote: So if I understand what you are saying (I don't think I do): First the lcms plugin converts the image to the actual monitor display profile. Then something converts the image to sRGB and sends the image to Cairo? And then Cairo sends the image to the screen? I don't think that is what really happens. If it were happening, all images displayed by Gimp would have a magenta color cast as displayed on my monitor. And they don't. Perhaps Cairo just sends RGB numbers to the screen (and doesn't care what these numbers mean), and Gimp is sending the monitor profile RGB numbers to Cairo. FYI, color management in Cairo is a work in progress. Adrian needs input on desired API, though. Without it he cannot proceed further. http://inkscape.13.n6.nabble.com/Creating-color-managed-PDFs-td4964914.html Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On Thu, Aug 30, 2012 at 4:41 PM, Alexandre Prokoudine wrote: FYI, color management in Cairo is a work in progress. Adrian needs input on desired API, though. Without it he cannot proceed further. http://inkscape.13.n6.nabble.com/Creating-color-managed-PDFs-td4964914.html Also, http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=color-space Alexandre Prokoudine http://libregraphicsworld.org ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
Am 30.08.2012 13:55, schrieb Elle Stone: So if I understand what you are saying (I don't think I do): First the lcms plugin converts the image to the actual monitor display profile. Then something converts the image to sRGB and sends the image to Cairo? And then Cairo sends the image to the screen? If I'm not entirely mistaken then there should be only one real conversions. In this lcms would convert the linear color to a pseudo sRGB, which is actually the monitor display profile. This is because Cairo only supports sRGB and does no conversion to the monitor profile on it's own. So the colors have to be converted before passing them them to Cairo (regardless if sRGB or RGB30). Bit depth and ICC profile color gamut are two different things. Bit depth determines how many steps to get from min to max. For example, 8-bits gives you 255 steps to get from solid green (0,255,0) to solid yellow (255,255,0). 10 bits gives you 1023 steps to cross the same distance. But the meaning of solid green and solid yellow is determined by where the monitor profile (or any other ICC profile) locates solid green and solid yellow in an reference space (profile connection space) such as XYZ or Lab space. Kind regards, Elle Right. I do not really understand why the conversions should be such painfull. Ideally all image data (except alpha) should be handled as linear internally. This has effectively nothing to do with color management (only depth conversion), except that we want to give every channel/layer a own profile to avoid rounding errors on low bit depth. Rounding errors would occur if we have a 8bit sRGB image and would convert it to 8bit linear RGB. So we have a dilemma: A) Storing everything as 32bit float linear RGB would dramatically decrease programming overhead and computation time (no color conversion, except for final output), but it would consume a great amount of RAM for just 8 or 16 bit images. B) Leaving the the values as they are and doing conversions every time a pixel is accessed saves a lot of RAM. The downside is that every pixel has to be converted from channel profile and depth to another profile and depth if doing some stuff. This could be drastically speed up if there are specialized methods that can do the operation the short way, but i doubt that it would be beneficial to implement all permutations. Personally i would favor scheme A) since performance is one of my biggest concerns for GIMP right now. RAM is important, but it doesn't really matter as much. This steady conversions from one color space to another are really a performance killer. Option C) would be a cache for Option B) that keeps the image data as it is (uncoverted, original bit depth), but stores the pixel information as linear RGB 32 bit. But it would not store the whole layer, it would just store what is On Screen, already resized, transformed, etc, but not flattened. That way only one layer must be converted (cache-layer) while drawing. Kind regards, Tobias Oelgarte ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On 30 August 2012 13:55, Elle Stone l.elle.st...@gmail.com wrote: On 8/30/12, Jon Nordby jono...@gmail.com wrote: On 30 August 2012 01:01, Elle Stone l.elle.st...@gmail.com wrote: Regarding sRGB and rendering to the screen: Could you explain more about what you mean by rendering to the screen is done using sRGB? What about the actual monitor profile? Cairo, the library used for rendering to the screen in GTK and GIMP expects its input as sRGB*. See app/display/gimpdisplayshell.c for example of how we use this library. The Babl format cairo-ARGB32 is short for R'aG'aB'aA u8: 8 bit unsigned integer gamma-corrected, pre-multiplied alpha. The LCMS plugin is used before this step to do the conversion with the actual monitor profile. So if I understand what you are saying (I don't think I do): First the lcms plugin converts the image to the actual monitor display profile. Then something converts the image to sRGB and sends the image to Cairo? And then Cairo sends the image to the screen? You understood me correctly, but what I said it turned out to be wrong. Quoting myself from the follow up email: Corrections : the LCMS display filter module is used, not the LCMS plugin. File: modules/display-filter-lcms.c The conversion is done _after_ the image has been rendered into the Cairo image buffer. See the call to gimp_color_display_stack_convert_surface in gimpdisplayshell-renderer.c So the pipeline is at the moment: GeglBuffer (format depending on image precision setting) - | gegl_buffer_get | - sRGB (without a profile or with the profile of the document?) - | display filter stack | - sRGB in monitor profile - | Cairo | This is actually one more conversion and one step earlier than we need to. Ideally the pipeline should look like this: GeglBuffer - | display filter stack | - sRGB in monitor profile - | Cairo | That way we only convert to the monitor profile as a last step. This would require GEGLifying the display filter stack and all the modules it uses. I don't think that is what really happens. If it were happening, all images displayed by Gimp would have a magenta color cast as displayed on my monitor. And they don't. Perhaps Cairo just sends RGB numbers to the screen (and doesn't care what these numbers mean), and Gimp is sending the monitor profile RGB numbers to Cairo. Yes, you are probably right that Cairo itself does not care about the meaning of the RGB values, and that this is up to the display system and screen. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
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. The working space of the layer modes currently used by GIMP are implemented with sRGB gamma based compositing, thus for higher bit-depth data - we must convert from linear to the sRGB working space - perhaps go back to linear for some other operation, and in most cases we convert back to 8bit sRGB for display (with proper color management we'd go from higher bit-depth to the displays ICC profile or similar). All these legacy 8bit layer modes are scheduled for replacement with operations working in linear light (linear gamma) - at that stage a lot of conversions back and forth (in floating point) will be avoided. Importing 8bit or 16bit images that do not contain sRGB data - should result in precision promotion to probably 32bit floating point, where the data can be well represented ... pending a _potential_ conversion back to the source ICC profile. 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. /Ø ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
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). And many, many more people work with 16-bit images that are NOT sRGB images and DON'T use the sRGB TRC (ProPhoto, Beta, WideGamut, etc). The working space of the layer modes currently used by GIMP are implemented with sRGB gamma based compositing, thus for higher bit-depth data - we must convert from linear to the sRGB working space - perhaps go back to linear for some other operation, and in most cases we convert back to 8bit sRGB for display (with proper color management we'd go from higher bit-depth to the displays ICC profile or similar). All these legacy 8bit layer modes are scheduled for replacement with operations working in linear light (linear gamma) - at that stage a lot of conversions back and forth (in floating point) will be avoided. Importing 8bit or 16bit images that do not contain sRGB data - should result in precision promotion to probably 32bit floating point, where the data can be well represented ... pending a _potential_ conversion back to the source ICC profile. 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? 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. 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. With increasing dismay, but still with warmest regards, Elle Stone ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
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
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
On 29 August 2012 19:03, Elle Stone l.elle.st...@gmail.com wrote: Why does /babl/babl/util.h provide functions that transforms back and forth between linear gamma TRC and the regular sRGB TRC? I'm sure there is a reason, but the reason is not apparent to me. Babl is a pixel format conversion library. It can convert between RGB pixel representations with linear gamma and gamma-corrected, separate alpha channel and premultiplied alpha, or to/from other pixel formats like HSV, HSL, LAB. Why does the /babl/babl/util.h code get executed from fast-float.c, float.c, model-rgb.c, model-gray.c, and several other files, resulting in endlessly performed conversions between linear and regular sRGB TRC in the background of all image processing? That conversion from linear gamma to the sRGB tone response curve and back gets executed literally hundreds of thousands of time, every time you do anything at all using Gimp. Rendering to to screen / the windowing system is done using sRGB. So anything that causes canvas updates when the image itself is not in sRGB will trigger such conversions. Also, any legacy code paths that are still in place before the GEGLification might cause conversions to sRGB. I don't know exactly which parts those are in the current codebase, but anything that uses the deprecated pixel manipulation functions are likely candidates. I note that the lcms plugin still uses these interfaces, and I suspect that is what is causing the implicit (and unwanted) conversions you are seeing. -- Jon Nordby - www.jonnor.com ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] Why the endless background conversions between linear and regular sRGB TRC?
Regarding legacy code/deprecated functions: On 8/29/12, Jon Nordby jono...@gmail.com wrote: Also, any legacy code paths that are still in place before the GEGLification might cause conversions to sRGB. I don't know exactly which parts those are in the current codebase, but anything that uses the deprecated pixel manipulation functions are likely candidates. I note that the lcms plugin still uses these interfaces, and I suspect that is what is causing the implicit (and unwanted) conversions you are seeing. On 8/29/12, Simon Budig si...@budig.de wrote: Basically all of the plugins (including your lcms port) use the old pixel-region API for accessing the image data. This also means that they don't specify a proper working format, this even could be the reason for all kind of potentially useless conversions. Earlier to day I found Mitch's blog post: http://gimpfoo.de/2012/04/17/goat-invasion-in-gimp/ - which coheres nicely with what both of you are saying about the old vs new way of accessing pixel data. So it looks like my next step is to replaced the deprecated functions in the lcms plug-in. So I will start doing exactly that. It was the next step anyway, but I was feeling very discouraged about the whole babl/babl/util.h thing. Regarding sRGB and rendering to the screen: On 8/29/12, Jon Nordby jono...@gmail.com wrote: On 29 August 2012 19:03, Elle Stone l.elle.st...@gmail.com wrote: Why does the /babl/babl/util.h code get executed from fast-float.c, float.c, model-rgb.c, model-gray.c, and several other files, resulting in endlessly performed conversions between linear and regular sRGB TRC in the background of all image processing? Rendering to to screen / the windowing system is done using sRGB. So anything that causes canvas updates when the image itself is not in sRGB will trigger such conversions. Could you explain more about what you mean by rendering to the screen is done using sRGB? What about the actual monitor profile? Back in the day, a decent CRT monitor could easily be calibrated to match the sRGB color space, because sRGB was based on the display characteristics (tone curve, primaries, dial-a-white-point and 0 black point) of the CRT monitor. (See All the Colors, Some of the Colors, the Colors of Daylight: http://ninedegreesbelow.com/photography/all-the-colors.html). Today's LCD monitors are not well-characterized by sRGB. It is not just a matter of the LCD monitor native white point not being D65. The phosphors are different, which means the primaries are different, which means the color gamut is different. And unlike a CRT, with an LCD you can't get (0,0,0) displayed to the screen (the sRGB black point assume zero light can be sent to the screen). Which means you cannot really calibrate your monitor to use the sRGB TRC. (See sRGB — Not So Good for LCD Monitors: http://ninedegreesbelow.com/photography/srgb-bad-monitor-profile.html and Image Display Technology: http://www.marcelpatek.com/LCD.html.) A wide gamut monitor profiled in its native state would be an even worse fit to sRGB, though compared to a regular LCD, a wide gamut LCD monitor can achieve a much closer calibration to sRGB, IF one chooses to give up the extra color gamut. But why would you want to give up all that extra color gamut goodness? My own LCD native state monitor profile covers 93% of the sRGB color space, but the sRGB color space covers only 84% of my monitor profile color gamut. If I calibrated my monitor to match sRGB as closely as possible, I would end up with a monitor profile color gamut that is actually smaller than sRGB, at the additional price of less smooth tonal transitions - a very bad move, it seems to me. So to repeat my question, how does rendering to the screen . . . using sRGB cohere with using an LCD monitor that is not well-described by the sRGB color space profile? Kindest regards, Elle -- http://ninedegreesbelow.com Articles and tutorials on open source digital imaging and photography ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
