On Wed, Oct 8, 2014 at 9:49 PM, Elle Stone
<ellestone@xxxxxxxxxxxxxxxxxxxx> wrote:
>> On Wed, Oct 8, 2014 at 4:25 PM, scl <scl.gplus@xxxxxxxxx> wrote:
>> The we have to juggle a large set of different types of pixel formats
>> already? The initial thinking was that linear working in RGB and HDR
>> was sufficient, that is what the current babl is sufficient for, one
>> uses ICC based conversions to get into the internal formats which are
>> supposed to have efficient management, programming naming and
>> conversions. And uses an external CMS for interacting with the
>> outside. As Elle has repeatedly pointed out, that is not sufficient;
>> and the scope of what is considered natively juggled pixel formats
>> must be extended.
>
> The babl/GEGL/GIMP code base has a relatively short list of places where
> hard-coded sRGB parameters are used. I've already identified most such code.
> Most of it uses sRGB Y values.
Each location that says babl_format("RGBA foo") or babl_format
("R'G'B'A foo") or babl_format ("RaGaB..) etc. is a location that
requests a specific format. It is not the places in the code that
implements the sRGB primaries which is in question.
> To generalize such code to work with all RGB working spaces, replace
> hard-coded sRGB Y values with Y values retrieved by LCMS from the user's
> chosen RGB working space colorant XYZ values. The Y values can be retrieved
> upon opening an image and again upon switching images for users who have
> several images open at once.
What you are describing is exactly what I outlined API for elsewhere.
You would..
babl_set_named_rgb_chromaticities (babl, "hack", colorants..
and you would get what you want by having replacing all occurences of
"RGBA float" and "R'G'B'A float" with "hack:RGBA float" and
"hack:R'G'B'A float", and the same for u8 and u16. But the "R'G'B'A
u8" and u16 and similar better be left alone because they have been
written with the assumption that their data is sRGB. Globally
switching it upon switching images does not work for copy and paste
between images and other forms of work where different spaces might be
at play.
> The babl conversion to XYZ uses the sRGB D65 color space xy values and the
> D65 white point to convert to XYZ. This results in wrong results even for
> sRGB images in a D50-adapted ICC profile color-managed workflow. The right
> thing to do is retrieve the user's chosen profile's colorant XYZ values and
> ferry that to babl. This takes the place of the hard coded (and wrong) D65
> sRGB xy values. The equations for converting from XYZ to LAB are well known.
Babl has no XYZ format and thus in a sense no conversion to XYZ. The
CIE Lab implementation which came from GIMP does however contains an
internal conversion to XYZ; you are saying the CIE Lab code is broken.
> I don't understand why replacing the hard-coded sRGB parameters is meeting
> such massive resistance. It's the right thing to do. I don't see how it can
> require more overhead than retrieving the target color space information
> anyway and using it to constantly convert back and forth between "sRGB as
> PCS" and the target color space for the many operations that won't work
> correctly in "sRGB as PCS"
Since one approach permits internal color management, and the other
permits managing sRGB TRC perceptual vs not. Would require conversions
involving the external CMS for all things doing cross window/document
copy, paste, cloning and more. Keeping babl as an actual CMS and not
one with only one reconfigurable RGB model permits the above, as well
as keeping the contract with existing GEGL operations, as well as
applications using GEGL to what the pixel format identifiers mean;
we're not designing a system from scratch, but we try to change what
we have; without breaking much; to be able to do much more. Ripping
out the PCS of the internal color management system; would break
things.
Even though I know that many find the idea of writing here
intimidating; I am hope some that are agreeing with the direction GEGL
has been trying to go in on the projects in our other communication
channels also chime in.
/Ø
_______________________________________________
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
