[sane-devel] SANE2 standard completion

[Rene Rebe]

On 28.03.2008, at 19:34, m. allan noah wrote:

> On Fri, Mar 28, 2008 at 2:28 PM, Rene Rebe <rene at exactcode.de> wrote:
>>
>>
>> On 28.03.2008, at 19:19, m. allan noah wrote:
>>
>>
>>> On Fri, Mar 28, 2008 at 2:14 PM, Rene Rebe <rene at exactcode.de>  
>>> wrote:
>>>
>>>>
>>>> On 28.03.2008, at 19:02, Alessandro Zummo wrote:
>>>>
>>>>
>>>>> On Fri, 28 Mar 2008 15:49:17 +0100
>>>>> Rene Rebe <rene at exactcode.de> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> Right now the only thing I miss are marks for infra-red frames,  
>>>>>> and
>>>>>> maybe
>>>>>> a ability to pass duplex data without buffering the rear side,  
>>>>>> which
>>>>>> becomes
>>>>>> even more of a problem with the next generation, higher end  
>>>>>> devices
>> I
>>>>>> got
>>>>>>
>>>>>
>>>>> I'm interested in this.. you receive the data of two pages at
>>>>> the same time? It's interleaved in some way?
>>>>>
>>>>
>>>> I speak about the duplex devices here, which have 2 CCDs (or
>>>> similar and scan both sides at the same time (long supported by
>>>> the Avision backend, btw. :-)
>>>>
>>>> Avision developed several ways to transfer the duplex data (aside
>>>> from the few, trivial) paper flipping devices with just a single  
>>>> CCD),
>>>> for some they buffer the page in-memory inside the scanner, for  
>>>> newer
>>>> ones there are several interlaced variants.
>>>>
>>>> For the interlaced variants I so far buffer the rear stripes in the
>>>> backend
>>>> and return the backed data every second frame.
>>>>
>>>> Probably the fujitsu backend does something similar.
>>>>
>>>>
>>>
>>> yes- fujitsu is just the same, grep fujitsu.c for COLOR_INTERLACE_*,
>>> you will see several variants.
>>>
>>> my (as yet unreleased) backend for the big kodak machines does not
>>> have this problem, because the machines have tons of ram, and buffer
>>> the images themselves, and there is no way to stop it :)
>>>
>>
>> WIth "no way to stop", you mean no way to stop the processing?
>
> no- i mean no way to tell scanner that you want it to interlace  
> front and back.
>
>> Because
>> that is also a point that could get improvements in SANE, the backend
>> should these days better push the data to the frontend, like begin  
>> page,
>> data, end page. As the bigger machines tend to deliver data so fast  
>> they
>> only honor a cancel with n++ pages in memory or on the network  
>> wire ...
>> (or not at all).
>
> this is true of the bigger machines, it might be 20 or 30 pages ahead
> of the wire when the cancel call comes in, especially if you are not
> using a compressed image type.
>
> for your other points, i dont really see how push is any better than
> blocking pull...

I found some machines touchy when the data is not cleared, so
in cancel or close you sometimes end up throwing data away
until the device is in a sane state again, ... An future version
of SANE using a push model would make that easier to
code, and IIRC there where issues with endorser pages
might have a scan index no. printed which where thrown
away later on, etc. pp.

It is not a must, as I said I'm more happy with the current SANE
than an artificially forced SANE2. One can usually convert
and poll etc. as needed, despite printed endorser guarantees,
but IIRC we just ended up with some custom scan script that
would throw all images into the database anyway, as you
usually do not use like scanimage in production :-)

Yours,

-- 
   René Rebe - ExactCODE GmbH - Europe, Germany, Berlin
   http://exactcode.de | http://t2-project.org | http://rene.rebe.name