[sane-devel] Digital ICE support
Sun, 30 Nov 2003 18:40:01 +0100
Content-Type: text/plain; charset=UTF-8
On Sun, 2003-11-30 at 17:05, Major A wrote:
> > since some days I've been thinking about implementing routines to
> > utilize the infrared channel supplied by my Nikon LS-2000 scanner for
> > automatic defect correction. Is someone already working on this?
> There a few people who've tried things, myself included, but none of
> the efforts have produced anything robust enough to go into SANE.
That's a pity...
> > My ideas for a first shot on this are (with low IR values ("black")
> > being high defect probability values):
> You've missed the first point: the IR information must be extracted
> first. Since the IR channel is a non-linear combination of the defect
> map with the R, G, B channels, this might get rather tricky. IBM has a
> patent on this as well.
Hmm, can you elaborate? Can't the backend simply do the second "scan"
when reading the IR channel is enabled and operate with that? Well,
that's what I can do manually so I can imagine it'd be hard, but not
> > - Identify single defects (pixel clusters):
> > - Count all pixels above a certain probability threshold automaticall=
> > as defects
> This works, the only problem is there doesn't seem to be a universal
> threshold. Something that's adaptive (i.e. a threshold varying across
> the image) would be the ideal solution.
=46rom what I looked at, defects are noticably and to a certain degree
homogenously "blacker" IR-wise than other stuff, like e.g. the "ghost
image" when scanning a Kodak material ;-). Of course, an adaptive
algorithm for the threshold would be ideal, but a manually controllable
threshold should do it for starters.
> > - Group adjacent defect pixels into defect clusters
> What for?
- Being able to treat one defect at a time.
- Giving feedback to the user about the recognized defects, possibly
with means to influence the correction process.
Maybe this would need some additions to the backend API, but if it needs
> > - Add pixels adjacent to a cluster that are above a second (lower)
> > defect probability threshold to the defect cluster
> I would just add all adjacent pixels, no threshold necessary.
Um, the defect cluster should contain defect pixels only -- we don't
want to "repair" pixels that are already ok.
> Also, you have to treat any parts of the image that are obscured by,
> say, the slide mount, separately. Otherwise they will also fall in the
> category of dirty pixels, and interpolating a large area for nothing
> is probably the last thing you want to spend your CPU time on.
Agreed. Recognizing the framing etc. should be fairly easy though from
what I've seen -- it's really "black" and always at the edge of the
> > - Repair defects by interpolation between "healthy" pixels. Obviously
> > this is the trickier part of it all.
> This is the easiest bit... if you do the rest, I'll add this one :)
Sometimes disagreeing has its advantages.
> If you have some time, please look at my code in Coolscan2 CVS:
> There's some rudimentary code there that works OK if you have time to
> tweak the parameters a lot... I haven't done anything to it recently
> because I haven't yet come up with a good way of doing the defect
> detection adaptively.
I'll certainly look at it.
> I'd love to have defect removal functionality in SANE, so please let
> me know if you have any good ideas and maybe we can one day make
> something that rivals ICE.
You mean e.g. not giving up on Kodak slides? I have many of this type,
so I'll love to have it as well.
Nils Philippsen / Berliner Stra=C3=9Fe 39 / D-71229 Leonberg=20
email@example.com / firstname.lastname@example.org / email@example.com
PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011
Ever noticed that common sense isn't really all that common?
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
-----END PGP SIGNATURE-----