Elle Stone (ellestone@xxxxxxxxxxxxxxxxxxxx) wrote:
> On 10/15/2014 08:30 AM, Øyvind Kolås wrote:
> >On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone
> >>When the user opens a color-managed fooRGB image, for which *specific*
> >>editing operations will the image be converted to unbounded sRGB?
>
> >
> >If the user is putting a text-layer, which has been rendered using
> >cairo and is in 8bit sRGB premultiplied alpha. The compositing of this
> >with preceding data in the layer stack the babl-format of the output
> >buffer of the over/normal compositing operation, as well as the data
> >fetched from both buffer inputs - would likely be RaGaBaA float - if
> >the two linear inputs differ.
>
> I'm not sure why your text-layer stack example is relevant to my very direct
> and still unanswered question.
As you very well know we don't *have* the specific list of editing
operations you ask for. I don't know why you keep repeating the
question. You seem to think that not getting an answer to that question
proves a point, but I definitely have no idea what the point is.
What would be the benefit of having such a list?
If the implementor of an operation thinks, that an operation needs to
work in unbounded bablRGB then it will request bablRGB input and gegl/babl
will do its work to provide that.
An example *could* be an operation that does change the "warmth" of an
image by simulating lighting by a different illuminant. The operation
could request bablRGB input data, convert that to XYZ internally, do the
shift, convert back to bablRGB and provide that as output.
But then the author might be better off with requesting the data in XYZ
directly, saving him from the work of doing the bablRGB to XYZ conversion:
Gegl/Babl does that for him.
Both ways are fine, Gegl/Babl can do this today. It is up to the author
to choose and it will be *completely* transparent to the user of the
operation.
This is completely independent from how the image pixels are stored in
memory, even when they are stored with a different set of RGB primaries.
Gegl/babl in that case will know how to transform the stored pixels into
bablRGB the operation requests, and they'll know what to do with the
output.
The text example from pippin is supposed to illustrate that Gegl in real
world situations has to deal with external sources which are beyond the
control of Gimp. And Gegl/Babl provide the facilities to deal with that.
> >At all points we know the CIE Lab or XYZ coordinates of all involved
> >pixels
>
> You don't "know" the XYZ coordinates until you actually convert from fooRGB
> to XYZ. Likewise with CIELAB. So it's not clear what the above sentence
> really means.
If you know the pixel values of a pixel and know how to convert fooRGB
to XYZ there is absolutely no need to do the actual conversion. You can
still claim that you know the XYZ as well as CIELAB coordinates. You
just don't bother to do the conversion until you really need it.
If you know that x is 5 and you know how to calculate the square of a
given value you don't need to do the actual calculation. Yet you still
"know" in the sense that the specific value is available to you as soon
as you need it.
> But here's a maxim for *RGB* image editing:
>
> For RGB editing operations, don't ever, ever, ever convert color-managed
> fooRGB to unbounded sRGB.
I assume that by "RGB editing operations" you're referring to the
"math-centric" ones which bluntly apply a mathematical formula to the
pixel data, not caring if the operation makes sense from a
colorimetric/physics based viewpoint. (Examples would be "multiply" or
even "levels" on the RGB channels).
We now have operations who utterly need to know the colorimetric values
of a pixel, because they are based on color theory. Shifting the color
temperature of an image might be a good example.
We have to be able to mix these operations, because Future Gimp (TM)
will head towards non-destructive editing, where the user uses the UI to
construct a graph of operations to combine all the image sources to get
to the desired result. We don't intend to stick to the "have-an-image,
do-an-operation, have-a-new-image, repeat" paradigm.
So we need infrastructure that can mix both, the colorimetric and the
math-centric approach. Your proposal of never-ever-converting will make
real colorimetric operations a pain, since the color-temperature
operation has to accept the fooRGB data, convert it to XYZ, do its
operation and convert back to fooRGB, because fooRGB is ultimately what
is needed for a potential next math-centric operation.
With the infrastructure proposed by pippin the "math-centric" operations
will ask for fooRGB data as input and provide fooRGB data as output.
That means that chaining them together will neatly avoid colorspace
conversions.
If the user then decides to put a color-temperature change in the mix
(lets assume it requests bablRGB as input and provides bablRGB as
output, since the author decided against XYZ for some reason) Gegl/Babl
will put a fooRGB->bablRGB conversion into the chain. And after the
operation there will be a bablRGB->fooRGB conversion to provide the
subsequent levels-operation with the desired input. Let this be the only
operation in the chain that works in a colorspace other than fooRGB.
Now lets assume the color temperature is configured to shift from 5000K
to 5000K, i.e. it is basically a no-op.
Obviously we then burn lots of CPU cycles for an essentially useless op
to do a useless color space conversion to bablRGB and back.
However: This has absolutely *no* negative impact on the rest of the
chain which operates in fooRGB (ignoring rounding errors, which are
probably negligible for the floats we're likely to use in the chain).
The result will be indiscernible from the result we get by removing the
unnecessary op. Claiming that this facility would in any sense break the
workflow for color managed images is just incorrect.
And note that the choice of color primaries for our "bablRGB" is
irrelevant for this argument. They might be the same as for sRGB, but
as long as they work as a basis for the colorspace any combination will
work, as long as they are known.
Bye,
Simon
--
simon@xxxxxxxx http://simon.budig.de/
_______________________________________________
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
