<div dir='auto'>Hi,<div dir="auto"><br></div><div dir="auto">Was the handheld scanner an HP device by any chance? If so, I have some folklore about it.</div><div dir="auto"><br></div><div dir="auto">My former professor at KTH, Mark Smith, has shown us a now rare exemplary once, from his days at Hewlett-Packard. It has the capability of scanning a page with remarkable precision by rubbing the device over it in a free pattern, including curved and overlapping strokes.</div><div dir="auto"><br></div><div dir="auto">This is something that, according to him, was achieved with very clever analog electronics calculating a complex trigonometric function over a set of optical input signal to calculate the shape of the strokes, as at that time digital didn't quite cut it for processing power for this application; as well as a stitching algorithm to put the strokes together, which I think ran directly on the device's processor (as opposed to a personal computer).</div><div dir="auto"><br></div><div dir="auto">The story goes like this: the team had been working on the idea for some time, and it mostly worked. Except they optimized and optimized the firmware, but just couldn't process the input from the optical sensors fast enough to preprocess the scanned strokes before stitching to make marketing happy. Until one day, during the x'th meeting about the issue, they were overheard by an Ancient Sage from a different engineering team, which asked them to note down the function they were trying to compute on a blackboard. The Sage then proceeded to draft down a very small and cheap analog circuit to compute that function and preprocess the input signal. And just like that, the product was suddenly possible.</div><div dir="auto"><br></div><div dir="auto">Of course, the clever circuit was buried in an IC. And the exact function and the stitching algorithm, are, according to him, an industrial secret that no competitor has been able to replicate to date.</div><div dir="auto"><br></div><div dir="auto">Riccardo P. Bestetti</div></div><div class="gmail_extra"><br><div class="gmail_quote">Il 22 ago 2023 14:26, Billy Croan <Billy@croan.org> ha scritto:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>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.<div dir="auto"><br /></div><div dir="auto">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.</div><div dir="auto"><br /></div><div dir="auto">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.</div><div dir="auto"><br /></div><div dir="auto">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.</div><div dir="auto"><br /></div><div dir="auto">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.</div><div dir="auto"><br /></div><div dir="auto">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.</div><div dir="auto"><br /></div><div dir="auto">Interesting thought experiment.</div><div dir="auto"><br /></div><div dir="auto">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.  </div><div dir="auto"><br /></div><div dir="auto">I wonder how that worked.  What would it have done if you dragged it across the gymnasium floor with a laptop?</div><div dir="auto">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.</div><br /><div class="elided-text"><div dir="ltr">On Mon, Aug 21, 2023, 18:51 Marshall Jose <<a href="mailto:kerwoodderby@gmail.com">kerwoodderby@gmail.com</a>> wrote:<br /></div><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.</div><div><br /></div><div>An example of a more elaborate scheme can be found at <a href="http://semitone440.co.uk/scanner/">http://semitone440.co.uk/scanner/</a> . 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.</div><div><br /></div><div>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.</div><div><br /></div><div>Marshall<br /></div><div><br /></div></div><br /><div class="elided-text"><div dir="ltr">On Mon, Aug 21, 2023 at 12:17 PM Harvey Nimmo <<a href="mailto:harvey@nimmo.de">harvey@nimmo.de</a>> wrote:<br /></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb( 204 , 204 , 204 );padding-left:1ex"><div><div>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! :-)</div><div><br /></div><div>Cheers</div><div>Harvey</div><div><br /></div><div>On Mon, 2023-08-21 at 11:00 -0400, m. allan noah wrote:</div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb( 114 , 159 , 207 );padding-left:1ex"><div dir="ltr"><div>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.</div><div><br /></div><div>allan<br /></div></div><div><br /></div><div class="elided-text"><div dir="ltr">On Mon, Aug 21, 2023 at 9:11 AM Andy Bennett <<a href="mailto:andyjpb@ashurst.eu.org">andyjpb@ashurst.eu.org</a>> wrote:<br /></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb( 114 , 159 , 207 );padding-left:1ex"><div>Hi,<br /></div><div><br />I don't have a solution I'm afraid but can offer some solidarity below!<br /></div><div><br /></div><div><br />> like CVS/Walgreens long<br />><br />> Is there a scanner out there that can scan up to 24"? or 36?<br />><br />> I've been folding and making a multipage PDF.  Is there a better way?<br />><br />> Is there a reason scanners must have a maximum length or could <br />> they just stream data back to the PC continuously until the scan <br />> is complete.  like a toilet paper roll for example.<br /></div><div><br />I have wondered about this too but not found any good implementations in <br />desktop scanners.<br /></div><div><br />My ix500 has a scanning length that's not quite long enough for some things <br />such as certain kinds of official certificates that are A4 width but have <br />extra long fold out bits at the end.<br /></div><div><br />I'd suggest cutting the reciept into pieces, but I always hate a solution <br />like that when there seems to be No Good Reason why the product doesn't do <br />it in the first place. Besides, there may be good reasons to not want to <br />cut your document into pieces for the sake of a scan.<br /></div><div><br />For my scenarios it often suffices to scan it one way up and then the other <br />because the documents are less than twice the length the scanner can <br />handle.<br />...but that still leaves an annoying amount of post-processing to do. It's <br />even harder if the documents are particularly thin (like reciepts) because <br />you're more likely to get a wobbly horizontal registration between the two <br />scans.<br /></div><div><br /></div><div><br />> I have no problem scanning a 700 page document if I keep that <br />> ADF feder hopper full and keep the exit tray from filling up on <br />> my ADF scanners.  But what reasons are there, that a single page <br />> can not be say, 100 feet long?<br /></div><div><br />I guess none in principle. This one (done with a line scan camera which is <br />similar to the single pixel-wide CCDs a scanner would use) is as long as a <br />train: <a href="http://elm-chan.org/works/lcam/g/Y0008.jpg">http://elm-chan.org/works/lcam/g/Y0008.jpg</a><br /></div><div><br />(via <a href="http://elm-chan.org/works/lcam/report.html">http://elm-chan.org/works/lcam/report.html</a> )<br /></div><div><br />I've seen others that document entire long distance train journeys.<br /></div><div><br /></div><div><br />Good luck and please let us know if you find anything!<br /></div><div><br /></div><div><br />Best wishes,<br />@ndy<br /></div><div><br /></div></blockquote></div></blockquote><div><br /></div><div></div></div>
</blockquote></div>
</blockquote></div></div></div>
</blockquote></div><br></div>