Re: [Gimp-developer] [Gegl-developer] Don't make an architectural mistake based on a groundless premise
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? Simone ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] Don't make an architectural mistake based on a groundless premise
On 10/12/2014 06:46 AM, Øyvind Kolås wrote: 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. Exactly. People with wide gamut monitors would be pretty upset if their images were squeezed through sRGB before being sent to the screen. Converting to sRGB before converting to the monitor's profile would limit what is seen on the screen to the *overlap* between the sRGB color gamut and the LCD monitor profile's color gamut. Many LCDs, even many widegamut LCDs, can't display all of sRGB. See Can the entire sRGB color gamut be displayed on today's LCD monitors? http://ninedegreesbelow.com/photography/srgb-bad-working-space-profile.html Elle ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-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 ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-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 ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-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. /Ø ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-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 ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-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. /Ø ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-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 ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-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. /Ø ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
