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 Sat, Oct 4, 2014 at 2:46 PM, Elle Stone
<ellestone@xxxxxxxxxxxxxxxxxxxx> wrote:
> Based on the groundless premise that editing operations should produce the
> same results when performed on the same colorimetric colors, ..

No; but same parameters for same input colors producing same results
is considered desirable behavior. Predictable interfaces are nice

> ... the BABL/GEGL/GIMP architecture specifies that:
> 1. sRGB should be the universal RGB working space.

No.. but GEGL stores the pixel-format/color-space of a pixels values
along with the pixel as it is passed around (along with the whole
GeglBuffer actually). Internally GEGL doesn't use ICC for this but
BablFormats which represents a subset of possible ICC formats. The
"profile connection space" used by babl is linear RGB with sRGB
primaries, since this permits very low overhead for doing operations
in this color space; a color space which also is suitable for these
operations (most layer compositing modes and blurring). The intention
is to keep using babl for internal buffer management and integrate
well with an external color management system for interacting with the
more complex things ICC profiles express.

> 2. Developers should decide whether an operation is done using linear RGB or
> RGB encoded using the "almost perceptually uniform" sRGB TRC.

Almost, developers decide which pixelformat is appropriate for their
operation, with a choice of linear RGB, sRGB, CIE Lab, some gray scale
formats as well as formats used with digital video with different data
types; currently the set of babl formats. The problems you've pointed
out with for instance multiply have led to a consensus that we will
also need a target-space/working-space choice, perhaps two; one linear
and one more perceptual.

The logic involved in configuring the pixel format inputs/outputs of
each operation could possibly be made more configurable (in GEGL, not
necessarily work to be done by the implementor of the op), thus also
enabling mostly conversion free processing modes of operation like
what you seem to want when you reduce babl to only deal with precision

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