Re: [Gimp-developer] [Gegl-developer] babl roadmap

[Elle Stone <ellestone ninedegreesbelow com>]

On 10/17/2014 07:00 AM, Simon Budig wrote:
> Elle Stone (ellestone ninedegreesbelow com) wrote:
> > On 10/17/2014 06:39 AM, Simon Budig wrote:
> > > Elle Stone (ellestone ninedegreesbelow com) wrote:
> > > > //begin quote from http://color.org/DevCon/devcon14.xalter
> > > >
> > > > While this fixed PCS is capable of delivering unambiguous color transforms,
> > > > it cannot support the increasing demand for spectrally-based reproduction.
> > > [...]
> > > > Tying GIMP to "sRGB as PCS" is a dead-end move.
> > >
> > > If you take "spectrally based reproduction" as an argument against "sRGB
> > > as PCS" you should be at least be so fair to also mention that *any* RGB
> > > based image editing is bound to fail for this.
> >
> > In point of fact, I've already said thist. But I'm happy to say it again.
> > RGB data is not spectral data.
>
> I know. Which is why your previous mail could have had the very same
> text and the following sentence as the conclusion:
>
> "Tying GIMP to RGB based editing is a dead-end move."
>
> Which is exactly the dead end you have been advocating a lot in the
> recent discussion.

In point of fact, I never used "spectrally based reproduction" as an 
argument against "sRGB as PCS". But if you do want "same slider moves" 
to produce "same results", I think spectral data might the thing to look 
at.

*GIMP* is an *RGB* image editor.

We have been discussing the advisability of babl/GEGL/GIMP using 
unbounded sRGB for editing RGB images that were originally in another 
RGB color space of the artist's choosing.

RGB working space data is determined by the profile chromaticities. 
Change the chromaticities and the channel data itself changes.

sRGB is a singularly ill-advised choice for working with RGB data from 
interpolated camera raw files.

Kind regards,
Elle Stone