Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL
On 11/07/2014 04:25 AM, Simos Xenitellis wrote:
Hi All,
I am a recent subscriber to the list and I have read with interest the
recent threads and I am trying to figure out the "what next?".
Developer resources in any project are generally very limited, so it's
important to get more people contributing.
Is there a test suite available that could show the expected behavior?
If not, let's try to build one, both the test-suite code plus the images
(before/after).
Regarding the color spaces and conversions, it should be easy to try to
make some of the the changes
(most of them sound like simple text substitutions),
compile the source and see how well it performs on the test-suite.
Any comments on that?
Simos
The text/code editor Geany can be used to do a file search in GEGL and
GIMP for the following string (confine the search to *.c and *.h files):
babl_format ("
GEGL has 212 such strings. GIMP has 503.
Here are some example strings with the actual babl formats included (the
list is not exhaustive):
babl_format ("Y' u8")
babl_format ("Y u32")
babl_format ("YA u32")
babl_format ("Y float")
babl_format ("Y' float")
babl_format ("Y'A float")
babl_format ("Y'CbCrA float")
babl_format ("R'G'B'A u8")
babl_format ("R'G'B'A u16")
babl_format ("R'G'B' float")
babl_format ("R'G'B'A float")
babl_format ("R'aG'aB'aA float")
babl_format ("CIE Lab alpha float")
and so on . . .
If I understand Jon Nordby correctly, all of these babl_formats really
are supposed to be dedicated formats that were intended to be used only
with images encoded using the sRGB primaries. Changing the intended
meaning of these formats might break compatibility with other software
that uses babl.
So new babl_formats need to be written to take the place of all the
"dedicated sRGB only" formats. Then the text substitutions could be made.
The problem is made more complicated by the fact that babl does many of
the calculations for GEGL and GIMP functions that use Y (in particular
painting on a mask and making an grayscale copy of the image for use as
a mask). Babl also does the conversions to the YCbCr and CIELAB formats
for GEGL and GIMP.
So all the babl functions that currently use hard-coded sRGB parameters
either need to be generalized to use parameters pulled from UserRGB
(meaning whatever RGB working space the user chooses, which might in
fact be sRGB, or might be ProPhotoRGB, or etc). Or else duplicate babl
functions for UserRGB need to be written.
The same is true for GEGL and GIMP functions that use Y to calculate
Luminance, except most likely for GEGL and GIMP there won't be any "side
by side" generalized and sRGB-only functions. Instead the existing
functions will all be generalized.
Only a few GIMP UI functions use RGB working-space-specific ("UserRGB")
Y and XYZ values. This article lists where UserRGB Y and XYZ parameters
need to be used:
http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html
To avert any possible confusion, when you open an image using GIMP,
there is not and never has been a forced conversion from UserRGB to
sRGB. The previously planned code that would have done so, never was
written. If I understand Jon Nordby correctly, the development plan that
would have required such code seems to have been put aside.
Currently only a few GIMP UI editing operations (that use Y to calculate
Luminance or XYZ to convert to LAB) are affected by the "babl_format"
assumption that the image really is an sRGB image. This article lists
most of the GIMP UI functions that are currently only accurate for sRGB
images:
http://ninedegreesbelow.com/photography/users-guide-to-high-bit-depth-gimp.html
Hopefully Jon Nordby will point out any mistakes I might have made in
the above summary.
Best regards,
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] [Gimp-developer] GIMP should fork babl and GEGL
On Thu, Nov 6, 2014 at 10:00 PM, Elle Stone wrote: > On 11/06/2014 12:35 PM, Gary Aitken wrote: > >> Maybe I'm misunderstanding the discussion. Gimp asks when one opens an >> image what one wants as the working colorspace. But we're talking >> about operations *after* the image has been opened and the working >> colorspace has been established. >> >> Once I establish the colorspace, I expect all operations to be performed >> in a manner which is consistent with and preserves that colorspace. If >> some operation deals in some other space without my knowledge, that's >> not good. >> >> My apologies if I'm misunderstanding the discussion. >> > > You aren't misunderstanding the discussion. > > The current proposed solution to the current hard-coded Y and XYZ sRGB > parameters is to generalize all editing operations to use UserRGB Y and XYZ. > > But there are a handful of editing operations that can't be generalized, > that only work properly when done on actual sRGB images. > > One proposed solution to the "only works in sRGB" problem is to convert > the image to sRGB for those few editing operations. That would be OK as an > *option*. Even just a UI notification would be sufficient and then the user > could choose to convert to sRGB or to simply not use that particular > editing operation. > > Previously (back in April) the plan was to convert all images to unbounded > sRGB before editing would begin, and the user wouldn't have a choice in the > matter. > > More recently the plan was to convert to unbounded sRGB for just some > editing operations and use UserRGB for other editing operations, and again > the user wouldn't have a choice in the matter. > > At this point we hopefully are down to "only convert to sRGB for those > very few editing operations that really only work in the sRGB color space". > > I'm saying "and make sure you still give the user a choice." There should > never, ever be a forced conversion to sRGB. The only correct thing to do is > tell the user what the problem is and let the user decide what to do, > either convert to sRGB or else don't use the affected editing operation. > > In addition to trying to avert any forced ICC profile conversions, I'm > also concerned about special "sRGB only optimized code". > > Personally I would prefer that sRGB be treated just like any other RGB > working space, with no special "sRGB only optimized code paths", partly > because there are too many sRGB profile variants (Will the Real sRGB > Profile Please Stand Up? http://ninedegreesbelow.com/ > photography/srgb-profile-comparison.html). > > Giving the user a choice whether to use or not use "optimized sRGB only > code paths" would be OK. Not telling the user that sRGB images might be > handled differently is not OK. > > I don't want the devs to decide for me that "this profile is close enough > to sRGB that we'll just assume it really is the same as GIMP's sRGB and > then we'll use different code paths." > > Even if the image profile really is the GIMP sRGB profile, I still think > the user should have a choice of whether to use "optimized sRGB only" code > paths. > > Given the previously planned forced conversions to unbounded sRGB, I think > it's important to stress that the user really does need to have complete > control over when and whether: > * an image is converted from UserRGB to sRGB. > * the GIMP sRGB profile is assumed to be "close enough" to some other > sRGB profile variant. > * special optimized sRGB only code is used. > > Hi All, I am a recent subscriber to the list and I have read with interest the recent threads and I am trying to figure out the "what next?". Developer resources in any project are generally very limited, so it's important to get more people contributing. Is there a test suite available that could show the expected behavior? If not, let's try to build one, both the test-suite code plus the images (before/after). Regarding the color spaces and conversions, it should be easy to try to make some of the the changes (most of them sound like simple text substitutions), compile the source and see how well it performs on the test-suite. Any comments on that? Simos ___ 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] [Gimp-developer] GIMP should fork babl and GEGL
On 11/06/2014 12:35 PM, Gary Aitken wrote: Maybe I'm misunderstanding the discussion. Gimp asks when one opens an image what one wants as the working colorspace. But we're talking about operations *after* the image has been opened and the working colorspace has been established. Once I establish the colorspace, I expect all operations to be performed in a manner which is consistent with and preserves that colorspace. If some operation deals in some other space without my knowledge, that's not good. My apologies if I'm misunderstanding the discussion. You aren't misunderstanding the discussion. The current proposed solution to the current hard-coded Y and XYZ sRGB parameters is to generalize all editing operations to use UserRGB Y and XYZ. But there are a handful of editing operations that can't be generalized, that only work properly when done on actual sRGB images. One proposed solution to the "only works in sRGB" problem is to convert the image to sRGB for those few editing operations. That would be OK as an *option*. Even just a UI notification would be sufficient and then the user could choose to convert to sRGB or to simply not use that particular editing operation. Previously (back in April) the plan was to convert all images to unbounded sRGB before editing would begin, and the user wouldn't have a choice in the matter. More recently the plan was to convert to unbounded sRGB for just some editing operations and use UserRGB for other editing operations, and again the user wouldn't have a choice in the matter. At this point we hopefully are down to "only convert to sRGB for those very few editing operations that really only work in the sRGB color space". I'm saying "and make sure you still give the user a choice." There should never, ever be a forced conversion to sRGB. The only correct thing to do is tell the user what the problem is and let the user decide what to do, either convert to sRGB or else don't use the affected editing operation. In addition to trying to avert any forced ICC profile conversions, I'm also concerned about special "sRGB only optimized code". Personally I would prefer that sRGB be treated just like any other RGB working space, with no special "sRGB only optimized code paths", partly because there are too many sRGB profile variants (Will the Real sRGB Profile Please Stand Up? http://ninedegreesbelow.com/photography/srgb-profile-comparison.html). Giving the user a choice whether to use or not use "optimized sRGB only code paths" would be OK. Not telling the user that sRGB images might be handled differently is not OK. I don't want the devs to decide for me that "this profile is close enough to sRGB that we'll just assume it really is the same as GIMP's sRGB and then we'll use different code paths." Even if the image profile really is the GIMP sRGB profile, I still think the user should have a choice of whether to use "optimized sRGB only" code paths. Given the previously planned forced conversions to unbounded sRGB, I think it's important to stress that the user really does need to have complete control over when and whether: * an image is converted from UserRGB to sRGB. * the GIMP sRGB profile is assumed to be "close enough" to some other sRGB profile variant. * special optimized sRGB only code is used. Best regards, 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] [Gimp-developer] GIMP should fork babl and GEGL
Hi Alex, >>> If you *ask* the user whether they want to have their data treated as >>> "bonified same as GIMP's sRGB" and then use optimized sRGB-only code, >>> that's one thing. Doing so behind the user's back, without their >>> consent, that's another thing. That is disrespecting the user's >>> control over their RGB data. >> >> This is critical. If I'm working with a wide-gamut profile, I really >> really really don't want gimp screwing with the rgb data without my >> say so. > > Frankly, I'm puzzled. It's been, how many? 8 years? since GIMP asks > users what it should do with a picture that is tagged with a profile > that doesn't match the current RGB working space. Has anyone actually > suggested that this is going to be otherwise? :) Maybe I'm misunderstanding the discussion. Gimp asks when one opens an image what one wants as the working colorspace. But we're talking about operations *after* the image has been opened and the working colorspace has been established. Once I establish the colorspace, I expect all operations to be performed in a manner which is consistent with and preserves that colorspace. If some operation deals in some other space without my knowledge, that's not good. My apologies if I'm misunderstanding the discussion. Gary ___ 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] [Gimp-developer] GIMP should fork babl and GEGL
On Thu, Nov 6, 2014 at 8:24 PM, Gary Aitken wrote: >> If you *ask* the user whether they want to have their data treated as >> "bonified same as GIMP's sRGB" and then use optimized sRGB-only code, >> that's one thing. Doing so behind the user's back, without their >> consent, that's another thing. That is disrespecting the user's >> control over their RGB data. > > This is critical. If I'm working with a wide-gamut profile, I really > really really don't want gimp screwing with the rgb data without my > say so. Frankly, I'm puzzled. It's been, how many? 8 years? since GIMP asks users what it should do with a picture that is tagged with a profile that doesn't match the current RGB working space. Has anyone actually suggested that this is going to be otherwise? :) 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] [Gimp-developer] GIMP should fork babl and GEGL
I'd like to add my penny's worth on this discussion. My primary use of gimp involves editing photographic images, for both web and print purposes. On 11/06/14 05:04, Elle Stone wrote: > Speaking as a developer (you all keep telling me I'm a developer), a > crucially important guiding principle for writing a high end image > editor is that you never mess with the user's RGB data without the > user's explicit consent. > > If you *ask* the user whether they want to have their data treated as > "bonified same as GIMP's sRGB" and then use optimized sRGB-only code, > that's one thing. Doing so behind the user's back, without their > consent, that's another thing. That is disrespecting the user's > control over their RGB data. This is critical. If I'm working with a wide-gamut profile, I really really really don't want gimp screwing with the rgb data without my say so. Even if the result is not obvious visually, I need a heads-up so I can pay close attention to what's happening and undo the operation if appropriate. Gary ___ 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] [Gimp-developer] GIMP should fork babl and GEGL
On 11/05/2014 09:40 AM, Jon Nordby wrote: On 5 November 2014 14:50, Elle Stone wrote: For the babl code that converts an sRGB image to grayscale for use as a layer mask, do you plan to add a new set of functions that convert from UserRGB to grayscale? That code would, of course, need to pull Y values from UserRGB. Which of course means that the new code for UserRGB would also work for sRGB images. For the babl code that converts from color to Y for painting on a mask, that code currently is hard-coded to use sRGB Y values. Do you plan to add a new set of functions that convert from UserRGB to Y for painting on a mask? That code would also, of course, need to pull Y values from UserRGB. Which of course means that the new code for UserRGB would also work for sRGB images. For all the GIMP UI functions that currently use hard-coded sRGB Y values sprinkled through babl, GEGL, and GIMP, do you plan to add a new set of alternate functions that will use Y values pulled from UserRGB? Again, that new UserRGB code will also work for sRGB images. How is this not side-by-side implementation? When I said "operations" I meant GEGL operations: There will be no side-by-side implementation of GEGL operations. Will this also be true of any editing operations that remain within the GIMP code base, once GIMP is fully geglified? A separate question - will there actually be any remaining editing operations in the GIMP code base once GIMP is fully geglified? Yes, we will have to introduce new babl color conversion functions which handle arbitary RGB color spaces by looking up parameters from UserRGB. Both to convert from&to grayscale and between the various RGB spaces. There is no escaping that, as we don't have any code that can handle these cases right now. OK. This makes sense. Whether the existing conversion functions with hardcoded sRGB parameters for bablRGB will remain once general functions exists, is an open question. It could be that they will just call into the general RGB color conversion functions with the particular parameters of sRGB. It seems to me that this might be the preferable course of action. This way there would be no reason for code to be written that tries to second-guess the user's intentions as to whether UserRGB really is the same as GIMP's built-in sRGB. Or it could be that keeping the functions as-is has benefits that outweigh the cost of keeping the code around, like being able to do performance optimization tricks not possible in the general case. Speaking as a developer (you all keep telling me I'm a developer), a crucially important guiding principle for writing a high end image editor is that you never mess with the user's RGB data without the user's explicit consent. If you *ask* the user whether they want to have their data treated as "bonified same as GIMP's sRGB" and then use optimized sRGB-only code, that's one thing. Doing so behind the user's back, without their consent, that's another thing. That is disrespecting the user's control over their RGB data. What part of the latest new plan am I missing? Could you explain the purpose that is served by having all the functions with hard-coded sRGB parameters sit side by side with equivalent functions that use UserRGB parameters? Or are you really getting rid of *all* the hard-coded sRGB parameters? In which case, what is the new purpose for the bablRGB formats that "will not change" their meanings? For operations which have an actual dependency on sRGB parameters, like the previously mentioned operations emulating color blindness. Two practical problems will need solutions: First, for code that clearly requires that the image be an sRGB image, converting the image to sRGB without the user's *explicit* consent is disrespecting the user's RGB data. If there are GIMP UI functions that only work for sRGB images, give the user a choice. Don't convert the image to sRGB without the user's explicit consent. Maybe they'd just as soon not use that editing operation. Second, some functions currently use sRGB and NTSC *device* parameters: * Some of the existing hard-coded sRGB *device* parameters in the code base clearly ought to be D50-adapted ICC profile parameters. That code should be generalized to use UserRGB Y and XYZ values. * Some of the functions seem to suggest that the unadapted *device* parameters really are appropriate for the originally intended use, and that the affected functions simply aren't appropriate for use in an ICC profile *color-managed* workflow. These "device" functions should be identified in the UI so the unsuspecting user doesn't try to use these functions thinking they are appropriate for ICC profile color-managed images. I think the color-deficiency filter might actually be one of these functions. Converting the image to the sRGB or NTSC ICC profile is in
Re: [Gimp-user] [Gimp-developer] GIMP should fork babl and GEGL
On 5 November 2014 13:50, Elle Stone wrote:
> On 11/04/2014 02:31 PM, Jon Nordby wrote:
>
>> (apologies for top-posting)
>>
>> Hi Elle,
>>
>> The BABL roadmap[1], which was written in response to comments raised by
>> you (and others),
>> details a mechanism for working with multiple RGB color spaces. It will
>> be possible to create a babl format specifier which means
>> "whatever-the-artist-chose-for-this-image RGB".
>> All GEGL operations which currently wrongly use hardcoded bablRGB ("RGBA
>> float" and similar) will be changed to use this new specifier.
>> Duplicate/side-by-side implementations of operations is not necessary
>> nor planned.
>>
>
> With this BABL work in place, GIMP/GEGL can then use LCMS to read in the
>> ICC color profiles from inputs and set up the parameters for this color
>> space.
>>
>> I do not understand how this solution (once implemented) will not work
>> for your usecase. If you think it will not, please explain why.
>>
>> I have no desired for a "sRGB only" workflow, and it does not help the
>> discussion to jump such a conclusion. Please do not assume that the
>> different needs are in conflict/adverserial to each other.
>>
>> 1. https://git.gnome.org/browse/babl/tree/docs/roadmap.txt#n74
>>
>
> What you just described IS side-by-side implementations of operations. In
> an ICC profile color-managed application, sRGB is just another RGB working
> space. You don't need to special-case sRGB.
>
No it is not. There will be one implementation of say "multiply". It will
be able to work on any RGB color space. Including sRGB, but without need
for special casing.
> Right now all GEGL operations specify "bablRGB": RGBA, R'G'B'A, etc.
>
> In Pippin's originally planned "unbounded sRGB architecture", "bablRGB"
> meant "convert the image to unbounded sRGB before perfoming *any* editing
> operation". Now the plan is that bablRGB will mean "convert to unbounded
> sRGB for *some* operations".
>
The meaning of the "bablRGB" specifiers has not, and will not change. The
vast majority of operations will just stop using them (because they have
hardcoded sRGB parameters), and instead use the new specifiers, as per the
roadmap.
--
Jon Nordby - www.jonnor.com
___
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] [Gimp-developer] GIMP should fork babl and GEGL
On 5 November 2014 14:50, Elle Stone wrote: > On 11/05/2014 08:22 AM, Jon Nordby wrote: > >> What you just described IS side-by-side implementations of >> operations. In an ICC profile color-managed application, sRGB is >> just another RGB working space. You don't need to special-case sRGB. >> >> >> No it is not. There will be one implementation of say "multiply". It >> will be able to work on any RGB color space. Including sRGB, but without >> need for special casing. >> >> Right now all GEGL operations specify "bablRGB": RGBA, R'G'B'A, etc. >> >> In Pippin's originally planned "unbounded sRGB architecture", >> "bablRGB" meant "convert the image to unbounded sRGB before >> perfoming *any* editing operation". Now the plan is that bablRGB >> will mean "convert to unbounded sRGB for *some* operations". >> >> >> The meaning of the "bablRGB" specifiers has not, and will not change. >> The vast majority of operations will just stop using them (because they >> have hardcoded sRGB parameters), and instead use the new specifiers, as >> per the roadmap. >> >> > For the babl code that converts an sRGB image to grayscale for use as a > layer mask, do you plan to add a new set of functions that convert from > UserRGB to grayscale? > > That code would, of course, need to pull Y values from UserRGB. Which of > course means that the new code for UserRGB would also work for sRGB images. > > For the babl code that converts from color to Y for painting on a mask, > that code currently is hard-coded to use sRGB Y values. Do you plan to add > a new set of functions that convert from UserRGB to Y for painting on a > mask? That code would also, of course, need to pull Y values from UserRGB. > Which of course means that the new code for UserRGB would also work for > sRGB images. > > For all the GIMP UI functions that currently use hard-coded sRGB Y values > sprinkled through babl, GEGL, and GIMP, do you plan to add a new set of > alternate functions that will use Y values pulled from UserRGB? Again, that > new UserRGB code will also work for sRGB images. > > How is this not side-by-side implementation? > When I said "operations" I meant GEGL operations: There will be no side-by-side implementation of GEGL operations. Yes, we will have to introduce new babl color conversion functions which handle arbitary RGB color spaces by looking up parameters from UserRGB. Both to convert from&to grayscale and between the various RGB spaces. There is no escaping that, as we don't have any code that can handle these cases right now. Whether the existing conversion functions with hardcoded sRGB parameters for bablRGB will remain once general functions exists, is an open question. It could be that they will just call into the general RGB color conversion functions with the particular parameters of sRGB. Or it could be that keeping the functions as-is has benefits that outweigh the cost of keeping the code around, like being able to do performance optimization tricks not possible in the general case. What part of the latest new plan am I missing? Could you explain the > purpose that is served by having all the functions with hard-coded sRGB > parameters sit side by side with equivalent functions that use UserRGB > parameters? > > Or are you really getting rid of *all* the hard-coded sRGB parameters? In > which case, what is the new purpose for the bablRGB formats that "will not > change" their meanings? For operations which have an actual dependency on sRGB parameters, like the previously mentioned operations emulating color blindness. Or for interacting with (sometimes broken) operating-system/library interfaces which expects sRGB. I don't expect it to be particularly common. The primary reason (as I see it) for not changing the semantics of existing specifiers is to preserve compatibility. Code outside of BABL/GEGL/GIMP could very well be reliant on the current meaning of the bablRGB formats. -- Jon Nordby - www.jonnor.com ___ 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] [Gimp-developer] GIMP should fork babl and GEGL
On 11/05/2014 09:07 AM, Simon Budig wrote: Elle Stone (ellest...@ninedegreesbelow.com) wrote: Why would any sane developer want to write all the new code and have it exist side by side with equivalent hard-coded sRGB functions? Why would any sane developer want to fork an existing libary and have it exist side by side with an equivalent but subtly incompatible library? Bye, Simon You are entirely avoiding the very pertinent question I just asked and you full well know it. Now could you try answering the question I did ask? Although frankly I'd rather hear what Jon Nordby has to say. 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] [Gimp-developer] GIMP should fork babl and GEGL
Elle Stone (ellest...@ninedegreesbelow.com) wrote: > Why would any sane developer want to write all the new code and have it > exist side by side with equivalent hard-coded sRGB functions? Why would any sane developer want to fork an existing libary and have it exist side by side with an equivalent but subtly incompatible library? 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] [Gimp-developer] GIMP should fork babl and GEGL
On 11/05/2014 08:22 AM, Jon Nordby wrote: What you just described IS side-by-side implementations of operations. In an ICC profile color-managed application, sRGB is just another RGB working space. You don't need to special-case sRGB. No it is not. There will be one implementation of say "multiply". It will be able to work on any RGB color space. Including sRGB, but without need for special casing. Right now all GEGL operations specify "bablRGB": RGBA, R'G'B'A, etc. In Pippin's originally planned "unbounded sRGB architecture", "bablRGB" meant "convert the image to unbounded sRGB before perfoming *any* editing operation". Now the plan is that bablRGB will mean "convert to unbounded sRGB for *some* operations". The meaning of the "bablRGB" specifiers has not, and will not change. The vast majority of operations will just stop using them (because they have hardcoded sRGB parameters), and instead use the new specifiers, as per the roadmap. For the babl code that converts an sRGB image to grayscale for use as a layer mask, do you plan to add a new set of functions that convert from UserRGB to grayscale? That code would, of course, need to pull Y values from UserRGB. Which of course means that the new code for UserRGB would also work for sRGB images. For the babl code that converts from color to Y for painting on a mask, that code currently is hard-coded to use sRGB Y values. Do you plan to add a new set of functions that convert from UserRGB to Y for painting on a mask? That code would also, of course, need to pull Y values from UserRGB. Which of course means that the new code for UserRGB would also work for sRGB images. For all the GIMP UI functions that currently use hard-coded sRGB Y values sprinkled through babl, GEGL, and GIMP, do you plan to add a new set of alternate functions that will use Y values pulled from UserRGB? Again, that new UserRGB code will also work for sRGB images. How is this not side-by-side implementation? Why would any sane developer want to write all the new code and have it exist side by side with equivalent hard-coded sRGB functions? What part of the latest new plan am I missing? Could you explain the purpose that is served by having all the functions with hard-coded sRGB parameters sit side by side with equivalent functions that use UserRGB parameters? Or are you really getting rid of *all* the hard-coded sRGB parameters? In which case, what is the new purpose for the bablRGB formats that "will not change" their meanings? Best regards, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ 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] [Gimp-developer] GIMP should fork babl and GEGL
In his last post on the topic Pippin said: Once we have the vocabulary to also describe this aspect of the pixelformats used by operations, 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 any of userRGB or bablRGB (or other linear RGB); and creating output buffers in the same format – to avoid unnecessary conversions in such cases. Using a fixed linear RGB format instead of userRGB is what for some operations will provide the consistent results for the same property values / slider positions. Knowing which operations this is important for is easier to determine when we have code providing the vocabulary in babl. The further along on the roadmap, more of the road will have to be laid/determined as we walk it. Nothing in the above post shows that Pippin has given up on unbounded sRGB. If Pippin really understood anything I've been trying to explain, he wouldn't still be saying things like: //begin quote "Using a fixed linear RGB format instead of userRGB is what for some operations will provide the consistent results for the same property values / slider positions. Knowing which operations this is important for is easier to determine when we have code providing the vocabulary in babl." //end quote There is not one single operation for which it is important that sliders produce consistent results. NONE. NOT ONE. The whole premise that sliders should produce consistent results is grounded in a misconception of the requirements for RGB image editing. Anyone not indoctrinated in the whole unbounded sRGB mystique that's been perpetrated among the babl/GEGL/GIMP devs for the last however many years would be rolling on the floor laughing if they could fight their way past the nonstandard "color management" vocabulary enough to understand what you all have been talking about all these years. I no longer have the time to continue being actively involved with GIMP development (OK, that cheering in the background isn't nice! :) ). My hope is to see the whole unbounded sRGB thing abandoned. Let bablRGB be UserRGB. You can deal with device-specific code with a UI warning. An RGB image editor should NEVER mess with the user's RGB data without the user's explicit request. Behind the scenes conversions to unbounded sRGB is just wrong. GIMP is important to free/libre artists. GIMP is also important to would-be refugees from Adobe Cloud. Artists need non-proprietary alternatives and specifically they need software that doesn't lock the user's work inside proprietary formats that can't even be accessed without a subscription. (To forestall one of Pippin's stock responses, no, I am not advocating that GIMP be a PhotoShop clone. One reason I switched to Linux and free software was because I was unhappy with PhotoShop limitations regarding linear gamma image processing; sadly Cinepaint capabilities were overrated; even more sadly, all these years later GIMP high bit depth image processing is saddled with the whole unbounded sRGB overlay.) If GIMP can't get ICC profile color management exactly right, well, DarkTable partly fills the gap with its built-in masks. And Krita is frankly leaving GIMP in the dust in very many ways. Krita is a load of fun to use for painting. But Krita not aimed at photographers and it's not as easy to use for strictly RGB image editing as GIMP would be, could be, if unbounded sRGB is just abandoned and the devs starting listening to potential and actual GIMP users. What free/libre photographers really need is for GIMP to be everything it could be if ICC profile color management is properly implemented across the board for all editing operations. This whole unbounded sRGB thing is a dead-end street. Best regards, Elle Stone ___ 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] [Gimp-developer] GIMP should fork babl and GEGL
On 11/04/2014 02:31 PM, Jon Nordby wrote:
(apologies for top-posting)
Hi Elle,
The BABL roadmap[1], which was written in response to comments raised by
you (and others),
details a mechanism for working with multiple RGB color spaces. It will
be possible to create a babl format specifier which means
"whatever-the-artist-chose-for-this-image RGB".
All GEGL operations which currently wrongly use hardcoded bablRGB ("RGBA
float" and similar) will be changed to use this new specifier.
Duplicate/side-by-side implementations of operations is not necessary
nor planned.
With this BABL work in place, GIMP/GEGL can then use LCMS to read in the
ICC color profiles from inputs and set up the parameters for this color
space.
I do not understand how this solution (once implemented) will not work
for your usecase. If you think it will not, please explain why.
I have no desired for a "sRGB only" workflow, and it does not help the
discussion to jump such a conclusion. Please do not assume that the
different needs are in conflict/adverserial to each other.
1. https://git.gnome.org/browse/babl/tree/docs/roadmap.txt#n74
What you just described IS side-by-side implementations of operations.
In an ICC profile color-managed application, sRGB is just another RGB
working space. You don't need to special-case sRGB.
Right now all GEGL operations specify "bablRGB": RGBA, R'G'B'A, etc.
In Pippin's originally planned "unbounded sRGB architecture", "bablRGB"
meant "convert the image to unbounded sRGB before perfoming *any*
editing operation". Now the plan is that bablRGB will mean "convert to
unbounded sRGB for *some* operations".
But thankfully the "convert from UserRGB to unbounded sRGB" code has not
yet been written. So in reality, at this point in time "bablRGB" already
IS UserRGB. There is no reason to write a whole bunch of new babl format
specifiers for UserRGB. That would be side-by-side implementation.
ALL current babl/GEGL/GIMP editing operations already work just fine,
regardless of the user's chosen RGB working space, EXCEPT for the fact
that there are still hard-coded Y and XYZ parameters in the
babl/GEGL/GIMP code base.
To work with UserRGB data, those hard-coded sRGB Y and XYZ parameters
need to be generalized to use Y and XYZ parameters pulled from the
user's chosen RGB working space. If you generalize those operations to
work with Y and XYZ pulled from UserRGB, those operations will work just
fine even when UserRGB really is sRGB.
"bablRGB" is now in fact and should remain UserRGB. There is no reason
to write code that makes "bablRGB" mean "convert to unbounded sRGB" and
then write more code that means "use UserRGB instead of sRGB".
I'm leaving to one side the babl sRGB TRC flips because that code
requires special handling, and the user really does need a way to
completely disable those TRC flips. A fundamental premise for writing an
RGB image editor is that you never mess with the user's RGB data without
their explicit permission. Just opening the image with GIMP is NOT
explicit permission.
Best regards,
Elle Stone
___
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] [Gimp-developer] GIMP should fork babl and GEGL
(apologies for top-posting)
Hi Elle,
The BABL roadmap[1], which was written in response to comments raised by
you (and others),
details a mechanism for working with multiple RGB color spaces. It will be
possible to create a babl format specifier which means
"whatever-the-artist-chose-for-this-image RGB".
All GEGL operations which currently wrongly use hardcoded bablRGB ("RGBA
float" and similar) will be changed to use this new specifier.
Duplicate/side-by-side implementations of operations is not necessary nor
planned.
With this BABL work in place, GIMP/GEGL can then use LCMS to read in the
ICC color profiles from inputs and set up the parameters for this color
space.
I do not understand how this solution (once implemented) will not work for
your usecase. If you think it will not, please explain why.
I have no desired for a "sRGB only" workflow, and it does not help the
discussion to jump such a conclusion. Please do not assume that the
different needs are in conflict/adverserial to each other.
1. https://git.gnome.org/browse/babl/tree/docs/roadmap.txt#n74
On 4 November 2014 19:27, Elle Stone wrote:
> Below explains why GIMP should fork babl and GEGL for use just with GIMP:
>
> Hacker News picked up an article from my website: The Sad State of High
> Bit Depth GIMP Color Management
> (http://ninedegreesbelow.com/photography/sad-state-of-high-
> bit-depth-gimp-color-management.html)
>
> In the Hacker News comments (https://news.ycombinator.com/item?id=8549560
> ), "unhammer" said:
>
> //begin quote
> From glancing over it, it seems to me like Elle Stone wants GIMP to make a
> rather radical shift to Do The Right Thing, while Øyvind Kolås (Pippin)
> values making small improvements one step at a time to avoid breaking
> current functionality.
> //end quote
>
> unhammer's otherwise excellent summary overlooks one very important point,
> which is that there is absolutely *no* current functionality in GIMP that
> would be broken by Doing the Right Thing, which is to give GIMP proper ICC
> profile color management.
>
> The only caveat is that a very few GIMP UI functions really do need to be
> labelled as "only for device sRGB images" or in some cases "only for device
> NTSC images". This article lists all such functions:
> http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html
>
> Moving back to the Hacker News comments, our very own Jon Nordby
> ("jononor") reveals precisely where the "current functionality" that would
> be broken by Doing the Right Thing actually resides:
>
> //begin quote
> GEGL is developed for GIMP, and other projects.
> http://www.jonnor.com/2014/04/imgflo-0-1-an-image-processing...
> http://www.jonnor.com/2014/11/imgflo-0-2-the-grid-launched/ Disclosure:
> I'm a GEGL dev and the imgflo maintainer.
>
> The 'other projects' part is one of the reasons why the proposed solution
> 'just strip all colorspace info, assume it is the same throughout entire
> processing pipeline' is not acceptable for GEGL, even if that might
> somewhat close to the typical usecase for GIMP.
> //end quote
>
> In other words, nothing in *GIMP* would be compromised or broken by Doing
> the Right Thing. However, Nordby's other projects *would* be affected. Of
> course his other software could be patched to assume sRGB as the image
> input profile, but perhaps that is something he doesn't want to do.
>
> As an aside, by "just strip all colorspace info", Norby seems to mean
> replacing hard-coded sRGB parameters with equivalent parameters pulled from
> the user's chosen RGB working space, which is precisely the Right Thing to
> Do for GIMP.
>
> The ICC profile color management problem with current GIMP 2.8/2.9 is that
> some babl/GEGL/GIMP functions are written using hard-coded sRGB Y and XYZ
> parameters. These functions necessarily give wrong results if you, the GIMP
> user, try to edit images in other RGB working spaces such as AdobeRGB1998,
> BetaRGB, or ProPhotoRGB (http://ninedegreesbelow.com/
> photography/users-guide-to-high-bit-depth-gimp.html).
>
> The "Right Thing to Do" for GIMP is to use LCMS to retrieve the Y and XYZ
> values from the image's actual user-chosen ICC working space profile and
> then use the Right values instead of the Wrong values.
>
> Moving back to the Hacker News comments, Jon Nordby said:
>
> //begin quote
> This article is primarly a strawman argument, the 'architecture' which is
> so adamantly argued against has already been abandoned (much thanks to
> arguments from OP). https://git.gnome.org/browse/
> babl/tree/docs/roadmap.txt#n74 It has however not magically implemented
> itself yet.
>
> This is somewhat recognized in the article section which starts "There is
> a ray of hope". The implication that the issues demonstrated will go away
> as a consequence of this has somehow been lost, possibly due to
> miscommunication.
> //end quote
>
> My article does not present a strawman argument. Based on his last post to
> the GIMP developer's mailing list, head babl/GEGL deve
