[sane-devel] IR support for pixma devices

Thu Feb 14 18:18:18 UTC 2013

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
>>>
>>>
>>>