[sane-devel] CANOSCAN 8400F
Stef
stef.dev at free.fr
Wed Jun 25 04:41:15 UTC 2014
On 23/06/2014 15:51, Myroslav Kavatsyuk wrote:
> Dear Stef,
>
> Thanks a lot for your suggestions. I have studied genesys
> documentation, and indeed it is helpful :)
>
> I have collected usblogs for all useful scan modes. In case you would
> like to look at them, you can
> download processed (with your script) logs at: CS8400F
> <https://www.dropbox.com/sh/6je6fz2tsjy0r6x/AAA1yr9P6RrlEWaqk5lWjLNSa>
>
>
>
> image
> <https://www.dropbox.com/sh/6je6fz2tsjy0r6x/AAA1yr9P6RrlEWaqk5lWjLNSa>
>
>
> CS8400F
> <https://www.dropbox.com/sh/6je6fz2tsjy0r6x/AAA1yr9P6RrlEWaqk5lWjLNSa>
> Shared with Dropbox
>
> View on www.dropbox.com
> <https://www.dropbox.com/sh/6je6fz2tsjy0r6x/AAA1yr9P6RrlEWaqk5lWjLNSa>
>
> Preview by Yahoo
>
> I made summary of all possible sensor profiles. For each profile I
> wrote at which "dpi" setting of windows driver
> it is used, value of the DPISET register, value of the AVEENB bit
> (average over few pixels or drop pixels):
> /*
> {CCD_CS8400F, dpi, 22000, 0x0, 0xff, 0x0, 5168, 0,0x2a,0x 0,
> 0x 0, 0x 0, -1, 0x07, 0x08, -1, -1,
> {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x3b, 0x0c, 0x10, 0x2a,
> 0x30, 0x00, 0x00, 0x9a},
> {0x01, 0x04, 0x07, 0x0a, 0x0d, 0x10, 0x1b, 0x00, 0x40, 0x00,
> 0x00, -1, 0x88},
> }, // Scanner init, DPISET=600; AVEENB=1
> {CCD_CS8400F, dpi, 10800, 0xe3f, 0x0, 0x1b6db, 5168, 0,0x2a,0x
> 0, 0x 0, 0x 0, -1, 0x01, 0x02, -1, -1,
> {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x33, 0x0c, 0x13, 0x2a,
> 0x30, 0x00, 0x00, 0x84, },
> {0x0d,0x10,0x01,0x04,0x07,0x0a,0x6b,0x00,0x40,0x00,0x00,-1,0x88,},
> }, // Scanner init DPISET=2400, most probably TPU, AVEENB=1
> {CCD_CS8400F, dpi, 7200, 0xe3f, 0x0, 0x1b6db, 5168,
> 0,-1,0xfffffffffffffeff, 0xfffffffffffffeff, 0xfffffffffffffeff, -1,
> 0x01, 0x02, -1, -1,
> {-1, -1, -1, -1, -1, -1, 0x33, 0x0c, 0x13, -1, 0x30, -1, 0x00,
> 0x84},
> {0x0d,0x10,0x01,0x04,0x07,0x0a,0x6b,-1,0x40,0x00,0x00,-1,0x88},
> }, // 600 dpi DPISET=4800 (last value 0x88 -> 0x85); 400,300
> dpi DPISET=2400, last number 0x85; 100 dpi DPISET=1200
> {CCD_CS8400F, dpi, 7200, 0xe3f, 0x0, 0x1b6db, 5168, 0,0x2a,0x
> 0, 0x 0, 0x 0, -1, 0x01, 0x02, -1, -1,
> {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x33, 0x0c, 0x13, 0x2a,
> 0x30, 0x00, 0x00, 0x84},
> {0x0d, 0x10, 0x01, 0x04, 0x07, 0x0a, 0x6b, 0x00, 0x40, 0x00,
> 0x00, -1, 0x85},
> }, // 800 dpi, DPISET=4800
> {CCD_CS8400F, dpi, 14400, 0x1ff, 0x0, 0x24924, 5168, 0,0x2a,0x
> 0, 0x 0, 0x 0, -1, 0x00, 0x01, -1, -1,
> {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x33, 0x0c, 0x11, 0x2a,
> 0x30, 0x00, 0x00, 0x84},
> {0x0b, 0x0e, 0x11, 0x02, 0x05, 0x08, 0x63, 0x00, 0x40, 0x00,
> 0x00, -1, 0x82},
> }, // 1200, 1600 dpi; DPISET=4800
> {CCD_CS8400F, dpi, 28800, 0x0, 0x0, 0x24924, 5168, 0,0x2a,0x
> 0, 0x 0, 0x 0, -1, 0x09, 0x0a, -1, -1,
> {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x33, 0x0c, 0x10, 0x2a,
> 0x30, 0x00, 0x20, 0x84, },
> {0x02, 0x05, 0x08, 0x0b, 0x0e, 0x11, 0x1b, 0x00, 0x40, 0x00,
> 0x00, -1, 0x88},
> }, // 3200,2400 scan; DPISET=4800 (last value can be 0x88 -> 0x81)
> //
> // AVEENB=1 for dpi from 100-400 range; AVEENB=0 for dpi
> 600-3200 range
> */
> This values are almost ready to be plugged into the code. I have to
> replace at some places "-1" values. What is strange for me
> that DPISET values are very high with respect to dpi setting
> reported by driver.
>
> My questions are:
> 1) what does the second field (dpi) means in the scanner profile? Is
> this value of the DPISET register?
> 2) I did not manage to follow where actually sane decides which
> profile to use, which DPISET value to select?
> In other words how to make sure that the correct combination will
> be selected for scan if I pass resolution of dpi to scanimage.
> 3) From the logs I do not see how to extract motor tables (like one in
> the genesys_gl843.h at line 678). In the logs
> I have seen setting up of the MTRTBL bit for downloading table
> (genesys_write_register(0x5b,0x01)genesys_write_register(0x5c,0x00))
> This statements are followed by data. Is that data a motor table?
>
> Best regards,
> Myroslav
Hello,
1) the dpi value is the effective maximum dpi for the scan. Scan's
dpi is the result of DPISET, DPIHW and CKSET. In the simplest case it is
the hardware DPI set for the recorded scan.
2) for a given target resolution, exposure is chosen first
(gl843_compute_exposure which uses get_sensor_profile) by selecting the
sensor profile which has the lowest dpi value above or equal to the
target dpi.
3) data can be written to the GL843 by many slightly different ways
that the decoding scripts may not handle, so look for bulk writes mostly
shorter than 2048 bytes, which turned (little-endian) to 16 bit values
give a decreasing slope with end values becoming closer. In such a
situation, I look at semi-processed log generated by the 'partial.sh'
script. After writes to 5b/5c registers like you noticed.
Example from a 4400F log:
URB 2992 control 0x40 0x04 0x82 0x00 len 8 wrote 0x01 0x00 0x82
0x00 0xfe 0x01 0x00 0x00
URB 2993 bulk_out len 510 wrote 0x00 0x60 0x00 0x60 0xd4 0x3c 0x32
0x2e 0x29 0x26 0xdb 0x20 0x1e 0x1d 0x41 0x1a 0x00 0x18 0x2e 0x16 0xaf
0x14 0x61 0x13 0x49 0x12 0x5b 0x11 0x84 0x10 0xc0 0x0f 0x18 0x0f 0x7d
0x0e 0xf6 0x0d 0x71 0x0d 0x04 0x0d 0x97 0x0c 0x36 0x0c 0xd6 0x0b 0x81
0x0b 0x36 0x0b 0xe9 0x0a 0xa5 0x0a 0x65 0x0a 0x27 0x0a 0xec 0x09 0xb4
0x09 0x82 0x09 0x4f 0x09 0x21 0x09 0xf4 0x08 0xca 0x08 0xa1 0x08 0x79
0x08 0x53 0x08 0x31 0x08 0x0d 0x08 0xed 0x07 0xce 0x07 0xae 0x07 0x91
0x07 0x74 0x07 0x5b 0x07 0x40 0x07 0x27 0x07 0x0d 0x07 0xf7 0x06 0xdf
0x06 0xc9 0x06 0xb3 0x06 0x9e 0x06 0x8b 0x06 0x77 0x06 0x64 0x06 0x52
0x06 0x40 0x06 0x2e 0x06 0x1d 0x06 0x0c 0x06 0xfb 0x05 0xec 0x05 0xdc
0x05 0xce 0x05 0xbf 0x05 0xb1 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf
0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05 0xaf 0x05
URB 2994 control 0x40 0x04 0x83 0x00 len 2 wrote 0x5b 0x00
which gives 0x6000, 0x6000, 0x3cd4, 0x2e32, ...., 0x05ce, 0x05bc,
0x05b1, 0x05af, 0x05af .... 0x05af
Regards,
Stef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20140625/785fa2ee/attachment-0001.html>
More information about the sane-devel
mailing list