Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise
On Fri, Oct 10, 2014 at 6:36 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/09/2014 07:52 PM, Michael Henning wrote: On Thu, Oct 9, 2014 at 7:22 PM, Elle Stone So where in the conversion to XYZ and then to LAB (or any other reference color space) will sRGB as PCS fit in? Of course you could convert from User_RGB to XYZ, from XZY to sRGB as PCS, from sRGB as PCS back to XYZ, and then, finally, to LAB. But I don't see the point of doing such an odd sequence of conversions. This conversion would be User_RGB - sRGB PCS - LAB. While Linear User_RGB to Linear User_RGB2, might end up being just be Linear User_RGB - Linear User_RGB2. The choice of XYZ or linear sRGB or any other linear RGB as a PCS should not have an impact on either the results you get or the number of conversions happening - when converting between RGB spaces. Any linear RGB space is a matrix multiplication away from XYZ, this includes the PCS of babl. Two such matrix multiplication steps can be combined into a single step by multiplying the matrices corresponding to the steps. Thus the number of operations to do per pixel is the same when going from from babl PCS - XYZ - some linear RGB, as if you do XYZ - some linear RGB. This matrix will be stored in the specific BablModel for this color space; and available in code paths for doing conversions to/from PCS or directly between such models. It is only for CIE Lab and related spaces we end up with a longer sequence of conversions (the CIE color models are the type of spaces that need a bit more special treatment, which is why those color models have an implementation of XYZ to/from linear sRGB.). Most algorithms and editing is RGB centric; thus this is a fair compromise. The CIE Lab code if refactored could also be a single step away from the PCS. Given that the choice of PCS, is any suitable RGB space. We are left with looking for other redeeming qualities to make a choice. A lot of - yes legacy; but we have code integrating with such libraries file formats and more; 8bit images around, and some 16bit images as well do use sRGB. And sRGB continues to be the recommended format on the web and elsewhere. /pippin ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise
On 10/10/2014 01:41 PM, Øyvind Kolås wrote: On Fri, Oct 10, 2014 at 6:36 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/09/2014 07:52 PM, Michael Henning wrote: On Thu, Oct 9, 2014 at 7:22 PM, Elle Stone So where in the conversion to XYZ and then to LAB (or any other reference color space) will sRGB as PCS fit in? This conversion would be User_RGB - sRGB PCS - LAB. You cannot get from User_RGB to sRGB as PCS without going through XYZ. XYZ is the PCS (Profile Connection Space) for converting between RGB color spaces. sRGB is not a Profile Connection Space. You cannot get from sRGB as PCS to LAB without first converting from sRGB as PCS to XYZ. LAB is a mathematical transform of XYZ, not sRGB. This is the normal path from User_RGB to LAB: User_RGB - XYZ - LAB. Two conversions. You want to take this path, yes? User_RGB - XYZ - sRGB as PCS - XYZ - LAB. Four conversions, going through XYZ twice. Why is the second path preferable? With respect, Elle Stone ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise
On Fri, Oct 10, 2014 at 9:38 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: You cannot get from sRGB as PCS to LAB without first converting from sRGB as PCS to XYZ. LAB is a mathematical transform of XYZ, not sRGB. This is the normal path from User_RGB to LAB: User_RGB - XYZ - LAB. Two conversions. You want to take this path, yes? User_RGB - XYZ - sRGB as PCS - XYZ - LAB. Four conversions, going through XYZ twice. Why is the second path preferable? Forget about CIE Lab, and consider RGB spaces - which is what we are most concerned about. When transforming between linear RGB spaces there will be no conversion to XYZ. In the end when things are rigged up propertly, this will be performed in a single step with a single transformation matrix; which is cached nearby in the code doing the copy. From the mental model of how babl and BablFormats are used; all of this is however implementation details. The important thing is that a pointer to a single unique BablFormat is all we need to be sure about the colorimetric values of the pixel. Which is the role of an ICC profile in color management between applications and devices. We can combine this with other BablFormats that we want to read or write the data in. As well as create buffers that store their content in any BablFormat. Existing code written with assumptions of sRGB, whether in GIMP and GEGL that we control or in XPM, GTK, GDK, or elsewhere that has sRGB assumed will continue to work. We take the existing architecture which is following general guidelines of assuming sRGB where none is specified. This is what I mean by sRGB/the PCS being Celcius in the temperature analogy. A lot of the buffers that GIMP ends up for drawing its user interface are all things that are expected to be passed as sRGB data. (most bits of GTK outside actual image windows; which we should be communicating with the system compositor in opting out of global color corrections the it already should be doing of the pixels from sRGB-display profile.). /Øyvind K. ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise
On 10/10/2014 04:08 PM, Øyvind Kolås wrote: On Fri, Oct 10, 2014 at 9:38 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: You cannot get from sRGB as PCS to LAB without first converting from sRGB as PCS to XYZ. LAB is a mathematical transform of XYZ, not sRGB. This is the normal path from User_RGB to LAB: User_RGB - XYZ - LAB. Two conversions. You want to take this path, yes? User_RGB - XYZ - sRGB as PCS - XYZ - LAB. Four conversions, going through XYZ twice. Why is the second path preferable? Forget about CIE Lab I really don't want to forget about LAB. The plan is that sRGB as PCS will be used for something. I'm trying to figure out what exactly something covers. So I have two specific questions. The first question is about converting to LAB. The second question (which I haven't asked yet) has to do with Y. sRGB as PCS is linear gamma unbounded sRGB. I think it's reasonable to ask why a conversion to unbounded sRGB should be involved in a conversion from User_RGB to LAB. , and consider RGB spaces - which is what we are most concerned about. When transforming between linear RGB spaces there will be no conversion to XYZ. By transforming between linear RGB spaces, do you mean converting between User_RGB and unbounded sRGB, both encoded linearly? If you plan to convert from User_RGB to unbounded sRGB, how do you do the conversion without a conversion to XYZ? In the end when things are rigged up propertly, this will be performed in a single step with a single transformation matrix; which is cached nearby in the code doing the copy. Does this mean you will get the User_RGB colorants and cache a conversion from User_RGB to XYZ to unbounded sRGB into a concantenated matrix transform? Existing code written with assumptions of sRGB, whether in GIMP and GEGL that we control or in XPM, GTK, GDK, or elsewhere that has sRGB assumed will continue to work. We take the existing architecture which is following general guidelines of assuming sRGB where none is specified. Assigning sRGB to images with no embedded profile is done because you can't display images in an ICC profile color-managed workflow until an ICC profile is assigned. How images with no embedded profile are handled is irrelevant to the question of why a conversion from User_RGB to LAB needs to involve unbounded sRGB. This is what I mean by sRGB/the PCS being Celcius in the temperature analogy. A lot of the buffers that GIMP ends up for drawing its user interface are all things that are expected to be passed as sRGB data. Whatever happens to the user interface is irrelevant to the question of why a conversion from User_RGB to LAB needs to involve unbounded sRGB. (most bits of GTK outside actual image windows; which we should be communicating with the system compositor in opting out of global color corrections the it already should be doing of the pixels from sRGB-display profile.). Opting out of global color corrections is not a reason to stick unbounded sRGB in the middle of a conversion to LAB. I can move on to my question about Y and unbounded sRGB. But I still don't understand why unbounded sRGB should be involved in a conversion from User_RGB to LAB. With respect, Elle Stone ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise
On Sat, Oct 11, 2014 at 1:18 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: I really don't want to forget about LAB. The plan is that sRGB as PCS will be used for something. I'm trying to figure out what exactly something covers. So I have two specific questions. The first question is about converting to LAB. The second question (which I haven't asked yet) has to do with Y. We will try to do what makes sense and helps us achieve what we need to achieve efficiently; while keeping what works well, working well. sRGB as PCS is linear gamma unbounded sRGB. I think it's reasonable to ask why a conversion to unbounded sRGB should be involved in a conversion from User_RGB to LAB. For the same reason XYZ is involved (or not, depending on how the CMM does it) in an ICC workflow. Existing code written with assumptions of sRGB, whether in GIMP and GEGL that we control or in XPM, GTK, GDK, or elsewhere that has sRGB assumed will continue to work. We take the existing architecture which is following general guidelines of assuming sRGB where none is specified. Assigning sRGB to images with no embedded profile is done because you can't display images in an ICC profile color-managed workflow until an ICC profile is assigned. How images with no embedded profile are handled is irrelevant to the question of why a conversion from User_RGB to LAB needs to involve unbounded sRGB. This is not about how images with no embedded profile are handled. sRGB derived 8bit (and to a lesser degree 16bit) formats are used for many other things than images with no embedded profile. These pixel formats are crucical for integrating with existing file formats and libraries; and we want these conversions to be as fast as possible - even if it might have an impact on the conversion speed for CIE Lab, though that does not have to be the case either. Choosing any PCS *but* linear sRGB would tend to make these important conversions slower. I can move on to my question about Y and unbounded sRGB. But I still don't understand why unbounded sRGB should be involved in a conversion from User_RGB to LAB. We will do what makes most sense and is neccesary when we get there, I suspect each RGB model with have an associated Y and YA model. Due to how the existing BablModels interact with components and vocabulary used to address them in babl; potential support for different TRCs is even vaguer; we'll know when we have more code. Maybe we have more code by the time of LGM, if not that would be an excellent place to elaborate; until then I prefer IRC. /pippin ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
