Re: [Gimp-developer] Don't make an architectural mistake based on a groundless premise

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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:!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
Color management and free/libre photography

gegl-developer-list mailing list
List address:    gegl-developer-list@xxxxxxxxx
List membership:

[Index of Archives]     [Yosemite News]     [Yosemite Photos]     [gtk]     [GIMP Users]     [KDE]     [Gimp's Home]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux