[sane-devel] A couple issues with genesys HP G4010
Le Saturday 29 January 2011 21:26:03 Brian Shaver, vous avez ?crit : allan, If I comment out the function call which was causing the crash, then I'm able to run with a high genesys debug level. This function call was just for debug purposes to create the unprocessed.pnm file. The following commands were executed with: SANE_DEBUG_GENESYS=255 SANE_DEBUG_SANEI_MAGIC=255 ./scanimage --mode Lineart --resolution 100 -l 21.4 -t 79.7 -x 148.7 -y 138.9 --swdespeck=yes /tmp/despeck.pnm 2 /tmp/despeck.log ./scanimage --mode Lineart --resolution 100 -l 21.4 -t 79.7 -x 148.7 -y 138.9 /tmp/no_despeck.pnm 2 /tmp/no_despeck.log Attached are the images and log files. The black band at the bottom of the despeck image does not change size based on the despeck value. Thanks, Brian .. On Sat, Jan 29, 2011 at 11:30 AM, m. allan noah kitno455 at gmail.com wrote: brian- I did not write the genesys backend, but I did write the sanei_magic library that it uses to provide the swdespeck option. It would be interesting to see a low resolution version of the two images, and a log with: SANE_DEBUG_SANEI_MAGIC=255 combined with whatever the highest debug level genesys will give without crashing. allan On Fri, Jan 28, 2011 at 8:19 AM, Brian Shaver shakerlxxv at gmail.com wrote: I'm using the Lineart mode and trying the --swdespeck option and I've noticed its leaving a black band along the bottom of the image. The 2nd issue, is that when I turn the debug up ( SANE_DEBUG_GENESYS=10 ) and try the same scan, the process seg faults. The following is the stack from the core: (gdb) bt #0 0x7fa3e4ce35c8 in sanei_genesys_write_pnm_file (filename=0x7fa3e4cec479 unprocessed.pnm, data=0x7fa3e2267000 Address 0x7fa3e2267000 out of bounds, depth=1, channels=1, pixels_per_line=2360, lines=3188) at genesys_low.c:144 #1 0x7fa3e4caa60f in genesys_buffer_image (s=0x99e340) at genesys.c:6895 #2 0x7fa3e4caccab in sane_genesys_start (handle=0x99e340) at genesys.c:7864 #3 0x7fa3eae33ae2 in sane_dll_start (handle=0x99b2a0) at dll.c:1263 #4 0x7fa3eae20d38 in sane_start (h=0x99b2a0) at dll-s.c:48 #5 0x00406d1c in main (argc=13, argv=0x7fffe2b73a08) at scanimage.c:2283 The code is trying to write out a file ( unprocessed.pnm ) containing ... I think the Lineart converted data before performing the despeck process. I'd be happy to help with a fix for this, or provide further information or testing. Thanks, Brian .. -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org -- The truth is an offense, but not a sin Hello, thanks for providing these detailed information. For the crash, the image writing function doesn't handle line art bitmap format. I'm currently fixing that. For the black band, it is due to incorrect settings in registers in line art mode which makes the backend reading too much data from the scanner. This extra data is filled with 'noise'. I am currently looking into that. Regards, Stef
[sane-devel] A couple issues with genesys HP G4010
Thanks Stef! Let me know if you'd like any additional information, or if I can be any help with the fix. Thanks, Brian .. On Sun, Jan 30, 2011 at 2:36 AM, stef stef.dev at free.fr wrote: Le Saturday 29 January 2011 21:26:03 Brian Shaver, vous avez ?crit : allan, If I comment out the function call which was causing the crash, then I'm able to run with a high genesys debug level. This function call was just for debug purposes to create the unprocessed.pnm file. The following commands were executed with: SANE_DEBUG_GENESYS=255 SANE_DEBUG_SANEI_MAGIC=255 ./scanimage --mode Lineart --resolution 100 -l 21.4 -t 79.7 -x 148.7 -y 138.9 --swdespeck=yes /tmp/despeck.pnm 2 /tmp/despeck.log ./scanimage --mode Lineart --resolution 100 -l 21.4 -t 79.7 -x 148.7 -y 138.9 /tmp/no_despeck.pnm 2 /tmp/no_despeck.log Attached are the images and log files. The black band at the bottom of the despeck image does not change size based on the despeck value. Thanks, Brian .. On Sat, Jan 29, 2011 at 11:30 AM, m. allan noah kitno455 at gmail.com wrote: brian- I did not write the genesys backend, but I did write the sanei_magic library that it uses to provide the swdespeck option. It would be interesting to see a low resolution version of the two images, and a log with: SANE_DEBUG_SANEI_MAGIC=255 combined with whatever the highest debug level genesys will give without crashing. allan On Fri, Jan 28, 2011 at 8:19 AM, Brian Shaver shakerlxxv at gmail.com wrote: I'm using the Lineart mode and trying the --swdespeck option and I've noticed its leaving a black band along the bottom of the image. The 2nd issue, is that when I turn the debug up ( SANE_DEBUG_GENESYS=10 ) and try the same scan, the process seg faults. The following is the stack from the core: (gdb) bt #0 0x7fa3e4ce35c8 in sanei_genesys_write_pnm_file (filename=0x7fa3e4cec479 unprocessed.pnm, data=0x7fa3e2267000 Address 0x7fa3e2267000 out of bounds, depth=1, channels=1, pixels_per_line=2360, lines=3188) at genesys_low.c:144 #1 0x7fa3e4caa60f in genesys_buffer_image (s=0x99e340) at genesys.c:6895 #2 0x7fa3e4caccab in sane_genesys_start (handle=0x99e340) at genesys.c:7864 #3 0x7fa3eae33ae2 in sane_dll_start (handle=0x99b2a0) at dll.c:1263 #4 0x7fa3eae20d38 in sane_start (h=0x99b2a0) at dll-s.c:48 #5 0x00406d1c in main (argc=13, argv=0x7fffe2b73a08) at scanimage.c:2283 The code is trying to write out a file ( unprocessed.pnm ) containing ... I think the Lineart converted data before performing the despeck process. I'd be happy to help with a fix for this, or provide further information or testing. Thanks, Brian .. -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password to sane-devel-request at lists.alioth.debian.org -- The truth is an offense, but not a sin Hello, thanks for providing these detailed information. For the crash, the image writing function doesn't handle line art bitmap format. I'm currently fixing that. For the black band, it is due to incorrect settings in registers in line art mode which makes the backend reading too much data from the scanner. This extra data is filled with 'noise'. I am currently looking into that. Regards, Stef -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20110130/61db34f1/attachment.htm
[sane-devel] New magicolor backend for inclusion in git
I'm trying to build this now on Fedora 14 with net-snmp enabled, and I get the following error: magicolor.c: In function 'mc_network_discovery_handle': magicolor.c:1800:2: error: 'netsnmp_indexed_addr_pair' undeclared (first use in this function) magicolor.c:1800:2: note: each undeclared identifier is reported only once for each function it appears in magicolor.c:1800:29: error: 'responder' undeclared (first use in this function) magicolor.c:1800:69: error: expected expression before ')' token magicolor.c:1801:2: warning: ISO C90 forbids mixed declarations and code magicolor.c: In function 'mc_network_discovery': magicolor.c:1909:20: warning: pointer targets in assignment differ in signedness magicolor.c:1910:2: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness /usr/include/string.h:399:15: note: expected 'const char *' but argument is of type 'u_char *' magicolor.c:1912:20: warning: assignment discards qualifiers from pointer target type make[2]: *** [libmagicolor_la-magicolor.lo] Error 1 And poking around in /usr/include/net-snmp reveals no definition for netsnmp_indexed_addr_pair. This is using net-snmp 5.5, which seems like it might still be a current release? allan On Tue, Jan 25, 2011 at 5:17 PM, Brian Shaver shakerlxxv at gmail.com wrote: These changes compiled fine for me on Fedora 13 x64. Thanks, Brian .. On Tue, Jan 25, 2011 at 3:38 PM, Reinhold Kainhofer reinhold at kainhofer.com wrote: Am Samstag, 22. Januar 2011, um 11:54:29 schrieb Reinhold Kainhofer: Anyway, I have a local patch that gets rid of all the byteorder.h macros and instead copies all little-endian encoded values manually byte-by-byte. I'm currently away from home, so I cant test it with my magicolor scanner. I'll commit it as soon as I'm back home (probably tomorrow). Finally, I could test that patch and fix all the problems with it. I've now pushed a fix to the problems (I no longer use the htole32a etc. macros), so I hope that the backend now properly compiles also on 64-bit systems. Cheers, Reinhold -- -- Reinhold Kainhofer, reinhold at kainhofer.com, http://reinhold.kainhofer.com/ ?* Financial Actuarial Math., Vienna Univ. of Technology, Austria ?* http://www.fam.tuwien.ac.at/, DVR: 0005886 ?* LilyPond, Music typesetting, http://www.lilypond.org -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password ? ? ? ? ? ? to sane-devel-request at lists.alioth.debian.org -- sane-devel mailing list: sane-devel at lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject unsubscribe your_password ? ? ? ? ? ? to sane-devel-request at lists.alioth.debian.org -- The truth is an offense, but not a sin
