On 10/08/2014 04:20 PM, Øyvind Kolås wrote:
On Wed, Oct 8, 2014 at 9:49 PM, Elle Stone
<ellest...@ninedegreesbelow.com> wrote:
On Wed, Oct 8, 2014 at 4:25 PM, scl <scl.gp...@gmail.com> 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.
To somewhat simply, ICC RGB working space profiles are characterized by:
1. The profile Red, Green, and Blue colorant XYZ values, aka "primaries".
2. The profile Tone Reproduction Curve, "TRC" for short.
Right now, when a user opens a regular ProPhotoRGB image, the primaries
AND the TRC are not what the babl/GEGL/GIMP code expects (the regular
ProPhotoRGB TRC is Gamma=1.8). The only operations that *don't* produce
wrong results are operations that don't use sRGB primaries AND don't
linearize the sRGB TRC.
You can make an ICC profile using any primaries and any TRC. For
example, a profile can be made using the ProPhotoRGB primaries and the
sRGB TRC. So here is one way to make the current hard-coded sRGB
TRC-based transforms between linear and perceptually uniform RGB work:
Upon opening an image, use LCMS to make a profile using the user's
chosen primaries and the sRGB TRC, and convert the image to this new
profile. Once. Not repeatedly back and forth.
And of course replace all the code that uses hard-coded sRGB primaries.
I have two questions about the linear-to-perceptual "babl TRC flips" code:
1. Is it acceptable to mess with a user's RGB data by keeping the
primaries intact and "only" modifying the TRC? A user who expects their
data is encoded using the ProPhotoRGB gamma=1.8 TRC will not fail to
notice that data encoded using the sRGB TRC gives different results.
The "babl TRC flips" code could be modified to give the user a choice of
TRCs for encoding perceptually uniform RGB.
2. Does the repeated linear-to-perceptual-to-linear "babl TRC flips"
required by the current architecture impose a loss of precision? How
much loss, after how many flips?
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.
I'm not proposing that you use "sRGB as PCS" and then hack the code to
fix the resulting problems. I'm proposing that you eliminate "sRGB as
PCS" altogether. It's a broken model for RGB editing.
The VFX people understood with *one* multiply example that there can be
no universal RGB working space. The best working space depends on the
artistic intent plus the device(s) that produced the colors, and
eventually on the device(s) on which the colors will be displayed.
Adobe-centric advice implies that color gamut is the only consideration
when choosing an RGB working space. Adobe has hard-coded ProPhotoRGB
primaries into their raw processing software. It is distressing to see
GIMP follow Adobe's lead by writing code on the assumption that the sRGB
primaries are suitable for editing all images.
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.
If there is code for 8-bit and 16-bit integer images that uses sRGB
*primaries*, that code needs to be rewritten or removed. It makes no
sense in the context of a high end, high bit depth image editor.
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.
Copy-paste/drag-drop do require converting the pixels from the source
layer stack's ICC profile to the destination layer stack's ICC profile.
That's what properly color-managed image editors do. Krita does this.
Surely GIMP can also do this.
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.
My apologies, I meant to type "RGB to XYZ to LAB". You can't get
directly from RGB to LAB. You have to go through XYZ. You get from RGB
to XYZ by using the illuminant-adapted profile colorants.
Also, proper "color temperature change" code requires converting to XYZ
to do Bradford/CATO2/etc chromatic adaptation. So a function that
converts from RGB to XYZ really is necessary. The current temperature
change code is hard-coded for sRGB images and although it does produce
pleasing results for sRGB images, those results are not colorimetrically
correct.
With respect,
Elle Stone
_______________________________________________
gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list