Re: [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-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On 11/15/2014 08:20 PM, Øyvind Kolås wrote: On Sat, Nov 15, 2014 at 8:01 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: This really is my last post on unbounded sRGB unless someone has a specific question to ask. Well, I think a question was asked. On 11/14/2014 11:47 AM, Øyvind Kolås wrote: I ask for an assumption of good faith, that the babl/GEGL developers know what they are doing and have incorporated your input from April on out how multiply and gamma produce undesirable results for values outside the 0.0-1.0 range working with unbounded sRGB. That we want to and will incorporate that in the color management model of GEGL. A model that differs from how traditional ICC based photo editors traditionally work, GEGL has both internal (babl) and external (ICC) color management; and you have correctly pointed out that the internal color management is lacking and needs to take more RGB spaces into account. I think it's important to clarify some of Pippin's misunderstandings that are betrayed in the above quote: 1. Multiply and gamma slider adjustments are both highly chromaticity dependent editing operations. What Kolås fails to acknowledge, and maybe doesn't even understand, is that this is true regardless of whether the RGB channel values are *in* or *out* of gamut with respect to the bounded sRGB color space. The multiply compositing op; doesn't really have any sliders, I don't think you intended to imply that I think the Multiply layer blend mode (compositing op) has a slider. So I'll assume you are rightly pointing to an ambiguity in how I phrased the sentence. I should have said something like this: Multiply and also Levels gamma slider adjustments. and gamma adjustments are among the things that definetely would not end up using bablRGB; regardless of how far we get in specifying other working spaces. I'm going to ask you a question. Please don't take the question the wrong way. I'm trying to establish some common ground for communication. Here's some background to the question: There are four basic mathematical operations that can be performed on the pixels in an RGB image: add and subtract, and multiply and divide. Add and subtract are inverses, and multiply and divide are inverses, so really the four basic operations reduce to two: add and multiply. Here's the question: 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. See: 1. http://nbviewer.ipython.org/github/colour-science/colour-website/blob/master/ipython/about_rendering_engines_colourspaces_agnosticism.ipynb 2. http://ninedegreesbelow.com/photography/unbounded-srgb-multiply-produces-meaningless-results.html 3. http://ninedegreesbelow.com/photography/unbounded-srgb-color-correction-fails.html 4. The list of chromaticity dependent editing operations is much longer than just multiply and gamma slider adjustments: * For editing performed on more or less perceptually uniform RGB data, the list includes essentially *all* editing operations. * For editing performed on linear gamma RGB data, the list includes at least the following operations (I haven't checked every single editing operation made available through the GIMP UI): Channel data used as a blending layer Channel data used for making selections Colors/Alien Map HSL Colors/Alien Map RGB Colors/Auto stretch contrast Colors/Auto stretch contrast HSV Colors/Channel Mixer (try Margulis' enhance green formula) Colors/Desaturate average Colors/Desaturate lightness Colors/Mono Mixer (except straight Luminosity-based BW conversion) Colors/Posterize Colors/Threshold Colors/Levels Gamma slider operations Colors/Levels Red, Green, and Blue Input/Output sliders Colors/Levels Auto Pick (used for white balancing images) Filters/Artistic/Cartoon (this uses hard-coded Y values) Filters/Edge Detect/Sobel Filters/Enhance/Red Eye Removal Filters/Noise/HSV Noise Filters/Noise/RGB Noise Filters/Artistic/Soft glow Filters/Artistic/Vignette (any color except gray, white, black) Layer blend Mode/Burn Layer blend Mode/Color Layer blend Mode/Darken only Layer blend Mode/Difference Layer blend Mode/Divide Layer blend Mode/Dodge Layer blend Mode/Hard light Layer blend Mode/Hue Layer blend Mode/Lighten only Layer blend Mode/Multiply Layer blend
Re: [Gimp-user] Time to fork BABL and GEGL
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 – The babl roadmap being incomplete/leaving room for interpretation is on purpose – what is stated there is the minimum roadmap bringing us towards a situation where such details makes sense to decide upon. Some operations we might change to not be chromaticity dependent in this way (for instance using CIE Lab or Lch) but for most of them the change will be using a babl-format specifiers like target:RGBA and target:R'G'B' instead of un-prefixed format specifiers like now, which in the future will be synonyms for sRGB:RGBA etc. 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], revisions to the file has been integrating various bits lost in the mailinglist threads. The last revisions was to add what has been stated before in gimp-developer about single-precision floating point and accumulated rounding errors – since the issue was brought up here. Once a format has been resolved using babl_format(babl, bar:RGBA float) the returned pointer would refer to the babl context that looked up bar's definition of bar. This . . . allows rigging up a situation where the user has control over the RGB space used for chromaticity dependent operations. In light of the revised roadmap and the above list of chromaticity dependent editing operations, I have two more questions. Again, I'm trying to establish common ground for communication, or at least clarify where we disagree. 1. Do you agree or disagree that for *all* chromaticity dependent editing operations, the *user* should be in control of which RGB chromaticities are used to perform the operation? That is the point of adding more, and named, RGB families to babl. Chromaticity dependent operations are the operations where we would use userRGB instead of bablRGB – effectively it being the way for the developer to say that for this operation the users chosen format should be used. using user:Y user:Y' user:R'G'B' and user:RGB would be different ways the op developer can request pixel formats based on this user choice; when the op developer knows it should (or should not) be linear of perceptual data. But also note that while in GIMPs use of babl/GEGL, there might only be one such user family of pixel formats controllable in one location of the UI, in the general flow based computing model of GEGL one might expect a single configured processing graph to have multiple userRGBs for photos coming from different sources. 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; and if there wasn't any chromaticity dependent operations – a single RGB family like bablRGB would be sufficient – You convinced us to abandon that plan in april. If a GEGL graph contains multiple different userRGBs source buffers, chromaticity independent compositing operations compositing two buffers with different RGB chromaticities need to be converted to the same linear RGB. Initially this will be bablRGB; later – depending on profiling and time for doing it – we might end up making such compositing produce output in the same RGB family as the input buffer and convert the aux buffer to the same. 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). /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
This really is my last post on unbounded sRGB unless someone has a specific question to ask. On 11/14/2014 11:47 AM, Øyvind Kolås wrote: I ask for an assumption of good faith, that the babl/GEGL developers know what they are doing and have incorporated your input from April on out how multiply and gamma produce undesirable results for values outside the 0.0-1.0 range working with unbounded sRGB. That we want to and will incorporate that in the color management model of GEGL. A model that differs from how traditional ICC based photo editors traditionally work, GEGL has both internal (babl) and external (ICC) color management; and you have correctly pointed out that the internal color management is lacking and needs to take more RGB spaces into account. I think it's important to clarify some of Pippin's misunderstandings that are betrayed in the above quote: 1. Multiply and gamma slider adjustments are both highly chromaticity dependent editing operations. What Kolås fails to acknowledge, and maybe doesn't even understand, is that this is true regardless of whether the RGB channel values are *in* or *out* of gamut with respect to the bounded sRGB color space. 2. Given that multiply and gamma slider adjustments produce different results in different RGB working spaces, only the *artist* has the right to decide which results are better. Developers aren't in a position to make this decision on behalf of users. 3. The fact that multiplying and making gamma slider adjustments on out of gamut channel values produce absolutely *meaningless* results is just icing on the badly baked cake that is unbounded sRGB. The artist's control over her own RGB data is already removed as soon as her RGB data is converted to unbounded sRGB without her consent. 4. The list of chromaticity dependent editing operations is much longer than just multiply and gamma slider adjustments: * For editing performed on more or less perceptually uniform RGB data, the list includes essentially *all* editing operations. * For editing performed on linear gamma RGB data, the list includes at least the following operations (I haven't checked every single editing operation made available through the GIMP UI): Channel data used as a blending layer Channel data used for making selections Colors/Alien Map HSL Colors/Alien Map RGB Colors/Auto stretch contrast Colors/Auto stretch contrast HSV Colors/Channel Mixer (try Margulis' enhance green formula) Colors/Desaturate average Colors/Desaturate lightness Colors/Mono Mixer (except straight Luminosity-based BW conversion) Colors/Posterize Colors/Threshold Colors/Levels Gamma slider operations Colors/Levels Red, Green, and Blue Input/Output sliders Colors/Levels Auto Pick (used for white balancing images) Filters/Artistic/Cartoon (this uses hard-coded Y values) Filters/Edge Detect/Sobel Filters/Enhance/Red Eye Removal Filters/Noise/HSV Noise Filters/Noise/RGB Noise Filters/Artistic/Soft glow Filters/Artistic/Vignette (any color except gray, white, black) Layer blend Mode/Burn Layer blend Mode/Color Layer blend Mode/Darken only Layer blend Mode/Difference Layer blend Mode/Divide Layer blend Mode/Dodge Layer blend Mode/Hard light Layer blend Mode/Hue Layer blend Mode/Lighten only Layer blend Mode/Multiply Layer blend Mode/Overlay Layer blend Mode/Screen Layer blend Mode/Saturation Layer blend Mode/Value Paint tools depend on the working space chromaticities when using the following blend Modes: Burn, Color, Darken only, Difference, Divide, Dodge, Hard light, Hue, Lighten only, Multiply, Overlay, Saturation, Screen, Soft light, Value. In other words, *most* editing operations are chromaticity dependent. This means the *artist*, not the developer, is the only person who should choose the RGB working space. 5. Putting aside color gamut limitations, the editing operations that are chromaticity *in*dependent already produce exactly the same results (same XYZ colors) in all RGB working spaces. So for chromaticity *in*dependent editing operations, there is no point whatsoever in forcing these operations to be performed in the unbounded sRGB color space. But there are two serious *dis*advantages: 1. Conversions between color spaces necessarily involve floating point rounding errors, and rounding errors will accumulate over time as the RGB channel data is needlessly converted back and forth between the user's chosen RGB working space and unbounded sRGB. 2. The user is entirely at the mercy of developer decisions as to which operations will be done in the user's chosen RGB working space and which will be done in the unbounded sRGB color space. This article
Re: [Gimp-user] Time to fork BABL and GEGL
On 11/14/2014 12:01 PM, Alexandre Prokoudine wrote: Øyvind, having a last say in every dispute typically makes one look like a jerk. I am a living proof of that. My apologies to Simon and Alex for continuing this discussion, and yes I guess I'll be the jerk with the last word unless Pippin wants to respond. On 11/14/2014 11:47 AM, Øyvind Kolås wrote: I was saying that one can construct a scene, that photographed with your camera, would yield the type of desired black and white - when done in sRGB or some other non sensor RGB space. So yes; for the purposes of black and white conversion and using a single channel for it - I still call that image a corner case. I have no idea what Pippin means by one can construct a scene, that photographed with your camera, would yield the type of desired black and white - when done in sRGB or some other non sensor RGB space. If someone can help me out here, I'd be grateful. In the meantime, as a note to Pippin, it sort of sounds like you expect photographers to change their workflow and their way of taking pictures to suit your unbounded sRGB architecture. The yellow flower in question is long dead. So if there ever was a possibility of reshooting the scene in a way that would make the blue channel information available for use in the sRGB color space, that possibility is gone. The flower's blue channel has interesting detail that is missing in the red and green channels. I used the blue channel as a blending layer over a straight luminance-based conversion to black and white. Here's a link to my envisioned black and white conversion: http://ninedegreesbelow.com/gimpgit/gimp-srgb/channel-mix-blend/flower-blue-channel-over-luminance.jpg This article shows what happened when I tried to do the envisioned conversion to black and white in the unbounded sRGB color space: Channel blending when converting to black and white can fail completely in the unbounded sRGB color space (http://ninedegreesbelow.com/photography/unbounded-srgb-channel-blend-convert-black-white.html) Frankly I am appalled that Pippin says my yellow flower image represents a corner case. How many of *your* images will he dismiss as corner cases? Elle ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
16 нояб. 2014 г. 3:05 пользователь billn for...@gimpusers.com написал: My way or the highway developers. How many would love to fork? LIbreoffice and Ubuntu folks may help with funds needed to move Gimp to the next level. This is free software, so you are entitled to forking it, even if you don't understand why you would be doing that, exactly. And you do not understand that judging by how easily you dismiss both sides of the argument telling you there is no controversy, just misunderstanding. I strongly suggest that you start your own mailing list to discuss all these forks you've been talkibg about. Your further emails here will be regrettably moderated. Alex ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On 16.11.2014 01:31, Alexandre Prokoudine wrote: 16 нояб. 2014 г. 3:05 пользователь billn for...@gimpusers.com написал: My way or the highway developers. Your further emails here will be regrettably moderated. [x] done -- Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On Sat, Nov 15, 2014 at 8:01 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: This really is my last post on unbounded sRGB unless someone has a specific question to ask. On 11/14/2014 11:47 AM, Øyvind Kolås wrote: I ask for an assumption of good faith, that the babl/GEGL developers know what they are doing and have incorporated your input from April on out how multiply and gamma produce undesirable results for values outside the 0.0-1.0 range working with unbounded sRGB. That we want to and will incorporate that in the color management model of GEGL. A model that differs from how traditional ICC based photo editors traditionally work, GEGL has both internal (babl) and external (ICC) color management; and you have correctly pointed out that the internal color management is lacking and needs to take more RGB spaces into account. I think it's important to clarify some of Pippin's misunderstandings that are betrayed in the above quote: 1. Multiply and gamma slider adjustments are both highly chromaticity dependent editing operations. What Kolås fails to acknowledge, and maybe doesn't even understand, is that this is true regardless of whether the RGB channel values are *in* or *out* of gamut with respect to the bounded sRGB color space. The multiply compositing op; doesn't really have any sliders, and gamma adjustments are among the things that definetely would not end up using bablRGB; regardless of how far we get in specifying other working spaces. 2. Given that multiply and gamma slider adjustments produce different results in different RGB working spaces, only the *artist* has the right to decide which results are better. Developers aren't in a position to make this decision on behalf of users. 3. The fact that multiplying and making gamma slider adjustments on out of gamut channel values produce absolutely *meaningless* results is just icing on the badly baked cake that is unbounded sRGB. The artist's control over her own RGB data is already removed as soon as her RGB data is converted to unbounded sRGB without her consent. 4. The list of chromaticity dependent editing operations is much longer than just multiply and gamma slider adjustments: * For editing performed on more or less perceptually uniform RGB data, the list includes essentially *all* editing operations. * For editing performed on linear gamma RGB data, the list includes at least the following operations (I haven't checked every single editing operation made available through the GIMP UI): Channel data used as a blending layer Channel data used for making selections Colors/Alien Map HSL Colors/Alien Map RGB Colors/Auto stretch contrast Colors/Auto stretch contrast HSV Colors/Channel Mixer (try Margulis' enhance green formula) Colors/Desaturate average Colors/Desaturate lightness Colors/Mono Mixer (except straight Luminosity-based BW conversion) Colors/Posterize Colors/Threshold Colors/Levels Gamma slider operations Colors/Levels Red, Green, and Blue Input/Output sliders Colors/Levels Auto Pick (used for white balancing images) Filters/Artistic/Cartoon (this uses hard-coded Y values) Filters/Edge Detect/Sobel Filters/Enhance/Red Eye Removal Filters/Noise/HSV Noise Filters/Noise/RGB Noise Filters/Artistic/Soft glow Filters/Artistic/Vignette (any color except gray, white, black) Layer blend Mode/Burn Layer blend Mode/Color Layer blend Mode/Darken only Layer blend Mode/Difference Layer blend Mode/Divide Layer blend Mode/Dodge Layer blend Mode/Hard light Layer blend Mode/Hue Layer blend Mode/Lighten only Layer blend Mode/Multiply Layer blend Mode/Overlay Layer blend Mode/Screen Layer blend Mode/Saturation Layer blend Mode/Value Paint tools depend on the working space chromaticities when using the following blend Modes: Burn, Color, Darken only, Difference, Divide, Dodge, Hard light, Hue, Lighten only, Multiply, Overlay, Saturation, Screen, Soft light, Value. In other words, *most* editing operations are chromaticity dependent. This means the *artist*, not the developer, is the only person who should choose the RGB working space. 5. Putting aside color gamut limitations, the editing operations that are chromaticity *in*dependent already produce exactly the same results (same XYZ colors) in all RGB working spaces. So for chromaticity *in*dependent editing operations, there is no point whatsoever in forcing these operations to be performed in the unbounded sRGB color space. But there are two serious *dis*advantages: 1. Conversions between color spaces necessarily involve floating point rounding errors, and rounding errors will accumulate over
Re: [Gimp-user] Time to fork BABL and GEGL
On Fri, Nov 14, 2014 at 6:03 AM, billn wrote: BABL has been on the drawing board since 2008? 6 years and still not a no go for a stable Gimp 2.10 release. Changing Gimp license may be faster than waiting another 3-5 years for a stable BABL so Gimp can use better open source tools. Are you suggesting that relicensing babl would somehow magically right all wrongs? :) How? Alex ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
Von: Alexandre Prokoudine alexandre.prokoud...@gmail.com On Fri, Nov 14, 2014 at 6:03 AM, billn wrote: BABL has been on the drawing board since 2008? 6 years and still not a no go for a stable Gimp 2.10 release. Changing Gimp license may be faster than waiting another 3-5 years for a stable BABL so Gimp can use better open source tools. Are you suggesting that relicensing babl would somehow magically right all wrongs? :) How? Do not feed the troll. -- Regards, Michael GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On 11/14/2014 02:15 AM, Øyvind Kolås wrote: On Sun, Nov 9, 2014 at 12:23 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: if the other babl/GEGL/GIMP developers really are in agreement with Jon Nordby (the babl roadmap leaves room for differing interpretations), then there is no reason whatsoever for further discussion of forking babl and GEGL to benefit GIMP. Misinterpreting is your choice. You still seem to have little trust that babl/GEGL/GIMP developers have the interests of users/colors or the future of their software in mind. Really there is only one developer who's current stance on unbounded sRGB seems a little unclear. babl/GEGL/GIMP developers have had rough consensus on this topic since march or april, You are somewhat rewriting history: In 2011 Kolås said: My stance is that the sliders on an operations should be predictable and always do the same thing for the colorimetrically absolute same color . . . . The RGB space defined by and used by babl uses the same primaries as sRGB (http://article.gmane.org/gmane.comp.video.gimp.devel/19916) In 2012 Kolås said: ICC profiles should only need to be involved upon loading files from disk and exporting to files used outside - internally it is up to GIMP/GEGL/babl to assign appropriate fully color managed color spaces to the raster storage of the buffers in the layers; for 8bpc precision this will be sRGB and for higher bitdepths this should be linear light/linear scRGB . . . . this differs from any assumptions that might have been in 2.8 and before wrt color management and the ability to assign color profiles to images; I would not trust (and want GIMP to get rid of) any such things in the UI. (https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00261.html) In March 2014 Kolås confirmed that images would be converted to unbounded sRGB before editing could begin (https://mail.gnome.org/archives/gimp-developer-list/2014-March/msg00086.html). In April 2014 I asked for explicit confirmation that in GIMP 2.10 all images would be converted to unbounded sRGB before editing would begin (extended and unbounded mean the same thing): [Q] Will the image be converted to extended sRGB before image editing can begin? [A] Yes. (https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg1.html) In April 2014 two other GIMP users and myself started testing whether unbounded sRGB actually was a viable model for image editing, and I took on the task of posting our results to the GIMP developers mailing list. Initially Kolås dismissed our results as involving extreme edits and/or colors that hardly ever showed up in real images. Then he decided that at some point in the future special treatment might be needed for some images, some of the time. The record is in the April and May GIMP developer's mailing list: Some blend modes break in unbounded mode sRGB (https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg00049.html) GIMP and Adobe RGB (1998) (https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg00094.html) Attempt to summarize the discussion of my examples of what doesn't work in unbounded sRGB (https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg00102.html) Drawing Rec 2020 gradients in the unbounded mode sRGB color space (https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg00103.html) Gamma slider adjustments don't work in unbounded mode sRGB (https://mail.gnome.org/archives/gimp-developer-list/2014-April/msg00133.html) Possible approach for some non-sRGB GEGL/GIMP color workflows (https://mail.gnome.org/archives/gimp-developer-list/2014-May/msg00059.html) Then I gave up the discussion as a lost cause, until this article was posted to the web: About Rendering Engines Colourspaces Agnosticism (http://nbviewer.ipython.org/github/colour-science/colour-website/blob/master/ipython/about_rendering_engines_colourspaces_agnosticism.ipynb) GIMP being extremely important free/libre editing software, it seemed worthwhile to start another discussion on the topic of unbounded sRGB: Don't make an architectural mistake based on a groundless premise (https://mail.gnome.org/archives/gimp-developer-list/2014-October/msg2.html) Twice in subsequent discussion it seemed that at least some of the babl/GEGL/GIMP devs had given up on unbounded sRGB, but each time Kolås made it clear that Kolås hadn't given up on unbounded sRGB. Here's Kolås's last public statement on the topic of unbounded sRGB (bablRGB and fixed linear RGB both mean unbounded sRGB): the first thing we should do is to annotate all the operations which are broken when done with sRGB primaries, then we will be able to continue refactoring, profiling and optimizing; without breaking existing functionality/rendering. Not only in terms of making more operations request directly userRGB, but also doing things like make some linear operations accept
Re: [Gimp-user] Time to fork BABL and GEGL
On 11/14/2014 04:56 AM, Alexandre Prokoudine wrote: On Fri, Nov 14, 2014 at 6:03 AM, billn wrote: BABL has been on the drawing board since 2008? 6 years and still not a no go for a stable Gimp 2.10 release. Changing Gimp license may be faster than waiting another 3-5 years for a stable BABL so Gimp can use better open source tools. Are you suggesting that relicensing babl would somehow magically right all wrongs? :) How? I *think* Bill N might think that forking babl would mean that GIMP development could switch to a release early and often approach to future development. I think that's the difference between OpenOffice and LibreOffice that he's pointed to. People who don't make a habit of reading the babl/GEGL/GIMP git logs on a regular basis might not realize what a huge amount of coding effort has gone into the conversion to a geglified GIMP. It's not a matter of incremental improvements. Elle ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On Fri, Nov 14, 2014 at 1:26 PM, Elle Stone Really there is only one developer who's current stance on unbounded sRGB seems a little unclear. Or there is one time-thief that continues to not understand what a PCS is in a color management system, what implementation details mean; which is allergic to implementation details involving anything relating to sRGB; that continues to argue over her own misunderstandings of the architecture. The writeup in the babl roadmap document is a summary of the ideas that have been around since LGM in Leipzig; which was in the beginning of April this year. You convinced us that we had to care about RGB spaces beyond sRGB; and we decided to incorporate that in the architecture with a concept of a target-space; this was in my eyes thus far your thus far last positive contribution. I have spent hundreds of hours more on babl/GEGL this year than I intended, most of them on unproductive arguments on mailinglists, a medium I not well suited for clearing up misunderstandings but you refuse to spend time where the developers normally clear up misunderstandings, reach consensus and make plans; on IRC. I wrote the babl roadmap when it became clear that playing in your preferred medium, on the mailinglist, answering your questions was more conductive to deepen misunderstandings than clear them up. Like the continued refusal to understand that converting to unbounded linear sRGB on import to the system would be an implementation detail and not neccesarily mean that any processing would necessarily happen in that format - as well as broader principles of software engineering and how one keeps working code working. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On 11/14/2014 09:04 AM, Øyvind Kolås wrote: I have spent hundreds of hours more on babl/GEGL this year than I intended, most of them on unproductive arguments on mailinglists, a medium I not well suited for clearing up misunderstandings I agree with you 100% that you shouldn't waste your time responding to mailing list discussions. Personally I would very much prefer that you use your time to: * Write the requisite babl format specifiers for allowing GEGL and GIMP code to be modified so functions can use Y and XYZ values from the user's chosen RGB working space, instead of using hard-coded sRGB values. * Write the requisite generalized or additional babl functions so that when the user draws on a mask or uses a grayscale image as a mask, the mask is drawn using the correct Y values from the user's chosen RGB working space, instead of using hard-coded sRGB Y values. * And maybe fix the babl conversion to LAB code that still uses unadapted D65 sRGB values instead of the D50-adapted values suitable for an ICC profile color-managed workflow. The current code produces wrong results for ICC profile color-managed sRGB images, and even more so for images in other RGB working spaces. However, I do understand that proper ICC profile color management isn't a high priority for GIMP 2.10. So the hard-coded sRGB values might still be in the code base when GIMP 2.10 is released, which would mean GIMP 2.10 would produce incorrect results for some operations, for images that aren't sRGB images. but you refuse to spend time where the developers normally clear up misunderstandings, reach consensus and make plans; on IRC. As you well know, I did try discussing unbounded sRGB with you on IRC. On IRC you felt free to issue personal insults. And you wasted time eliciting general agreement from people who learned everything they know about color management from you. I wrote the babl roadmap when it became clear that playing in your preferred medium, on the mailinglist, answering your questions was more conductive to deepen misunderstandings than clear them up. Like the continued refusal to understand that converting to unbounded linear sRGB on import to the system would be an implementation detail and not neccesarily mean that any processing would necessarily happen in that format - STILL you want to convert to unbounded sRGB upon opening an image? STILL?? Why What is this implementation detail supposed to accomplish? In case you hadn't noticed, I had already ceased discussing unbounded sRGB, on the apparently quite mistaken assumption that the unbounded sRGB architecture had actually been abandoned. In an ICC profile color-managed workflow: * sRGB is just another RGB working space. * sRGB doesn't require special treatment, being handled just fine by generalized code that retrieves the user's chosen RGB working space's Y and XYZ values. * Developers need to respect the user's RGB data. There is *never* any justification for forcibly convert the user's RGB data to an RGB working space not of the user's choosing. as well as broader principles of software engineering and how one keeps working code working. Nothing in the current GIMP code base depends on unbounded sRGB. No GIMP functionality will be broken by not writing new code that will convert the user's image to unbounded sRGB. If you insist on writing special sRGB only code (unbounded or otherwise), at least give the user the option to opt out of using such code, even for sRGB images. /pippin Elle ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On Fri, Nov 14, 2014 at 3:48 PM, Elle Stone but you refuse to spend time where the developers normally clear up misunderstandings, reach consensus and make plans; on IRC. As you well know, I did try discussing unbounded sRGB with you on IRC. On IRC you felt free to issue personal insults. And you wasted time eliciting general agreement from people who learned everything they know about color management from you. If calling the examples you used for corner cases, and that one can construct scenes favoring different RGB spaces for orthogonality between channels - not only the sensor space - a personal insult; I call it being direct. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
Hi Pippin, Hi Elle. I know that i am not really a neutral party in this dispute, but I'll try anyways? WILL YOU TWO PLEASE STOP FIGHTING? Neither is Elle in the position to tell pippin what he is supposed to work on, nor is pippin right when he holds Elle responsible for the time he decided to waste in this discussion. Elle is entitled to a told you so when we claim this feature to be done and she can figure out from the outer workflow if internal conversions happened or not. Sheesh. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On 11/14/2014 11:08 AM, Øyvind Kolås wrote: On Fri, Nov 14, 2014 at 3:48 PM, Elle Stone but you refuse to spend time where the developers normally clear up misunderstandings, reach consensus and make plans; on IRC. As you well know, I did try discussing unbounded sRGB with you on IRC. On IRC you felt free to issue personal insults. And you wasted time eliciting general agreement from people who learned everything they know about color management from you. If calling the examples you used for corner cases, and that one can construct scenes favoring different RGB spaces for orthogonality between channels - not only the sensor space - a personal insult; I call it being direct. /pippin My apologies, I don't understand what you are trying to say. Can you give links to specific mailing list threads? Are you perhaps again saying that my yellow flower image is a corner case and therefore it's OK to write an image editor that makes it literally impossible for me to perform my envisioned conversion to black and white? As an aside, insults are things like: * backseat driver * half-knowledgeable filibusterer (I'm only guessing that was directed at me; perhaps I'm wrong) * suggesting on IRC that I'm insulting GIMP (which I have never done, GIMP is my favorite RGB image editor) when really I'm questioning your understanding of the requirements for proper RGB image editing * suggesting that because I agree that you are intelligent (obviously you are), therefore I should stop trying to educate you about where your color management theories took a wrong turn and are threatening to take GIMP with them. ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On 11/14/2014 11:21 AM, Simon Budig wrote: Hi Pippin, Hi Elle. I know that i am not really a neutral party in this dispute, but I'll try anyways? WILL YOU TWO PLEASE STOP FIGHTING? Neither is Elle in the position to tell pippin what he is supposed to work on, nor is pippin right when he holds Elle responsible for the time he decided to waste in this discussion. Elle is entitled to a told you so when we claim this feature to be done and she can figure out from the outer workflow if internal conversions happened or not. Sheesh. Bye, Simon +1 Elle ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On Fri, Nov 14, 2014 at 4:24 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: My apologies, I don't understand what you are trying to say. Can you give links to specific mailing list threads? Are you perhaps again saying that my yellow flower image is a corner case and therefore it's OK to write an image editor that makes it literally impossible for me to perform my envisioned conversion to black and white? I was saying that one can construct a scene, that photographed with your camera, would yield the type of desired black and white - when done in sRGB or some other non sensor RGB space. So yes; for the purposes of black and white conversion and using a single channel for it - I still call that image a corner case. * backseat driver * half-knowledgeable filibusterer (I'm only guessing that was directed at me; perhaps I'm wrong) * suggesting on IRC that I'm insulting GIMP (which I have never done, GIMP is my favorite RGB image editor) when really I'm questioning your understanding of the requirements for proper RGB image editing * suggesting that because I agree that you are intelligent (obviously you are), therefore I should stop trying to educate you about where your color management theories took a wrong turn and are threatening to take GIMP with them. You are quoting later venting of frustration with your later walls of text on the mailinglists questioning and demanding answers for every single little detail before details even exist. One of your quotes isn't even from IRC; and guess what, if you were on IRC I would have asked you questions there instead of venting frustration about your mailinglist posts. I ask for an assumption of good faith, that the babl/GEGL developers know what they are doing and have incorporated your input from April on out how multiply and gamma produce undesirable results for values outside the 0.0-1.0 range working with unbounded sRGB. That we want to and will incorporate that in the color management model of GEGL. A model that differs from how traditional ICC based photo editors traditionally work, GEGL has both internal (babl) and external (ICC) color management; and you have correctly pointed out that the internal color management is lacking and needs to take more RGB spaces into account. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
14 нояб. 2014 г. 19:47 пользователь Øyvind Kolås pip...@gimp.org написал: You are quoting later venting of frustration with your later walls of text on the mailinglists questioning and demanding answers for every single little detail before details even exist. Øyvind, having a last say in every dispute typically makes one look like a jerk. I am a living proof of that. Elle, we do invite you to attend Libre Graphics Meeting 2015 in Toronto, April 29 to May 2. Travel expenses will be covered. Alex ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On 11/14/2014 12:01 PM, Alexandre Prokoudine wrote: 14 нояб. 2014 г. 19:47 пользователь Øyvind Kolås pip...@gimp.org написал: You are quoting later venting of frustration with your later walls of text on the mailinglists questioning and demanding answers for every single little detail before details even exist. Øyvind, having a last say in every dispute typically makes one look like a jerk. I am a living proof of that. I don't know as Pippin intended to have the last say. I replied to Pippin's next-to-last post about a half-minute before Simon's very wise post arrived in my inbox. So the timestamps are out of order. Pippin likewise may have hit the send button before receiving Simon's post. Elle, we do invite you to attend Libre Graphics Meeting 2015 in Toronto, April 29 to May 2. Travel expenses will be covered. Alex, that is very kind. If at all possible I will atttend. Toronto is easier than Germany. But other obligations unfortunately make travelling even to Toronto a bit difficult. Alex ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] Time to fork BABL and GEGL
BABL has been on the drawing board since 2008? 6 years and still not a no go for a stable Gimp 2.10 release. Changing Gimp license may be faster than waiting another 3-5 years for a stable BABL so Gimp can use better open source tools.. I agree with Alexandre. If I really do understand what Jon Nordby is saying (see https://mail.gnome.org/archives/gimp-developer-list/2014-November/msg00018.html and https://mail.gnome.org/archives/gimp-developer-list/2014-November/msg00023.html), and if the other babl/GEGL/GIMP developers really are in agreement with Jon Nordby (the babl roadmap leaves room for differing interpretations), then there is no reason whatsoever for further discussion of forking babl and GEGL to benefit GIMP. -- billn (via www.gimpusers.com/forums) ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On Sun, Nov 9, 2014 at 12:23 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: if the other babl/GEGL/GIMP developers really are in agreement with Jon Nordby (the babl roadmap leaves room for differing interpretations), then there is no reason whatsoever for further discussion of forking babl and GEGL to benefit GIMP. Misinterpreting is your choice. You still seem to have little trust that babl/GEGL/GIMP developers have the interests of users/colors or the future of their software in mind. babl/GEGL/GIMP developers have had rough consensus on this topic since march or april, and the roadmap is as detailed as it is not for the benefit of babl/GEGL developers but to contrast the endless and pointless email threads. If the hundreds of hours donated/devoted to the topic had been spent on actual development instead of disagreement about how the software should be developed, we would have a more capable stack already. /pippin ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On Saturday 08 November 2014 22:27:45 billn did opine And Gene did reply: Time to fork off BABL and GEGL. Forking was good for Openoffice. LIbreoffice is kicking tail. Developers who want to turn out a good product in a timely manner and other programmers who want to wait 3-5 years for small improvements. LOL Thats a yes and no situation. None of the artwork examples that many megabytes of that come with OO, do not come with LO for copyright reasons. And despite that I still like LO better, I have now tried to dl the latest update 7 times, 6 of those made it to something north of 208 megs and stalled, and once only to about 30 megs. I have no clue how many megs the tarball actually is, oly that if I rename it so a tar session can unpack it, the tarball is incomplete. I am tempted to think that it stalls if you do not make a donation from that same screen, and I am not the least allergic to supporting the project, but I don't buy a 3 legged pig in a poke. Cheers, Gene Heskett -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Genes Web page http://geneslinuxbox.net:6309/gene US V Castleman, SCOTUS, Mar 2014 is grounds for Impeaching SCOTUS ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
On 11/09/2014 02:56 AM, Alexandre Prokoudine wrote: 09 нояб. 2014 г. 6:28 пользователь billn for...@gimpusers.com написал: Time to fork off BABL and GEGL. Forking was good for Openoffice. LIbreoffice is kicking tail. Developers who want to turn out a good product in a timely manner and other programmers who want to wait 3-5 years for small improvements. LOL I'm not sure if it was meant as sarcasm or if it was serious. However, if you are not personally prepared to maintain a develop fork, you might reconsider publicly suggesting something that makes sense so little that you'd need a microscope to expertly deal with it. The topic of forking the libraries was born out of miscommunication. Could we please finally bury this? I agree with Alexandre. If I really do understand what Jon Nordby is saying (see https://mail.gnome.org/archives/gimp-developer-list/2014-November/msg00018.html and https://mail.gnome.org/archives/gimp-developer-list/2014-November/msg00023.html), and if the other babl/GEGL/GIMP developers really are in agreement with Jon Nordby (the babl roadmap leaves room for differing interpretations), then there is no reason whatsoever for further discussion of forking babl and GEGL to benefit GIMP. ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
[Gimp-user] Time to fork BABL and GEGL
Time to fork off BABL and GEGL. Forking was good for Openoffice. LIbreoffice is kicking tail. Developers who want to turn out a good product in a timely manner and other programmers who want to wait 3-5 years for small improvements. LOL -- billn (via www.gimpusers.com/forums) ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
Re: [Gimp-user] Time to fork BABL and GEGL
09 нояб. 2014 г. 6:28 пользователь billn for...@gimpusers.com написал: Time to fork off BABL and GEGL. Forking was good for Openoffice. LIbreoffice is kicking tail. Developers who want to turn out a good product in a timely manner and other programmers who want to wait 3-5 years for small improvements. LOL I'm not sure if it was meant as sarcasm or if it was serious. However, if you are not personally prepared to maintain a develop fork, you might reconsider publicly suggesting something that makes sense so little that you'd need a microscope to expertly deal with it. The topic of forking the libraries was born out of miscommunication. Could we please finally bury this? Alex ___ gimp-user-list mailing list List address:gimp-user-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list
