On 10/17/2014 07:00 AM, Simon Budig wrote:
Elle Stone (ellestone@xxxxxxxxxxxxxxxxxxxx) wrote:
On 10/17/2014 06:39 AM, Simon Budig wrote:
Elle Stone (ellestone@xxxxxxxxxxxxxxxxxxxx) 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
_______________________________________________
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
