Re: [Fenfire-dev] Re: Could you merge

[Tuomas Lukka]

On Mon, Sep 22, 2003 at 10:14:03PM +0300, Janne Kujala wrote:
> On Mon, Sep 22, 2003 at 05:47:58PM +0300, Tuomas Lukka wrote:
> > On Mon, Sep 22, 2003 at 03:06:29PM +0300, Janne Kujala wrote:
> > > Nyt oletuksena oletetaan monitorin noudattavan sRGB:tä
> > > (kokeile vob.demo.lava.gamma). Minulla Eizo F730:lla ilman sRGB:n 
> > > "offset":ia gamma oli pielessä aina joko tummilla tai vaaleilla 
> > > väreillä, mutta nyt "xgamma -gamma .87":lla tulee epälineaarisuus
> > > lähes tarkalleen sRGB:n mukaan.
> > 
> > I think that for papers and other purposes, we need to discuss this on the 
> > list first,
> > before merging.
> > 
> > Forcing people to adjust xgamma to such a strange value is not to be taken 
> > lightly.
> > Translation of jvk's mail (I recommend posting merge requests to the list 
> > in the future,
> > along with a short description so discussion can be began directly):
> > 
> >     Now it is assumed that the monitor obeys sRGB (try
> >     vob.demo.lava.gamma). For me, on an Eizo F730, without the sRGB
> >     "offset" the gamma was always wrong either on the dark or
> >     light colors, but now "xgamma -gamma .87" gives the nonlinearity
> >     almost exactly according to sRGB.
> > 
> > Now, the problem with this gamma is that all other software will look *too 
> > dark*.
> > Most people will not adjust their gamma so. Another problem is that the 
> > OpenGL
> > filtering which is linear will not work correctly either.
> > 
> 
> I feel that you may have misunderstood the issue ;)

I've not claimed at any point that I haven't ;) ;)

But that still implies that a better explanation is needed.. thank you for
giving it.

> We have discussed the gamma matter before, here's a short summary:
> 
>       - We used to assume linear rgb reproduction
>       - PC's are typically configured for non-linear rgb with around
>         2.2 gamma, i.e., by default, the rgb values map to physical 
>         intensities approximately as x -> x**2.2
>       - Thus, people were forced to do "xgamma -gamma 2.2" in order to
>         "neutralize" the default non-linearity
>       - We decided to assume the typical 2.2 gamma in libpaper
>         (by applying the inverse of the nonlinearity to the
>         linear-RGB paper colors) so that people would not have to
>         adjust their gammas.

Also, that gamma corresponds to the human eye response curve better,
having more resolution where it counts.

> Now, compared to the above decision, the change in the present patch is 
> minor -- from the assumption of plain 2.2 exponent to the very similar
> assumption of sRGB nonlinearity. Try gnuplotting
> 
>       plot [0:1] x**2.2,((x+.055)/1.055)**2.4
> 
> to get an idea of the difference. 

I don't understand **at all** how this follows from the above, where
you speak of "-gamma .87" ...

> What is important in sRGB is the different behavior near zero, 
> which models the actual non-linearity implemented in monitors and/or 
> graphics cards much better.

So it's an alternative gamma model?

> Thus, the change will 
>       1) not force anybody to set their gamma anymore than anyone 
>          was forced to set it before,
>       2) yield more accurate color reproduction for RGB components 
>          near zero.
> 
> I needed the .87 gamma correction just to obtain the standard
> 2.2 gamma. That is, in my configuration, the default was actually 
> around 1.9 instead of the assumed 2.2. I'd be happy to change the 
> assumption to 1.9, if it was shown that my case was not an exception 
> but actually closer to the typical case than the standardized value.

Ahh..., Ok, *now* it becomes clear.

> What comes to the linear filtering in OpenGL, we have decided that 
> the inaccuracies resulting from the display gamma will just have to 
> be accepted (as does everybody else) rather than force people to 
> configure for linear RGB, which would 
>       1) make other programs look too light,
>       2) reduce the color resultion (the non-linearity is 
>          implemented to better match perceptual scaling).
> 
> If proper filtering is necessary, a fragment program could be used 
> to implement the inverse non-linearity.

Ok, an excellent explanation. Thank you. 

Will merge presently.

        Tuomas