Re: [Gimp-user] [Gimp-developer] Time to fork BABL and GEGL

[Simon Budig <simon budig de>]

Elle Stone (ellestone ninedegreesbelow com) wrote:
> > A slight preface here. I don't consider it important to focus on the
> > *storage* of the pixel data, as in the actual bulk memory for the pixel
> > data.
>
> If you choose to *store* the user's RGB data using chromaticities not of
> user's choosing, that suggests that you also intend to *edit* the user's RGB
> data using chromaticities not of user's choosing

I think that this is the core of the misunderstanding here.

In Gegl the *storage* of pixel data in memory is totally and 100%
independent from the colorspace used to *edit* the user's RGB data. You
seem to think that the storage "suggests" an intent, but a lot of the
communication from pippin, jonnor and me is about explaining that this
is *not* the case.

Obviously it makes a lot of sense to bring storage and editing workspace
in line to avoid computational bottlenecks. But this is just a
performance optimization, i.e. implementation detail.

> > > 1. Upon opening an image, the image will be converted to unbounded sRGB.
> >
> > I don't think that this is decided yet, I actually consider it unlikely
> > at the moment. I think it might be more likely to have it sitting in
> > memory as userRGB.But again, this is an implementation detail, where I
> > assume that the floating point math is sufficiently precise to avoid
> > visible rounding errors.
>
> This is not just an implementation detail. The user has the right to control
> what RGB working space is used when performing RGB edits on the user's own
> RGB data.

We need to make sure two things:

a) upon import of an image the "userRGB"-format-descriptor within the
images context needs to be set up to refer to the chromaticies of the
source image.

b) whenever a chromaticity dependent operation works on the images data
the infrastructure needs to make sure that the pixel data gets fed into
the operation using the chromaticies of the source image. We'll do this
by having the operation request the image data in the "userRGB" format
from the images context.

Note that this is totally independent from the pixel *storage* in
memory. This will work the same when the pixel *storage* is in userRGB,
sRGB or XYZ.

> > For all chromaticity dependent RGB editing operations the pixels will be
> > re-encoded in the format the operations requests. Which most likely will
> > be userRGB.
>
> If the user opens a BetaRGB image or an AdobeRGB image or whatever, the user
> really does expect that *all* RGB edits wil be done using the user's chosen
> RGB working space chromaticities.

We agree here. The *edits* for the chromaticity dependent operations
need to be done in the chromaticies of the source image.

> > If specific userRGB to XYZ/whatever transforms are
> > available to babl it will make use of them. This will likely be the case
> > for e.g. AdobeRGB.
>
> OK, if I understand what you just said, this is getting silly.
>
> I think you are indicating a willingness to write hard-coded AdobeRGB
> editing operations and put them right alongside the hard-coded sRGB editing
> operations.

Oh, I was under the assumption that AdobeRGB had well defined
chromaticies. If that is not the case then please consider my example
moot. I am well aware that dealing with color profiles most definitely
is not my area of expertise.

If there were chromaticies for a given "userRGB" which are widely used
in a lot of real world applications, then it might make sense to support
them in a similiar way like we currently do for the sRGB primaries.

If that is not the case then this indeed would be silly.

Bye,
        Simon

-- 
              simon budig de              http://simon.budig.de/