Based on the groundless premise that editing operations should produce
the same results when performed on the same colorimetric colors, the
BABL/GEGL/GIMP architecture specifies that:
1. sRGB should be the universal RGB working space.
2. Developers should decide whether an operation is done using linear
RGB or RGB encoded using the "almost perceptually uniform" sRGB TRC.
Any editing application that dictates the ways in which the artist can
transform the artist's data is broken by design.
Developers can't know *why* an artist draws a gradient, applies a curve,
pulls out channel data, or multiplies colors, and therefore can't
dictate from afar what primaries and what tonal transform are
appropriate to the task.
Thomas Mansencal explains why there can't be a universal RGB working
space:
http://nbviewer.ipython.org/github/colour-science/colour-website/blob/master/ipython/about_rendering_engines_colourspaces_agnosticism.ipynb
Mansencal quotes Pixar's Rick Sayre's high level summary:
"The RGB basis vectors typically become non-orthogonal when transformed
to XYZ, and definitely so in this case. Thus there should be no surprise
that component-wise multiply does not yield a proper transform between
two non-orthogonal spaces."
Pippin's premise, that editing operations should produce the same
results when performed on the same colorimetric colors, flatly
contradicts the requirements for professional image editing.
Forcing the use of a universal color space for RGB image editing is a
great big huge mistake.
Respectfully,
Elle Stone
--
For all you word counters, this post contains 232 words.
http://ninedegreesbelow.com
Color management and free/libre photography
_______________________________________________
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
