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

[Øyvind Kolås <pippin gimp org>]

On Sun, Oct 5, 2014 at 5:16 PM, Elle Stone
<ellestone ninedegreesbelow com> wrote:
> On 10/04/2014 11:59 AM, Øyvind Kolås wrote:
> > On Sat, Oct 4, 2014 at 2:46 PM, Elle Stone
> > <ellestone ninedegreesbelow com> wrote:
> > > Based on the groundless premise that editing operations should
>
> produce the
> > > same results when performed on the same colorimetric colors, ..
> >
> >
> > No;
>
>
> I'm not sure what you are saying "No" to. Here are excerpts from previous
> posts that you've made talking about the matter:
> http://article.gmane.org/gmane.comp.video.gimp.devel/19916

I am saying no to it being groundless premise, It is a desirable
interaction goal.

It is the same desire that makes sure that things like image
resampling and blurring should always happen with _associcated_alpha_
and linear TRC. Instead of letting the user configure a working space
where scaling or blurring behaves in ways not resembling physics.

The architectural implementation of that desire is tagging of all
buffers explicitly with their color space, associated alpha state,
data type etc.
Each operation tells GEGL both what type of data it wants to read as
well as what type of data it wants to write in the "prepare" stage for
the op, which happens before any data is being processed. 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.

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.

> > My stance is that the sliders on an
> > operations should be predictable and always do the same thing for the
> > colorimetrically absolute same color

(relative colorimetric likely makes more sense; or perhaps just
colorimetric - though thats a detail).

> http://markmail.org/message/n6ttql3ajtjbe767
> > GEGLs image processing is intended to all operate in device independent
> > color spaces, no matter which camera you took a picture with
> > gaussian blurs, color adjustments etc, should behave the same.
>
>
> > No; but same parameters for same input colors producing same results
> > is considered desirable behavior. Predictable interfaces are nice
> > interfaces.
>
>
> In a properly color managed image editor, the way for a user to get
> predictable editing results is to set up a consistent workflow based on the
> RGB working spaces that the user finds appropriate for the tasks at hand.

I don't think a medium high-end user of GIMP should _need_ to be
concerned about working spaces; we should strive to make a system that
behaves well by default.

> Until GIMP is properly color managed, the only users who might find GIMP
> editing results predictable are users who already only edit their images in
> the sRGB color space.

GEGL strives to bring linear light editing all the places it makes
sense; this will hopefully be a better experience than 8bpc sRGB.

"properly color managed" is not one single thing, 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.). One could also
claim that a system that converts everything to a single working space
and passes pixels untagged through is "weaker" color managed than the
plan that has been outlined for GEGL.

You've already been invited, and I invite you again to spend some time
with the rest of the GIMP team and others with interest in color,
photography and graphics in Toronto, end of april next year for the
next Libre Graphics Meeting.

/Ø