[sane-devel] [PATCH] epkowa: 16-bit on Epson 4490
olaf.meeuwissen at avasys.jp
Mon Jun 2 00:21:11 UTC 2008
Carl Troein <carl.troein at ed.ac.uk> writes:
> Hi all,
> 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:
> 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
> 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
Hope this helps,
Olaf Meeuwissen FLOSS Engineer -- AVASYS Corporation
FSF Associate Member #1962 sign up at http://member.fsf.org/
More information about the sane-devel