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

[Elle Stone <ellestone ninedegreesbelow com>]

On 11/19/2014 06:20 PM, Jon Nordby wrote:
> On 19 November 2014 23:57, Elle Stone <ellestone ninedegreesbelow com
> <mailto:ellestone ninedegreesbelow com>> wrote:
>
>     In case you don't understand this, HDR sRGB data is still *bounded*
>     by the sRGB xy chromaticities. It's only unbounded along the Y axis.
>     There are NO negative channel values in HDR sRGB data unless the
>     *user* chooses to do something odd, in which case the *user* is
>     responsible for fixing the results.
>
>
> Doesn't this contradict with the following, from your recent mail? (I
> don't know what particularly is the definition of HDR used)
>
> "We've also agreed that for chromaticity independent RGB editing
> operations ("CI ops", for short), by definition the same colors (as
> located in the XYZ reference color space) are obtained regardless of the
> chromaticities that are used to encode the data."

If you choose to do CI ops using sRGB chromaticities instead of UserRGB 
chromaticities, and you make a mistake about whether the op really is a 
CI op instead of the CD op, editing results are wrong. This is the crux 
of why you shouldn't do something so incredibly unnecessary as to 
convert UserRGB to unbounded sRGB to do the editing op.


Unbounded sRGB is NOT HDR scene-referred. If you guys would actually do 
a little reading and try to understand what you are talking about, this 
whole conversation could have been over a long time ago.

Read these two articles. Then read them again.

http://ninedegreesbelow.com/photography/lcms2-unbounded-mode.html

http://ninedegreesbelow.com/photography/display-referred-scene-referred.html

Elle