[sane-devel] EPSON 3490, calibration and raw data

[Kai-Uwe Behrmann]

Krzysztof,

not an insider of sane programming, but some comments below:

Am 11.02.06, 13:54 +0100 schrieb Krzysztof Halasa:

> Hi,
> 
> Please forgive my ignorance, I've just started using EPSON 3490.
> 
> I'm especially interested in scanning negative 35 mm films (yes, I know
> it's low-end, it's like an experiment).
> 
> Reading the sources to snapscan backend I got the impression that:
> a) before the actual scanning the scanner performs white level calibration
>    (and, with TPU, black level calibration).
>    This is actually READ/READ_CALIBRATION and READ/READ_CALIBRATION_BLACK
>    and the scanner just scans 16 lines of open area behind the actual
>    film (and respectively 48 lines for black calibration, not sure where).
> 
>    The images are either 8-bit or 16-bit, but I'm not sure all bits are
>    used (details?).
> 
> b) the scanned "calibration image" is averaged and a single line is sent
>    back using SEND/READ_CALIBRATION and SEND/READ_CALIBRATION_BLACK.
>    Not sure about 16-bit, does the values differ from 8-bit mode?
> 
> c) eventually the "analog" gamma information is uploaded to the scanner
>    as well (not yet sure about details, someone?).
> 
> What do I need? I need to obtain "raw" scan data, without any calibration
> or gamma correction at scanning time.

My expectation about indevice gamma correction, it is a mathematical 
conversion to the full bit depth. Thus the native 10/12/14-bit signal is 
fixed in the AD unit and anything like gamma and B/W point is applied to 
this stream. If someone with more technical insight can negate it would 
be interessting on how to manipulate the AD conversion.

> Now I have disabled READ/READ_CALIBRATION* command and the whole averaging
> etc. and I'm doing SEND/READ_CALIBRATION* with the following data:
> - for white: 255 0 0 0 ...
> - for black: 0 0 0 0 ...
> 
> Does it disable the calibration and related calculations? The following
> code fragments suggests so but the algorithm seems a bit strange (for black
> and white but it essentially the same for RGB):
> 
>         /* now make averages */
>         for (k = 0; k < num_bins; k++) {
>             bins[k] /= cal_lines;
>             /* also divide by 64 for 16bit mode */
>             if (bytes_per_bin == 2)
>               bins[k] /= 64;
>         }
> 
> and then:
> 
>             g = 0;
>             for (k = 0; k < num_bins; k++) {
>                 *pbuf++ = bins[k] - g;
>                 g = bins[k];
>             }
> 
> Why the /64? Does the calibration data in 16-bit mode consist of 8-bit
> samples shifted left by 6 bits (i.e., 14-bit samples with lower 6 bits
> unused/ignored)?
> 
> 
> Next thing, "analog" gamma - does setting it to 1.0 prevents scanner
> firmware from doing any calculations?
> 
> Is this scanner really 48-bit (3 * 16 bit)? Can I really get full 16-bit
> data from it?

This certainly not for the above device. I would guess 10-14 bit with 
appropriate noice. Multisampling helps for the latter. You have to test if 
the tonal range is good enough for negative scanning. Not shure if newer 
consumer scanners are better in this field.

> Do you think adding "get raw data" option and possibly "get calibration
> data" (for further processing with general image-manipulation programs)
> to this backend would make sense?
> 
> 
> Any help will be appreciated.
> -- 
> Krzysztof Halasa
> 

regards
Kai-Uwe Behrmann
                                + development for color management 
                                + imaging / panoramas
                                + email: ku.b at gmx.de
                                + http://www.behrmann.name