Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL
On 11/20/2014 06:53 AM, Elle Stone wrote: On 11/20/2014 04:34 AM, Elle Stone wrote: Unbounded sRGB is NOT HDR scene-referred. If you guys would actually do a little reading and try to understand what you are talking about, this whole conversation could have been over a long time ago. This came out a great deal more snippy than I intended it to be and I apologize. Elle Again, my apologies for being snippy. Hopefully I haven't bored you all to tears trying to explain problems with editing in the unbounded sRGB color space. For personal reasons (time constraints), I'm at least temporarily unsubscribing from various mailing lists, including this one. GIMP is amazing and I feel very honored that you all have allowed me to work with you on GIMP color management. 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] [Gimp-user] Time to fork BABL and GEGL
On Fri, Nov 21, 2014 at 5:05 PM, Elle Stone wrote: For personal reasons (time constraints), I'm at least temporarily unsubscribing from various mailing lists, including this one. GIMP is amazing and I feel very honored that you all have allowed me to work with you on GIMP color management. Please keep the invitation to LGM2015 in mind, though :) Alex ___ 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] [Gimp-user] Time to fork BABL and GEGL
On Fri, Nov 21, 2014 at 2:05 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: Again, my apologies for being snippy. Hopefully I haven't bored you all to tears trying to explain problems with editing in the unbounded sRGB color space. For personal reasons (time constraints), I'm at least temporarily unsubscribing from various mailing lists, including this one. GIMP is amazing and I feel very honored that you all have allowed me to work with you on GIMP color management. Based on some of the last few exchanges it seems like you are in almost complete agreement with the babl part of the babl roadmap, and only disagree on some of the direction GEGL should be taking once the babl roadmap has been implemented, and the results of added capabilities to babl start propagating through GEGL and GIMP. We've spent much energy discussing the future instead of making it happen. I hope you've got the energy to continue help us in more productive ways once we've got more of those plans in place. /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] [Gimp-user] Time to fork BABL and GEGL
On 11/21/2014 09:43 AM, Øyvind Kolås wrote: On Fri, Nov 21, 2014 at 2:05 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: Again, my apologies for being snippy. Hopefully I haven't bored you all to tears trying to explain problems with editing in the unbounded sRGB color space. For personal reasons (time constraints), I'm at least temporarily unsubscribing from various mailing lists, including this one. GIMP is amazing and I feel very honored that you all have allowed me to work with you on GIMP color management. Based on some of the last few exchanges it seems like you are in almost complete agreement with the babl part of the babl roadmap, and only disagree on some of the direction GEGL should be taking once the babl roadmap has been implemented, and the results of added capabilities to babl start propagating through GEGL and GIMP. We've spent much energy discussing the future instead of making it happen. I hope you've got the energy to continue help us in more productive ways once we've got more of those plans in place. /pippin Once things are in place, I would love to continue working towards improving GIMP color management. Hopefully by the time spring rolls around those time constraints I mentioned might have loosened up a bit. As to whether or how much the discussions in the last month have been productive, well, that's a point on which there would be probably be considerable disagreement. Best regards, 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] [Gimp-user] Time to fork BABL and GEGL
First, in spite of the intensity of this discussion, I appreciate it. Thanks to all contributors for your efforts to make it clear. A simple question, which may have been answered already and I may have missed (if so, a pointer will do). What is the advantage of using unbounded sRGB instead of user RGB, *presuming* user RGB is not sRGB, and ignoring assumptions any outside software may be making about colorspace? I'm having a great deal of difficulty understanding why one would choose to use a pipeline which by definition is going to require conversions when the user is using anything except sRGB. Both from a potential loss / distortion of data perspective and from a simple performance perspective. As people become more comfortable with different colorspaces, and as they become more comfortable dealing with individual color channels, more and more work will be done using them. Particularly as device prices keep coming down and capabilities going up. I can understand how / why one might wish to work in unbounded sRGB as an interim step towards a goal of working in user RGB *if* doing so gets significant results considerably faster than would otherwise be possible; and if doing so does not result in a lot of effort which will be discarded at the next step. But I have difficulty understanding why it would be the final design goal. The final design goal should be to get it right. If one were starting from scratch, would one choose to use unbounded sRGB? I've personally made this mistake once and it resulted in the death of a good product. I also worked for a company which made this mistake and it cost them a year of (re)development when technology caught up with their assumptions. Gary ___ 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] [Gimp-user] Time to fork BABL and GEGL
On 11/19/2014 06:13 PM, Simon Budig wrote: Hi Elle. Elle Stone (ellest...@ninedegreesbelow.com) wrote: In case you don't understand this, HDR sRGB data is still *bounded* by the sRGB xy chromaticities. It's only unbounded along the Y axis. There are NO negative channel values in HDR sRGB data unless the *user* chooses to do something odd, in which case the *user* is responsible for fixing the results. I think you are missing that unbounded also allows *negative* R, G or B coordinates. That makes the colors imaginary in the sRGB color space, but it still is possible to convert them to all other RGB color spaces. No I am not missing anything. When you convert from a wider gamut color space to unbounded sRGB, the out of gamut colors are expressed using at least one and perhaps two negative channel values. When you edit HDR scene-referred images, the RGB channel values can be greater than 1.0. They never go negative unless the user chooses to do something odd like subtract red from black. HDR scene-referred data is bounded by the xy coordinates of the RGB working space chromaticities. Unbounded sRGB isn't bounded by anything. See Models for image editing: Display-referred and scene-referred http://ninedegreesbelow.com/photography/display-referred-scene-referred.html Unbounded sRGB can express all the colors XYZ can express. Of course it can. Transformations from userRGB to sRGB to userRGB are lossless. Of course they are lossless, to the limits of the precision used to do the conversion. Please read the article I just linked to above. And then read this article: LCMS2 Unbounded ICC Profile Conversions http://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html There is a great big huge difference between HDR scene-referred and unbounded sRGB that none of you seem to understand. But you really do need to understand the difference between scene-referred and unbounded sRGB. That difference really does matter. 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] [Gimp-user] Time to fork BABL and GEGL
On 11/19/2014 06:20 PM, Jon Nordby wrote: On 19 November 2014 23:57, Elle Stone ellest...@ninedegreesbelow.com mailto:ellest...@ninedegreesbelow.com wrote: In case you don't understand this, HDR sRGB data is still *bounded* by the sRGB xy chromaticities. It's only unbounded along the Y axis. There are NO negative channel values in HDR sRGB data unless the *user* chooses to do something odd, in which case the *user* is responsible for fixing the results. Doesn't this contradict with the following, from your recent mail? (I don't know what particularly is the definition of HDR used) We've also agreed that for chromaticity independent RGB editing operations (CI ops, for short), by definition the same colors (as located in the XYZ reference color space) are obtained regardless of the chromaticities that are used to encode the data. If you choose to do CI ops using sRGB chromaticities instead of UserRGB chromaticities, and you make a mistake about whether the op really is a CI op instead of the CD op, editing results are wrong. This is the crux of why you shouldn't do something so incredibly unnecessary as to convert UserRGB to unbounded sRGB to do the editing op. Unbounded sRGB is NOT HDR scene-referred. If you guys would actually do a little reading and try to understand what you are talking about, this whole conversation could have been over a long time ago. Read these two articles. Then read them again. http://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html http://ninedegreesbelow.com/photography/display-referred-scene-referred.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] [Gimp-user] Time to fork BABL and GEGL
On 11/19/2014 10:47 PM, Simon Budig wrote: Since a few questions have popped up on IRC and it really is a weird concept to grasp I thought I'd expand a bit on the color math that is being discussed here. Sorry it is so long, I hope it is somewhat entertaining though :) Most of what you said is exactly right. When we talk about unbounded sRGB in the Gegl/Babl context we do away with this restrictions: We allow absurdly high intensities way beyond the physical capabilities of a specific light source. And we allow for negative intensities. Yes, negative intensities are 100% absurd and wrong when you think about them in terms of implementing computer monitors. However, we don't need to model a real computer monitor. We are not bound to the laws of physics when dealing with pixels in memory. Allowing negative coefficients for the RGB values makes it possible to escape the dreaded gamut triangle. In fact this makes the unbounded sRGB color space as expressive as AdobeRGB, ProPhotoRGB and XYZ. To reiterate: Every XYZ coordinate can be represented in the terms of sRGB primaries. Above is exactly true. You can DISPLAY and STORE all colors using the sRGB chromaticities. What you can't do is EDIT using sRGB as a universal RGB working space. I'm not going to rehearse all the problems that are caused by trying to force EDITING to be done using the sRGB chromaticities. See this article and follow the links and keep reading because I'm getting tired of repeating myself: Using unbounded sRGB as a universal color space for image editing is a really bad idea http://ninedegreesbelow.com/photography/unbounded-srgb-as-universal-working-space.html You can DISPLAY and STORE all colors using sRGB chromaticities. But EDITING is a different matter. For example: The Green Primary of the AdobeRGB 1998 colorspace is - specified with its own primaries - at the coordinates (0, 1, 0) (which is somewhat obvious). Using e.g. the slightly convoluted color calculator at http://www.brucelindbloom.com/ we can convert this to XYZ = ( 0.185554, 0.627349, 0.070687 ). (Note that there is a normalization involved here: AdobeRGB (1, 1, 1) is converted to an XYZ value scaled to Y = 1.0. We also get the xy coordinate of the green point here: xy = (0.21, 0.71) ) This in turn translated into unbounded linear sRGB yields: sRGB = (-0.398283, 1.0, -0.042939) And thats it. The color represented by (0,1,0) in AdobeRGB is equivalent to the color represented by (-0.40, 1.0, -0.04) in unbounded linear sRGB (bablRGB). Yes, there are negative coefficients, no, we don't need to worry about them. And we can use the same math in reverse to reconstruct the AdobeRGB value to use it as userRGB for our multiplication operation. We end up at RGB=(0,1,0) where we started. Note that there is nothing special about the sRGB that makes this possible. The same math would work with any other primaries, as long as they don't form a line in the xy diagram (i.e. they need to be linearily independant in XYZ). However, for this to work we absolutely must not clamp negative values to zero. As soon as we do that huge errors will be introduced. Yes, all of the above is true. I've said the same myself. In fact I've written articles on the topic. Again, EDITING is different from STORING and DISPLAYING. 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] [Gimp-user] Time to fork BABL and GEGL
On Thu, Nov 20, 2014 at 10:42 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 11/19/2014 10:47 PM, Simon Budig wrote: Since a few questions have popped up on IRC and it really is a weird concept to grasp I thought I'd expand a bit on the color math that is being discussed here. Sorry it is so long, I hope it is somewhat entertaining though :) Most of what you said is exactly right. To reiterate: Every XYZ coordinate can be represented in the terms of sRGB primaries. Above is exactly true. You can DISPLAY and STORE all colors using the sRGB chromaticities. What you can't do is EDIT using sRGB as a universal RGB working space. I'm not going to rehearse all the problems that are caused by trying to force EDITING to be done using the sRGB chromaticities. You can DISPLAY and STORE all colors using sRGB chromaticities. But EDITING is a different matter. Yes, all of the above is true. I've said the same myself. In fact I've written articles on the topic. Again, EDITING is different from STORING and DISPLAYING. Then why have you argued against everyone trying to explain this to you? -- Mikael Magnusson ___ 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] [Gimp-user] Time to fork BABL and GEGL
On 11/20/2014 05:13 AM, Mikael Magnusson wrote: On Thu, Nov 20, 2014 at 10:42 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 11/19/2014 10:47 PM, Simon Budig wrote: Since a few questions have popped up on IRC and it really is a weird concept to grasp I thought I'd expand a bit on the color math that is being discussed here. Sorry it is so long, I hope it is somewhat entertaining though :) Most of what you said is exactly right. To reiterate: Every XYZ coordinate can be represented in the terms of sRGB primaries. Above is exactly true. You can DISPLAY and STORE all colors using the sRGB chromaticities. What you can't do is EDIT using sRGB as a universal RGB working space. I'm not going to rehearse all the problems that are caused by trying to force EDITING to be done using the sRGB chromaticities. You can DISPLAY and STORE all colors using sRGB chromaticities. But EDITING is a different matter. Yes, all of the above is true. I've said the same myself. In fact I've written articles on the topic. Again, EDITING is different from STORING and DISPLAYING. Then why have you argued against everyone trying to explain this to you? Umm, what are you talking about? I'm not being sarcastic. I don't understand what you are trying to say. Do you think I am arguing in favor of unbounded sRGB image editing? What is it that you think I am missing? 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] [Gimp-user] Time to fork BABL and GEGL
On Thu, Nov 20, 2014 at 9:42 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: Using unbounded sRGB as a universal color space for image editing is a really bad idea There has been no plan for using unbounded sRGB as a universal color space in GEGL, not since the introduction of a target-space in April in the plans, these days called userRGB in the discussion. The roadmap is a plan for how to achieve these things as smoothly and with as little unexpected work as possible. If someone has been working on the babl part of that roadmap and have a version of babl with the planned capabilities (I don't). It would be possible to use that new babl with current GEGL without the behavior of GEGL changing. Then the GEGL side of the work will start, first moving defintely chromaticity dependent ops to userRGB, as well as some chromaticity independent ops, it is also likely that *some* operations/tasks continue using the PCS, which is also a linear RGB, the user of an application like GIMP would neither know or be affected – this is what we are stating will be an implementation detail. The roadmap as planned is a roadmap for babl, which includes some bits about changes in GEGL. The changes in GIMP, following things changing in babl and GEGL are, like the details of decisions we will be making in the GEGL stages, out of scope for planning how we add the needed capabilities to babl. /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] [Gimp-user] Time to fork BABL and GEGL
On 11/20/2014 05:17 AM, Øyvind Kolås wrote: On Thu, Nov 20, 2014 at 9:42 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: Using unbounded sRGB as a universal color space for image editing is a really bad idea There has been no plan for using unbounded sRGB as a universal color space in GEGL, not since the introduction of a target-space in April in the plans, these days called userRGB in the discussion. Yes, you are correct. In April we did agree that some editing operations might require being done in the target space, now called UserRGB. Thankfully we have moved on to the question of whether *any* UserRGB editing ops should be done using sRGB chromaticities. My article Using unbounded sRGB as a universal color space for image editing is a really bad idea isn't aimed specifically at GIMP. It's aimed at the notion of using a universal RGB working space. Other software developers besides babl/GEGL/GIMP have contemplated using unbounded sRGB for all editing. Some of the VFX people contemplated using ACES as a universal RGB working space. One look at multiplication and they gave that up. Lightroom uses ProPhotoRGB as a universal RGB working space. Some of the free/libre raw processors also use ProPhotoRGB as a universal RGB working space. Adobe would like everyone to think ProPhotoRGB is the ultimate RGB working space for interpolated camera raw files, but that's just not true. The roadmap is a plan for how to achieve these things as smoothly and with as little unexpected work as possible. If someone has been working on the babl part of that roadmap and have a version of babl with the planned capabilities (I don't). It would be possible to use that new babl with current GEGL without the behavior of GEGL changing. Then the GEGL side of the work will start, first moving defintely chromaticity dependent ops to userRGB, as well as some chromaticity independent ops, If babl formats for UserRGB are defined and made available to GEGL to use, then there is no rational reason for *any* GEGL/GIMP RGB editing operations to use sRGB chromaticities instead of UserRGB chromaticities. Just do a wholesale find and replace and be done with it. That way there are no unnecessary transforms to the sRGB chromaticities and there's no chance that the developers will decide operation X is chromaticity independent when really it's chromaticity dependent. The only complication with find and replace is the handful of can't be generalized editing operations, plus whatever device-based code you want to keep around. All such color-space-specific code needs to be labelled in the GIMP UI so the user doesn't use the op without understanding what they are getting into. Right now GIMP users can merrily use NTSC-based and sRGB device-based editing operations regardless of what color space they are really in, with no UI notification. I tried to locate all such code to help make fixing the problem of color-space-specific code easier: http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html it is also likely that *some* operations/tasks continue using the PCS, which is also a linear RGB, If you want to convert from UserRGB to XYZ to unbounded sRGB to XYZ to LAB, etc, because for whatever reason it might be more efficient to concantenate and store a UserRGB to sRGB transform than to generalize the code that converts from UserRGB to XYZ and on LAB, that's not going to cause any problems. But the distinction between device-based sRGB and ICC profile illuminant-adapted sRGB does need to be reflected in the babl code. the user of an application like GIMP would neither know or be affected – this is what we are stating will be an implementation detail. The user will be affected if the devs mistakenly decide that a chromaticity dependent RGB op really is a chromaticity independent RGB op. And the devs will need to add new code that deals with complications caused by extraneous and unnecessary conversions to unbounded sRGB and back. There's no reason to saddle the devs with trying to make this kind of coding distinction, when the CI and CD ops can both be done using UserRGB chromaticities. The roadmap as planned is a roadmap for babl, which includes some bits about changes in GEGL. The changes in GIMP, following things changing in babl and GEGL are, like the details of decisions we will be making in the GEGL stages, out of scope for planning how we add the needed capabilities to babl. The babl functions that use Y to paint on a mask and to make grayscale masks really do need to be generalized to use UserRGB Y, or else there needs to be side by side functions. Otherwise GIMP layer masks will only be correct for sRGB images. /pippin 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:
Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL
On 11/20/2014 04:34 AM, Elle Stone wrote: Unbounded sRGB is NOT HDR scene-referred. If you guys would actually do a little reading and try to understand what you are talking about, this whole conversation could have been over a long time ago. This came out a great deal more snippy than I intended it to be and I apologize. 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] [Gimp-user] Time to fork BABL and GEGL
Simon Budig wrote: We need to make sure two things: a) upon import of an image the userRGB-format-descriptor within the images context needs to be set up to refer to the chromaticies of the source image. b) whenever a chromaticity dependent operation works on the images data the infrastructure needs to make sure that the pixel data gets fed into the operation using the chromaticies of the source image. We'll do this by having the operation request the image data in the userRGB format from the images context. With regard to b), it is conceivable that the chromaticity dependent operation itself could be transformed to take into account the userRGB format description, such that the resulting transformed operation could be applied directly to the unbounded RGB data. In cases where doing so is advantageous, the implementer should have that option. The requirement should only be thatthe infrastructure produce the same result as if the operation were working in the userRGB colorspace. ___ 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 a) upon import of an image the userRGB-format-descriptor within the images context needs to be set up to refer to the chromaticies of the source image. b) whenever a chromaticity dependent operation works on the images data the infrastructure needs to make sure that the pixel data gets fed into the operation using the chromaticies of the source image. We'll do this by having the operation request the image data in the userRGB format from the images context. ___ 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 ___ 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] [Gimp-user] Time to fork BABL and GEGL
On 11/18/2014 03:05 AM, Michael Henning wrote Now, please explain this to me with a straight answer: Why is it so insanely important to know what color space an operation happens in, in a situation where it*by definition* does not matter, that you are willing to waste hours of your time and hours of developers' time arguing about it? As usual I've written too many words and yes I've covered some of the points before. But this time there's an outline and an organized presentation. We've agreed that for chromaticity dependent RGB editing operations (CD ops, for short), editing in UserRGB versus unbounded sRGB will produce different results (except in the limiting case where UserRGB is sRGB), and so the correct thing to do is perform the edits using UserRGB chromaticities. We've also agreed that for chromaticity independent RGB editing operations (CI ops, for short), by definition the same colors (as located in the XYZ reference color space) are obtained regardless of the chromaticities that are used to encode the data. Nonetheless CI ops should be done using UserRGB chromaticities. Summary: Performing CI ops using sRGB chromaticities requires a whole lot of otherwise unnecessary implementation details and also requires identifying which operations really are CI. Proposed CIELAB workarounds won't work. Outline: 1. Editing in alternate versions of GIMP that do and don't convert to unbounded sRGB for CI ops 2. Precision and CPU considerations 3. The onerous task of deciding which ops are CI ops 4. Dealing with Histograms, FG/BG Colors, Color Picker, and Gradients 5. CIELAB as a replacement for displaying and picking RGB colors: not a good idea 6. Replacing chromaticity dependent RGB ops with CIELAB ops: not a good idea 7. Moving past unbounded sRGB to HDR scene-referred editing 1. Editing in alternate versions of GIMP that do and don't convert to unbounded sRGB for CI ops: Assume Person A is using a version of GIMP that uses UserRGB for all ops. Person A performs a CI op involving one or more image layers, followed by a CD op. Assume Person B is using a version of GIMP that converts the image layer(s) to unbounded sRGB for all CI ops. Person B performs the same CI op as Person A, and then the image layer(s) are converted back to UserRGB for the CD op. GIMP is a display-referred image editor and so all editing operations are presumed to be working on RGB channel values that are clipped to fit within the UserRGB channel data range 0.0 to 1.0. When shooting raw, it's incredibly easy to record colors that exceed the very small bounded sRGB color gamut. Accordingly, converting the image from UserRGB to unbounded sRGB for CI ops will require unclipping all the CI ops. And upon conversion back to UserRGB, the unbounded sRGB colors will need to be clipped to the UserRGB color gamut. If the CI op in question is a layer blend mode, then in reality to get the same UserRGB channel values as Person A, Person B will need to make a New from Visible layer from the blended layers, and then convert back to UserRGB. Of course babl/GEGL/GIMP code can be added that makes this New from Visible layer be created automatically. And so you can consider this new code to be an implementation detail. But now Person B is forced to deal with an additional layer in the stack that Person A doesn't have to deal with. But presumably a way can be coded up to make this New from Visible layer invisible to the user. Throw a mask on the top blended layer. Now every time Person B modifies the mask, a new conversion to unbounded sRGB and a new New from Visible layer will need to be made before the layers are converted back to UserRGB. Person A, of course, doesn't need a New from Visible layer. If UserRGB is used for both CD and CI ops, there is no need to worry dealing with CI layer blend modes or unclipping CI ops and then clipping the unbounded results to fit within the UserRGB color gamut. 2. Precision and CPU considerations: If CI ops are performed using sRGB chromaticities and CD ops are performed using UserRGB chromaticities, then every time a CI op is followed by a CD op, or vice versa, a conversion between UserRGB and sRGB will be required. Let's make the assumption that babl/GEGL/GIMP throughput precision is equal to theoretical floating point precision (does anyone really think this is the case?). Even so, CPU time is required to perform conversions between UserRGB and unbounded sRGB. Pippin has been working very hard to shave seconds off of various editing operations. It seems at best questionable to code up CPU-consuming conversions between UserRGB and unbounded sRGB only to get the same colors that UserRGB would have produced. So it's better to use UserRGB for both CD and CI ops. 3. The onerous task of deciding which ops are CI ops: When performed on linearized RGB data, the list of chromaticity dependent editing operations is long,
Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL
On Wed, Nov 19, 2014 at 7:31 PM, Elle Stone ellest...@ninedegreesbelow.com wrote a lot of text that has been trimmed away... I am only going to reply to the issues you seem to have with color image processing algorithms operating in CIE Lab. My general stance is that if at all possible, algorithms should operate on linear RGB data. Some algorithms do however not work well on linear data and expect more of a perceptually uniform color space to give satisfying results. Many of the ops fitting this categorization - both in GIMP and GEGL have been using sRGB; even if academic papers introducing/describing the algorithms specifies that processing is to be done in CIE Lab. Such operations might be using division, multiplication, power functions and other chromaticity dependent arithmetic building blocks. It is for these type of operations using CIE Lab should be evaluated rather than UserRGB – just like CIE Lab can be considered for new color image processing ops that rely on more perceptual uniformity than linear RGBs provide. /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] [Gimp-user] Time to fork BABL and GEGL
On 11/19/2014 03:27 PM, Øyvind Kolås wrote: On Wed, Nov 19, 2014 at 7:31 PM, Elle Stone ellest...@ninedegreesbelow.com wrote a lot of text that has been trimmed away... Hmm. I worked hard to explain why even for chomaticitiy independent editing operations the RGB data shouldn't be converted to unbounded sRGB. You dismissed my efforts with Elle Stone wrote a lot of text that has been trimmed away... 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] [Gimp-user] Time to fork BABL and GEGL
On Wed, Nov 19, 2014 at 9:28 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On Wed, Nov 19, 2014 at 7:31 PM, Elle Stone ellest...@ninedegreesbelow.com wrote a lot of text that has been trimmed away... Hmm. I worked hard to explain why even for chomaticitiy independent editing operations the RGB data shouldn't be converted to unbounded sRGB. You dismissed my efforts with Elle Stone wrote a lot of text that has been trimmed away... I think it is too early to productively discuss implementation details in GEGL, and therefore choose to focus on things that are *not* implementation details. Thankfully you no longer seem to disagree with the general direction of the babl roadmap as can be seen in your reference to how the architecture of babl/GEGL goes beyond traditional ICC RGB editing, encompasses HDR. There is much work to be done in babl – by someone; not neccesarily me – before it is possible to experiment with different approaches. When we can profile running code, see what the CPU is busy doing most of the time and then spend time refactoring unneccesary conversions away. I have even speculated and pointed out likely complications for some of the chromaticity independent operations when *different* user:RGBs are to be composited. To repeat an earlier remark on one of the other points, there is no lists to maintain of which operations operate with what representation – this is local to the ops. Each individual operation within its own code specifies the data representation of input and output data in its own implementation. /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] [Gimp-user] Time to fork BABL and GEGL
On 11/19/2014 04:47 PM, Øyvind Kolås wrote: On Wed, Nov 19, 2014 at 9:28 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On Wed, Nov 19, 2014 at 7:31 PM, Elle Stone ellest...@ninedegreesbelow.com wrote a lot of text that has been trimmed away... Hmm. I worked hard to explain why even for chomaticitiy independent editing operations the RGB data shouldn't be converted to unbounded sRGB. You dismissed my efforts with Elle Stone wrote a lot of text that has been trimmed away... I think it is too early to productively discuss implementation details in GEGL, and therefore choose to focus on things that are *not* implementation details. Whether to *ever* use unbounded sRGB chromaticities to perform edits on UserRGB data is NOT AN IMPLEMENTATION DETAIL. Unbounded sRGB is a mistake, pure and simple, *unless* the data is intended by the USER to be HDR sRGB data. In case you don't understand this, HDR sRGB data is still *bounded* by the sRGB xy chromaticities. It's only unbounded along the Y axis. There are NO negative channel values in HDR sRGB data unless the *user* chooses to do something odd, in which case the *user* is responsible for fixing the results. Converting a display-referred wider gamut image to unbounded sRGB doesn't magically produce HDR data. It just creates a mess that will require a bunch of onerous implementation details to straighten out. There is *no* point in *ever* editing UserRGB data using sRGB chromaticities. You can call all the shenanigans that would be required to straighten out the resulting mess implementation details if you want. But it's still a mistake to edit UserRGB data using ANY chromaticities not of the user's choosing. Thankfully you no longer seem to disagree with the general direction of the babl roadmap as can be seen in your reference to how the architecture of babl/GEGL goes beyond traditional ICC RGB editing, encompasses HDR. The ONLY part of the babl/GEGL architecture I've ever disagreed with is your desire to force UserRGB to be re-encoded using sRGB chromaticities. Other than unbounded sRGB, what you've been trying to do is *brilliant*. Even brilliant people sometimes have ideas that turn out to be not so great. There is much work to be done in babl – by someone; not neccesarily me – before it is possible to experiment with different approaches. You don't need to experiment with vs not converting UserRGB to unbounded sRGB. Converting UserRGB to chromaticities not of the user's choosing is a mistake. All it does is create unnecessary complications. You shouldn't be trying to control what RGB working space the user is allowed to use to edit the user's own RGB data. When we can profile running code, see what the CPU is busy doing most of the time and then spend time refactoring unneccesary conversions away. I have even speculated and pointed out likely complications for some of the chromaticity independent operations when *different* user:RGBs are to be composited. When the user wants to composite images together, the only thing you can *legitimately* do is let the *user* decide what RGB working space to use to composite the images. If you try to *dictate* the RGB working space for compositing the user's images, you are making a great big fat HUGE mistake. In fact you are making *exactly* the same mistake as forcing editing of UserRGB data to be done using sRGB chromaticities, except in cases where the *user* really intends the data to be sRGB data. To repeat an earlier remark on one of the other points, there is no lists to maintain of which operations operate with what representation – this is local to the ops. Each individual operation within its own code specifies the data representation of input and output data in its own implementation. If each developer decides on his own whether to use unbounded sRGB chromaticities for any given operation, together the developers are creating an ad hoc list. Playing with semantics to make it sound like there is no list is not helpful. It's just throwing chaff into the air. Could you *please* abandon the entirely misguided notion of forcing UserRGB data to be edited using sRGB chromaticities or any other chromaticities not of the user's choosing? /pippin 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] [Gimp-user] Time to fork BABL and GEGL
On 19 November 2014 23:57, Elle Stone ellest...@ninedegreesbelow.com wrote: In case you don't understand this, HDR sRGB data is still *bounded* by the sRGB xy chromaticities. It's only unbounded along the Y axis. There are NO negative channel values in HDR sRGB data unless the *user* chooses to do something odd, in which case the *user* is responsible for fixing the results. Doesn't this contradict with the following, from your recent mail? (I don't know what particularly is the definition of HDR used) We've also agreed that for chromaticity independent RGB editing operations (CI ops, for short), by definition the same colors (as located in the XYZ reference color space) are obtained regardless of the chromaticities that are used to encode the data. -- Jon Nordby - www.jonnor.com ___ 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] [Gimp-user] Time to fork BABL and GEGL
Hi Elle. Elle Stone (ellest...@ninedegreesbelow.com) wrote: Whether to *ever* use unbounded sRGB chromaticities to perform edits on UserRGB data is NOT AN IMPLEMENTATION DETAIL. Unbounded sRGB is a mistake, pure and simple, *unless* the data is intended by the USER to be HDR sRGB data. It really is not about editing. Even when for some reason the data in the graph is present as unbounded sRGB data the multiplication op will request the data as userRGB which will result in a transform, the op will get the colors in the desired space. In case you don't understand this, HDR sRGB data is still *bounded* by the sRGB xy chromaticities. It's only unbounded along the Y axis. There are NO negative channel values in HDR sRGB data unless the *user* chooses to do something odd, in which case the *user* is responsible for fixing the results. I think you are missing that unbounded also allows *negative* R, G or B coordinates. That makes the colors imaginary in the sRGB color space, but it still is possible to convert them to all other RGB color spaces. Unbounded sRGB can express all the colors XYZ can express. Transformations from userRGB to sRGB to userRGB are lossless. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ 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] [Gimp-user] Time to fork BABL and GEGL
Since a few questions have popped up on IRC and it really is a weird concept to grasp I thought I'd expand a bit on the color math that is being discussed here. Sorry it is so long, I hope it is somewhat entertaining though :) Simon Budig (si...@budig.de) wrote: I think you are missing that unbounded also allows *negative* R, G or B coordinates. That makes the colors imaginary in the sRGB color space, but it still is possible to convert them to all other RGB color spaces. Unbounded sRGB can express all the colors XYZ can express. Transformations from userRGB to sRGB to userRGB are lossless. The normal sighted human eye contains three types of cones which respond differently to a given light spectra. In 1931 researchers have tried to map the response of these cone types by having people stare at projection screens and match colors. The results of these experiments were combined and resulted in the definition of a CIE standard observer, with the most important aspect being functions describing the standard response of the three cone types to light wavelengths: http://en.wikipedia.org/wiki/File:CIE_1931_XYZ_Color_Matching_Functions.svg The Tristimulus values X, Y, Z refer to the three cone types. They can be determined by weighting the spectral power distribution with the resp. response curve and then computing the integral over the wavelength range from 380 to 780nm. Related to XYZ is xy, which simply is the color information normalized to a given intensity: x = X/(X+Y+Z) and y=Y/(X+Y+Z). The horseshoe-diagram you see frequently when colors are discussed (http://en.wikipedia.org/wiki/File:CIE1931xy_blank.svg ) lives in the xy plane. Note that these are absolute colors we're talking about here. For a given spectral power distribution we end up with certain XYZ values. This totally ignores other aspects of the human vision system. In particular knowing the XYZ coordinate of a color does not help at all in determining if something is perceived as white. This is where the whitepoint becomes relevant. For example if you look at a piece of letter paper lighted by candle light you perceive it as white, since your eye is trained to take the color of the environment light source into account. Also experiences are relevant as well. You just assume that this piece of paper is white, since this is what you are used to and then your vision system takes this as a reference point. If you'd see the same XYZ color in a daylight context, you'd probably be surprised how reddish yellow it actually is. Taking a photo of a candlelight scene with a digital camera set to a daylight whitepoint will give you an idea. No, the yellow color is not the camera lying to you, it is the eye not being allowed to lie to you. Another important aspect of the XYZ system is, that it contains imaginary colors: Color coordinates where it is impossible to create light spectra for. If you look at the color matching functions referenced above you see why: they do have huge overlaps, most wavelengths trigger two or even all three of the cone types simultaneously. Looked at it from the math point of view that means for example that if Y is nonzero, then X or Z will be nonzero as well. The XYZ coordinate (0, 1, 0) is an imaginary color. It is impossible to construct a real world light spectrum that results in this XYZ coordinate. Pure light with about 520nm wavelengh might get you close, but you still have X and Z components 0. The rounded boundary in the horseshoe diagram represents the pure wavelengths and the weird shape is determined by the overlaps in the color matching functions. XYZ is very useful in that it is a good tool to describe absolute colors and it is a superset of all the color impressions the CIE standard observer can perceive. It is the safe bet of color spaces. However, since pure X, pure Y and pure Z are basically a physical impossibility they cannot be used to build real world computer monitors. It has turned out that variants of Red/Green/Blue are a useful compromise to compose color impressions. The Phosphors used in CRTs and the filters used in LCDs have a specific spectral distribution and can be varied in their intensity, resulting in an absolute XYZ coordinate. In the real world we have a maximum brightness for each of the components and reducing the intensity moves the XYZ coordinate on a straight line towards (0,0,0), i.e. black. Since the integral math behaves additively the three independent components construct a skewed cube in the XYZ color space. This is the gamut: the range of color impressions that can be shown with this particular monitor. If you now normalize the intensities of the coordinates within this skewed cube you end up with a triangle in the xy-space, which is useful to describe the range of colors available to you with a given set of base colors: http://en.wikipedia.org/wiki/File:CIE1931xy_gamut_comparison.svg The corners of the triangle are the xy-coordinates of the
Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL
On Mon, Nov 17, 2014 at 11:39 PM, Gez lis...@ohweb.com.ar wrote: P.s.: If you think this discussion is a waste of your time and my time, feel free to skip an answer. I don't think it's a waste of time at all, it's developer/user interaction regarding important aspects of the tool. Do you really think that discussing this is counterproductive? Yes, I think that discussing this is counterproductive because it is premature. If I had spent the time I spent responding to color-related emails on coding this system instead, it would easily be working right now. Then, we could be discussing the details of a system that actually existed, instead of the details of a system that does not exist, and if current rates of coding continue, will never exist. You say I should stop responding, but it's hard to stop responding when novels are being written about how wrong you are, but you believe you are right. It's hard to stop responding when an article portraying you as incompetent appears on hacker news. It's hard to stop responding when you genuinely want people to understand. -- drawoc ___ 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] [Gimp-user] Time to fork BABL and GEGL
On 11/17/2014 06:56 PM, Simon Budig wrote: Oh, I was under the assumption that AdobeRGB had well defined chromaticies. If that is not the case then please consider my example moot. I am well aware that dealing with color profiles most definitely is not my area of expertise. It absolutely does have well-defined chromaticities. LCMS specifies an odd value for D65 and doesn't compensate for hexadecimal rounding. And so almost everyone who distributes ICC profiles made with LCMS makes AdobeRGB1998-compatible profiles that don't exactly match the Adobe specifications. Graham Gill distributes ClayRGB1998.icm that exactly matches the Adobe specs. I've submitted code to GIMP to make a proper AdobeRGB1998-compatible profile. Other free/libre profile makers really aren't distributing an exact match to the Adobe specs. I've already reported this on the LCMS mailing list. Similar problems obtain with a lot of other free/libre ICC profiles. 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] [Gimp-user] Time to fork BABL and GEGL
Great! Glad to hear it! Please prove to us your understanding by expressing, in your own words, the difference between a design detail and an implementation detail. Ciao, Ed -Original Message- From: Elle Stone Sent: Tuesday, November 18, 2014 10:17 AM To: Ed . ; Mikael Magnusson Cc: gimp-user-l...@gnome.org ; gimp-developer-list@gnome.org Subject: Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL On 11/17/2014 07:32 PM, Ed . wrote: Elle, If you don't understand the difference between a design detail, and an implementation detail, you need to either a) go away and get to understand that difference; or b) stop commenting. I am neutral as to which you choose. Ed Again, Ed, in this discussion you don't have a leg to stand on. ___ 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] [Gimp-user] Time to fork BABL and GEGL
These are the type of emails that are not helpful. It is not helpful also because it's a rephrased email that was sent 15 hours ago. Simos On Tue, Nov 18, 2014 at 5:27 PM, Ed . ej...@hotmail.com wrote: Great! Glad to hear it! Please prove to us your understanding by expressing, in your own words, the difference between a design detail and an implementation detail. Ciao, Ed -Original Message- From: Elle Stone Sent: Tuesday, November 18, 2014 10:17 AM To: Ed . ; Mikael Magnusson Cc: gimp-user-l...@gnome.org ; gimp-developer-list@gnome.org Subject: Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL On 11/17/2014 07:32 PM, Ed . wrote: Elle, If you don't understand the difference between a design detail, and an implementation detail, you need to either a) go away and get to understand that difference; or b) stop commenting. I am neutral as to which you choose. Ed Again, Ed, in this discussion you don't have a leg to stand on. ___ 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 ___ 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] [Gimp-user] Time to fork BABL and GEGL
On Tue, Nov 18, 2014 at 6:27 PM, Ed . wrote: Great! Glad to hear it! Please prove to us If you have personal issues with any of the list members, I strongly advice taking it off-list. We'd like to keep the interaction professional, thank you. Alex ___ 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] [Gimp-user] Time to fork BABL and GEGL
On 11/18/2014 03:05 AM, Michael Henning wrote: On Mon, Nov 17, 2014 at 11:39 PM, Gez lis...@ohweb.com.ar wrote: P.s.: If you think this discussion is a waste of your time and my time, feel free to skip an answer. I don't think it's a waste of time at all, it's developer/user interaction regarding important aspects of the tool. Do you really think that discussing this is counterproductive? Yes, I think that discussing this is counterproductive because it is premature. If I had spent the time I spent responding to color-related emails on coding this system instead, it would easily be working right now. If I had not spent time and effort explaining the problems *before* you got around to implementing unbounded sRGB image editing, you would have coded up a working high bit depth GIMP that was steadily churning out wrong results. And I'd be filing a whole lot of bug reports. Then, we could be discussing the details of a system that actually existed, instead of the details of a system that does not exist, and if current rates of coding continue, will never exist. And the discussion would be exactly the same. You would still need to use UserRGB chromaticities instead of sRGB chromaticities. But you'd have to undo a lot of new code to get there. Convincing the babl/GEGL/GIMP devs of anything regarding color management has never been easy. For example, in 2013 I tried to explain why there is a difference between device Y vs ICC profile D50-adapted Y: * https://mail.gnome.org/archives/gimp-developer-list/2013-September/msg00113.html and eight follow-up messages * http://ninedegreesbelow.com/photography/srgb-luminance.html. Michael Henning did understand and did make appropriate changes to babl's hard-coded sRGB Y values. But I doubt whether any of the other devs understood; if they did, babl wouldn't still use D65 device sRGB to convert to XYZ before converting to LAB, and GIMP wouldn't still be full of hard-coded D65 device sRGB Y values. See: GIMP really does need someone on the team who understands ICC profile color management. But it doesn't do any good to have such a person around unless you actually listen. To listen *intelligently* so you can ask the right questions when your color management person seems to be giving wrong advice (I'm just as capable as the next person when it comes to giving wrong advice), you need to understand a little bit about ICC profile color management. I've done my best to make this task easier: Completely Painless Programmer's Guide to XYZ, RGB, ICC, xyY, and TRCs http://ninedegreesbelow.com/photography/xyz-rgb.html I've learned a lot while trying to explain where babl/GEGL/GIMP has gone off track regarding one or another color management issue. Hopefully the exchange of knowledge has been a two-way street. You say I should stop responding, but it's hard to stop responding when novels are being written about how wrong you are, but you believe you are right. It's hard to stop responding when an article portraying you as incompetent appears on hacker news. It's hard to stop responding when you genuinely want people to understand. -- drawoc I agree with you that it's hard to stop responding when you want people to understand something that you care about. I doubt whether any of you have a clue just how much I value GIMP as an RGB image editor. But GIMP is critically important to free/libre artists and therefore GIMP color management needs to be right. Now, please explain this to me with a straight answer: Why is it so insanely important to know what color space an operation happens in, in a situation where it*by definition* does not matter, that you are willing to waste hours of your time and hours of developers' time arguing about it? This is exactly the right question. It will me take a bit of time to put together a straight answer that is also not one of my walls of words. I'll try to post the answer today or at least by tomorrow morning. 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] [Gimp-user] Time to fork BABL and GEGL
On 11/18/2014 11:00 AM, Elle Stone wrote: Convincing the babl/GEGL/GIMP devs of anything regarding color management has never been easy. For example, in 2013 I tried to explain why there is a difference between device Y vs ICC profile D50-adapted Y: * https://mail.gnome.org/archives/gimp-developer-list/2013-September/msg00113.html and eight follow-up messages * http://ninedegreesbelow.com/photography/srgb-luminance.html. Michael Henning did understand and did make appropriate changes to babl's hard-coded sRGB Y values. But I doubt whether any of the other devs understood; if they did, babl wouldn't still use D65 device sRGB to convert to XYZ before converting to LAB, and GIMP wouldn't still be full of hard-coded D65 device sRGB Y values. See: Sorry, typo, the See: is misplaced. It should read: Convincing the babl/GEGL/GIMP devs of anything regarding color management has never been easy. For example, in 2013 I tried to explain why there is a difference between device Y vs ICC profile D50-adapted Y See: * https://mail.gnome.org/archives/gimp-developer-list/2013-September/msg00113.html and eight follow-up messages * http://ninedegreesbelow.com/photography/srgb-luminance.html. Michael Henning did understand and did make appropriate changes to babl's hard-coded sRGB Y values. But I doubt whether any of the other devs understood; if they did, babl wouldn't still use D65 device sRGB to convert to XYZ before converting to LAB, and GIMP wouldn't still be full of hard-coded D65 device sRGB Y values. 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] [Gimp-user] Time to fork BABL and GEGL
As a small aside... Alexandre Prokoudine (alexandre.prokoud...@gmail.com) wrote: We'd like to keep the interaction professional, thank you. I'd like to ask everyone involved in this discussion to remove the gimp-user mailinglist from the CC-list. The level of this discussion really is hardcore gimp-devel stuff and there is no need to duplicate it on gimp-user. People on gimp-user who are interested in this discussion are welcome to join gimp-devel. Let this be the last mail in this thread duplicated to both of the lists :) Thanks, Simon -- si...@budig.de http://simon.budig.de/ ___ 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] [Gimp-user] Time to fork BABL and GEGL
On Tue, Nov 18, 2014 at 7:00 PM, Elle Stone wrote: Michael Henning did understand and did make appropriate changes to babl's hard-coded sRGB Y values. But I doubt whether any of the other devs understood; if they did, babl wouldn't still use D65 device sRGB to convert to XYZ before converting to LAB, and GIMP wouldn't still be full of hard-coded D65 device sRGB Y values. See: Elle, assuming that things are not done/fixed, because we don't understand them or don't care about them, is simply incorrect. We have a roadmapful of things we care about which still need someone to work on. It really is that easy. By now, it's been repeated about a dozen of times that we had adjusted our plans in the past to honor your useful input, and we are going to do so in the future __time permitting__. Is there a good reason why there should be another dozen of times for this to be said in the public? As Michael already stated, there are things we simply don't know yet, because they are implementation details. hence we don't have all the answers for you. Please show us some patience. Alex ___ 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] [Gimp-user] Time to fork BABL and GEGL
In keeping with Simon's request, I'm not copying the user list. On 11/18/2014 11:16 AM, Alexandre Prokoudine wrote: On Tue, Nov 18, 2014 at 7:00 PM, Elle Stone wrote: Michael Henning did understand and did make appropriate changes to babl's hard-coded sRGB Y values. But I doubt whether any of the other devs understood; if they did, babl wouldn't still use D65 device sRGB to convert to XYZ before converting to LAB, and GIMP wouldn't still be full of hard-coded D65 device sRGB Y values. See: Elle, assuming that things are not done/fixed, because we don't understand them or don't care about them, is simply incorrect. We have a roadmapful of things we care about which still need someone to work on. It really is that easy. I didn't mean to offend anyone and my apologies if I did. Not too long ago I wanted to submit a patch for the GIMP sRGB Y values. I was told by one of the developers that it was still undecided as to whether D65 or D50-adapted Y values were appropriate. This would have been a small code change to make. I would have done the required coding, so it would have required no developer time except the time to make the commit. It would have brought GIMP Y into line with babl Y. There was no reason to not accept the change other than a failure to understand that in an ICC profile color-managed application where the profile illuminant is D50, using D65 unadapted Y values is incorrect. This is not casting blame. This is describing a situation where the required knowledge for making a decision simply wasn't there. I used to tutor math students and learned very quickly that the only way to get information from teacher to student is to enable the student to ask the right questions, which means trying to see things from the student's perspective. Before I suggest anything related to color management to the GIMP devs, I've already tested it sixteen ways from Sunday. In the cases of which Y and the inadvisability of using sRGB chromaticities for editing images that the user intends to be in some other RGB working space, my advice is correct. But explaining why really is taking a long time and also is trying everyone's patience, including mine. I think part of the problem is people (no doubt including me) aren't asking the right questions. I've been trying to understand the babl/GEGL/GIMP perspective on color management. I've also been trying to impart enough information to enable the devs to ask me the right questions, but I don't seem to be doing a very good job. By now, it's been repeated about a dozen of times that we had adjusted our plans in the past to honor your useful input, and we are going to do so in the future __time permitting__. Is there a good reason why there should be another dozen of times for this to be said in the public? Actually I feel very honored that you all trust my input enough to make changes. And I do realize that tasks need to be prioritized. For instance, I expect you probably will release 2.10 before fixing the hard-coded sRGB parameters. Rome wasn't built in a day and even I will agree that getting GIMP geglified and removing more of the deprecated functions is a higher priority task than fixing GIMP color management. As Michael already stated, there are things we simply don't know yet, because they are implementation details. hence we don't have all the answers for you. Please show us some patience. Well, I've been patiently explaining why some of those implementation details really belong over in the overall plan category. And you all have been extraordinarily patient with my efforts to communicate. 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] [Gimp-user] Time to fork BABL and GEGL
On 11/16/2014 05:18 PM, Øyvind Kolås wrote: On Sun, Nov 16, 2014 at 9:01 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: Do you understand that when I say that Multiply is a chromaticity-dependent editing operation, I don't just mean the Multiply layer blend mode? that in fact *all* editing operations that use multiplication or division are chromaticity dependent, regardless of whether the colors are *in* gamut or *out* of gamut with respect to the very small bounded sRGB color gamut? The exception to all, of course, is when multiplying or dividing by black, gray, or white. Yes I do understand that OK, thanks! for confirming. I was afraid my phrasing might have obscured an important point. 1. Do you agree or disagree that for *all* chromaticity dependentediting operations, the *user* should be in control of which RGBchromaticities are used to perform the operation? That is the point of adding more, and named, RGB families to babl. 2. Do you agree or disagree that for chromaticity *in*depedent editing operations (for example, and assuming linearized RGB: adding, scaling, gaussian blur, etc), the same results (same XYZ values) are obtained whether the operation is done in the user's chosen RGB working space or in unbounded sRGB? I do; So it appears that we agree on the following, yes? 1. The user's chosen RGB working space chromaticities should be used for performing all chromaticity dependent RGB editing operations. 2. For chromaticity independent RGB editing operations, the same XYZ values are obtained regardless of whether the operation is performed using the user's chosen RGB working space chromaticities or after converting the image to unbounded sRGB. Somewhat switching gears, the revised babl roadmap (https://git.gnome.org/browse/babl/tree/docs/roadmap.txt) says: The plan in roadmap hasn't really changed since mid-april[1], I agree with you that the plan you outlined in April is pretty much the same plan that I think you are outlining now. In April you did agree that some RGB editing operations don't work in unbounded sRGB. You said that using targetRGB (ie the user's chosen RGB working space, UserRGB, barRGB, etc) would be one solution and that another solution would be converting to CIELAB to do the operation. Putting aside coding considerations that might affect other software that uses babl and GEGL, here's my understanding of your current plan for babl/GEGL/GIMP: 1. Upon opening an image, the image will be converted to unbounded sRGB. 2. For all chromaticity dependent RGB editing operations: * Either the image will be re-encoded using the user's chosen RGB working space chromaticities, and then the operation will be performed. * Or else the image will be converted to CIELAB and then the operation will be performed. 3. For all chromaticity *in*dependent RGB editing operations, the image will be converted to unbounded sRGB for processing. 4. When converting to XYZ/CIELAB/etc, the image will first be converted to unbounded sRGB. 5. The GEGL developers will specify on an operation by operation basis whether the operation requires being encoded using UserRGB/Y/etc, or unbounded sRGB/Y/etc, or CIELAB as a substitute for chromaticity dependent RGB processing, or etc. As an important note, depending on the last operation that was done, the image might already be encoded using the GEGL-operation-specified format, in which case a conversion to that format is not needed. Are the above five points (and note) an accurate summary of your current plan for babl/GEGL/GIMP? I have a couple of followup questions, but there's no point in asking them if I don't have a clear understanding of what your current plan really is. I think we've both been rightly accused of talking right past each other. 1: the only change in plans since then (and that changed occured before roadmap.txt was started), was abandoning the plan to do conversions between bablRGB and userRGBs in babl using LCMS2; and instead do those conversions directly ourselves in babl; a change without impact on how babl will be used by GEGL (and GIMP). Using babl instead of LCMS2 to do ICC profile matrix conversions makes perfect sense, being faster and potentially a lot more accurate (https://mail.gnome.org/archives/gimp-developer-list/2014-October/msg00093.html). /pippin 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] [Gimp-user] Time to fork BABL and GEGL
Hi Elle. The following is my understanding, when pippin answers his answers have more authority than mine. Elle Stone (ellest...@ninedegreesbelow.com) wrote: Putting aside coding considerations that might affect other software that uses babl and GEGL, here's my understanding of your current plan for babl/GEGL/GIMP: A slight preface here. I don't consider it important to focus on the *storage* of the pixel data, as in the actual bulk memory for the pixel data. The important part is, that the data is available to the operations in the format they request upon request. If that is in memory already pre-converted or if that gets converted on the fly is an implementation detail. 1. Upon opening an image, the image will be converted to unbounded sRGB. I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB. But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors. 2. For all chromaticity dependent RGB editing operations: * Either the image will be re-encoded using the user's chosen RGB working space chromaticities, and then the operation will be performed. * Or else the image will be converted to CIELAB and then the operation will be performed. Conceptually the image won't be converted as a whole. A pixel-data-flow-graph will be set up that considers the region of interest. For all chromaticity dependent RGB editing operations the pixels will be re-encoded in the format the operations requests. Which most likely will be userRGB. And the re-encoding-step can be a NOP, if the previous node in the operations tree already provides the requested format. 3. For all chromaticity *in*dependent RGB editing operations, the image will be converted to unbounded sRGB for processing. For all chromaticity *in*dependent RGB editing operations the pixels will be converted to the format the operations requests. Which most likely will 0e sRGB or XYZ. And the re-encoding-step can be a NOP, if the previous node in the operations tree already provides the requested format. (Sorry for repeating, but this is an important point: in a given image context userRGB really is not conceptually different from sRGB or XYZ, it gets slightly more complicated when two images with different user chromaticies are to be combined.) 4. When converting to XYZ/CIELAB/etc, the image will first be converted to unbounded sRGB. Not necessarily. If specific userRGB to XYZ/whatever transforms are available to babl it will make use of them. This will likely be the case for e.g. AdobeRGB. 5. The GEGL developers will specify on an operation by operation basis whether the operation requires being encoded using UserRGB/Y/etc, or unbounded sRGB/Y/etc, or CIELAB as a substitute for chromaticity dependent RGB processing, or etc. It probably will be specified within the implementation. I.e. there won't be a pre-existing separate document with a list for each individual operation. However there might be such a document generated from the implementation. As an important note, depending on the last operation that was done, the image might already be encoded using the GEGL-operation-specified format, in which case a conversion to that format is not needed. Yes, but it is important to keep in mind that we don't sequentially apply one operation after each other, with image-in-memory-steps inbetween. We build a graph of connected operations, where the connections between the nodes will be negotiating the resp. pixel formats. *Then* the pixel data will be fed from the sources into the graph, flow through the graph, have the operations operate on them, potentially converting them to the negotiated pixel formats and finally get sunk into the output (e.g. the node painting into the image view). Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ 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] [Gimp-user] Time to fork BABL and GEGL
On 11/17/2014 10:46 AM, Simon Budig wrote: Hi Elle. The following is my understanding, when pippin answers his answers have more authority than mine. Hi Simon, I appreciate your answers, but the points you make aren't actually relevant to the questions that I wanted to ask Pippin. This is my fault. In an effort to clarify what I think he's saying, I seem to have just opened the door for more miscommunication. Elle Stone (ellest...@ninedegreesbelow.com) wrote: Putting aside coding considerations that might affect other software that uses babl and GEGL, here's my understanding of your current plan for babl/GEGL/GIMP: A slight preface here. I don't consider it important to focus on the *storage* of the pixel data, as in the actual bulk memory for the pixel data. If you choose to *store* the user's RGB data using chromaticities not of user's choosing, that suggests that you also intend to *edit* the user's RGB data using chromaticities not of user's choosing 1. Upon opening an image, the image will be converted to unbounded sRGB. I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB.But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors. This is not just an implementation detail. The user has the right to control what RGB working space is used when performing RGB edits on the user's own RGB data. 2. For all chromaticity dependent RGB editing operations: * Either the image will be re-encoded using the user's chosen RGB working space chromaticities, and then the operation will be performed. * Or else the image will be converted to CIELAB and then the operation will be performed. Conceptually the image won't be converted as a whole. A pixel-data-flow-graph will be set up that considers the region of interest. This really is an implemetation detail. For all chromaticity dependent RGB editing operations the pixels will be re-encoded in the format the operations requests. Which most likely will be userRGB. If the user opens a BetaRGB image or an AdobeRGB image or whatever, the user really does expect that *all* RGB edits wil be done using the user's chosen RGB working space chromaticities. 3. For all chromaticity *in*dependent RGB editing operations, the image will be converted to unbounded sRGB for processing. For all chromaticity *in*dependent RGB editing operations the pixels will be converted to the format the operations requests. Which most likely will 0e sRGB or XYZ. This brings me to the question that I was planning on asking Pippin. If Pippin *doesn't* intend to convert the image to unbounded sRGB before performing any RGB editing operations, then my question is irrelevant. So the pre question is: Does Pippin intend that the image will be converted to unbounded sRGB before performing chromaticity *in*dependent RGB editing operations? If Pippin's answer to the pre question is yes, here's the question I wanted to ask Pippin: 1. We've agree that many RGB editing operations really are chromaticity dependent and therefore should be done using the user's chosen RGB working space chromaticities. 2. We've agree that for chromaticity *in*dependent editing operations, the resulting colors as located in the XYZ reference color space are the same *regardless* of the chromaticities used to encode the RGB data before performing the operation. Given the above two points of agreement, what is point of EVER converting the image to unbounded sRGB? I can list a whole bunch of disadvantages. But I don't understand what the advantages are supposed to be. I thought Jon Nordby had made it clear (more than once) that for all RGB editing operations, the user's chosen RGB working space's chromaticties would be used. But it's hard to tell whether Pippin agrees with Jon Nordby. So I'm asking Pippin as directly as possible whether he ever intends that RGB editing will be done using sRGB chromaticities instead of the user's chosen RGB working space's chromaticities. If Pippin's answer is yes, then the next question is Why?. (Sorry for repeating, but this is an important point: in a given image context userRGB really is not conceptually different from sRGB or XYZ, My apologies, but this statement makes no sense unless you mean the trivially obvious point that RGB color data can be losslessly converted to various unbounded color spaces including the XYZ reference color space, of course putting aside floating point precision limitations and sundry other sources of computational loss of precision. it gets slightly more complicated when two images with different user chromaticies are to be combined.) Again, let the *user* decide what RGB working space to use for combining images. Except for the few compositing operations that are
Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL
On Mon, Nov 17, 2014 at 10:03 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 11/17/2014 10:46 AM, Simon Budig wrote: Hi Elle. The following is my understanding, when pippin answers his answers have more authority than mine. Hi Simon, I appreciate your answers, but the points you make aren't actually relevant to the questions that I wanted to ask Pippin. This is my fault. In an effort to clarify what I think he's saying, I seem to have just opened the door for more miscommunication. Elle Stone (ellest...@ninedegreesbelow.com) wrote: Putting aside coding considerations that might affect other software that uses babl and GEGL, here's my understanding of your current plan for babl/GEGL/GIMP: A slight preface here. I don't consider it important to focus on the *storage* of the pixel data, as in the actual bulk memory for the pixel data. If you choose to *store* the user's RGB data using chromaticities not of user's choosing, that suggests that you also intend to *edit* the user's RGB data using chromaticities not of user's choosing 1. Upon opening an image, the image will be converted to unbounded sRGB. I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB.But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors. This is not just an implementation detail. The user has the right to control what RGB working space is used when performing RGB edits on the user's own RGB data. The above two things are implementation details as Simon said. If you don't understand this, then please don't write long articles full of misinformation that get widely quoted. Your answers suggest you didn't even understand what he said. Your argument is like saying it matters if you store an integer in decimal or binary, and doing anything else than the user input is definitely wrong, because there is no longer any way to display it in this format. Gegl stores pixels in memory in some format, it knows what format it used. Gimp can display/edit pixels in some color space (specified by the user). Gimp asks Gegl for pixels saying what colorspace it wants. Gegl presents the pixels to Gimp. All is well. It doesn't matter how the pixels are stored. -- Mikael Magnusson ___ 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] [Gimp-user] Time to fork BABL and GEGL
On 11/17/2014 05:41 PM, Mikael Magnusson wrote: On Mon, Nov 17, 2014 at 10:03 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 11/17/2014 10:46 AM, Simon Budig wrote: I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB.But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors. This is not just an implementation detail. The user has the right to control what RGB working space is used when performing RGB edits on the user's own RGB data. The above two things are implementation details as Simon said. There is no reason to *store* the image using the sRGB chromaticities unless you also intend to *edit* the image using the sRGB chromaticities, or else if you intend to convert the image to unbounded sRGB and then to Y or else to XYZ and then maybe to CIELAB. So yes, the question of how you *store* the user's RGB data really does matter. It's not just an implementation detail. Unless maybe you think it's reasonable to randomly re-encode the user's RGB data using the sRGB chromaticities just because you can. If you don't understand this, then please don't write long articles full of misinformation that get widely quoted.Your answers suggest you didn't even understand what he said. I do understand what Simon said. And I'm waiting for Pippin to clarify whether *Pippin* intends that images will be converted to unbounded sRGB before performing chromaticity independent RGB editing operations. If Pippin's answer is yes, the image will be converted to unbounded sRGB for chromaticity independent RGB editing operations, I want to ask him why. There are many bad consequences of doing this. So if Pippin's answer is yes, there must be some advantages that I don't see. Pippin and Jon Nordby seem to be saying different things. Three times Nordby has said that the image won't be converted to sRGB except for the handful of editing operations that really can't be generalized. (As an aside, in these cases, I hope a UI warning will be provided so the user knows what's going on and can exercise the right to not use the affected operation.) And three times Pippin has made statements that seem to directly contradict Jon Nordby. Your argument is like saying it matters if you store an integer in decimal or binary, and doing anything else than the user input is definitely wrong, because there is no longer any way to display it in this format. Umm, could you untangle your analogy? Because all of sudden the integer encodings became undisplayable images. I assure you that if you add integers encoded using binary, while thinking you are adding decimal numbers, you will almost certainly get results that diverge from what you expect, adding 0+1 being an obvious exception. And if you composite colors thinking you are compositing in UserRGB, when really you are compositing in sRGB, likewise you are very likely to get results other than what you expected. Gegl stores pixels in memory in some format, it knows what format it used. babl and GEGL do communicate with each other as to what format the data is in and what format is needed next. Are you trying to say something else? Gimp can display/edit pixels in some color space (specified by the user). Well, this really is the question: according to Pippin, what color space chromaticities will be used for chromaticity independent RGB editing operations? UserRGB's or sRGB's? Gimp asks Gegl for pixels saying what colorspace it wants. Well, sometimes GIMP specifies the babl format and sometimes GEGL specifies the babl format. The question is whether for RGB editing operations the format so specified will ever be unbounded sRGB. Each time Nordby seems to say no, Pippin seems to say yes. Gegl presents the pixels to Gimp.All is well. It doesn't matter how the pixels are stored. Again, there is no reason to re-encode and *store* the pixels using the sRGB chromaticities *unless* there is an intention to *use* the re-encoded information for some purpose other than storing the pixels. As GIMP is an image editor, presumably that purpose would be for *editing*, and the format the pixels are in for editing does matter a great deal. 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] [Gimp-user] Time to fork BABL and GEGL
Elle Stone (ellest...@ninedegreesbelow.com) wrote: A slight preface here. I don't consider it important to focus on the *storage* of the pixel data, as in the actual bulk memory for the pixel data. If you choose to *store* the user's RGB data using chromaticities not of user's choosing, that suggests that you also intend to *edit* the user's RGB data using chromaticities not of user's choosing I think that this is the core of the misunderstanding here. In Gegl the *storage* of pixel data in memory is totally and 100% independent from the colorspace used to *edit* the user's RGB data. You seem to think that the storage suggests an intent, but a lot of the communication from pippin, jonnor and me is about explaining that this is *not* the case. Obviously it makes a lot of sense to bring storage and editing workspace in line to avoid computational bottlenecks. But this is just a performance optimization, i.e. implementation detail. 1. Upon opening an image, the image will be converted to unbounded sRGB. I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB.But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors. This is not just an implementation detail. The user has the right to control what RGB working space is used when performing RGB edits on the user's own RGB data. We need to make sure two things: a) upon import of an image the userRGB-format-descriptor within the images context needs to be set up to refer to the chromaticies of the source image. b) whenever a chromaticity dependent operation works on the images data the infrastructure needs to make sure that the pixel data gets fed into the operation using the chromaticies of the source image. We'll do this by having the operation request the image data in the userRGB format from the images context. Note that this is totally independent from the pixel *storage* in memory. This will work the same when the pixel *storage* is in userRGB, sRGB or XYZ. For all chromaticity dependent RGB editing operations the pixels will be re-encoded in the format the operations requests. Which most likely will be userRGB. If the user opens a BetaRGB image or an AdobeRGB image or whatever, the user really does expect that *all* RGB edits wil be done using the user's chosen RGB working space chromaticities. We agree here. The *edits* for the chromaticity dependent operations need to be done in the chromaticies of the source image. If specific userRGB to XYZ/whatever transforms are available to babl it will make use of them. This will likely be the case for e.g. AdobeRGB. OK, if I understand what you just said, this is getting silly. I think you are indicating a willingness to write hard-coded AdobeRGB editing operations and put them right alongside the hard-coded sRGB editing operations. Oh, I was under the assumption that AdobeRGB had well defined chromaticies. If that is not the case then please consider my example moot. I am well aware that dealing with color profiles most definitely is not my area of expertise. If there were chromaticies for a given userRGB which are widely used in a lot of real world applications, then it might make sense to support them in a similiar way like we currently do for the sRGB primaries. If that is not the case then this indeed would be silly. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ 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] [Gimp-user] Time to fork BABL and GEGL
On Mon, Nov 17, 2014 at 11:56 PM, Simon Budig si...@budig.de wrote: If there were chromaticies for a given userRGB which are widely used in a lot of real world applications, then it might make sense to support them in a similiar way like we currently do for the sRGB primaries. Nah, we only need one unbounded PCS ;) – other linear RGB spaces, like linear adobeRGB, are a matrix transform away from linear bablRGB. There might however be some non-similar ways to optimize things, however many of those likely add decision overhead in scenarios like per scanline calls for partial tile conversions that cancel out the benefit over just doing a straight matrix transform. /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] [Gimp-user] Time to fork BABL and GEGL
Elle, If you don't understand the difference between a design detail, and an implementation detail, you need to either a) go away and get to understand that difference; or b) stop commenting. I am neutral as to which you choose. Ed -Original Message- From: Elle Stone Sent: Monday, November 17, 2014 11:52 PM To: Mikael Magnusson Cc: gimp-user-l...@gnome.org ; gimp-developer-list@gnome.org Subject: Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL On 11/17/2014 05:41 PM, Mikael Magnusson wrote: On Mon, Nov 17, 2014 at 10:03 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 11/17/2014 10:46 AM, Simon Budig wrote: I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB.But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors. This is not just an implementation detail. The user has the right to control what RGB working space is used when performing RGB edits on the user's own RGB data. The above two things are implementation details as Simon said. There is no reason to *store* the image using the sRGB chromaticities unless you also intend to *edit* the image using the sRGB chromaticities, or else if you intend to convert the image to unbounded sRGB and then to Y or else to XYZ and then maybe to CIELAB. So yes, the question of how you *store* the user's RGB data really does matter. It's not just an implementation detail. Unless maybe you think it's reasonable to randomly re-encode the user's RGB data using the sRGB chromaticities just because you can. If you don't understand this, then please don't write long articles full of misinformation that get widely quoted.Your answers suggest you didn't even understand what he said. I do understand what Simon said. And I'm waiting for Pippin to clarify whether *Pippin* intends that images will be converted to unbounded sRGB before performing chromaticity independent RGB editing operations. If Pippin's answer is yes, the image will be converted to unbounded sRGB for chromaticity independent RGB editing operations, I want to ask him why. There are many bad consequences of doing this. So if Pippin's answer is yes, there must be some advantages that I don't see. Pippin and Jon Nordby seem to be saying different things. Three times Nordby has said that the image won't be converted to sRGB except for the handful of editing operations that really can't be generalized. (As an aside, in these cases, I hope a UI warning will be provided so the user knows what's going on and can exercise the right to not use the affected operation.) And three times Pippin has made statements that seem to directly contradict Jon Nordby. Your argument is like saying it matters if you store an integer in decimal or binary, and doing anything else than the user input is definitely wrong, because there is no longer any way to display it in this format. Umm, could you untangle your analogy? Because all of sudden the integer encodings became undisplayable images. I assure you that if you add integers encoded using binary, while thinking you are adding decimal numbers, you will almost certainly get results that diverge from what you expect, adding 0+1 being an obvious exception. And if you composite colors thinking you are compositing in UserRGB, when really you are compositing in sRGB, likewise you are very likely to get results other than what you expected. Gegl stores pixels in memory in some format, it knows what format it used. babl and GEGL do communicate with each other as to what format the data is in and what format is needed next. Are you trying to say something else? Gimp can display/edit pixels in some color space (specified by the user). Well, this really is the question: according to Pippin, what color space chromaticities will be used for chromaticity independent RGB editing operations? UserRGB's or sRGB's? Gimp asks Gegl for pixels saying what colorspace it wants. Well, sometimes GIMP specifies the babl format and sometimes GEGL specifies the babl format. The question is whether for RGB editing operations the format so specified will ever be unbounded sRGB. Each time Nordby seems to say no, Pippin seems to say yes. Gegl presents the pixels to Gimp.All is well. It doesn't matter how the pixels are stored. Again, there is no reason to re-encode and *store* the pixels using the sRGB chromaticities *unless* there is an intention to *use* the re-encoded information for some purpose other than storing the pixels. As GIMP is an image editor, presumably that purpose would be for *editing*, and the format the pixels are in for editing does matter a great deal. Elle ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https
Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL
El mar, 18-11-2014 a las 00:32 +, Ed . escribió: Elle, If you don't understand the difference between a design detail, and an implementation detail, you need to either a) go away and get to understand that difference; or b) stop commenting. I am neutral as to which you choose. Ed Are you the same Ed. who wanted to ease communication between Elle and pippin? If not, plase give us back the old Ed. we liked him better. You seem a tad biased for someone who admittedly doesn't understand the issue being discussed. Do you really think that asking someone to STFU helps here? Gez. ___ 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] [Gimp-user] Time to fork BABL and GEGL
El lun, 17-11-2014 a las 23:41 +0100, Mikael Magnusson escribió: The above two things are implementation details as Simon said. If you don't understand this, then please don't write long articles full of misinformation that get widely quoted. Your answers suggest you didn't even understand what he said. Your argument is like saying it matters if you store an integer in decimal or binary, and doing anything else than the user input is definitely wrong, because there is no longer any way to display it in this format. Gegl stores pixels in memory in some format, it knows what format it used. Gimp can display/edit pixels in some color space (specified by the user). Gimp asks Gegl for pixels saying what colorspace it wants. Gegl presents the pixels to Gimp. All is well. It doesn't matter how the pixels are stored. I think I have at this point a reasonable grasp of what's the plan here and that unbounded sRGB is intended a just one representation of the many possible with babl (and that its primary function is to be used as a PCS)- I also understand that chromaticity dependent operations will use userRGB. However, and this is what Elle is asking and nobody seems to understand, the question is if bablRGB is still going to be used as the RGB space for all the chromaticity independent operations and if that's a yes, then WHY. Is it just to spare one single matrix transform in case the buffer is not available in userRGB? And yes, jonnor said something that seems to contradict pippin if that's the case: in the future RGB operations that now ask for bablRGB should ask for userRGB instead. That of course doesn't take bablRGB out of the picture (it would still would be used as PCS), but means specifically that operations won't be fed anymore with unbounded sRGB but user defined RGB. When Elle says converting to unbounded sRGB, she's referring to what babl will do when an operation requests for bablRGB. (We know it's not a forced conversion at the beginning of the pipe, and the GEGL tree can keep different representations for the buffer). If chromaticity independent RGB operations request for bablRGB or userRGB doesn't seem a mere implementation detail. I think it's a valid question to ask why requesting for bablRGB when the mechanism for userRGB will be available. Could you please address that question with a straight answer? Gez. ___ 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] [Gimp-user] Time to fork BABL and GEGL
On Mon, Nov 17, 2014 at 8:48 PM, Gez lis...@ohweb.com.ar wrote: If chromaticity independent RGB operations request for bablRGB or userRGB doesn't seem a mere implementation detail. I think it's a valid question to ask why requesting for bablRGB when the mechanism for userRGB will be available. Could you please address that question with a straight answer? It's very likely that the processing will happen in userRGB for performance reasons. Nobody wants to give you a straight answer because to be honest, we don't know for sure. We could change our mind at any point in the future, and you wouldn't know without reading the code. It doesn't matter what space they happen in because chromaticity independent operations, by definition, do not care which of the spaces we pass them. If we do find a compelling reason to have those operations happen in bablRGB (performance or numerical stability, for example), then we reserve the right to do those operations in bablRGB. And if we do, then nobody will ever know the difference, other than the whopping three people that will ever read that section of the gegl code. Now, please explain this to me with a straight answer: Why is it so insanely important to know what color space an operation happens in, in a situation where it *by definition* does not matter, that you are willing to waste hours of your time and hours of developers' time arguing about it? -- drawoc ___ 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] [Gimp-user] Time to fork BABL and GEGL
El lun, 17-11-2014 a las 21:19 -0500, Michael Henning escribió: On Mon, Nov 17, 2014 at 8:48 PM, Gez lis...@ohweb.com.ar wrote: If chromaticity independent RGB operations request for bablRGB or userRGB doesn't seem a mere implementation detail. I think it's a valid question to ask why requesting for bablRGB when the mechanism for userRGB will be available. Could you please address that question with a straight answer? It's very likely that the processing will happen in userRGB for performance reasons. Nobody wants to give you a straight answer because to be honest, we don't know for sure. We could change our mind at any point in the future, and you wouldn't know without reading the code. It doesn't matter what space they happen in because chromaticity independent operations, by definition, do not care which of the spaces we pass them. If we do find a compelling reason to have those operations happen in bablRGB (performance or numerical stability, for example), then we reserve the right to do those operations in bablRGB. And if we do, then nobody will ever know the difference, other than the whopping three people that will ever read that section of the gegl code. Now, please explain this to me with a straight answer: Why is it so insanely important to know what color space an operation happens in, in a situation where it *by definition* does not matter, that you are willing to waste hours of your time and hours of developers' time arguing about it? Sure. My main concern is performance. It doesn't seem likely that flip-flopping between pixel formats can be more performant than just tossing the user RGB to operations. It's already necessary for chromaticity dependent operations, so why not just using it for EVERY RGB operation? There are benefits: The channel data is always in the range the users expects, color pickers pick the data the user expects, and that requires exactly zero conversions. Please note that my question was related ONLY to what RGB operations take and give. If you have a compelling reason to keep an extra representation (bablRGB) as PCS for converting to other color models and give me channels for my processing needs, great. But is there a compelling reason to change RGB from the RGB users choose to something else? Gez. P.s.: If you think this discussion is a waste of your time and my time, feel free to skip an answer. I don't think it's a waste of time at all, it's developer/user interaction regarding important aspects of the tool. Do you really think that discussing this is counterproductive? ___ 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
