The three key things I learned were:
1. You had to use a more advanced Video Decoder than the generics, because the Images are so large
2. The output [Pin] for the Czurtek USBVideo Capture element contains a Software Still Capture button
3. You have to use a more advanced Video Encoder to render the capture back into a file format
The end result is when the graph is [Run] by pressing the green triangle [Play] button, you can right click the output pin on the Czurtek to Take a [Snap Shot] which is then piped out the advanced video decoder through the advanced video encoder and stored in a file. Due to application/operating system mem/disk caching the file isn't actually updated with a thumbnail until its closed by stopping the graph by pressing the red [Stop] button.
The result is a jpeg file with 2304 x 1728 pixel dimensions, in a quite small space of about 800 kb
Although I have on occasion triggered a guideline projection on a captured image, I have not been able to do so consistently.. probably due to a gap in my understanding of how that is being triggered.. and perhaps because there isn't a control in the graph for specifically setting it.
This appears to be close, but not the maximum "advertised" resolution of the scanner. One more level is indicated in the USB Descriptors but I have not been able to determine if there is a hardware/software limitation in my setup or the scanner simply becomes unstable when pushing to those limits.
Regardless the image captured above is very high resolution and clear.. and speaks to the "possibilities" this hardware brings.
Here is a direct link to the actual jpeg file, you can download it and zoom in to inspect the level of detail.
Still-Capture-at-2304x1728.jpg
One thing stiring in my mind is that the work flow for making ebooks from scans is rather cumbersome. Really the APIs and tools are more like Linear Video Editing. and Microsoft banished the Still Capture features of their API to the 'Movie Maker' venue.. which got me to thinking of camera rolls and Google Picasa and their struggles with things like Adobe Lightroom to "manage" all these images.. which are really digital photographs. We trust the timecodes and order are being preserved.. lest they tumble like a stack of unruly photographs to the floor in such disarray as to never be reassembled in order.
So on the edge of my thoughts are.. perhaps a Book "binding" program that treats scanning as a sequential "Movie" frame by frame.. enabling you to save projects and "half complete work" in "Project file" format that is a sequential set of frames like a photoroll..but also handled like a Movie.. in which you can Non-Linearly Edit if you like.. re-shoot footage and splice and re-splice until the final product is ready for distillation and "publication" or saving in its final form. In such a mindset.. the PDF would become a type of Interleaved "A/V" file without the "A" but if you should choose perhaps thats not a bad idea either.. since Visual Books are often translated into Audio books.. and I believe PDF files now have some form of Speech or Audio inclusion capabilites.
In the bigger picture.. something like Sony Vegas Movie Editor.. with all its filters for Chroma correction, Rotation, Masking and Dewarping.. don't seem so far out of place.. and also could become truly useful tools when editing an ebook.. we just need to "discover" an export feature from a Movie Maker program for publishing in PDF or ePub format.
For the more casual of users however a simpler sequential capture and bind workflow would be simpler and faster to follow. Say for the office person who just wants to scan a bunch of paperwork, shred it and save the PDF file to a legal form.. perhaps to be OCR'd later.. perhaps not.. but OCR and Indexing by OCR are not necessarily a required step in capturing books and loose leaf materials in a digital format.
One of the really great things this exercise teaches.
Is that this was all done using the USBVideo Class, which is supported by every operating system platform that supports USB 2.0 devices. There is nothing special about this technique. It was instructive of course how "limited" the default original generic video decoders and encoders "were" and that you had to use a component or library that "allowed" or took into account the "possibility" of really "large" image sizes.
Back in the day.. megapixel images just weren't "normal" and for an API thinking in terms of low res webcams streaming over slow dial up internet connections.. the expectations and "limits" were just set too low. In order to embrace this type of evolutionary device.. more modern code libraries will have to be used.
Unfortunately I think that also means simpler "shrink wrap" software programs we might already want to use to help capture and build documents.. might need to either take these into account.. or something that is actually built for edocument capture and publishing, like Adobe PDF programs may be where we have to go until -- that "Movie maker" Non-Linear Book binding program comes along.
In the mean time however we can all pretend to be the great Messier Star Catalog and map out our Globular Clusters of documents on our hard disks ourselves.
