Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise
On 10/11/2014 08:52 PM, Jon Nordby wrote: Accurate UI colors is a desktop color management issue, entirely irrelevant to programming a color-managed image editor. The application needs to interface with the desktop (windowing system). GIMP uses GTK+ for that, which uses Cairo APIs for rendering - which basically assumes 8-bit sRGB. I suspect that on X11/Linux these assumptions go deeper in the graphics stack as well. Yes, it is not right, but such is the state of things. We will have to improve it step-by-step. Please correct me if I misunderstood what you are saying. I think you are saying: GIMP uses GTK+. GTK+ uses Cairo APIs for rendering to the screen. Cairo APIs assume 8-bit sRGB. Therefore in GTK+ applications such as GIMP, images must be converted to sRGB before they can be displayed on the screen. Is the above correct? Kind regards, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ 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 Sun, Oct 12, 2014 at 8:41 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/11/2014 08:52 PM, Jon Nordby wrote: Please correct me if I misunderstood what you are saying. I think you are saying: GIMP uses GTK+. GTK+ uses Cairo APIs for rendering to the screen. Cairo APIs assume 8-bit sRGB. Therefore in GTK+ applications such as GIMP, images must be converted to sRGB before they can be displayed on the screen. The same applies for most UI toolkits/APIs integrating with color management; the implementation that is unmanaged (or all!) content is to be presented in the framebuffer as sRGB and the desktop color management to compensate towards the monitor profile. Applications like GIMP, image viewers and similar - should be requesting that rectangular parts of the UI (image viewing areas and similar) be excepted from these conversions. Ideally we would be dealing differently with, no desktop CM and no display profile, no desktop CM (but have a display profile), desktop CMM without ability to opt out regions, and desktop CM with the ability to opt out regions. sRGB goes even deeper in cairo, where all API entry points where individual colors are specified for stroking/filling/gradients is specified as floating point sRGB (with the TRC as well). Buffers we get from cairo for doing things like text rendering are 8bit sRGBA with sRGB TRC and pre-multiplied alpha. An annoyance for GEGL is that cairo is limited to 8bpc in its rasterization of vectors (by using a clever implementation choice; which makes things fast - but tricky to adapt for 8bit.). Cairo is just one part of our eco-system which is following the guidelines of how to integrate with color management even if you do it badly; assume sRGB. Mostly everyone else tries to assume sRGB for consistency - when color management is considered hard; babl aims to make it easy and fast for GEGL to continue integrating with such code. /pippin (btw, babl/docs/roadmap.txt has been slightly updated). ___ 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/12/2014 09:01 AM, Simone Karin Lehmann wrote: Am 12.10.2014 um 12:46 schrieb Øyvind Kolås pip...@gimp.org: On Sun, Oct 12, 2014 at 8:41 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/11/2014 08:52 PM, Jon Nordby wrote: Please correct me if I misunderstood what you are saying. I think you are saying: GIMP uses GTK+. GTK+ uses Cairo APIs for rendering to the screen. Cairo APIs assume 8-bit sRGB. Therefore in GTK+ applications such as GIMP, images must be converted to sRGB before they can be displayed on the screen. Cairo is just one part of our eco-system which is following the guidelines of how to integrate with color management even if you do it badly; assume sRGB. so that means, that specifying a monitor profile in GIMP’s preferences other than sRGB will result in displaying wrong colors. Or am I wrong? I didn’t know that. On systems with builtin desktop CM, like OS X, wouldn’t it be better to disable the choice of a monitor profile in GIMP at all, as long as cairo assumes SRGB? In reality, it is not the case that images in GIMP must be converted to sRGB before they can be displayed on the screen. There is no such conversion in the entire babl/GEGL/GIMP code base. If there were, there would be precious little reason for letting the user set a monitor profile. I wasn't agreeing with what Jon Norby said. I was asking if I understood him correctly. Sorry for causing confusion! Best regards, 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 10/10/2014 07:49 PM, Øyvind Kolås wrote: On Sat, Oct 11, 2014 at 1:18 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: 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. The above statement is devoid of content. It serves to dismiss my specific questions about why you want to keep hard-coded sRGB XYZ and Y in a color-managed workflow. 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. Please provide a specific example of an actual CMM in an ICC profile workflow that doesn't use XYZ for converting between RGB working spaces. 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. A guideline for dealing with images that don't have embedded ICC profiles makes an appalling bad guideline for writing a color-managed image editor. 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. You falsely assume that 8-bit images are always sRGB images and that 16-bit integer images are probably sRGB images. These pixel formats are crucical for integrating with existing file formats and libraries; File formats that only work with sRGB images should not impact color-managed image editing. Advise the user to convert to sRGB. Accurate UI colors is a desktop color management issue, entirely irrelevant to programming a color-managed image editor. 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 into a PCS would tend to make these important conversions slower. Unbounded linear gamma sRGB is not a Profile Connection Space. Idiosyncratic redefinitions of well-established color management terms confuses people who don't understand ICC profile color management. Idiosyncratic redefinitions of well-established color management terms makes it difficult for people who do understand ICC profile color management to communicate with the babl/GEGL devs. 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. Is there any point in my demonstrating how convoluted and unworkable it will be to convert to unbounded sRGB whenever Y is involved? Because if there isn't, I don't want to waste my time. Maybe we have more code by the time of LGM, if not that would be an excellent place to elaborate; As I have indicated before, the invitation is very kind. But not everyone is able to drop other obligations and go to LGM. until then I prefer IRC. Twice I tried to discuss problems with unbounded sRGB on IRC. It was neither pleasant nor productive. For a moment it seemed that perhaps unbounded sRGB was going to be dropped and we could move on to generalizing the code to use Y and XYZ taken from the user's chosen RGB working space (http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html). However, given Pippin's latest explanations of how things will be done, I'm not sure there's any point in my continued involvement with GIMP development. Kindest regards, 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:41 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: As I have indicated before, the invitation is very kind. But not everyone is able to drop other obligations and go to LGM. until then I prefer IRC. Twice I tried to discuss problems with unbounded sRGB on IRC. It was neither pleasant nor productive. That is an apt summary of this email exhange as well, neither pleasant nor productive - sorry. At least on IRC there is the chance of correcting misunderstanding before they've been published as books. The only reason I have responded in this thread is that someone is wrong on the internet and was spreading fundamental misunderstandings about how babl works as well as how we intended it to be used in GEGL in the future, I wish that time had been spent implementing it instead. Many of the questions in your later e-mail have been responded to in other emails preceding your emails. I find it ironic that the architecture that you question is the architectural foundation that ICC also is using. With similar constraints and performance characteristics. /Øyvind ___ 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
Please provide a specific example of an actual CMM in an ICC profile workflow that doesn't use XYZ for converting between RGB working spaces. Please read simons post about matrix multiplication, in his camera example the data never exists as XYZ. You falsely assume that 8-bit images are always sRGB images and that 16-bit integer images are probably sRGB images. This is not being assumed, but it is a matter of fact that a lot of buffers are in these formats and we want to deal well with them. formats are crucical for integrating with existing file formats and libraries; File formats that only work with sRGB images should not impact color-managed image editing. Advise the user to convert to sRGB. The data needs to be loaded into a GeglBuffer with a BablFormat that uniqely describes the color content. For 8bit sRGB with babl that has traditionally been R'G'B' u8, in the roadmap in babl I even suggested that the buffers data is loaded into should be changed to be sRGB:R'G'B' u8 for clarity even if it will continue to mean the same as R'G'B' u8. And the chromaticity/working/target space should also be set to sRGB:R'G'B'. Unbounded linear gamma sRGB is not a Profile Connection Space. Idiosyncratic redefinitions of well-established color management terms confuses people who don't understand ICC profile color management. Idiosyncratic redefinitions of well-established color management terms makes it difficult for people who do understand ICC profile color management to communicate with the babl/GEGL devs. There are differences between the internal implementation of a system and the public API. Calling the bablRGB a PCS, since that is the role it has in the internal implementation was an attempt at making you understand the architecture, and I guessed you did understand since you have been using the term as well. I thought you would understand how XYZ fills the same role in ICC. It is never called either XYZ nor PCS in the babl code. It is better if we call it bablRGB than linear sRGB which is an oxymoron. Is there any point in my demonstrating how convoluted and unworkable it will be to convert to unbounded sRGB whenever Y is involved? Because if there isn't, I don't want to waste my time. For a moment it seemed that perhaps unbounded sRGB was going to be dropped and we could move on to generalizing the code to use Y and XYZ taken from the user's chosen RGB working space (http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html). I was hinting at how a given set of chromaticities wouldn't be affecting single babl formats but change interpretation of also other formats when given a prefix. You seem to challenge mention of sRGB to the extent that people have been championing linear workflows. While bablRGB will end up being an implementation detail that is an optimization. Babl will end up having _many_ different RGB spaces with associated grayscale format; at some point probably also associated non-linear spaces but that will have lower priority. Among these spaces will be a space called sRGB which behaves like the unprefixed formats. When we have these spaces. When we have these additional spaces - what I have suggested is that we then mark the operations which _are_ chromaticity dependent to operate in this space. I have also hinted at what we might want to do, or at least which things would be possible to do - including getting rid of all unprefixed formats, as well as the possibility that such things could be decided dynamically. There is a lot of code in GIMP that we intend to keep working as we move forward, the only way is by small incremental changes while keeping things working, changing as few assumptions as possible as move move along. /Ø ___ 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 11 October 2014 13:41, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/10/2014 07:49 PM, Øyvind Kolås wrote: 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. You falsely assume that 8-bit images are always sRGB images and that 16-bit integer images are probably sRGB images. No-one said always. sRGB is however the most common for 8-bit images. These pixel formats are crucical for integrating with existing file formats and libraries; File formats that only work with sRGB images should not impact color-managed image editing. Advise the user to convert to sRGB. Accurate UI colors is a desktop color management issue, entirely irrelevant to programming a color-managed image editor. The application needs to interface with the desktop (windowing system). GIMP uses GTK+ for that, which uses Cairo APIs for rendering - which basically assumes 8-bit sRGB. I suspect that on X11/Linux these assumptions go deeper in the graphics stack as well. Yes, it is not right, but such is the state of things. We will have to improve it step-by-step. -- Jon Nordby - www.jonnor.com ___ 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 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
Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise
On Wed, Oct 8, 2014 at 3:25 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/07/2014 08:23 PM, Øyvind Kolås wrote: The choice of something close to sRGB is to have efficient integration with libpng/libjpeg/gtk/v4l/ffmpeg (in addition to raster layers stored in sRGB). None of the above-listed libraries justify using a broken architecture that requires converting images to sRGB as PCS: You're not supposed to have to care about the PCS of a color management system. So I don't see how sRGB as PCS can broken, however enforcing linear sRGB, which is babls PCS, as a working space is something we have acknowledge to be broken in our color management architecture ever since we started talking about having support for target / chromaticity spaces. linear sRGB being used as the PCS should have no bearing on which other formats are supported. Since the theoretical - albeit due to optimizations not true - computational path is source format - PCS - destination format. Redefining what RGBA float means destroys the ability for the babl_model(RGBA) to act as a PCS at all, this is where RGBA double is the Celcius from the temperature analogy. It is perhaps unfortunate that the name of the PCS as exposed in the API is RGBA double/float.., and that the way the vocabulary has been defined that R'G'B' u8 the non-linear variant of the PCS directly is sRGB, but this has allowed the existing code to be consistently written and be certain that both color management, data types and opacity and are in the expected format (not only color-space) at all times. The type of BablFormat which most closely resembles what is desired to break free of sRGB with babl, is the babl-palette type formats which implement indexed mode in GIMP. Where the per palette BablModels fuel per palette BablFormats, providing a crude-non-dithering transparent conversion to and from RGBA permitting GEGL operations to work on this pixelformat transparently. The important part being the use of BablModel's with allocated data containing the palette. This despite the naming in the existing code leading you to think otherwise. The way palette formats are addressed would not be suitable for RGB profiles and for instance the use of them for linear processing on chromaticity dependent operations, hence the target:RGB float prefix I used in another e-mail for the format. On the public API of babl we then need an additional call to specify what target or camera2-chromaticities or some other named RGB format is. void babl_set_named_rgb_chromaticities ( Babl *babl, const char *name, double red_xyz[3], double blue_xyz[3], double green_xyz[3], int white_reference); At this stage; we would be able to control which formats are being used inside a GeglOperation, we could even add utility functions which derive the working-space for the current operation based on combinations of parameters from the op-author, and the environment (GIMP); permitting to implement various flows of data. And at some point start referring to sRGB with a different babl format. Making it possible to have concurrent views; in separate open documents is something made harder by naming the model in the format name; that the existing palette api solves. This can be catered for by permitting to create sub-Babl *babl instances with their own namespaces and formats - where all babl formats derived from the same root Babl * are possible to use with each other. /Ø ___ 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/07/2014 07:32 PM, Simone Karin Lehmann wrote: In babl/unbounded sRGB world your input space and output space differ in a very important aspect to the PCS space unbounded sRGB: unbounded sRGB can have values 0 or 1, input and output don't. Whereas in ICC / XYZ world input, output and PCS have well defined boundaries, namely 0 and 1 and well defined clipping, so everything is 0 = x = 1. Display-referred editing does require bounded RGB channel values and will require an incredible amount of hacks to work within the proposed sRGB as PCS architecture. This picture illustrates why gamma slider adjustments only make sense when done on display-referred channel values: http://ninedegreesbelow.com/gimpgit/gimp-srgb/data-container/red-car-after-levels.jpg The image on the left is a ProPhotoRGB image. The image in the middle was given a Levels gamma slider adjustment in the ProPhotoRGB color space. Results are normal and expected. The image on the right was converted to unbounded sRGB and given the same Levels gamma slider adjustment. Results are quite abnormal and unexpected. This article explains why gamma slider adjustments requires values that are bounded by the range 0.0 to 1.0: http://ninedegreesbelow.com/photography/unbounded-srgb-levels-gamma-slider.html#gamma-slider-mathematics Gamma slider adjustments should be added to the official list of editing operations that require a hack in order to work in sRGB as PCS. 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
I'm posting to the original thread. Pippin had started a new thread: https://mail.gnome.org/archives/gimp-developer-list/2014-October/msg00010.html On 10/07/2014 06:27 AM, Øyvind Kolås wrote: On Tue, Oct 7, 2014 at 1:57 AM, Simone Karin Lehmannsim...@lisanet.de wrote: BTW, I've noticed, that although Elle always gives equations or real world examples and images to prove her statements, you don't. So, I'd like to ask you for such a mathematical equation or real world example for your statements. Simone, thanks! for contributing to the discussion. Lets keep T out of the picture for the moment and focus on the others, the current state of babl. It is an environment where all temperatures are tagged with a unit, and the things operating on these values always check the units of incoming data, converts to their preferred unit; and pass data on annotated with which unit the temperature has. This is how babl works, all computations gets a unit associated with it. If it is computations that need to compare energy levels, K would be used. Doing this is what for instance mitigates http://www.4p8.com/eric.brasseur/gamma.html problems for scaling/blurring. Brasseur shows why scaling needs to be done on linearized RGB. The defining primaries are irrelevant. Nothing in Brasseur's demonstrations provide any justification for a forced conversion to sRGB as PCS. Babl provides the vocabulary and set of _defined_ units to be able deal with the multitude of temperature units/pixel formats in use by different algorithms and libraries. The original plan was to convert from whichever local units are being used to C, K or F the limited set of known format of babl at import time. So that we only would need to be able to transform other types of units like A,B or T into one of C, K or F at the beginning, and potentially convert back to some other format after having done computations on the data purely with C, K or F. Elle has pointed out that there are _some_ operations we are doing which actually depends on subjective celcius or T, how far from freezing towards water would be at a given temperature locally. Perhaps a thermostat where the sensitivity for the hysteresis is computed in T based on T yielding a value in T (or C/K doesn't matter). If we have stripped away the knowledge of where we are (what T really means) we are unable to do that computation. And at the moment we are using C here instead which is broken everywhere but at sealevel, where all C == T and linear sRGB == linear camera space. Then there is two approaches to solving this - both would give the same result, one is to add the ability to express for our thermostat op that it wants to receive/operate on/produce T instead of in C in addition to the already existing units. The other approach is to replace all usage of the unit C with T also for operations where C and T yield the same result (multiplication in the temperature case, addition in the color case). For many parts of GEGL doing this change is a way to preview what the result of doing the above approach would result in, other parts of GEGLs universe that use the unit C break if its data blindly will be treated as T, or it gets fed data which in T treating it as C. The set of pixel formats currently in babl are by implementationdefinition references to unchanging color spaces and representations - this is how babl is built with linear sRGB as it's connection space; and this is how ICC works with XYZ as it's connection space. A babl format like R'G'B'A u8 (actual sRGB 8bit) is an as immutable entity as an ICC profile is in ICC, one can consider babl formats light weight ICC profiles - and part of the foundations for being rigid with treatment of color in GEGL - which is why I compare refactoring sRGB out of babl to banning Celcius. Babl is being used in GEGL for all copies of pixel data, the copies gets the unit of both source and destination - when these match it is a plain copy (and in many cases - not even a copy). Thus chains of operations asking for the same unit - means no conversions in-between. If we had T in addition to C,K. then it could be possible to enforce more operations using T in the code which hosts the gegl ops. This somewhat tortured temperature conversion analogy reads like obfuscation trying to disguise itself as logical justification for a broken architecture. Personally I prefer writing documentation to writing email, but neither of those are pleasurable like writing code. You can however take my word for how babl and GEGL works - the code is a real world example, and when people do not understand how things work. A standard polemical ploy is to claim that someone doesn't understand how something works. I do understand how babl/GEGL works. There is a difference between understanding and agreeing. Any architecture that requires hacks to make basic editing operations work is broken. You can dress it up and make it sound like the hacks are
Re: [Gegl-developer] [Gimp-developer] Don't make an architectural mistake based on a groundless premise
On Tue, Oct 7, 2014 at 8:10 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: I'm posting to the original thread. Pippin had started a new thread: https://mail.gnome.org/archives/gimp-developer-list/2014- gmail started a new thread when I tired to change the alarmist subject. Brasseur shows why scaling needs to be done on linearized RGB. The defining primaries are irrelevant. Nothing in Brasseur's demonstrations provide any justification for a forced conversion to sRGB as PCS. They provide a justification for keeping track of the pixel format of the buffers, or enforcing that only linear spaces are permitted processing spaces. There in practice with regard to data loss, no forced conversion to sRGB. Any more than any use of ICC profiles would be a forced conversion to CIE XYZ. Babl provides the vocabulary and set of _defined_ units to be able deal with the multitude of temperature units/pixel formats in use by different algorithms and libraries. I do understand how babl/GEGL works. There is a difference between understanding and agreeing. To me it seems like you do not like the fact that the neutrally sounding babl_format name RGBA float is strictly defined in the architecture of both babl and GEGL, and see this as the thing in the architecture that should be changed to be *the*processing*space*. While I am arguing that this is existing functionality we need; and that reconfigurable primaries should be a separate addition instead of deleting both neccesary functionality and optimizations for common pixel formats. Any architecture that requires hacks to make basic editing operations work is broken. You can dress it up and make it sound like the hacks are just extending existing functionality. But in this case it's obvious that the reason for the hacks is to fix something that is only broken because of an architecture that intends to use sRGB as PCS. Since April I've tried to explain why Pippin's architecture is broken. I've used logic, examples, equations, pictures, long explanations, short explanations, and other people's explanations. I have not disagreed that the current architecture is broken, but what you call hacks is how GIMP-2.9 avoids gamma errors when blurring and scaling, regardless of wheter you are editing an 8bit image with its layers stored non-linearly or not; as well as other distinctions where different operations have the need to do processing with different pixel representations. /Ø ___ 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/07/2014 02:57 PM, Øyvind Kolås wrote: On Tue, Oct 7, 2014 at 8:10 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: To me it seems like you do not like the fact that the neutrally sounding babl_format name RGBA float is strictly defined in the architecture of both babl and GEGL, and see this as the thing in the architecture that should be changed to be *the*processing*space*. While I am arguing that this is existing functionality we need; and Code that enables the user to easily switch between linearized RGB and perceptually uniform RGB could be amazingly useful. Two points: 1. The code that switches between linear and perceptually uniform RGB is completely separable from your desire to force a conversion to sRGB as PCS. That forced conversion code isn't in the code base yet. 2. You want to use that linear/perceptual code to control for every single op whether the op should be performed on linearized or perceptually uniform RGB. You can make a case for certain ops like scaling. But even that case means that a teacher or writer can't use GIMP to demonstrate concepts. You could accomplish guiding users as to the right choices regarding linear vs perceptual by creating presets and allowing users the freedom to control their own editing decisions. You don't have to build fences around what people can do with their own RGB color data. Elle ___ 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 Tue, Oct 7, 2014 at 9:23 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: You could accomplish guiding users as to the right choices regarding linear vs perceptual by creating presets and allowing users the freedom to control their own editing decisions. You don't have to build fences around what people can do with their own RGB color data. One design maxim is “Make common things easy, rare things possible.”. If there is confidence that a default behavior covers more than 99.999% of uses, and there are intended ways of working around the limitations - I think it might be of the benefit of both the normal user and the deviating expert that likely also does not need to do it in more than a couple of % of cases. /Ø ___ 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/07/2014 03:36 PM, Øyvind Kolås wrote: On Tue, Oct 7, 2014 at 9:23 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: You could accomplish guiding users as to the right choices regarding linear vs perceptual by creating presets and allowing users the freedom to control their own editing decisions. You don't have to build fences around what people can do with their own RGB color data. One design maxim is “Make common things easy, rare things possible.”. If there is confidence that a default behavior covers more than 99.999% of uses, and there are intended ways of working around the limitations - I think it might be of the benefit of both the normal user and the deviating expert that likely also does not need to do it in more than a couple of % of cases. /Ø Who decides what's common and what's rare for an artist to want to do? The GIMP devs? Isn't that just a trifle presumptuous? These kinds of decisions belong with the users, not the devs. For instance, on what basis did you decide that drawing gradients should always and only be done using perceptually uniform RGB? Back before all the rendering software switched to a linearized workflow, a radiometrically correct gradient was the poster child of why editing should be done on linearized RGB data. Don't use code to micromanage what users can do their own data based on what devs think is common or correct. Make it easy for the user to choose between linear vs perceptual for ALL ops, and put in good presets. Elle ___ 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 Tue, Oct 7, 2014 at 10:20 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: Who decides what's common and what's rare for an artist to want to do? The GIMP devs? Isn't that just a trifle presumptuous? These kinds of decisions belong with the users, not the devs. I'm sorry but you've crossed the line from being a user to a dev. Despite that your input has helped form future priorities. Don't use code to micromanage what users can do their own data based on what devs think is common or correct. Make it easy for the user to choose between linear vs perceptual for ALL ops, and put in good presets. Nothing in that quote wants to limit what a user can do; it rather act as a guide when designing interfaces (APIs/GUIs). As a metric to evaluate choices that provide the user (application or human) guidance/constraints making it simple to do the right thing. Rare things that should be possible; preferablly not to difficult either - are choosing which component(s) to gaussian-blur in linear RGB, CIE Lab and possibly other color spaces. That is something which is possible to achieve globally for all operations - without adding the code to do so in each operation. Thus on the GEGL level it would probably be harder to directly do it; than for abstractions possible to add for the user of a GUI like GIMP. /Ø ___ 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/05/2014 12:49 PM, Øyvind Kolås wrote: sure GIMP/GEGL is not there yet, but for a GIMP 2.10 release it is good enough. (2.10s stated goal is being to be able to do what 2.8 does; but with GEGL inside - the higher bitdepths and such are bonus.). The time table for implementing new features is irrelevant to why BABL/GEGL/GIMP intends to use a broken architecture. Most current named BablFormats are immutable - in the same ways ICC profiles are treated as immutable. Changing the meaning of R'G'B'A u8 or Y'CbCr u8 and similar will break color management for operations providing integration with various image loaders/video codecs/webcam/GUI that already exist. Whether or not device-specific code makes sense in a color-managed editing application isn't relevant to why BABL/GEGL/GIMP intends to use a broken architecture. GEGL strives to bring linear light editing all the places it makes sense; this will hopefully be a better experience than 8bpc sRGB. Linear RGB data manipulation does require high bit depth image editing. But linear RGB data manipulation is not facilitated by an architecture that converts the user's color data to sRGB as PCS. Precisely *because* the primaries used to encode RGB data do make a difference in the results of editing operations, the user must choose the appropriate primaries for the task at hand. Two justifications have been given in support of the BABL/GEGL/GIMP architectural requirement that images be converted to sRGB as PCS: Justification 1: A forced conversion to sRGB as PCS meets a desirable interaction goal that sliders produce the same results when operating on the same XYZ colors. This desirable interaction goal betrays a failure to understand the nature of RGB image editing. The interactions of real world light and colors are only partially preserved in RGB data. So necessarily RGB data is color data that is encoded using RGB primaries that are appropriate to the editing task at hand. Hacking the broken architecture to fix specific broken editing operations undermines the stated goal that sliders should produce the same results when operating on the same XYZ colors. So this justification has already fallen apart. Justification 2: A forced conversion to sRGB as PCS makes possible fast path conversions from sRGB as PCS to XYZ, LAB, YCbCr, etc. A fast path conversion that depends on mangling the artist's data by converting it to sRGB as PCS is just a fast way to get to a bad results out of a broken architecture. Any processing advantage provided by using hard-coded sRGB parameters will be swamped by the processing load imposed by hacks that convert from sRGB as PCS, to the artist-chosen RGB primaries, and back again to sRGB as PCS. The fast path conversion argument also has fallen apart. With what has been proposed as a solution for ops that need to use a target/working RGB space is that the operation would ask for a special symbolic babl format or similar; and GEGL/babl does the rest behind the scenes. You've conceded that your architecture is broken to the point where you must hack in fixes for multiply. That's the first of many such hacks to come: Retrieving the artist's original channel data? Hack. Display-referred editing using the negative channel values that will be produced by a forced conversion to sRGB as PCS? Hack. Using the Levels gamma sliders? Use the Red/Green/Blue Levels input/output sliders? Hack, hack. RGB data doesn't 100% capture the way light and color behave in the real world. Rather RGB data necessarily is encoded using different primaries for facilitating different editing goals. Think about the implications of Rick Sayre's comment on non-orthogonal transforms to XYZ: https://groups.google.com/forum/?_escaped_fragment_=msg/academyaces/9b4VuqPcOHQ/Hg8c9V6flOYJ#!msg/academyaces/9b4VuqPcOHQ/Hg8c9V6flOYJ What Sayre says cuts to the heart of why an architecture that requires a conversion to sRGB as PCS is broken and can't be fixed. With respect, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ 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 Mon, Oct 6, 2014 at 6:57 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/05/2014 12:49 PM, Øyvind Kolås wrote: You've conceded that your architecture is broken to the point where you must hack in fixes for multiply. That's the first of many such hacks to come: This is not the first such aspect of how pixel representation affects computation that operation developers must take into consideration for their operation (in which BablFormats they request). It is the same type of choice already existing with regard to linear/perceptual as well as pre-multiplied alpha or not, and should be dealt with in a similar way. I am going to try to describe the architecture of babl without mentioning color.. instead of doing color computations we will pretend to be doing temperature computations. Exactly how GEGL uses babl is not relevant for the discussion. Unfortunately enough - humans have many temperature scales, and they use different temperature scales for different purposes. To facilitate cooperation between scientists, engineers and others we have developed a convention of tagging numbers we use to refer to temperature with a unit qualifier, like thus: 37.7°C 100°F 310.9°K. That way, given a set of conversions formulas, it is possible to operate in the preferred unit. Some chemists need to do computations based on temperature relative to the _local_ boiling point of water. To facilitate this one can introduce a convention of local temperature; which could be 0.0 T at 0.0 C and 100.0 T when water boils at current altitude, that would might make these computations easier, this unit is the same as C some places on earth and different elsewhere. Being unchangeable units - like - C, K and F is the purpose for BablFormats existing, and the unit T is the proposed extension of our vocabulary for these recipies/chemistry formulas/whatisit that works differently at different heights. I understand you to propose using T everywhere; (or a set of new Ts; because in our case the differences between C and F are more important than in the real world, and mean alpha/linearity/precision). Or that interfaces at the edges of our system that are using C and F and working well with it should be discarded or reimplemented - because C and F will no longer mean what they meant when these systems were established. /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 Sun, Oct 5, 2014 at 5:16 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/04/2014 11:59 AM, Øyvind Kolås wrote: On Sat, Oct 4, 2014 at 2:46 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: Based on the groundless premise that editing operations should produce the same results when performed on the same colorimetric colors, .. No; I'm not sure what you are saying No to. Here are excerpts from previous posts that you've made talking about the matter: http://article.gmane.org/gmane.comp.video.gimp.devel/19916 I am saying no to it being groundless premise, It is a desirable interaction goal. It is the same desire that makes sure that things like image resampling and blurring should always happen with _associcated_alpha_ and linear TRC. Instead of letting the user configure a working space where scaling or blurring behaves in ways not resembling physics. The architectural implementation of that desire is tagging of all buffers explicitly with their color space, associated alpha state, data type etc. Each operation tells GEGL both what type of data it wants to read as well as what type of data it wants to write in the prepare stage for the op, which happens before any data is being processed. With what has been proposed as a solution for ops that need to use a target/working RGB space is that the operation would ask for a special symbolic babl format or similar; and GEGL/babl does the rest behind the scenes. Most current named BablFormats are immutable - in the same ways ICC profiles are treated as immutable. Changing the meaning of R'G'B'A u8 or Y'CbCr u8 and similar will break color management for operations providing integration with various image loaders/video codecs/webcam/GUI that already exist. My stance is that the sliders on an operations should be predictable and always do the same thing for the colorimetrically absolute same color (relative colorimetric likely makes more sense; or perhaps just colorimetric - though thats a detail). http://markmail.org/message/n6ttql3ajtjbe767 GEGLs image processing is intended to all operate in device independent color spaces, no matter which camera you took a picture with gaussian blurs, color adjustments etc, should behave the same. No; but same parameters for same input colors producing same results is considered desirable behavior. Predictable interfaces are nice interfaces. In a properly color managed image editor, the way for a user to get predictable editing results is to set up a consistent workflow based on the RGB working spaces that the user finds appropriate for the tasks at hand. I don't think a medium high-end user of GIMP should _need_ to be concerned about working spaces; we should strive to make a system that behaves well by default. Until GIMP is properly color managed, the only users who might find GIMP editing results predictable are users who already only edit their images in the sRGB color space. GEGL strives to bring linear light editing all the places it makes sense; this will hopefully be a better experience than 8bpc sRGB. properly color managed is not one single thing, sure GIMP/GEGL is not there yet, but for a GIMP 2.10 release it is good enough. (2.10s stated goal is being to be able to do what 2.8 does; but with GEGL inside - the higher bitdepths and such are bonus.). One could also claim that a system that converts everything to a single working space and passes pixels untagged through is weaker color managed than the plan that has been outlined for GEGL. You've already been invited, and I invite you again to spend some time with the rest of the GIMP team and others with interest in color, photography and graphics in Toronto, end of april next year for the next Libre Graphics Meeting. /Ø ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
