[sane-devel] Xsane notes
Hi, On Tue, Nov 12, 2002 at 11:43:49PM +0200, Juhana Sadeharju wrote: Bug: In Save mode, scanning is started before verifying if the file can be opened. The result is that the scanner stops at middle of scanning if the file cannot be opened. The file should be verified before also in the case where a file is going to be overwritten (if xsane asks for overwritings at all). That means that the file must be kept open until scanning is finished. I'm not sure if there are other implications, e.g. when sane_start results in something other than SANE_STATUS_GOOD. Bug: xsane cannot recover from the above problem. Pressing the start button gives an error failed to start scanner: invalid argument. Turned scanner power off and on; no help. Quitting xsane made the xsane wild, giving the following errors in an infinite loop: [epson] error in receive - status = 9 [epson] error in receive - status = 9 Well, Linux did not jam and at least kill -KILL helps. :-( That's probably a backend bug. XSane issues a sane_cancel and with the gt68xx backend there is no problem to scan again. Suggestion: reset the scanner button so that the start button works again without kill -KILL. I also have had problems in finding the scanner from usb line; some query scanner button could help (oh, but the xsane won't start because it does not find the scanner). That's either a backend or even kernel problem. Suggestion: Histogram could show the histogram of the scanned image, not of the preview. This saves in taking the previews, but one would still immediately notice any problems in patch scanning. But then picking white/gray etc. point wouldn't show up in the histogram? Suggestion: The start button could be larger and square. Sometimes it takes too much time to aim to the relatively tiny start button. The current width of the button seems to be ok, just make it square. Ctrl-Enter starts the scan, if this helps. Bye, Henning
[sane-devel] Xsane notes
Hello. Here I have yet new bug reports for xsane 0.84 (I will update later to more recent version), but first about the project save/load: Yes, all settings should be saved, including the preview image. The reasons for saving the preview image are: -Visual continuity of different sessions of the same project -No need to make another preview if the same project continues (saves the scanner mechanics) -The saved and later loaded preview image gives visual proof that one has the correct scanner settings (now one stares at Xsane logo and wonders if all settings really are the same) -Histogram tool shows the histogram of the preview image (or of that Xsane logo if preview is not saved) For those who does not need to save previews, there could be do not save preview for this project option. Yes, the exact scan area and the enchangements settings typically changes for different scanning, but for an individual project I usually select a large enough scanarea and always disable enchangements. This saves a lot of previews. Bug: The scanning mode is not saved at all. It should be part of the project save/load as well. Bug: In Save scanning mode, after browsing a new filename, the path is visible as /home/juhana/scann, not as annings/123.pnm as should be. Note: the next, incremented filename is shown correctly. Bug: In Save mode, scanning is started before verifying if the file can be opened. The result is that the scanner stops at middle of scanning if the file cannot be opened. The file should be verified before also in the case where a file is going to be overwritten (if xsane asks for overwritings at all). I would not want that scanner mechanics are used unnecessarily this way. (Replicate: Make scannings/temp/ dir, scan to temp/001.pnm, quit xsane, delete temp/ dir, run xsane, scan to the memorised temp/002.pnm -- ping.) Bug: xsane cannot recover from the above problem. Pressing the start button gives an error failed to start scanner: invalid argument. Turned scanner power off and on; no help. Quitting xsane made the xsane wild, giving the following errors in an infinite loop: [epson] error in receive - status = 9 [epson] error in receive - status = 9 Well, Linux did not jam and at least kill -KILL helps. :-( Suggestion: reset the scanner button so that the start button works again without kill -KILL. I also have had problems in finding the scanner from usb line; some query scanner button could help (oh, but the xsane won't start because it does not find the scanner). Suggestion: Histogram could show the histogram of the scanned image, not of the preview. This saves in taking the previews, but one would still immediately notice any problems in patch scanning. Suggestion: In Save mode, the scanned image could be displayed as well. Preferably in some smaller size, e.g., 600x400. The next image would appear in the same window so that user does not need to delete the window away before the next scan. Suggestion: The start button could be larger and square. Sometimes it takes too much time to aim to the relatively tiny start button. The current width of the button seems to be ok, just make it square. Suggestion: An adjustable time delay before the scanning really starts after pressing the start button. Say, 0,1,2,3,4,5 seconds are enough. This setting should be easily available, not puried to preferences. The delay should work even if one presses the start button of the scanner. The reason is that the big, fat books needs manual help from user: instead of pressing the book down flat and thus breaking the scanner, it helps if the other half of the book is lifted up and the center is gently hold on scanner. A couple of seconds delay gives time to prepare for the actual scanning. Best regards, Juhana
[sane-devel] Xsane notes
Major A, Mittwoch, 6. November 2002 23:17: # XSane settings: # resolution_x = 200.0 # resolution_y = 200.0 # gamma = 1.00 # brightness = 0.0 # contrast = 0.0 # XSANE data follows 01696 0 255 I Don`t know gqview. The header looks ok. Please bear in mind that, by convention, integers starting with 0 followed by another digit are taken to be octal numbers in most programs. Apparently, gqview simply does a strtol() on the line with the third parameter set to 0, thus realizing the first number in the line is octal. It stops when it encounters the 9, which is invalid in the octal base, the second strtol() then picks up at the 9. That's why the image size is taken to be 14 (which is 016 in octal) times 96. Unless the PNM standard (is there such a thing?) specifies explicitly that decimal base be used, this is a bug in SANE, whereever it is -- image dimensions must not have leading zeros. E.g. man pgm states, that width and height are formatted as ASCII characters in decimal. If some image viewer interprets the width/height as an octal number, I think one could call this a bug. bb Michael
[sane-devel] Xsane notes
Hi, On Wed, Nov 06, 2002 at 10:17:44PM +, Major A wrote: Please bear in mind that, by convention, integers starting with 0 followed by another digit are taken to be octal numbers in most programs. Apparently, gqview simply does a strtol() on the line with the third parameter set to 0, thus realizing the first number in the line is octal. It stops when it encounters the 9, which is invalid in the octal base, the second strtol() then picks up at the 9. That's why the image size is taken to be 14 (which is 016 in octal) times 96. Maybe that happened in the case described by the original author. I'm using GQview 1.0.2 here and it detects the width and height correctly. The crash happens when too much comments are used in the pnm. Looks like a buffer overflow. As this also happens with gqview 1.1.6, I'll write a bug report. Bye, Henning
[sane-devel] Xsane notes
E.g. man pgm states, that width and height are formatted as ASCII characters in decimal. If some image viewer interprets the width/height as an octal number, I think one could call this a bug. OK, thanks for that, I wasn't aware of that manpage. In this case, it's a bug in gqview. Andras === Major Andras e-mail: and...@users.sourceforge.net www:http://andras.webhop.org/ ===
[sane-devel] Xsane notes
I have xsane 0.84, and here goes::-) Feature suggestion: Saving of settings with a given project name; all settings are saved, including the preview settings and the preview image. That is, the preview image and the associated scanarea must be saved. (Project save/load perhaps?) Feature suggestion: Are the gamma/look-up tables (of some scanners) as wide as the internal precision? If a scanner has greater internal precision but only 8-bit output precision, then I guess the look-up tables could be used for dynamic compression for the 8-bit transfer. The full precision would then be recovered in driver or in application. One would have to scan a preview, compute the look-up tables, and do the final scan with the computed look-up tables. If also enchangements are done, they are also incorporated to the look-up tables. Bug: Gamma etc. settings were autoadjusted after acquiring the preview even I had unchecked Autoenchange gamma and Autocorrect colors Setup-options. Bug: In Save scanning mode, with Type PNM, with filename 123.pnm, the saved file is named as 123.pnm.pnm instead of the correct 123.pnm. I would also point out that gqview, a good image viewer, cannot load the pnm files produced by xsane. The following image is show incorrectly as of the size 14x96. P5 # XSane settings: # resolution_x = 200.0 # resolution_y = 200.0 # gamma = 1.00 # brightness = 0.0 # contrast = 0.0 # XSANE data follows 01696 0 255 Best regards, Juhana
[sane-devel] Xsane notes
Hi, On Wed, Nov 06, 2002 at 08:05:51PM +0200, Juhana Sadeharju wrote: Feature suggestion: Are the gamma/look-up tables (of some scanners) as wide as the internal precision? In hardware, yes. E.g. The Mustek SCSI Pro and Scanexpress models use 12 bits of gamma per color. It's not implemented in software, however (see messages posted earlier). If a scanner has greater internal precision but only 8-bit output precision, then I guess the look-up tables could be used for dynamic compression for the 8-bit transfer. That's how it works. Only that the mustek backend doesn't export the 12 bit gamma table to the fontends. The full precision would then be recovered in driver or in application. How? You have a table that reduces 4096 different values to 256. How do you want to revert that procedure? On the other hand, some scanners provide 12 (or 16) bit output directly. But maybe I didn't understand you correctly. One would have to scan a preview, compute the look-up tables, and do the final scan with the computed look-up tables. If also enchangements are done, they are also incorporated to the look-up tables. That's an issue for the backends I guess. Bug: Gamma etc. settings were autoadjusted after acquiring the preview even I had unchecked Autoenchange gamma and Autocorrect colors Setup-options. I have never seen this for my scanners. But I'm using xsane 0.88 so maybe it was an issue with earlier versions. Bug: In Save scanning mode, with Type PNM, with filename 123.pnm, the saved file is named as 123.pnm.pnm instead of the correct 123.pnm. Doesn't happen here with 0.88. I would also point out that gqview, a good image viewer, cannot load the pnm files produced by xsane. The following image is show incorrectly as of the size 14x96. Then I guess gqview has a bug. When I try gqview with xsane pnms, it crashes (segmentation fault). As all the other viewers show the image correctly, I think it's gqviews fault. If I remove the comments from the pnm file, gqview can show it. The comments are allowed in the pnm spec. Bye, Henning
[sane-devel] Xsane notes
Juhana Sadeharju schrieb: I have xsane 0.84, and here goes::-) Feature suggestion: Saving of settings with a given project name; all settings are saved, including the preview settings and the preview image. That is, the preview image and the associated scanarea must be saved. (Project save/load perhaps?) It does not make sense to save the preview image because when you remove the image from the scan surface you can not be sure to put it back to the same position. When you do preferences-save device preferences then all device dependant values are saved in the file. Save the filename with the name of your project. Feature suggestion: Are the gamma/look-up tables (of some scanners) as wide as the internal precision? If a scanner has greater internal precision but only 8-bit output precision, then I guess the look-up tables could be used for dynamic compression for the 8-bit transfer. The full precision would then be recovered in driver or in application. You can not recover 12 bits from the transfered 8 bit data. But you can produce data that uses the full range of the 8 bits. One would have to scan a preview, compute the look-up tables, and do the final scan with the computed look-up tables. If also enchangements are done, they are also incorporated to the look-up tables. That is what xsane does. Bug: Gamma etc. settings were autoadjusted after acquiring the preview even I had unchecked Autoenchange gamma and Autocorrect colors Setup-options. I can not reproduce this. Bug: In Save scanning mode, with Type PNM, with filename 123.pnm, the saved file is named as 123.pnm.pnm instead of the correct 123.pnm. I can not reproduce this. I would also point out that gqview, a good image viewer, cannot load the pnm files produced by xsane. The following image is show incorrectly as of the size 14x96. P5 # XSane settings: # resolution_x = 200.0 # resolution_y = 200.0 # gamma = 1.00 # brightness = 0.0 # contrast = 0.0 # XSANE data follows 01696 0 255 I Don`t know gqview. The header looks ok. I suggest you update to xsane-0.89, there were several improvements and bugfixes. Bye Oliver -- Homepage: http://www.rauch-domain.de sane-umax: http://www.rauch-domain.de/sane-umax xsane: http://www.xsane.org E-Mail: mailto:oliver.ra...@rauch-domain.de
[sane-devel] Xsane notes
# XSane settings: # resolution_x = 200.0 # resolution_y = 200.0 # gamma = 1.00 # brightness = 0.0 # contrast = 0.0 # XSANE data follows 01696 0 255 I Don`t know gqview. The header looks ok. Please bear in mind that, by convention, integers starting with 0 followed by another digit are taken to be octal numbers in most programs. Apparently, gqview simply does a strtol() on the line with the third parameter set to 0, thus realizing the first number in the line is octal. It stops when it encounters the 9, which is invalid in the octal base, the second strtol() then picks up at the 9. That's why the image size is taken to be 14 (which is 016 in octal) times 96. Unless the PNM standard (is there such a thing?) specifies explicitly that decimal base be used, this is a bug in SANE, whereever it is -- image dimensions must not have leading zeros. Andras === Major Andras e-mail: and...@users.sourceforge.net www:http://andras.webhop.org/ ===
