On 11/04/2014 02:31 PM, Jon Nordby wrote:
(apologies for top-posting)
The BABL roadmap, 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
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
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
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.
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
gimp-user-list mailing list
List address: firstname.lastname@example.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives: https://mail.gnome.org/archives/gimp-user-list