(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 <ellestone@xxxxxxxxxxxxxxxxxxxx> 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 developer Øyvind Kolås is
> still clinging to his hopelessly broken unbounded sRGB model for image
> editing.
>
> If Kolås had really given up on unbounded sRGB, he wouldn't still be
> saying things like "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" (https://mail.gnome.org/
> archives/gimp-developer-list/2014-October/msg00096.html). For those of
> you who don't speak "bablese", "fixed linear RGB" means linear gamma
> unbounded *s*RGB.
>
> Kolås's desire for "consistent slider results" betrays his failure to
> understand the nature of color-managed RGB image editing. Yes, many editing
> operations do produce different results in different RGB working spaces.
> This is precisely *why* we have different RGB working spaces. The ONLY
> person qualified to pick which RGB working space to use for any given
> technical or artistic purpose is YOU, the GIMP *USER*.
>
> Kolås's plan seems to be to use unbounded sRGB whenever and wherever
> possible, with Kolås being the judge of "whenever and wherever possible".
>
> Nordby's plan seems to be to "eventually" implement side-by-side babl/GEGL
> processing for sRGB and for the user's choice of RGB working spaces. This
> plan unnecessarily complicates the code and totally ignores the fact that
> sRGB is just another ICC profile RGB working space that needs *no* special
> treatment.
>
> The only way I can see for GIMP to get out of this babl/GEGL "hard-coded
> sRGB mess" is for GIMP to fork a babl/GEGL branch meant specifically for
> GIMP. That way Nordby can have his "sRGB only" branch, Kolås can play with
> unbounded sRGB, and GIMP can have proper ICC profile color management
> without having to take a backseat to the needs of other babl/GEGL projects.
>
> Another advantage to forking babl and GEGL for GIMP is that GIMP's fork of
> babl and GEGL could be GPLed, thus freeing the GIMP devs to add FFTW
> (Fourier transforms, http://www.fftw.org/) and other new functionality to
> GIMP. FFTW is GPLed. At present, GIMP is somewhat hobbled as to what GPL
> code can be used for new editing functions because the babl/GEGL code is
> LGPLed.
>
> With kindest regards,
> Elle Stone
> --
> http://ninedegreesbelow.com
> Color management and free/libre photography
> _______________________________________________
> gimp-developer-list mailing list
> List address: gimp-developer-list@xxxxxxxxx
> List membership: https://mail.gnome.org/mailman/listinfo/gimp-
> developer-list
> List archives: https://mail.gnome.org/archives/gimp-developer-list
>
--
Jon Nordby - www.jonnor.com
_______________________________________________
gimp-developer-list mailing list
List address: gimp-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
