primax: Thread: Re: primax_scan.c gamma

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.

Gustaf Kroling wrote:

> Hello Thomas,
>
> > 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.
>
> Well, what I meant was that the color_table is set up as if
> the black level
> is very close to zero and that white is max from the adc on
> all three channels.

That's ok. That's my way of thinking.

>
> This may work for you if the calibration routine can fine
> adjust both gains
> and offsets. This is not possible in my case since I need to
> set a gain in the interval 2 to 3 with a resolution of .25 per step!

Does this mean that you use a resolution of the color that correlates
with
the resolution of the 30 bits the adc uses? Do you make scans with 30
bit per
pixel instead of 24 bit per pixel?


With my scanner the black value is calibrated to a value below 0C hex.
The
transformation I use is the standard one (no command line argument!). So
with
a digital gain of 3 the value gets 24 hex at max. If that is not good
enough
use the brightness option to adjust the black to 0. An other way is to
look
to the calibration and make it better. ;;;-))))
One problem I have is that I don't know how black the black I use is.
This
means: I use a black stripe under the top scale to adjust the black
value.
But I do not know If this stripe is real black. The scanner may get
scattered
light, perhaps that stripe is only a dark gray. So use the brightness to
adjust your black. But remember the attenuation of the light getting to
different CCDs in the line is not the same at each point!  Look to the
PGA
array to see the function of attenuation.

>
> >
> > I've found a very nice document about gamma correction on the net: "FAQ
> > about Gamma" by Charles Poynton http:www.inforamp.net/~poynton
> Yes, very good. Did you notice the FQA too?
>
> > 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.
>
> I had a look at marcos original code and now I see that I
> missed that 'midin'
> cancels out. Shame on me. My real problem was the one
> described above.
>
> > 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?
>
> I am not sure that I understand the problem:
> >From my old book I get that they just do the gamma
> correction directly on

I have got an old tv-book too. But TV-systems were set up many years
ago. The
technic is analog.
-- We have a digital signal processing system called PC. Computers
normally
works in linear world to process pictures. So the gamma correction has
to be
done by the output interface (printer driver, video card.....).

>
> the signals from the camera tubes and then add them to get
> the gray signal.
> The book says that this is not really the correct way but it
> is simple. A better
> way would be to first do the addition and then gamma
> correct. But this is not
> good way to do it when the color-matrix is located in the
> scanner. Anyway, they
> use the same correction for colour and gray so they have no
> extra parameters
> involved if that is what you mean. Don't your scans look ok?

You said it, "it is not correct". But if I look to the correspondences
with
you and others it looks like "Every thing has to be correct and the
finest".

>
> I have also
> noticed that TaskBridge does not give you any chance to
> control the individual
> gammas when you select gray scanning.

TaskBridge is not the world. If we need other options we should create
them.

>
>
> Gustaf

Thomas

P.S. TaskBridge uses 2.2 as default value to the gamma correction.

PPS: The Code is licend to GNU. So feel free to make some functions in a
better way. (The actual version is an ALPHA version. Writing this code
is my
hobby not my profession.)

PPPS: Please use the mailing list ####@####.#### to
discuss problems like this. So that others can see that something is
already discussed.