[sane-devel] Digital ICE support

[Nils Philippsen]

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.
> > 
> > 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.
> 
> 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' = (A*r^1/3 + B*g^1/3 + C*b^1/3 + D*i^1/3) ^ 3

where A + B + C + D = 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
> > > 
> > > What for?
> > 
> > - Being able to treat one defect at a time.
> 
> Probably a good idea, I need to think about this one.
> 
> > - Giving feedback to the user about the recognized defects, possibly
> > with means to influence the correction process.
> 
> 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. 

> > > 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.
> 
> 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 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
> > scan.
> 
> 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.
> 
> I think it's probably better to use a clustering approach and just
> omit clusters that get too big.
> 
> > > 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.
> 
> 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.

From 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
-- 
Nils Philippsen / Berliner Straße 39 / D-71229 Leonberg 
nils at tiptoe.de / nphilipp at redhat.com / nils at 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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20031201/8398b8b8/attachment.sig>