On 10/05/2014 12:49 PM, Øyvind Kolås wrote:
sure GIMP/GEGL is
not there yet, but for a GIMP 2.10 release it is good enough. (2.10s
stated goal is being to be able to do what 2.8 does; but with GEGL
inside - the higher bitdepths and such are bonus.).
The time table for implementing new features is irrelevant to why
BABL/GEGL/GIMP intends to use a broken architecture.
Most current named BablFormats are immutable - in the same ways ICC
profiles are treated as immutable. Changing the meaning of "R'G'B'A
u8" or "Y'CbCr u8" and similar will break color management for
operations providing integration with various image loaders/video
codecs/webcam/GUI that already exist.
Whether or not device-specific code makes sense in a color-managed
editing application isn't relevant to why BABL/GEGL/GIMP intends to use
a broken architecture.
GEGL strives to bring linear light editing all the places it makes
sense; this will hopefully be a better experience than 8bpc sRGB.
Linear RGB data manipulation does require high bit depth image editing.
But linear RGB data manipulation is not facilitated by an architecture
that converts the user's color data to "sRGB as PCS". Precisely
*because* the primaries used to encode RGB data do make a difference in
the results of editing operations, the user must choose the appropriate
primaries for the task at hand.
Two justifications have been given in support of the BABL/GEGL/GIMP
architectural requirement that images be converted to "sRGB as PCS":
Justification 1: A forced conversion to "sRGB as PCS" meets a "desirable
interaction goal" that sliders produce the same results when operating
on the same XYZ colors.
This "desirable interaction goal" betrays a failure to understand the
nature of RGB image editing. The interactions of real world light and
colors are only partially preserved in RGB data. So necessarily RGB data
is color data that is encoded using RGB primaries that are appropriate
to the editing task at hand.
Hacking the broken architecture to fix specific broken editing
operations undermines the stated goal that sliders should produce the
same results when operating on the same XYZ colors. So this
justification has already fallen apart.
Justification 2: A forced conversion to "sRGB as PCS" makes possible
fast path conversions from "sRGB as PCS" to XYZ, LAB, YCbCr, etc.
A fast path conversion that depends on mangling the artist's data by
converting it to "sRGB as PCS" is just a fast way to get to a bad
results out of a broken architecture.
Any processing advantage provided by using hard-coded sRGB parameters
will be swamped by the processing load imposed by hacks that convert
from "sRGB as PCS", to the artist-chosen RGB primaries, and back again
to "sRGB as PCS".
The "fast path conversion" argument also has fallen apart.
With what
has been proposed as a solution for ops that need to use a
target/working RGB space is that the operation would ask for a special
symbolic babl format or similar; and GEGL/babl does the rest behind
the scenes.
You've conceded that your architecture is broken to the point where you
must hack in fixes for multiply. That's the first of many such hacks to
come:
Retrieving the artist's original channel data? Hack.
Display-referred editing using the negative channel values that will be
produced by a forced conversion to "sRGB as PCS"? Hack.
Using the Levels gamma sliders? Use the Red/Green/Blue Levels
input/output sliders? Hack, hack.
RGB data doesn't 100% capture the way light and color behave in the real
world. Rather RGB data necessarily is encoded using different primaries
for facilitating different editing goals.
Think about the implications of Rick Sayre's comment on non-orthogonal
transforms to XYZ:
https://groups.google.com/forum/?_escaped_fragment_=msg/academyaces/9b4VuqPcOHQ/Hg8c9V6flOYJ#!msg/academyaces/9b4VuqPcOHQ/Hg8c9V6flOYJ
What Sayre says cuts to the heart of why an architecture that requires a
conversion to "sRGB as PCS" is broken and can't be fixed.
With respect,
Elle Stone
--
http://ninedegreesbelow.com
Color management and free/libre photography
_______________________________________________
gegl-developer-list mailing list
List address: gegl-developer-list@xxxxxxxxx
List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
