[sane-devel] Digital ICE support
Mon, 22 Dec 2003 20:37:17 +0000
> > Agreed. I think there should be a sanei_* library that allows the code
> > to be used in frontends or meta-backends, whichever solution is
> > best. (Just think of a network scanner that is accessed by a handheld
> > device -- you don't want the IR cleaning to be done on the handheld.)
> I recall that someone suggested that there should be something like a
> "mid-end" (like saned) that does the correction. This would keep front-ends
> simple and provide a moer uniform way to access features like IR-correction.
That was me, and that's what I refer to as a meta-backend. Still, it's
best to implement the core defect removal functions in sanei_*, which
meta-backends have access to. One can then even use them in a
standalone post-process tool.
> I do not agree that there is little need for correction. When I try to correct
> using the simple GIMP-plugin, I find that both brightness and contrast of the
> IR-chanel are critcal and they must be set for each image separately. Also,
> the exposure for the IR-chanel seems important.
(It wasn't me who said that, BTW.)
Exposure for the IR channel is important of course, but on Coolscan
models, it's fixed anyway. But you're right, the algorithm must be
aware of exposure for the RGB channels, and their LUTs must be know
(best set to neutral). Gamma correction as specified by the user can
then be performed in the meta-backend after defect removal.
> Another reason why a mid-end could be better than the front-end is, that the
> mid-end can scan always at full bit-resolution (12 bits on my LS-2000), do
> the calculations and then round to 8 bits.
Agreed, though you could do that in the backend as well. For me, the
main reason for a meta-backend is that it gives the user the choice of
where the defect removal code is run. When a handheld is scanning from
a high-spec server, it's best to run it on the server, wheres if a
3GHz P4 scans from a diskless 1988 SPARCStation 1+ with 16MB RAM, then
that's not a good idea.