[sane-devel] CANOSCAN 8400F

[Stef]

On 04/06/2014 12:22, Myroslav Kavatsyuk wrote:
>
> Dear Stef,
>
> thanks a lot for your suggestions and scripts. The more I dig into the 
> source code, the more
> questions I have. Here they are:
>
> 1) file genesys_devices.c, definition of  Genesys_Model 
> canon_8400f_model (line 1691). I realized that the dpi list does not 
> correspond to the model (CS8400F has maximum resolution of 3200dpi).
> - Shell I change the array with values available in the windows driver 
> of the scanner? Is the length of the array fixed?
     You may do such. But be aware that the resolution advertised by the 
windows driver GUI are usually different from the DPI used to do the 
scan. It is safer to work with resolution you find in USB log, or 
resolution derived for other working ones. Try to do USB log of 
resolution matching physical hardware, or divided by a round factor.
     The length is fixed, and has a MAX_RESOLUTIONS size.

> - Are the other values extracted from some logs, or shell I 
> disassemble unit to measure all constants (position of white strip)?
     Tune scanarea geometry only when you have made scan working. No 
need to dismantle your scanner, change all offsets to be zero (in 
genesys_device.c), and it will scan itself where you cannot see.

> - I have performed test scan with resolution of 100dpi of size 10x10 
> cm (specified with -x -y option). The resulting image had proper 
> number of lines/rows (393), proper aspect ratio. However, the scan are 
> was about 15x15 cm. I assume this has something to do with wrong array 
> with dpi setting...
BTW, you can find GL843 datasheet on internet, it will help you 
understand what all the registers are for. Real dpi is a combination of 
sensor DPISET, deletion factor and exposure.

>
> 2) genesys_gl843.h, There is definition of the Sensor_Profile sensors. 
> For the CS8400F there is defined array (line 666). I logged several 
> scans with different dpi settings using usbsnoop. After processing 
> logs with your script I found that there are different possible values 
> reported for the sensor_profile and motor_profile. This profiles do 
> not coincide with the one in the genesys_gl843.h. Here are ones, 
> extracted from the logs:
>
> sensor_profile { sensor_id, dpi, 7200, 0xe3f, 0x0, 0x1b6db, 5168, 
> 0,0xffffffffffffffff,
> 0xfffffffffffffeff, 0xfffffffffffffeff, 0xfffffffffffffeff, 
> 0xffffffffffffffff, 0x01, 0x02, 0xffffffffffffffff, 0xffffffffffffffff,
> {0xffffffffffffffff, 0xffffffffffffffff, 0xffffffffffffffff, 
> 0xffffffffffffffff, 0xffffffffffffffff, 0xffffffffffffffff, 0x33, 
> 0x0c, 0x13, 0xffffffffffffffff, 0x30, 0xffffffffffffffff, 0x00, 0x84, },
> {0x0d,0x10,0x01,0x04,0x07,0x0a,0x6b,0xffffffffffffffff,0x40,0x00,0x00,0xffffffffffffffff,0x85,},
> }
> sensor_profile { sensor_id, dpi, 7200, 0xe3f, 0x0, 0x1b6db, 5168, 
> 0,0xffffffffffffffff,
> 0xfffffffffffffeff, 0xfffffffffffffeff, 0xfffffffffffffeff, 
> 0xffffffffffffffff, 0x01, 0x02, 0xffffffffffffffff, 0xffffffffffffffff,
> {0xffffffffffffffff, 0xffffffffffffffff, 0xffffffffffffffff, 
> 0xffffffffffffffff, 0xffffffffffffffff, 0xffffffffffffffff, 0x33, 
> 0x0c, 0x13, 0xffffffffffffffff, 0x30, 0xffffffffffffffff, 0x00, 0x84, },
> {0x0d,0x10,0x01,0x04,0x07,0x0a,0x6b,0xffffffffffffffff,0x40,0x00,0x00,0xffffffffffffffff,0x88,},
> },
> sensor_profile { sensor_id, dpi, 22000, 0x0, 0xff, 0x0, 5168, 0,0x2a,
> 0x 0, 0x 0, 0x 0, 0xffffffffffffffff, 0x07, 0x08, 0xffffffffffffffff, 
> 0xffffffffffffffff,
> {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,0xffffffffffffffff,0x88,},
> },
> sensor_profile { sensor_id, dpi, 10800, 0xe3f, 0x0, 0x1b6db, 5168, 0,0x2a,
> 0x 0, 0x 0, 0x 0, 0xffffffffffffffff, 0x01, 0x02, 0xffffffffffffffff, 
> 0xffffffffffffffff,
> {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,0xffffffffffffffff,0x88,},
> },
> sensor_profile { sensor_id, dpi, 14400, 0x1ff, 0x0, 0x24924, 5168, 0,0x2a,
> 0x 0, 0x 0, 0x 0, 0xffffffffffffffff, 0x00, 0x01, 0xffffffffffffffff, 
> 0xffffffffffffffff,
> {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,0xffffffffffffffff,0x88,},
> },
> sensor_profile { sensor_id, dpi, 7200, 0xe3f, 0x0, 0x1b6db, 5168, 0,0x2a,
> 0x 0, 0x 0, 0x 0, 0xffffffffffffffff, 0x01, 0x02, 0xffffffffffffffff, 
> 0xffffffffffffffff,
> {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,0xffffffffffffffff,0x85,},
> }
>
> They are all different. Do you have any suggestions what to do with 
> this? For each sensor_profile there is a motor_profile. They have the 
> following structure:
> motor_profile={id,7200,2, {0, 0, ......} all skipped numbers are zeros 
> (in contrast to one in the genesys_gl843.h, line 677). The second 
> number coincides with the first number reported in the sensor_profile.
>
> I would appreciate you suggestions for further implementation.
> Thank you in advance,
> Best regards,
> Myroslav
>
     Scan a ruler (either in inches or centimeters), and extract image 
data from log to find the real 'dpi' value in the *_profile. These 
profiles are only a database for a given motor or sensor (the id) for a 
given exposure. 0xffffffffffffffff is -1 and means register has never 
been set in logs. You can put whatever value you want in this case, but 
0 looks better. But having all o them 0 looks strange to me. Be sure you 
have the full log, from boot to end of scan.
     I usually choose few settings that let me derived several scan 
resolution, and more precisely one from final scan. What you see is that 
for a given scan, the scanner goes through several other scans in other 
resolution to calibrates himself. You can recognize the final scan by 
the pixel width and line number and the amount of data.

Regards,
     Stef
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20140610/3db068de/attachment.html>