--=-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 [email protected] / [email protected] / [email protected] 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--
