primax: Re: primax_scan.c gamma
Subject:
Re: primax_scan.c gamma
From:
####@####.#### (Thomas Schano)
Date:
25 Jan 2000 22:44:06 -0000
Message-Id: <388E246B.EC93C384@t-online.de>
Gustaf Kroling wrote:
>
> Thomas Schano wrote:
>
> > Remember the driver is only an alpha-version! I think Marco did his
> > best. As I remember he used the table from some scanns and tried to find
> > a function correlating to it. Until the funktion that produces the
> > color-tables is correctet (written like the definitions of gamma and so
> > on says) use the funktions of GIMP or other image-tools to correct the
> > gamma values.
>
> Ok, here is what I have found:
>
> The scanner has a semiconductor detector so it is linear,
> everything else
> up to the crt is also linear if nothing special is done.
> Remains the crt
> *and* the human eye. Low cost terminals are not gamma
> corrected so
> it is the gamma of the tube that counts. It is in the range
> 2.0 to 2.8 or so
> for a colour tube. The human eye is normally adapted to low
> light when one
> is looking at a crt indoors. This means that the eye is
> close to its lower
> limit for colour perception. Darker parts of a picture look
> very dark. The
> net effect is that you need a total gamma of 1.4 all over.
> The crt's gamma
> of maybe 2.8 is too much so we need a *gamma-correction* of
> 2.8/1.4 = 2.0 ie.
> our function to put into the color_table should look like (
> i )^1/2.0 .
>
> I have tried this and I think my scan looks exactly as a win
> scan when watching
> the pictures side by side on the same monitor. I use
> color[].gamma=2.0 .
>
> midin=(double)(redmin+redmax)/2.0;
> b = (1.0 + image->color[0].brightness / 100.0) *
> midin;
> m = 1.0 + image->color[0].contrast / 100.0;
> for (i=0; i <= maxin; i++){
> val=((double)i-midin)*m+b;
> if((int)val<redmin) image->color_table[0][i] =
> 0;
> else {
> if((int)val>redmax) image->color_table[0][i]
> = 0xff;
> else {
> image->color_table[0][i] = maxout * pow(
> (val-(double)redmin
> /(double)(redmax-redmin),(1.0 / image->color[0].gamma) );
> }
> }
> }
> .. and so on for green and blue.
>
> Before this redmin should be set to the adc value
> representing the black level and
> redmax should be set to the value you get for white. Note
> that the gamma correction
> is applied to the normalised input range not to the total
> range of the adc.
>
> Well, that was all. Hope it can be of some use. :-)
>
> Gustaf
Many thanks to you,
It isn't applied to the range of the adc (10 to 12 Bit per color). It is
applied to the possible range of 8 Bit per color at the output of the
scanner. That's the range off colors the crt gets. So it's normalized to
the systems max. value.
I've found a very nice document about gamma correction on the net: "FAQ
about Gamma" by Charles Poynton http:www.inforamp.net/~poynton I looked
to the Document and found, that what's marco made was quite ok. The only
fault was in the parse_options: The field for the gamma, brightness and
contrast has a component for every color. Only one component is written
in
parse_options. The others don't get new values. -- If someone is
irritated
about the 0.5 it's only for correct rounding.
The error is already corrected in my development version. The version
will be released soon.
An other problem is: I did the color to gray conversion with the PAL
values not with them for linear systems. My problem is now how to handle
the conversion values in respect to the gamma correction? Should I do it
mathematically or with parameters - who can handle all this
parameters?
Thomas
P.S. Be careful with the linearity of electronic devices -- I have not
seen any linear electronic device if you look to the figure! (Clipping
not
included). Often a nonlinearity of e.g. 10% is called linear.
