[sane-devel] Scanner Recommendation for long receipts?

[Billy Croan]

I do think I have observed behavior indicative of the scanner internally
buffering pages. If the network crashes during a scan over my software
shuts down. I have sometimes reopened it and hit the scan button after
carefully putting the pages back on the right order in the tray, but the
tray never feeds and I get 9 or 10 pages in rapid succession far faster
than the scanner has ever operated.

I think the scanner has internal memory that it saves each page objects too
and perhaps that memory is segmented in some way maybe partitioned just big
enough to hold one legal size sheet of paper each.  As opposed to holding
10, 000 one-dimensional lines of pixels.

That doesn't explain why it has to be that way but on my Epson
multifunction printer scanner it seems to be working that way.

For scanning a delicate artifact like a roll of piano paper I might imagine
sliding it between two sheets of glass that don't quite squeeze the paper
but keep it flat and then you can keep it moving at a constant speed like
it was intended, and use a moving camera that snaps a photo while moving at
the speed of the paper and then jumps back the other direction just enough
to overlap an inch.  You have to work really hard and getting the lighting
right.

Or maybe act together two separate sheet feed scanners and put their
sensors at different positions along the glass.  Then you have them take
17-in scans and succession so that when one is starting the other one is
halfway done. Each of them I think it's only scanning one page at a time
but because of their positioning it would be creating overlapping pages of
one continuous document.  Hacking existing scanners might be easier than
building your own and if their scanner element illuminates the page while
scanning it like mine does then you wouldn't have to mess with lighting so
much.

I could also imagine wanting to shield both sides of the piano roll with a
clear backer ribbon  Then you could feed the two backer layers between
rollers the same way you would feed the paper between a roller but with
less chance of damaging the paper.

Interesting thought experiment.

In the 90s I had something called a handheld scanner.  Back when it was
quite a novelty to have images on a computer screen let alone photographs.
Looked like a really fat and mouse and you could drag it across the page of
a bound book to scan a 6-in wide column.  It had an optical sensor bar and
a black wheel that measured distance.

I wonder how that worked.  What would it have done if you dragged it across
the gymnasium floor with a laptop?
Then again I remember you had to install an ISA card just for the scanner,
so, no laptops.  I wonder where this thing went so many years ago.  Perhaps
the manufacturer just never planned on it scanning longer than two times
its cord length.

On Mon, Aug 21, 2023, 18:51 Marshall Jose <kerwoodderby at gmail.com> wrote:

> As someone who made a hobby of scanning player piano rolls, I can tell you
> that the generalized solution to imaging paper of arbitrary length involves
> either the expenditure of much money, or else much effort. My journey ended
> with a flatbed scanner (using SANE), a paper advance mechanism, and some
> really ugly code to stitch successive images together; though
> unsophisticated, it has scanned 4,500 rolls to date.
>
> An example of a more elaborate scheme can be found at
> http://semitone440.co.uk/scanner/ . Note the role of the encoder wheel in
> providing essential information about the speed variations of the media
> passing in front of the line scan camera.
>
> The biggest problem lies in transporting many meters of flimsy or brittle
> paper without damaging it, and I don't believe that has a general solution
> to date.
>
> Marshall
>
>
> On Mon, Aug 21, 2023 at 12:17 PM Harvey Nimmo <harvey at nimmo.de> wrote:
>
>> My Canon GX5060 seems to have no problem feeding, for example, the long,
>> thin  British Birth, Marriage, Death certificates completely through the
>> AFD (Feeder. The flatbed is A4 compatible)), but either the associated
>> on-board software or the scanner drivers cannot scale the result onto a
>> complete image. In other words, I suspect it is only a software limitation
>> somewhere in the chain. ...and I would really appreciate a solution! :-)
>>
>> Cheers
>> Harvey
>>
>> On Mon, 2023-08-21 at 11:00 -0400, m. allan noah wrote:
>>
>> Most ADF scanners need to be told how long the paper is, so they can do
>> things like length-based double feed detection, buffering, blank page
>> detection, etc. However, the maximum length should be fairly long on most
>> machines I am familiar with. IIRC, some Canon and Fujitsu machines will go
>> up to one meter in length? I'll try to look around for some examples.
>>
>> allan
>>
>> On Mon, Aug 21, 2023 at 9:11 AM Andy Bennett <andyjpb at ashurst.eu.org>
>> wrote:
>>
>> Hi,
>>
>> I don't have a solution I'm afraid but can offer some solidarity below!
>>
>>
>> > like CVS/Walgreens long
>> >
>> > Is there a scanner out there that can scan up to 24"? or 36?
>> >
>> > I've been folding and making a multipage PDF.  Is there a better way?
>> >
>> > Is there a reason scanners must have a maximum length or could
>> > they just stream data back to the PC continuously until the scan
>> > is complete.  like a toilet paper roll for example.
>>
>> I have wondered about this too but not found any good implementations in
>> desktop scanners.
>>
>> My ix500 has a scanning length that's not quite long enough for some
>> things
>> such as certain kinds of official certificates that are A4 width but have
>> extra long fold out bits at the end.
>>
>> I'd suggest cutting the reciept into pieces, but I always hate a solution
>> like that when there seems to be No Good Reason why the product doesn't
>> do
>> it in the first place. Besides, there may be good reasons to not want to
>> cut your document into pieces for the sake of a scan.
>>
>> For my scenarios it often suffices to scan it one way up and then the
>> other
>> because the documents are less than twice the length the scanner can
>> handle.
>> ...but that still leaves an annoying amount of post-processing to do.
>> It's
>> even harder if the documents are particularly thin (like reciepts)
>> because
>> you're more likely to get a wobbly horizontal registration between the
>> two
>> scans.
>>
>>
>> > I have no problem scanning a 700 page document if I keep that
>> > ADF feder hopper full and keep the exit tray from filling up on
>> > my ADF scanners.  But what reasons are there, that a single page
>> > can not be say, 100 feet long?
>>
>> I guess none in principle. This one (done with a line scan camera which
>> is
>> similar to the single pixel-wide CCDs a scanner would use) is as long as
>> a
>> train: http://elm-chan.org/works/lcam/g/Y0008.jpg
>>
>> (via http://elm-chan.org/works/lcam/report.html )
>>
>> I've seen others that document entire long distance train journeys.
>>
>>
>> Good luck and please let us know if you find anything!
>>
>>
>> Best wishes,
>> @ndy
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/sane-devel/attachments/20230822/d6ea405e/attachment.htm>