[sane-devel] [PATCH] epkowa: 16-bit on Epson 4490

[Olaf Meeuwissen]

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/