This is a multi-part message in MIME format. --------------070606000501070302000803 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit
Thanks for the tip. I hadn't actually thought of looking at the calibration data as an image. There are no other data transfers between calibration scans. That and the fact that its a CIS scanner (cheaper, lower quality) lead me to believe that its not adjusting individual pixel gains for each sensor. The Windows .ini file has a bunch of other clues, like: Calibrate=1 // [1:Enable Calibration] DoPixelDC=1 // [1:Enable Dark Compensation] PixelDCDarkLevel=1 ScanPixelDCLines=16 CalibrationYDPI=300 CalibrationLines=30 GainTargetCode=0xEFEFEF ScanTargetCodeRed=260 ScanTargetCodeGreen=262 ScanTargetCodeBlue=259 TargetVGARed=6 TargetVGAGreen=6 TargetVGABlue=6 CalibrationSkipLines=8 CalibrationBackwardLines=95 etc... I'll probably take a break from this for a while (really busy at work), but I think I have enough clues with the calibration images to continue when I get back at it. regards, Fred Odendaal Earle F. Philhower, III wrote: >Hi Fred, > >Don't give up yet, some suggestions you probably already heard below... > >--- Fred Odendaal <[email protected]> wrote: > > >>So, I'm thinking "I've got a degree in comp. sci. How difficult can it >>be to write a scanner driver?" >> >> >...big snip... > > >>Finally after many Windows scans and log files at various different >>sizes, resolutions, and colour or gray scale mode I start writing the >>backend. It only took me about 2 weeks before I could scan on Linux, but >>this is the easy part! What I soon discovered is something called >>CALIBRATION. At 600x1200dpi colour resolution the Windows driver >>actually does ~20 scans off to the side of the glass flat bed. I have no >>idea what its doing. By looking at the usb logs it appears to be setting >>the gain and the dc offset in a gradual fashion over several calibration >>scans. >> >> > >Dump the received binary data to an image and then just see which >control register they're iterating over. Then it's just a matter of >figuring what they want the end image to look like (ie. adjust offset >down until black pixels are < XXX, then increase gains until white >pixels are near YYY). The received calibration image was really helpful >when I was trying to figure out what the heck the Microtek driver >was doing! > >It may also be adjusting the individual pixel gains for each sensor >element. If there's a really large download of slowly varying #s >between scans that might be a pointer. > >Good luck, > > > > > >__________________________________ >Do you Yahoo!? >Make Yahoo! your home page >http://www.yahoo.com/r/hs > > > --------------070606000501070302000803 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=us-ascii" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Thanks for the tip. I hadn't actually thought of looking at the calibration data as an image.<br> <br> There are no other data transfers between calibration scans. That and the fact that its a CIS scanner (cheaper, lower quality) lead me to believe that its not adjusting individual pixel gains for each sensor.<br> <br> The Windows .ini file has a bunch of other clues, like:<br> Calibrate=1 // [1:Enable Calibration]<br> DoPixelDC=1 // [1:Enable Dark Compensation]<br> PixelDCDarkLevel=1<br> ScanPixelDCLines=16<br> CalibrationYDPI=300<br> CalibrationLines=30<br> GainTargetCode=0xEFEFEF<br> ScanTargetCodeRed=260<br> ScanTargetCodeGreen=262<br> ScanTargetCodeBlue=259<br> TargetVGARed=6<br> TargetVGAGreen=6<br> TargetVGABlue=6<br> CalibrationSkipLines=8<br> CalibrationBackwardLines=95<br> etc...<br> <br> I'll probably take a break from this for a while (really busy at work), but I think I have enough clues with the calibration images to continue when I get back at it.<br> <br> regards,<br> Fred Odendaal<br> <br> <br> Earle F. Philhower, III wrote: <blockquote cite="[email protected]" type="cite"> <pre wrap="">Hi Fred, Don't give up yet, some suggestions you probably already heard below... --- Fred Odendaal <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]";><[email protected]></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">So, I'm thinking "I've got a degree in comp. sci. How difficult can it be to write a scanner driver?" </pre> </blockquote> <pre wrap=""><!---->...big snip... </pre> <blockquote type="cite"> <pre wrap="">Finally after many Windows scans and log files at various different sizes, resolutions, and colour or gray scale mode I start writing the backend. It only took me about 2 weeks before I could scan on Linux, but this is the easy part! What I soon discovered is something called CALIBRATION. At 600x1200dpi colour resolution the Windows driver actually does ~20 scans off to the side of the glass flat bed. I have no idea what its doing. By looking at the usb logs it appears to be setting the gain and the dc offset in a gradual fashion over several calibration scans. </pre> </blockquote> <pre wrap=""><!----> Dump the received binary data to an image and then just see which control register they're iterating over. Then it's just a matter of figuring what they want the end image to look like (ie. adjust offset down until black pixels are < XXX, then increase gains until white pixels are near YYY). The received calibration image was really helpful when I was trying to figure out what the heck the Microtek driver was doing! It may also be adjusting the individual pixel gains for each sensor element. If there's a really large download of slowly varying #s between scans that might be a pointer. Good luck, __________________________________ Do you Yahoo!? Make Yahoo! your home page <a class="moz-txt-link-freetext" href="http://www.yahoo.com/r/hs";>http://www.yahoo.com/r/hs</a> </pre> </blockquote> <br> </body> </html> --------------070606000501070302000803--
