Carl Troein <carl.troein at ed.ac.uk> writes: > Hi all,
Hi Carl, > A while back I got an Epson Perfection 4490 Photo and found out that the > 16-bit scanning didn't work, so I made a patch for the epkowa driver to > fix the problem. I posted it on the avasys message board, but evidently > didn't do enough research to find out that I could've posted it here. > Now Johannes Meixner has alerted me to the fact that Olaf Meeuwissen is > active on this list and the epkowa driver is indeed on-topic. Sorry for the late follow-up. > My patch has been mentioned on this list before: > http://lists.alioth.debian.org/pipermail/sane-devel/2007-September/019874.html > but now I've split it into the actual 16-bit fix and some entirely > optional code cosmetics. Thanks for the patches. I'll take a look and see what, if, when and in what form things will make it into the epkowa backend. Please note that from iscan's (somewhat myopic) point of view, 16-bit support is not required. All scans, except bi-level, are done with 8-bit. That means that any 16-bit support that makes it in will be pretty much untested. > The reason that 16-bit scanning didn't work is that the 4490 is a 'D' > level scanner, which means that it doesn't do colour correction. Instead, > the driver does this (which means that 16-bit raw data from the scanner > is all the more important to reduce discretization) but the driver > assumes that the data is 8-bit RGB. So the first patch merely adds a > 16-bit version of color_correct and a check for the depth. The modified > code path is only reachable for D-level scanners and should change > nothing for the 8-bit case. Hmm, I'd say all 16-bit scans should take that code path, irrespective of the scanner level (unless colour correction has been taken care of by the hardware already). > The second and third patch are just minor cleanup that should have no > noticable effects except on code size. The first-middle-last cases of > the data download are rolled into a smaller (and IMHO more readable) > loop, and a redundant memset is removed. I'm not sure about the unrolling of the loop. Apart from code size (and readability) does it improve anything else? Performance? I like to have variables initialised to a sane, well-known state before I use them, but other than that, yes, the memset() is not necessary. Hope this helps, -- Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation FSF Associate Member #1962 sign up at http://member.fsf.org/
