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

[Janne Kujala]

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:
> > Could you merge
> > 
> > address@hidden
> > sftp://himalia.it.jyu.fi/home/jvkujala/{archives}/address@hidden
> > libvob--jvk--0.1--patch-10
> > 
> > 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 ;)

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.

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. 

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.

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.

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.


        Janne