Re: [Gimp-developer] [Gimp-user] Time to fork BABL and GEGL

On 11/20/2014 05:17 AM, Øyvind Kolås wrote:
On Thu, Nov 20, 2014 at 9:42 AM, Elle Stone
<ellestone ninedegreesbelow com> wrote:
Using unbounded sRGB as a universal color space for image editing is a
really bad idea

There has been no plan for using unbounded sRGB as a universal color
space in GEGL, not since the introduction of a target-space in April
in the plans, these days called userRGB in the discussion.

Yes, you are correct. In April we did agree that some editing operations might require being done in the target space, now called UserRGB.

Thankfully we have moved on to the question of whether *any* UserRGB editing ops should be done using sRGB chromaticities.

My article "Using unbounded sRGB as a universal color space for image editing is a really bad idea" isn't aimed specifically at GIMP. It's aimed at the notion of using a universal RGB working space.

Other software developers besides babl/GEGL/GIMP have contemplated using unbounded sRGB for all editing.

Some of the VFX people contemplated using ACES as a universal RGB working space. One look at multiplication and they gave that up.

Lightroom uses ProPhotoRGB as a universal RGB working space. Some of the free/libre raw processors also use ProPhotoRGB as a universal RGB working space. Adobe would like everyone to think ProPhotoRGB is the ultimate RGB working space for interpolated camera raw files, but that's just not true.

The roadmap is a plan for how to achieve these things as smoothly and
with as little unexpected work as possible. If someone has been
working on the babl part of that roadmap and have a version of babl
with the planned capabilities (I don't). It would be possible to use
that new babl with current GEGL without the behavior of GEGL changing.
Then the GEGL side of the work will start, first moving defintely
chromaticity dependent ops to userRGB, as well as some chromaticity
independent ops,

If babl formats for UserRGB are defined and made available to GEGL to use, then there is no rational reason for *any* GEGL/GIMP RGB editing operations to use sRGB chromaticities instead of UserRGB chromaticities. Just do a wholesale find and replace and be done with it. That way there are no unnecessary transforms to the sRGB chromaticities and there's no chance that the developers will decide "operation X" is chromaticity independent when really it's chromaticity dependent.

The only complication with "find and replace" is the handful of "can't be generalized" editing operations, plus whatever device-based code you want to keep around.

All such color-space-specific code needs to be labelled in the GIMP UI so the user doesn't use the op without understanding what they are getting into. Right now GIMP users can merrily use NTSC-based and sRGB device-based editing operations regardless of what color space they are really in, with no UI notification.

I tried to locate all such code to help make fixing the problem of color-space-specific code easier:

it is also likely that *some* operations/tasks
continue using the PCS, which is also a linear RGB,

If you want to convert from UserRGB to XYZ to unbounded sRGB to XYZ to LAB, etc, because for whatever reason it might be more efficient to concantenate and store a UserRGB to sRGB transform than to generalize the code that converts from UserRGB to XYZ and on LAB, that's not going to cause any problems. But the distinction between device-based sRGB and ICC profile illuminant-adapted sRGB does need to be reflected in the babl code.

the user of an
application like GIMP would neither know or be affected – this is what
we are stating will be an implementation detail.

The user will be affected if the devs mistakenly decide that a chromaticity dependent RGB op really is a chromaticity independent RGB op. And the devs will need to add new code that deals with complications caused by extraneous and unnecessary conversions to unbounded sRGB and back.

There's no reason to saddle the devs with trying to make this kind of coding distinction, when the CI and CD ops can both be done using UserRGB chromaticities.

The roadmap as planned is a roadmap for babl, which includes some bits
about changes in GEGL. The changes in GIMP, following things changing
in babl and GEGL are, like the details of decisions we will be making
in the GEGL stages, out of scope for planning how we add the needed
capabilities to babl.

The babl functions that use Y to paint on a mask and to make grayscale masks really do need to be generalized to use UserRGB Y, or else there needs to be side by side functions. Otherwise GIMP layer masks will only be correct for sRGB images.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]