On 11/16/2014 05:18 PM, Øyvind Kolås wrote:
On Sun, Nov 16, 2014 at 9:01 PM, Elle Stone
<ellest...@ninedegreesbelow.com> wrote:
Do you understand that when I say that Multiply is a chromaticity-dependent
editing operation, I don't just mean the Multiply layer blend mode? that in
fact *all* editing operations that use multiplication or division are
chromaticity dependent, regardless of whether the colors are *in* gamut or
*out* of gamut with respect to the very small bounded sRGB color gamut?
The exception to "all", of course, is when multiplying or dividing by black,
gray, or white.
Yes I do understand that
OK, thanks! for confirming. I was afraid my phrasing might have obscured
an important point.
1. Do you agree or disagree that for *all* chromaticity dependentediting
operations, the *user* should be in control of which RGBchromaticities
are used to perform the operation?
That is the point of adding more, and named, RGB families to babl.
2. Do you agree or disagree that for chromaticity *in*depedent editing
operations (for example, and assuming linearized RGB: adding, scaling,
gaussian blur, etc), the same results (same XYZ values) are obtained
whether the operation is done in the user's chosen RGB working space or in
unbounded sRGB?
I do;
So it appears that we agree on the following, yes?
1. The user's chosen RGB working space chromaticities should be used for
performing all chromaticity dependent RGB editing operations.
2. For chromaticity independent RGB editing operations, the same XYZ
values are obtained regardless of whether the operation is performed
using the user's chosen RGB working space chromaticities or after
converting the image to unbounded sRGB.
Somewhat switching gears, the revised babl roadmap
(https://git.gnome.org/browse/babl/tree/docs/roadmap.txt) says:
The plan in roadmap hasn't really changed since mid-april[1],
I agree with you that the plan you outlined in April is pretty much the
same plan that I think you are outlining now. In April you did agree
that some RGB editing operations don't work in unbounded sRGB. You said
that using "targetRGB" (ie the user's chosen RGB working space, UserRGB,
"bar"RGB, etc) would be one solution and that another solution would be
converting to CIELAB to do the operation.
Putting aside coding considerations that might affect other software
that uses babl and GEGL, here's my understanding of your current plan
for babl/GEGL/GIMP:
1. Upon opening an image, the image will be converted to unbounded sRGB.
2. For all chromaticity dependent RGB editing operations:
* Either the image will be re-encoded using the user's chosen RGB
working space chromaticities, and then the operation will be performed.
* Or else the image will be converted to CIELAB and then the
operation will be performed.
3. For all chromaticity *in*dependent RGB editing operations, the image
will be converted to unbounded sRGB for processing.
4. When converting to XYZ/CIELAB/etc, the image will first be converted
to unbounded sRGB.
5. The GEGL developers will specify on an "operation by operation" basis
whether the operation requires being encoded using UserRGB/Y/etc, or
unbounded sRGB/Y/etc, or CIELAB as a substitute for chromaticity
dependent RGB processing, or etc.
As an important note, depending on the last operation that was done, the
image might already be encoded using the GEGL-operation-specified
format, in which case a conversion to that format is not needed.
Are the above five points (and note) an accurate summary of your current
plan for babl/GEGL/GIMP?
I have a couple of followup questions, but there's no point in asking
them if I don't have a clear understanding of what your current plan
really is. I think we've both been rightly accused of talking right past
each other.
1: the only change in plans since then (and that changed occured
before roadmap.txt was started), was abandoning the plan to do
conversions between bablRGB and userRGBs in babl using LCMS2; and
instead do those conversions directly ourselves in babl; a change
without impact on how babl will be used by GEGL (and GIMP).
Using babl instead of LCMS2 to do ICC profile matrix conversions makes
perfect sense, being faster and potentially a lot more accurate
(https://mail.gnome.org/archives/gimp-developer-list/2014-October/msg00093.html).
/pippin
Elle
_______________________________________________
gimp-user-list mailing list
List address: gimp-user-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives: https://mail.gnome.org/archives/gimp-user-list