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

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

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

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.


              simon budig de    

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]