Hi Gernot, I just committed simple infrared channel support for CS9000F to git.
Please check the code with your CS8800F. To enable ir support you must change PIXMA_CAP_TPU to PIXMA_CAP_TPUIR in the CS8800F DEVICE() definitions. Next I'll do some tests with antidust from http://www.ciselant.de/projects/antidust/. Cheers, Rolf Am 14.02.2013 19:18, schrieb Rolf Bensch: > Hi Gernot, > > I added the ml to our discussion. This issue could become system > relevant for the Pixma backend and/or Sane and/or the frontends. And > maybe other developers would like to be part of this discussion. > > If I look at the used hardware where Sane is running, I see the whole > scope from embedded systems with saned running, up to high end pc's with > "endless" memory. > > In theory a user can scan the whole scan area @ 9600 dpi (with a > CS9000F). Nobody who knows what he's doing will really do this, but he > *could*. This edge condition needs approx. 60 GB to hold one 3 channel > 16 bit uncompressed image (rgb) plus one 1 channel ir image. If he scans > one 24mm x 36mm slide the size is reduced to 1 GB or 6 GB for one slide > stripe or 21 GB for the complete slide holder area. Here we shouldn't > forget the embedded systems! > > If we want to create a rgba image for image post processing, the backend > would need a buffer size of up to 14 GB (5.3 GB for the complete slide > holder area) to hold ir data from a previous scan. I see a temp file to > handle this, otherwise it will run into swap. This also would include an > image resizing function. The CS9000F scans ir only with 600 - 2400 dpi. > Rgba frames are not part of the Sane standard, but this could be changed. > > I found another antidust project here: > http://www.ciselant.de/projects/antidust/. > > As a first step I'll commit my ir extension to git. And we can add ir > for your CS8800F. > > Then we can experiment with antidust and external image resizing. Maybe > we can get a copy of duster.c, which was part of the old Coolscan2 > project which isn't available anymore at sourceforge. > > Cheers, > Rolf > > > > > Am 13.02.2013 17:28, schrieb Gernot Hassenpflug: >> Hi Rolf, >> Thanks for the wonderful effort to do the IR scanning. I'm thinking >> that registration needs to be done in the backend, as that is pretty >> much dependent on the particular scan resolution set in the front end >> (the CCD and IR are not necessarily at the same resolution, and the >> registration also seems to depend on that relationship), or did you >> manage to do that already? Sorry, no time to check the code this week. >> I agree the front-end should finally have some kind of functions for >> removing imperfections based on the IR and CCD scans, but if it will >> be possible to perform some standard processing (maybe with parameters >> passed from the front-end) in the backend (as an option), then it will >> be possible for just a corrected image to be presented to the user, a >> kind of "quickscan" if you will. The reason I propose this is a) it >> seems there are few people working on front-ends (as far as I can >> tell), b) it sounds like it is possible to accomplish, c) it will be a >> major step forward compared to what was available before, and could be >> forked and/or ported to front-ends later, and finally d) backends are >> more likely to be included everywhere, whereas front-ends I am not so >> sure about. Maybe there are several memory and other resource >> considerations as well (front-ends may be more unstable, memory leaks, >> etc.). >> >> Just my 2 cents worth. >> Regards, >> Gernot >> >> >> Am 12.02.2013 23:22, schrieb Rolf Bensch: >>> Hi, >>> >>> Recently I added ir scan as separate image for my CS9000F (pls. see >>> attached patch). But Google cannot show me a proper way how to process >>> both files (rgb and ir) to reduce dust with gimp or imagemagick. I found >>> an old project which also has been discussed in the Sane ml, but it >>> isn't online anymore >>> (http://web.archiveorange.com/archive/v/O5zM9kE6TYpdOuGzAjGo). >>> >>> I think that the backend should simply scan. Any post processes should >>> be handled from a frontend or another specialised program. >>> >>> I found an old Sane project to generate rgba files (coolscan; >>> http://andreas.rick.free.fr/). Xsane has some normally not compiled rgba >>> features and can save a "Sane rgba" file. But this project defines a >>> 4-channel color space. >>> >>> I already started with some 4-channel rgba implementations, but it seems >>> to be too heavy to hack it into Sane / the backend without any feedback >>> from other Sane developers. >>> >>> I would like to add something like a "save as rgba" function to >>> scanimage or scanbd. This would enclose scanning two images (rgb and ir) >>> from the backend and save them as one rgba (png) file. With this we can >>> avoid any changes to the Sane standard. And we can use external programs >>> like gimp to handle dust removal (I guess there are some plugins >>> available to handle rgba files). >>> >>> Rolf >>> >>> >>> >>> Am 11.08.2012 14:25, schrieb m. allan noah: >>>> The biggest problem is that the sane standard does not allow us to >>>> return the IR channel to the frontend. If you do all the correction in >>>> the backend, I suppose that is not required. You should try to spin as >>>> much of the code as you can into a generic sanei_* library. >>>> >>>> allan >>>> >>>> On Sat, Aug 11, 2012 at 7:41 AM, Gernot Hassenpflug >>>> <aikishugyo at gmail.com> wrote: >>>>> Hello Allan, Rolf, >>>>> I received a request today from a Debian User Forums member who bought >>>>> a 2nd-hand CanoScan 8800F. He reports that VueScan works fine with IR >>>>> for noise removal under Windows, but lacks such support under linux >>>>> (which was news to me). He will try to compile SANE backends (I gave >>>>> him instructions), but wishes to know if there is a chance in future >>>>> of adding IR support to SANE. At this point, I think only the 8800F, >>>>> 9000F and a couple of the high-end MP devices use such functionality. >>>>> >>>>> In the past, 2 people (myself, and a gentleman from Belgium) were >>>>> working on implementing IR, and we ended up having to do piece-wise >>>>> registration of the IR image with the CCD image, since the IR image is >>>>> distorted w.r.t. to the CCD image. At that point we have stopped and >>>>> the experimental code (stand-alone) has been untouched for perhaps a >>>>> year. >>>>> >>>>> I would be interested in continuing work on this, as it appears to me >>>>> that a) more scanners in the pixma backend will benefit from this >>>>> functionality in future, b) the code would be portable to other >>>>> backends, where there are Canon scanners supported that use IR (e.g., >>>>> genesys backend, I believe). >>>>> >>>>> As I recall, there were some issues related to new dependencies (maths >>>>> libraries, I think), but I think that if I can solve to some level of >>>>> satisfaction the issue of registration, we should be able to >>>>> incorporate IR noise reduction as an experimental feature into the >>>>> development code. >>>>> >>>>> Any opinions on this? >>>>> Regards, >>>>> Gernot Hassenpflug >>>> >>>> >>>>