[sane-devel] genesys backend
On September 23 2005 15:33, Pierre Willenbrock wrote: > As always a full patch to get Canon LiDE 35/50 to work can be found > here(will be updated to match experimental cvs): > http://www.pirsoft-dsl-dropzone.de/genesys_gl841.diff.bz2 I tried out this patch and when I run scanimage, the scanner (LiDE 35) just makes a grinding noise. I'd like to give you more information, but I'm afraid running the program any more will damage the scanner. This is the first experimental genesys backend I've tried in a long time, so I'm *not* suggesting that this was caused by the latest patch you posted. Luke
[sane-devel] genesys backend
On September 23 2005 15:33, Pierre Willenbrock wrote: > As always a full patch to get Canon LiDE 35/50 to work can be found > here(will be updated to match experimental cvs): > http://www.pirsoft-dsl-dropzone.de/genesys_gl841.diff.bz2 Update: I ran the test program from http://www.pirsoft-dsl-dropzone.de/, and stopped it after the scan head had moved a few cm, then ran scanimage again and it worked without any grinding. I am assuming, then, that the scan head was originally parked all the way against the front end (closest to the buttons), and the backend expected it to start farther away from the front end. Also, scanimage segfaulted when the head reached the opposite end of the scanner. I ran xscanimage and tried to get a preview image, with the same result. Here's a backtrace: Program received signal SIGSEGV, Segmentation fault. 0xb786c5fd in fclose () from /lib/tls/libc.so.6 (gdb) backtrace #0 0xb786c5fd in fclose () from /lib/tls/libc.so.6 #1 0xb75a6853 in genesys_read_ordered_data (dev=0x8097070, destination=0xbfffc620 '?' ..., len=0xbfffc588) at genesys.c:3806 #2 0xb75a866f in sane_genesys_read (handle=0x80ca330, buf=0xbfffc620 '?' ..., max_len=0, len=0xbfffc614) at genesys.c:5178 #3 0xb79efc69 in sane_dll_read (handle=0x80ca180, data=0xbfffc620 '?' ..., max_length=8192, length=0xbfffc614) at dll.c:1164 #4 0xb79eff34 in sane_read (h=0x0, buf=0x0, maxlen=0, lenp=0x0) at dll-s.c:52 #5 0x08051d0f in input_available (data=0x81535d8, source=-1, cond=GDK_INPUT_READ) at preview.c:577 #6 0x08052767 in scan_start (p=0x81535d8) at preview.c:958 #7 0x08053cc4 in preview_scan (p=0x81535d8) at preview.c:1500 Luke
[sane-devel] genesys backend
On September 23 2005 15:33, Pierre Willenbrock wrote: > As always a full patch to get Canon LiDE 35/50 to work can be found > here(will be updated to match experimental cvs): > http://www.pirsoft-dsl-dropzone.de/genesys_gl841.diff.bz2 Of course, the segfault was because I didn't set this business: #ifdef SANE_DEBUG_LOG_RAW_DATA static FILE *rawfile = NULL; #endif After setting that, everything works fine. Good work! Luke
[sane-devel] Canon LIDE35 color and motor issues
First I want to thank everybody for their great work on the genesys backend, we really appreciate your hard work! Now the complaining bit. I've been comparing the sane driver to the windows driver and I've come up with a few notes: - The windows driver seems to have much smarter control of the stepper motor. This is just a minor issue, but at any scan speed, the head is constantly starting, stopping, reversing, and starting again under sane. - Color reproduction is better with the sane driver than the windows driver, which tends to boost the reds way too much (yaay) - Brightness reproduction is quite poor with the sane driver. It seems that darker colors just drop off to black very quickly. I've posted a sample scan on my website here: http://luke.no-ip.org/tmp/color_comparison.png There are four images--the top row is SANE, bottom row is windows. The left column shows the original scans and the right column has the contrast cranked up. You can see pretty clearly in the top-right image that a lot of the photo has been lost under SANE. If I have time, I'll tinker with some of the exposure registers (EXPR, EXPG, EXPB) and see if that helps.. any ideas for other places I might look? Luke
[sane-devel] Canon LIDE35 color and motor issues
It's been a while since I originally brought this up, but I've pulled out the ol' scanner for another go. to recap: color calibration isn't quite right on my canon lide35--the dark colors drop out to black. I turned on SCAN_FLAG_DISABLE_SHADING as you instructed, and as you predicted this recovered my lost dark colors. Where should I go from here? Should I crank up SANE_DEBUG_GENESYS and send you the scanimage output and *.pnm files? Thanks, Luke On 3/7/06, Pierre Willenbrock wrote: > > > - Color reproduction is better with the sane driver than the windows > driver, > > which tends to boost the reds way too much (yaay) > > - Brightness reproduction is quite poor with the sane driver. It seems > that > > darker colors just drop off to black very quickly. > > A better tool to determine if the bright and dark colors are correctly > reproduced is a histogram tool. You can clearly see, if there is still > room at the bottom and top of the histogram(not too much, as you still > want some useable color values ;-)). > > This reveals that dark colors are cut off for the sane driver, but it > also shows that the windows driver cuts off bright colors. > > Anyway, it shows a incorrect calibration on the sane side. > To get an unshaded image, you can disable shading correction in > gl841_init_regs_for_scan by changing the flags(last parameter to > gl841_init_scan_regs, currently 0) to include SCAN_FLAG_DISABLE_SHADING. > > If the image then still shows dark colors cut off, the offset/exposure > calibration is to blame. Otherwise the shading calibration calculates > incorrect data(which i suspect). > > I should put this lengthy description online somewhere.. > > Regards, > Pierre > -- next part -- An HTML attachment was scrubbed... URL: http://lists.alioth.debian.org/pipermail/sane-devel/attachments/20070104/5c54d066/attachment.htm From patrick@nerim.net Thu Jan 4 13:47:02 2007 From: patrick@nerim.net (patrick@nerim.net) Date: Thu Jan 4 16:02:04 2007 Subject: [sane-devel] Nikon LS9000 Message-ID: <2085.62.235.139.229.1167914822.squir...@webmail.nerim.net> Dear all I own a Nikon coolscan 9000. This model is even not in the list of the Nikon ones. Which effort is expected if I want to support this scanner? Regards
[sane-devel] LiDE 35 question
I got a Canon LiDE 35 a while back without checking to see if it was supported (I cleverly assumed that LiDE 30 support was good enough), and rather than sending it back, I'm giving a go at writing the backend. I'm most of the way finished sorting out the differences between the gl646 and the gl841, but I'm worried about damaging the scanner. Does anybody know what things I should look out for, and whether this scanner has any built-in protection? Luke
[sane-devel] LiDE 35 question
On January 18 2005 00:29, you wrote: > On Tuesday 18 January 2005 03:23, Luke Campagnola wrote: > > I got a Canon LiDE 35 a while back without checking to see if it was > > supported (I cleverly assumed that LiDE 30 support was good enough), and > > rather than sending it back, I'm giving a go at writing the backend. I'm > > most of the way finished sorting out the differences between the gl646 > > and the gl841, but I'm worried about damaging the scanner. Does anybody > > know what things I should look out for, and whether this scanner has any > > built-in protection? > > Hi, > > what protection you're looking for? These devices are so cheap, that > there's nothing inside which can protect them in any way. But in general, > if you take some care nothing will happen. Mostly I'm worried about moving the scan head too far and applying too much power to the lamps (there's a register that controls the lamp power by PWM). It seems like the Genesys chip will automatically stop the motor when the home sensor is triggered, but that would only work if there does indeed exist a home sensor. Luke
[sane-devel] LiDE 35 question
On January 21 2005 00:46, Gerhard Jaeger wrote: > [ . . . ] in general I suggest first to snoop the USB > traffic on the windoze box, analyse it and figure out the basic chip > settings for this scanner, then you should be save. It's some odd kinda > work, but I'm pretty sure there's no way without it :( > > Gerhard I did a USB snoop for a few different situations--preview, scan, and calibrate, but I've run into a snag- there are some USB control messages I don't understand, and their values are not listed in genesys_low.h. They seem to be fairly important messages because there are very many of them, and their data strings change constantly. Furthermore, the gl841 spec doesn't appear to have the USB protocol listed, so I'm at a loss here.. Where did you find the control message values that are listed in genesys_low.h? Luke
