[sane-devel] Digital ICE support

[Nils Philippsen]

--=-ZatCIFvW+Uy1uZiQ47rp
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, 2003-12-01 at 00:49, Major A wrote:
> > > 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.
> >=20
> > 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
> > unsolvable.
>=20
> The coolscan2 backend currently provides the IR data in a second scan,
> but this is only a kludge for the moment, it will go away with SANE2
> (which will support RGBI).

Good.

> This IR data is the raw data which contains quite a lot of red
> information as well, for most films. You need to extract the pure IR
> information, and that's probably best done by adding the cubic roots
> of the four channels with appropriate weighting factors and then raise
> the result to the power of 3.

Like in (sorry, I can cope better with formulae than text ;-):

i' =3D (A*r^1/3 + B*g^1/3 + C*b^1/3 + D*i^1/3) ^ 3

where A + B + C + D =3D 1? Is the order of the roots/power arbitrary or
just another secret I don't know about color theory?

My approach was a bit different, taking adjacent pixels into account
(refined version):

- Group (IR) pixels over a probability threshold (I used about 69% grey)
into defect clusters, fairly easy operation (tried that one last night
on some defect samples and it spotted them well)
- Let a cluster "bleed" into the vicinity, where each added pixel must
have at least a certain percentage of the "blackness" of adjacent ones
already in the cluster before this step. Lather, rinse, repeat.

> > > >   - Group adjacent defect pixels into defect clusters
> > >=20
> > > What for?
> >=20
> > - Being able to treat one defect at a time.
>=20
> Probably a good idea, I need to think about this one.
>=20
> > - Giving feedback to the user about the recognized defects, possibly
> > with means to influence the correction process.
>=20
> I don't think that would be very practical if IR processing is done
> during scanning. This could be useful while writing and debugging the
> code, though.

I disagree. I think that in most cases a fully automatic defect removal
algorithm is fine for the user, but there will always be borderline
cases/images where the algorithm will crash against the nearest wall and
where algorithm-aided manual removal will still be better than unaided
removal.=20

> > > I would just add all adjacent pixels, no threshold necessary.
> >=20
> > Um, the defect cluster should contain defect pixels only -- we don't
> > want to "repair" pixels that are already ok.
>=20
> In my experience, you have to mark all adjacent pixels as
> defective. If, for example, you have dust on a patch of sky, you could
> easily end up having a visible ring around the place where the dust
> was, simply because the surrounding pixels didn't quite reach the
> second threshold.

See my refined approach above.

> > > 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 th=
e
> > > category of dirty pixels, and interpolating a large area for nothing
> > > is probably the last thing you want to spend your CPU time on.
> >=20
> > 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
> > scan.
>=20
> Careful: it doesn't always surround the scan, you can adjust your scan
> window so that the border between two frames falls within the scan
> window. Also, some cameras print a date/time/whatever on the space
> between frames, which would also mess up the assumption that the black
> area is rectangular.
>=20
> I think it's probably better to use a clustering approach and just
> omit clusters that get too big.
>=20
> > > 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.
> >=20
> > 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.
>=20
> I assume you mean Kodachrome? I think it's possible to do IR cleaning

Yes.

> on Kodachrome, but it's a lot harder than for E6 and C41 because the
> IR channel is more strongly correlated with other colours than in the
> case of E6/C41.

=46rom my (small) experience, it's only harder with Kodachrome, the other
slides I had (mostly Agfa consumer material) had almost perfect IR
channels with no resemblance to the original picture, only speckles and
scratches.

Nils
--=20
Nils Philippsen / Berliner Stra=C3=9Fe 39 / D-71229 Leonberg=20
nils@tiptoe.de / nphilipp@redhat.com / nils@lisas.de
PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
Ever noticed that common sense isn't really all that common?


--=-ZatCIFvW+Uy1uZiQ47rp
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)

iD8DBQA/yv7ZR9ibZWlRMBERAhNDAJ4g5Mk+JDuGuVXmM+osC2wwjA2QzgCgj2xs
v5Ze1rO2ajPcd52cv+yHuGY=
=chM3
-----END PGP SIGNATURE-----

--=-ZatCIFvW+Uy1uZiQ47rp--