[sane-devel] pixels_per_line and bytes_per_line
Hi! The SANE Standard Version 1.04 under 4.3.8 states that c = B * n * d/8for d 1 Note that the number of bytes per line can be larger than the minimum value imposed by the right side of this equation. A frontend must be able to properly cope with such padded image formats. If I undersand it correctly, it means: For these parameters B = 1 [channel] n = 100 [pixels per line] d = 8 [bits per sample] c = 100 [bytes] a backend is allowed to set bytes_per_line (c) to a value more than or equal 100. For my scanner (Canon PIXMA MP150) a valid width in grayscale mode must be multiple of 12. I set n = 100 and c = 108 so that the backend by itself doesn't need to throw the padding bytes away. But the output image from scanimage is corrupted. It seems to me that the frontend works properly if and only if c = B*n*d/8. What should I do in this case? Regards -- Wittawat Yamwong Hannover, Germany
[sane-devel] sane_cancel and sane_read
Hi! Should/must/may a frontend call sane_read after sane_cancel? Case I: sane_cancel was called in a signal handler or in other thread. The reader thread still keeps calling sane_read until it returns an error or EOF. That's clear for me. Case II: The frontend has read a block of image data from a backend and it is writing the data to a file but a IO error occurs. The frontend probably calls sane_cancel. What will/must the frontend do next? Will it call sane_read until an error or EOF occurs? This is important to my backend (pixma). It would be much more complex if frontends are not required to call sane_read after sane_cancel because I have to check whether sane_cancel was called synchronously or asynchronously. If it's called synchronously (case II), an outstanding scan operation must be completely canceled before sane_cancel returns. If it's call asynchronously (case I), the request must be postponed by setting a flag for example. The request will be carried out when we return to the reader thread. Regards -- Wittawat Yamwong Hannover, Germany
[sane-devel] sane_cancel and sane_read
Hi Wittawat, On Tuesday 25 April 2006 14:07, Wittawat Yamwong wrote: Should/must/may a frontend call sane_read after sane_cancel? [...] This is important to my backend (pixma). It would be much more complex if frontends are not required to call sane_read after sane_cancel [...] I don't know what the correct answer to this is. However, if the SANE spec seems ambiguous to you then it may seem likewise to a front end writer who might interpret it either way. Therefore for maximum resilience you might be better to bite the bullet and be prepared for either case. cheers, Jon -- == Jon Chambers = http://www.jon.demon.co.uk, 020 8575 7097, 07931 961669 =
[sane-devel] Need Document Scanning on Linux for Kodak i40, i800
Hi! Please advise me as to availability of SANE with capability of scanning documents to produce XML, with interface to i40 and i800 Kodak scanners. The Kodak people say their native interface supports TWAIN and ISIS. Any suggestions would be more than welcome. Thanks! -- Dick Richard C. Johnson, Ph.D. CEO Open Voting Solutions, Inc. 631-689-3736 office 631-689-3774 fax 631-827-6899 cell
[sane-devel] pixels_per_line and bytes_per_line
Hi, On 2006-04-25 14:31, Wittawat Yamwong wrote: The SANE Standard Version 1.04 under 4.3.8 states that c = B * n * d/8for d 1 Note that the number of bytes per line can be larger than the minimum value imposed by the right side of this equation. A frontend must be able to properly cope with such padded image formats. The frontend should be able, but in reality it isn't. At least I don't know of any frontend who could do that. You can also test that behaviour with the test backend by setting the option --ppl-loss to a value 0. doesn't need to throw the padding bytes away. But the output image from scanimage is corrupted. It seems to me that the frontend works properly if and only if c = B*n*d/8. What should I do in this case? Fix scanimage and all the other frontends. Or easier, do the removal of the padding in the backend. Bye, Henning
[sane-devel] Genesys, Canon LiDE 35/40/50/60
Pierre wrote: So, if you own a scanner of the Canon LiDE 35/40/50/60 series, please try the code from the experimental module. The low power mode is used when scanning at resolutions =600dpi, and during calibration. Errors are most likely when the scanner does a fast feed to the scanning area. Also, it would be good if someone owning a gl646 based scanner tests the code, as the gl646 part tends to break whenever i change something :( Regards, Pierre Hello, Tested: LiDE 35: 150,300,600,1200 using usb-1.1. Motor ok. Scans at 150,300 are excellent quality. At 600, 1200 minor image flaws: there is faint but noticable streaks down the longest length of the image, from color reception or brightness not being quite right. Also a few slices across the image, possibly from a jerk of the head at that point in the scan. On the whole, an acceptable image. HP2400: no change, not working. Best regards, Gerald
[sane-devel] Genesys, Canon LiDE 35/40/50/60
Hi Gerald, Gerald Murray schrieb: Tested: LiDE 35: 150,300,600,1200 using usb-1.1. Motor ok. Scans at 150,300 are excellent quality. At 600, 1200 minor image flaws: there is faint but noticable streaks down the longest length of the image, from color reception or brightness not being quite right. That is probably a calibration problem. There is no easy way to fix that. What helped Henning was to clean the calibration area. The backend is currently not able to cope with (much) dirt there. You can get a distorted raw scan of the calibration area by enabling debugging. That should give you a file named black_white_shading.pnm. When scanned at the higher resolutions(=600dpi), it should have vertically striped area(s), but only very few dirt particles. Also a few slices across the image, possibly from a jerk of the head at that point in the scan. On the whole, an acceptable image. Did this happen because the scanner moved the head back to restart at the buffer overflow position? If that is the case, i need to do some more tuning on the acceleration tables. That should definitely not happen(Though it is no reason not to put the code into sane-backends). HP2400: no change, not working. Not working as in refuses to move head/deliver useful data or as in provides a 2400x1200dpi image? For the latter case i do have a patch, enabling a nearest match interpolation. Thanks for testing, Pierre
