> > > Btw, is there anyway a frontend could extract the proper
> > > RGB exposure times from you backend?
> >
> > Not in version 0.4.2 but I am working on the problem.
> > Do you really need these values or would it be sufficient
> > if you can change the exposure time in percent of the optimal
> > value determined by the prescan as it was for the LS-20?
>
> My concern is not changing the values but getting them from the
> backend so the frontend knows how to make sense out of the RGB values.
When you say "make sense out of the RGB values" do you mean:
"get some calibrated interpretation of the RGB values"?
This is a difficult topic. It requires that we calibrate the
scanner with some reference and also that all gamma-LUT-transformation
is applied to the image after we have done all the sensitivity
correction (e.g. between R G and B).
> I think we could use SANE_NAME_SCAN_EXPOS_TIME_R (defined in
> sane/saneopts.h) and friends for that.
OK. To transmit these values is not really a problem.
> That is, the frontend should
> check these options and if they are present then it should divide the
> RGB values by their corresponding exposure time.
This will require to transmit the data in a format that is linear
with exposure which requires 16 bit data to be transfered to the
frontend and also that the LUT is applied in the frontend.
> The RGB exposure options that the backend exports need not be absolute
> in any way; they can be relative to each other and the frontend should
> be able to make sense of it.
If they were absolut we could do scanning with an absolut reference
like optical density (=log(attenuation)). That could be nice too.
This will make professional quality scans possible where the
result is really as much scanner independent as possible within the
limits of the scanners capabilities.
>
> An alternative way would be to do the dividing in the backends. Since
> we're dealing with filmscanners here that will most likely use
> 16 bit transmit data, there is no loss of accuracy. For 8 bit data
> there would be unacceptable loss of accuracy when scanning negatives.
If you do it in the backend, you can divide and then apply the user
gamma-LUT and send a 8-Bit result to the fronend which has a good
accuracy (even for negatives).
> So where should we put it, in the frontend or up the backend?
I will probably do a test to implement this in the Coolscan backend,
but this doesn't exclude the frontend developpers to include
a better version (the two approaches are not exclusive).
One reason to do it inside the backend for the LS-30 and LS-2000
is to do a good correction of the infrared channel at the same time
so that finding the right threshold for dust removal becomes easy.
Andreas
-- Source code, list archive, and docs: http://www.mostang.com/sane/ To unsubscribe: echo unsubscribe sane-devel | mail majordomo@mostang.com