Figuring out a DirectShow GraphEdit graph and how to use it to perform Still Captures was not easy. But here is a working Graph.
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.
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.
Its hard to get a handle on how to communicate with the Czur USBVideo Class. Analyzing the pcap in Wireshark reports bcdDevice: 0x0100. The USB Video Class 1.1 example doc from 2005 make understanding the USB traffic somewhat easier.
Basically USB has many standards, which add up to an implementation in which a USB Host (the PC) communicates to a USB Device (the USB Video device) over a cable in a particular format.
The actual signalling involved on the USB wire is mostly ignored, since the operating system comes minimally equipped with device drivers for exporting a user program side interface that can be used to discover and send and receive "higher" protocol or "Class" protocol messages with a USB connected device.
Each "Class" of device has a set of "procedures" that roughly are designed to discover, query and setup that type of USB device using these "Class" protocols. They operate with a set of "assumptions" that are safe to make when you know your dealing with a particular device that belongs to that Class type.
A mouse or keyboard for example belong to the HID (Human Interface Device) "Class" and they are one of the simplest communications models to program.
A webcam belongs to the USB Video "Class" and is a lot more complicated.
The standard USB precursor to "Class" type communications first has to figure out which class the USB device belongs to, then load that class driver into memory and begin using Class protocols for it.
When monitoring or "sniffing" or "capturing" USB traffic by branching or inserting a "Tap" in the path between the operating system and the USB port driver. Everything comes out linearly, one after the other.. but each protocol message, read and write of a Class protocol message is conducted with a purpose in mind that serves the standard setup and operating procedure for that USB Class device.
The USB Specifications for the USB Class are very "wordily" explained.. in a somewhat backwards fashion beause the sentences while in English follow an Adjective or Description, before Object or Noun format. Which might be because historically "standards" originated in France and the language structure there is different than in other countries. Over time this has become the "normal" way of writing a standards document and makes it somewhat difficult for less experienced people to contemplate. -- this is not unique to USB standards, many things in Science and Art begin with a staged preamble regarding what will be talked about before getting around to discussing the subject matter. -- as a matter of course it appears "Indirect" and taxing on the casual "commoner listener" since they are usually less patient and more focused on the task at hand, not ten years from now.
But moving on.. with the task at hand.
The widely available USB_Video_Example 1.1.pdf document explains the "model" or assumed idealistic example of a webcam and what each linear procedure across the USB bus is doing after the USB Class driver is loaded and begins the task of setting up the device for communications. It also explains why things are they way they are and what purpose each call serves.
This is proving a useful document for understanding the Czur scanner.
Appearing as a USB Video 1.0 Class device, it has the standard interfaces one would expect with a few differences to account for more interfaces since the Czur scanner device also supports a few different compression and uncompression frame formats and methods of delivering those frames of information over USB.
Its been a really great motivation for me to better understand USB communications at the Class level which simpler classes rarely motivate one to do.
I suspect however that raw Class calls do not map directly back to the way the Native Czur scanner software communicates with the Czur scanner.
Rather, on Windows there is a long history going back to Windows 98, then ME, 2000, XP, Vista, then Win7, 8 and now 10 of declaring then abandonning various programming languages styles, APIs and program build tools.
Currently the USB Video Class came into being around the time of Visual C/C++ and the Video for Windows API era. That was supereced by the STI/WIA era which more or less emulated or copied the more widely used and still popular dedicated scanner API for many operating systems called TWAIN.
Then in Vista Microsoft re-thought, complicated, things by making WIA persona nongrata.. and removed most of the functionality for supporting the USB Video Class - Still Image support and banishing it to the DirectX/DirectShow "game development API".. because scanning is like "First Person Shooting, I guess? "
Which was scheduled for deprecation or dissolution by the Windows Media Foundation classes (for Movie making) but never quite got off the ground.
In the meantime.. C/C++ which replaced C/ASM development on old Windows, was itself depopularized or demonized by "Managed Code" after the altercations with Sun/Java and the emergence of the CLR and .NET family of languages.. but somehow.. they never bothered to port "legacy useful APIs" so they left it as an "exercise" for individual programmers themselves to "implement" Wrappers to produce code "Bindings" between legacy C/C++ libraries and .NET (so why is it we're doing .NET if its not good for anything ??)
So much has been left behind and so many people have left Microsoft in the last decade.. not to mention the little mobile problems.. that few outside MVPs outside the company seem to recall how to implement examples for things like AVCAP2.exe which included perhaps the oldest and only example of using the USB Video class for Still Image capture.
So...
Its speculation.. but using DirectShow GraphEdit (a Filter "programming" tool) to prototype using the Microsoft USBVideo.sys Class driver to communicate with the Czur scanner.. a "live" Rendering Window could be created.
Unfortunately a "functional" Still Image protype could not be made to "fire" or snag a full frame image because Microsoft deprecated the USBCmdButton API before it got very far.. and refer developers to instantiating the USB Video Controller and manually firing or hooking the device hardware interupt to actually "activate" the Still Image function on the scanner.
Its all rather frustrating.
The latest developments seem to be more people prefer using a Linux derived Kernel driver on the latest versions of Windows operating system Kernels because of the schizophrenic incomplete API hell developers appear to have to go through to create an application. [But] because Windows Kernel drivers must be signed, and must be signed by a cross signed code-developers signing certificate that costs hundreds of dollars a year to maintain.. the windows development for kernel drivers is grinding to a halt. -- I think in family dynamics this is called a "Habitual Dysfunctional Situation"
Its speculation, however the Czur native software appears to include several software development kit components or piece of frameworks. Notably avcodec, avdevice, avfilter, avformat, avutil -- would point towards a possible DirectShow or WMC connection for invoking the USB Video Still Image capture function. .NET libraries are no where to be found.
Video Lan Client or VLC is notable in that it can [also] invoke the USBVideo.sys Class library and acquire Live video at various resolutions..(invoking Dshow:// directly) but while it can capture Snapshots from its live feed.. it does not appear to have any built-in functionality for invoking the native USB Video Class Still image capture method.. which in theory should be much clearer and more stable.
USBPcap and hand decoding the last bytes from the [Still Image Frame (3)] subtype:
frame.protocols == "usb:usbvideo"
usbvideo.streaming.descriptorSubType == 3
00: if still method 2 this field is set to zero 04: number of Image Size patterns of this format: n
80:02: wWidth (1) 32770 or 640 e0:01: wHeight (1) 57345 or 480
00:09: wWidth (2) 9 or 2304 c0:06: wHeight (2) 49158 or 1728
40:06: wWidth (3) 16390 or 1600 b0:04: wHeight (3) 45060 or 1200
20:0a: wWidth (4) 8202 or 2592 98:07: wHeight (4) 38919 or 1944
00: number of Compression patter of this format 0
Which to me is in agreement with the UVC Spec on Page 15
Universal Serial Bus Device Class Definition for Video Devices Revision 1.1 June 1, 2005
Method 2 –
If the device supports higher-quality still images, it has the option of streaming still-image-specific packets across the active video pipe.
In this case, the host software will temporarily suspend video streaming, select the optimal bandwidth alternate setting based on the still probe/commit negotiation (subject to bandwidth availability), send a VS_STILL_IMAGE_TRIGGER_CONTROL Set request with the "Transmit still image" option (see section 4.3.1.4, "Still Image Trigger Control"), and prepare to receive the still image data.
The device transmits the still image data marked as such in the payload header (see section 2.4.3.2.2, "Sample Isochronous Transfers"). Once the complete still image is received, the host software will then revert back to the original alternate setting, and resume video streaming.
The resolutions are less than final images, but I "guess" this is due to using OpenCV mat functions to remap the pixels into a slightly larger final matrix as JPEG images.
Windows 7 no longer has support for WIA access to UVC video sources, however XP still did.. so it might make sense to see if WIA on XP can access a still image function exposed by the native UVC interface.
Update - while XP did identify the scanner as a USB device with Video and Audio, the Scanner app in XP would not take a picture.
I don't actually know of any Windows software that will make use of the STI capture feature in Windows 7
Possibly the Camera app in Windows 8/8.1 will looking forward.. something to test later today or tomorrow.
Used VLC and targeted the scanner as a capture device. The results were surprising:
Figure 1. Pedestal triggered image scan
Not sure how I triggered the Laser guides to appear and become part of the image scan, they can obviously be chroma-key removed, and extracted to contruct a mesh for de-warping.
Finding software that can make use of the captured images maybe more of a challenge.
Some like Booksorber also seem to already have "flattening" algorithms that would not make use of the guidelines.
Although, after the images are captured, it would be assumed you could "import" them into the native software provided with the scanner and corrected and ocr'd then bound into an ebook.
Although I still find the Quality of the native Czur software for the PC simply amazing.
Zooming in on a single image reveals its in focus, has fine detail and really looks good.
4:40 pm update
Browsed the native software directory and found libraries for VLC and the BSD Licensed OpenCV project, as well as familar libraries for Abby FineReader.. all best in Class quality components.
The OpenCV for "Open Computer Vision" project is known to have fairly technical library functions for both capture of images and manipulation, including "undistort" and "dewarping" functions.
So that further supports the "idea" that the scanner is a good quality camera and acquistion platform, but "flattening" of the images takes place within the native software provided.
The selected libraries are well chosen for porting the software to other platforms like Linux and Mac OSX since they exist on those operating systems as well.
All very encouraging news.
More than ever I wish they would release a simplified SDK for plugging the device into existing scanning tools on each operating system. I don't think existing tools would compete with the native software, but would quickly expand the range of useful options for people who don't have time to learn the native software, or would rather use the scanner in a way other than it was intended.
The one or two functions that would be most useful would be simply hi-res default image capture that the current native software uses to capture and image and offload that to the PC. The images seem to come in at about 3 MB and in the JPEG format. Also the function that captures the same image with Laser Guidelines would be very useful.
It was a lot simpler to setup, no reboot was required.
basically download and run, then run again to identify the USB Hub to monitor and enter the pcap file name to save the results, the capture begins, CTRL+C to end
where USBPcap3 is the "name" assigned to the USB Hub to be monitored when running the USBpcap command by itself to list available Hubs
as a Host the PC detects when a new device is plugged in, then interrogates it for its capabilites automatically
I believe the images are transfered Isochronously since I have made triggers and only seen Isochronous transfers, further when the USB bus was overloaded the Images saved to the PC are interwoven with parts from other images. No Bulk transfers were observed.
This reverses my earlier assumption that flattening was occuring in the device and leads me to think flattening takes place within the image.. but where the laser guideline information is stored I cannot say.
One capture alluded to [ Siri A9 UVC chipset 6333 ] which is every interesting if A9 and Siri happen to have something in common with Apple products. -- curious side note, I got an unusal answer from an inquiry about supporting the Czur scanner in other existing scanner software.. to which the answer was.. not now, working on adding Apple iPhones as capture devices. I thought nothing of it.. but now I wonder if that brief answer might be a result of the chipset already in the Czur scanner.
No news at present, but been exploring Windows device driver signing and enabling USBSnoopy to capture communications with the Scanner over USB. I'd like to document it well enough that a few simple tools could be created for enabling more software development with it on Windows and other operating systems.
This won't replace an official sdk if it were ever to be released.. but it could serve in the interim.
1:53 am - a little progress
The old Windows 98/XP debug program [SnoopyPro] proved somewhat cranky and difficult to get working. Many people seemed to think it would not run on Windows 7 x64.. turns out it will run.
The caveats come from misunderstanding much of the Microsoft documentation regarding the boot time F8 option to 'disable' signed driver enforcement.
Basically they said to 'disable' enforcement.. not that you could "load" unsigned drivers.
For example, to get Snoopy to work. I had to install the Windows SDK and DDK to get the tools to create a Self-Signed Code Signing Certificate, perform an [embedded] signing of just the USBSnoop.sys and USBSnpys.sys files and [pre-install] them by copying them to windows\system32\drivers.
Then run the [SnoopyPro.exe] separately and choose [not to] Unpack the drivers again.
See in the old days (and today) you had a choice of installing drivers from a binary, or packaging them separately with an INF file so the PnP service could inventory and load them for you when a device was plugged in.. this was not so normal for debugging software.. so they tended to perform the driver "injection" manually and carried the drivers inside themselves.. fast forward to Windows Vista days.. and signed driver enforcements.. and you had to make sure to [embed-sign] drivers that were to be carried inside the binary and deployed "at will" upon a system.
It didn't help the documentation provided [only] alluded to embedded signing requirements and proceeded to "document" in an old Word doc format with an example that did not explicitly demonstrate the signing procedure.. so your left with.. hints and innuendos.. and well.. "typical" ms documentation.
Normal outsiders "assumed" this meant you could disable driver "must-be-signed" enforcement
Microsoft insiders "meant" you could disable enforcement of "properly" signed drivers
The difference being, if you used a self-signed cert, its illegal "normally" but legal if you disable enforcement.
The problem being, if you have a driver that is "improperly" signed, perhaps a bad intermediate or cross sign cert.. you could get that driver to work with F8 or a boot option.. and "think" you got away with something when you really did not. -- the reality being.. it was signed.. just not "properly" signed.
[Next] you have to "Unblock" the [Silent] Executeable "Block" placed on files identified as coming from the Internet.. basically right-click SnoopyPro.exe then Properties and [Unblock].. otherwise running it would silently deny complete access to the system.. even if run as Administrator.
[Finally] you have to run in compatibility mode with [Windows Vista (Service Pack 2)] as Administrator.. and the program will start and be ready to capture packets.
There is no good documentation on how to use the program, but basically you F2 to display currently detected USB devices, select the one that says Czurtek and right-click to Install and Install service.
This preassumes you already installed the Snpys bridge > File > Install service and you [did not Unpack drivers, because you copied the "signed ones" into place]
Also you had already imported the signed certs for CA and self, and rebooted to press F8 and choose not to "enforce" security for improperly signed drivers -- see the "key" is the drivers are "signed", but they are not signed "properly" -- if they were not signed at all.. they are just not loaded and no warning messages are provided.
This all to avoid the $100+ requirement to get a crossed signed code signing certificate and to collect URB packets on my currently installed Window 7 x64 machine with the Czurtek drivers and software communicating with the scanner.
[With all of that "Preamble Ramble" the actual use is, all the setup did was insert a bridge driver for copying packets "sneaked out" from the driver stack for the connected device by the "filter" driver acting as a man-in-the-middle between the device and the operating system].. so once its built.. you basically [unplug/plug] the scanner into the PC with the usb cable and the SnoopyPro program opens a new dialog window inside its parent window and begins "capturing" packets.
I think its suppose to interpret them on the fly.. but it did not for me.. the window remained empty, but the status bar across the top of the new window indicated packets were being captured, a pause button and a stop button. I ran the Czur software then let it capture for a while and stopped it and used the File menu option from SnoopyPro to save the packets to a file. Then re-opened the log in SnoopyPro and it "interpreted the packets" as shown below:
There are two "devices" for the Czur scanner, one is the image device the other is a sound device. Or that is what the Windows Device Manager identifies them as.. how the software communicates with them after they are classified is vendor specific.
I can see that it appears a number of [USB Control] type packets are being exchanged, and witnessed a Bulk transfer.. possibly related to initating a snapshot in the software to capture an image.
But the interpretation of the communications is far from complete.. I am not even sure that SnoopyPro would be the best way of capturing and interpreting the packets.
I had thought to use it with USBrobot to replay the communications to test possible function calls for a users API.. but I have a lot of doubts about the stability and complete-ness of the data capture.. the Bulk transfer seemed to decode somewhat incompletely.
I am beginning to think if this were a Tape Media Changer USBSnoopy might be okay.. but there might be better tools for a more reliable analysis.. USBpcap looks interesting.. and then Wireshark could be used with LUA to intepret the packets.. even added to.. to test and develop an API that could be used in many operating systems.
Mostly this test was for completness sake.. I didn't want to over look a potentially easier way of capturing data and interpreting the results.
The Czur scanner (model ET16) is very intersting hardware. But I've long thought it would be much more interesting with an SDK "Software Development Kit" which basically shows you how to access the hardware through software on various operating systems. Since one is not available at this time from the manufacturer of the hardware. I've been looking at creating one by examining the hardware and software.
First, the Czur scanner can be used in one of three modes: HDMI live mode, PC scan mode, WiFi scan mode. These are not their official names, but serve as a convenient naming convention for the purposes of this blog post.
HDMI live mode and PC scan mode share a commonality in that they are invoked by the hardware depending on which cable is attached to the scanner. An HDMI cable causes the scanner to begin HDMI live mode. A USB cable causes the scanner to begin PC scan mode.
WiFi scan mode is the default mode when there is no cable attached to the scanner.
Obviously the only mode that makes sense for creating a software development kit, would be the PC scan mode.
As a USB device attached to a PC it must conform to the USB specifications, which are an object model view such that any USB device connected to a PC must offer up [device, interface and endpoints - with directions] The default device and interface can be queried using a standard request to determine information about the other device and interfaces, replies coming back as "descriptors" which can be though of as simple information strings.
So the first step is that a tool like usbview (part of the windows device driver kit) can be used to simply "view" the descriptors for all of the available devices, interfaces and endpoints that the hardware provides.
Windows uses this information to decide when a USB device is connected [which] device driver in its current inventory should be loaded into memory and executed to create software interfaces the operating system can use or expose for other application programs to use.
Windows has a long history, but in the past it had a signed device driver process where an INF file matched to the information in a USB descriptor and could either load a generic device driver, or a manufacturers specific custom device driver. The registation process was arduous and required optional WHQL certification and purchasing and maintaining a Software Signing Key and infrastructure which could cost thousands of dollars. With Vista and Windows 7 the signing became non-optional and "enforced" and difficult to defeat.
This was presented as a way to address quality standards and then as a way to prevent malware masquerading as drivers from compromising the operating system kernel. Poor documentation and few concrete examples of the process led to a high barrier of entry for causal programmers, custom home user written software and arguably jumpstarted a massive counter culture software revolution.
In any event a descriptor initated method of invoking a truly universal and generic WinUSB device driver and new USBClass of device driver came about and was backported to support even Windows XP.. as well as Windows 7, 8 and 10. The result of which is that the simpler way of looking at USB as a bus with raw access to the native methods of communicating with a device over the USB bus emerged.
Instead of looking at each hardware device on a USB port as a unique and standalone island, the WinUSB approach sees them as peers or equals on a single wired bus. The downside being WinUSB does not support the USB communications protocol or "type" called Isynchronous communications until after Windows 8.1 and logically only one process or program can communicate with a hardware device at a time.. overlapping or multithreaded communications with a single WinUSB supported device are not supported. (that is "shared, simultaneous" access to a single hardware device is not supported within the "kernel space" API) But these are usually not a detractor for the people who would actually use WinUSB.
Usually normal individuals are less concerned with theorectically supporting simultaneous "Time-Share" of a USB printer in a office scenario for example.. over the "simple" use case of printing a document to their personal printer at home. These strange, weird, obscure flights of fantasy are common on the windows platforms.
Concurrently efforts were being made in the Opensource world to address the lack of good documentation and examples in how to access USB devices on Linux, Mac OSX and Windows through efforts like USBdk and Libusbx and finally the re-unified and current Libusb projects.
Libusb is good across old operating system like XP up through Windows 10 and across platforms from Linux, OSX and Windows. And it does support the USB communications "type" of Isynchronous communications.
But it is a judgement call to decide which is more expedient to use, probably depending on the targeted platforms, versions of those platforms and likely software developer platform tools.. and their familarity with the patterns of development they are familiar.
Setting the choice aside, WinUSB or Libusb
There is still determining what the commands and usage model are for the hardware device.
USB is an open standard and it is relatively easy to insert a USB filter driver or device driver "bridge" for inspecting and collecting "copies" of the commands and response from the hardware as they fly back and forth across the USB bus within the Windows operating system.
We don't have to understand or write any of the low level details with regards to managing the USB bus, choosing a device driver or inserting it to handle traffic for a specific hardware device. Its easy enough to use tools to simply make sure the WinUSB or Libusb kernel device driver is forceably loaded and attached to the Czur scanner.
Determining the communications commands and protocol for setting up and initating a scan capture and retrival of an image would be the most challenging. But with things like USBSnoopy, USBRobot or more sophisticated tools this is almost trivial.
After that it remains to figure out.. how to present this.. as an add-on or standalone tool on each type of operating system? As a generic SDK kit? And how would this be used in a custom work flow.. assuming people use it rather than invest time in "learning" existing software that was good enough after a bit of study.
This is not meant as a tutorial.. just some thoughts.
The Czur scanner (model ET16) is really cool and useful hardware. The software is on par with other electronic document creation software that comes with cradle, sheetfed and flatbed scanners. Here are some thoughts on how to make it better.
First you have to understand that scanning software begins with the image. Its like taking a picture and results in a directory or folder full of jpeg or tiff images. The quality of the images will only be as good as your lighting conditions and the same factors that would affect any camera. The advantage of using a scanner is you don't have to worry about setting up many of the things that trip up a professional photographer. Its all preset up for you.
But in the end your still left with a pile of pictures, which might have some mistakes in them. The lighting might not be right, the color of the light, the straightness of the edges of the document, it could be rotated this way and that, have varying widths of margins surrounding the document. It might have captured fingers, hands or other parts of your body. You might have even been caught suddenly moving the object to be scanned while the picture was being taken. So you have the same problems everyone has when taking a picture.
So the next step is generally sorting through the pictures to find the ones that look acceptable and those that don't and replacing or retaking them. Some of the pictures can be saved however by using software to correct the brightness and contrast, color temperature (or hue), reorient or turn the pages slightly to line up the edges and finally to intentionally distort (or dewarp) the ones that actually have a wavy or "curved" appearance to an equivalent straight line in the document. All of this is [image] manipulation within software and its usually what professionals and perfectionists do with a tool like Photoshop.
The Czur scanner comes with free software called the Windows PC USB Capture software.
It is both a remote control program which can use the scanner to "take" pictures, or to receive them, when you press a button on the scanner or one of its optionally attached accessories, like the hand button or foot pedal.
Usually you'll want the freedom to stand or sit near the scanner and use the hand button or foot pedal to trigger a picture to be taken and "offloaded" to the PC running the Windows PC USB Capture software.
The scanner is attached (or tethered) to the PC by a USB 2.0 cable. When setting up the scanner with the PC, you had to make sure to [Install] the Czur software "first" so that it could insert the scanner driver into the Windows operating system [before] the scanner was connected with the USB cable. The reason being that the scanner can also appear as a generic webcam, if windows "sees" the scanner before it has the proper driver installed, it will install a webcam driver and [prevent] the Czur software from using the scanner. In that case you have to not only remove the device driver manually, but then have to make sure the software driver is installed and then reconnect the scanner.
When taking pictures with the hand button the scanner can capture images and save them to internal memory faster than it can "offload" them to the PC over the USB cable. Because it can do that you can continue to scan and take another picture much faster than waiting for the stack of pictures to be copied to the PC. But you have to also make sure not to interrupt the scanner once your done taking pictures until it says it has offloaded all of the pictures to the PC. If you power the scanner off or disconnect it from the PC before it is done copying the images over to the PC, those pictures that are not finished copying could be damaged or lost.
Once you have a stack of pictures on the PC, you can "post process" or begin the process of sorting and correcting them. You do this one at a time and save your changes to each picture. There are some batch features to make the same changes to many of the pictures, but thats a more advanced feature to learn.
At this point the Czur software differs in some way from other document creation software.
You can conveniently [bind] all the pictures together into one file called a PDF.
Or you can choose to run an image recognition program call OCR on each image to detect the pixels that represent letters and words. OCR stands for "Optical Character Recognition" and it basically means tell the computer to look at the image and create a text document from it. The information in the document can then be merged with the PDF to provide an [index] or "map" of where each letter and word was found in each picture in the document. This allows a person reading the PDF file in a reader program to [search] for letters and words and their program will jump to that spot in the document.
OCR'ed PDFs are somewhat common, but they are not required.
You can create a PDF that is not OCR'ed and just read the pages by look at them in a reader program.
You can also choose to run many third party OCR programs on a PDF file after it is created.
OCR is not perfect and often makes mistakes, the best OCR'ed documents are those that are "corrected" by humans who "proof edit" or manually "guide and correct" the OCR indexes that computers create.
Most people however would rather just scan and get a single OCR'ed document all at once without bothering with the details of "post processing" and "proof editing OCR results".
This is what simple office scanning document software does.
The Czur scanning software is much more powerful than that and allows you control over each stage of the document creation process. This is both a [pro] and a [con].
Its a [pro] because you have all the choices before you.
Its a [con] because it can appear complex and confusing.
If your used to creating documents from piles of pictures, you can also choose to just use the Czur scanner software to capture and offload images of the scanned documents and use them with the software that you already have. The choice is yours, Czur way?
Tips! How to simply scan a book and make a document.
The Czur ET16 scanner can support HDMI presentation, USB capture and WiFi capture. The HDMI mode simply displays whatever is placed in its field of view. The USB capture uses a traditional Windows PC and software to capture multiple images and processes them into single documents. The WiFi capture uses an offsite hosting website to receive captured images and enables sharing them with other internet connected users.
Enabling the WiFi mode is a series of steps, which must be performed in order to setup a cloud account, associate the scanner with the cloud account and then capture image scans which are automatically uploaded to the account. A cloud account user can then perform "some" postprocessing and choose to share the images with other internet connected users.
Although I glanced at the one-sheet and online pdf users guide. I did not read any material in depth and proceeded in an exploratory mode.. mostly relying on my previous experience with other book and document scanning solutions.
By far the most unintuitive aspect was getting the scanner associated with a Czur Services "Czur Cloud" account.
My first misstep was in assuming as the [First] step I would need a mobile device in order to scan the QR code on the bottom of the scanner pedestal to retrieve a website URL to begin the process.
In fact the
[First] step is to go to the https://www.czur.cc/ website and [Create] a new account by providing a username [phone number or email address] and password from 6-13 characters.
Normally I would encourage a long and complex password, but in this case since I would be typing it into the mobile device I chose a simple and short password.
[Second] step is to "Activate" the account, a confirmation email is automatically sent to the recipient email address which has a link to confirm the account request. This took about 2 minutes from the time I submitted the request to the time it appeared in my Inbox junk folder. I use Outlook.com and for some reason they automatically categorize it as junk mail without any further notification. So I restored it to my normal Inbox and completed the confirmation by clicking the link in the email which told me I had succeeded in activating the new account.
[Third] step is to use a mobile device and a barcode app to "Scan the QR" code on the bottom of the pedestal of the Czur Scanner. It immediately recognizes a complex URL path and asked for permission to continue by opening the URL in a browser. At first I tried Firefox for Android but this proved problematic.
Many browsers seem to be wary of allowing sound files to be played when opening a URL, and its a non-trivial task to enable a properly formed URL that works even when a browser user has been prompted in how to play an audio file embedded in a webpage.
Therefore I copied and pasted the URL from Firefox browser on Android to Chrome on Android.. and it still did not function properly.. but I'm getting a little ahead of myself here.
The QR code opens a website URL that asks for your Czur Service Czur Cloud account username and password. These are the credentials used to create your master account as describe above at https://www.czur.cc/ after typing those in -- the next page prompts for the WiFi SSD Name and Password for your local Wireless Access Point. (I did this both on Android and iOS, but since the scanner is now associated I can only show you the screencaps from the iPad iOS device.)
Figure 1. Android (already bound to a Cloud Account)
Figure 2. iOS 8.1.3 (iPad2.. okay so I don't Update often)
The type of WiFi security expected is not clearly stated, be it WPA, WPA2, WEP or Open. Generally consumer grade wireless access point/routers deploy a kind of WPA but not WPA2 and WEP is very rare these days, Open is possible but then you rarely need a password. If you have a captive portal type situation where a WiFi user is challenged with a custom logon prompt on first access to the internet with a brower.. this would probably not work.
In any event, the website prompting for SSID and password, accepted those and indicated a custom audio file will be created with that information and presents a button that says "flashing" but actually intends to mean I think "begin the process of configuring your scanner" -- pressing the online button produces a dynamic strobe/rotisserie indicating a "sound file" was being created.. then produces a new page with directions on how to place the scanner into [reset or "configuration" mode] and a button on the mobile device to [Play] the sound file.
Figure 3. WiFi Serenade Ready, Please Reset the Scanner
Figure 4. When the Scanner begins to Flash Green & Blue "Press Play >"
The speakers of the mobile device must be held close to the microphone in the "nose" of the scanner. It appears as a simple small pin hole in the surface of the plastic on the front of the scan head.
The first time I attempted to do this with Firefox for Android and then Chrome for Android no sound was produced, the web site indicated it was attempting to configure the scanner, then timed out and asked whether the scanner WiFi light was Green or had gone out. Green would mean it had succeeded, no light would mean it had failed to configure.
After a few moments of trial and error, in Chrome, I used the triple elipse or three vertical dots in the Chrome address bar to pull up extended options for the browser treatment of this webpage. I checked the box for [Desktop version] and it reloaded the page, and I tried again. This time the sound file played a musical number through the mobile devices speakers (i was using a Nexus 5X).
But the first attempt failed.
Repositioning my mobile speakers directly in front of the nose of the scanner, the second attempt failed.
The [Third] attempt succeeded, if by any chance I had entered in the wrong credentials for the WiFi I can imagine this process would take longer and be much more frustrating. But I had entered the [correct] and [accurate] Cloud account credentials and WiFi SSID and password.. so the failures could only be attributed to other variables... they were entered into the webpage for generating the sound file only once, subsequent trials were re-created by pressing back and forward in the browser to restart the sound file creation process without re-entering any of the credentials.
Using a web based "on the fly" generated audio file for configuring a hardware device is novel. But there are just too many variables in the process and possible human error that could make the process difficult, expecially for first time users.
I then repeated the process with an iPad2 and found the same URL links would also produce an audio file and played it back through the iPad2 speakers.. so it is device agnostic.. and possibly could be made to work with a notebook computer, even a desktop.. but I wouldn't recommend it.. for one thing you need a barcode scanner app for the computing device, these are ubiquitous on aPhones or iPhones. And you need to be able to position the output of the speaker directly in front of the "nose" of the Czur scanner.. something that might be more difficult with normal computer speakers.
Its been suggested by some people to support a [Fourth] option for Capture, plug in a USB storage device to the PC usb port.. its the wrong USB connector type "B", but an adapter could turn it into a normal USB storage type "A" connector [ B/A USB Adaptor ] then let the user offer up a USB SSD storage device to offload the scanned images with no WiFi and no computer.
SSD USB capture mode
would be awesome, a complete standalone scanning option.
I'm highly in favor of that option!
Even easier would be to [buffer] all of the scanned images in cache, until a USB storage device was plugged into the hand or foot pedal trigger port, and offload them enmasse. The firmware in the device would probably be able to distinguish between a USB storage device and a USB HID device and perform accordingly. -- in this way Mac and Linux would be able to access the images immediately once the USB storage was moved from scanner USB port to Mac or Linux USB port.
Honestly though.. while Windows automatically associating the [wrong] PnP driver when first connecting a device [before] installing the device drivers is [annoying].. it is.. far more familar a problem.
Windows PC USB capture remains my preferred mode of scanning at this time.
Once the device was configured, the scanners WiFi icon went solid green.. which I assume means it could connect to the WiFi gateway and through it the Internet. This had another effect in that the webpage on the mobile device, that was indicating it was trying to configure the scanner by playing the audio file. Then it transitioned to another web page indicating it had noticed the scanner had been successfully associated with the cloud account. I would assume the scanner updated status with the services on the cloud servers and that triggered the status change and then updated the webpage the mobile device was viewing.
I then proceeded to use the scanner to take a few image captures, it behaved much as it did in USB capture mode.. which was very good training for what to expect in Cloud capture mode. New scans were buffered in the scanner, and the total would increment on screen on the overhead display. As buffered scans were offloaded to the servers in the "cloud" the buffered count decremented until it reached zero. Multiple sequential scans if taken fast enough would increment the buffered count to 2, 3, 4 ect.. and then slowly begin draining to zero as they were offloaded. --
note: a user should not turn off the scanner while it is still uploading to the cloud, or they may loose data. -- I noticed a few sponsors of the project complained of torn or "incomplete" scan images, and this mode of failure [immediately] came to my mind, if they spend a lot of time scanning and manage to [buffer] some of the scans into cached memory.. then shut the scanner "off" while its still uploading to the cloud..
[.. well what happens when you find yourself "half-way" through a Stargate?..]
.. as they say... yeeaah.... instant spaghettification
The WiFi indicator would change to blue while it was uploading to the cloud and return to green when done. I assume green simply means it can contact the cloud services account.
The upload speed was fair and not that different from the upload or download speeds for USB Capture.
note: its Really Important! to pay attention to [capture speed] versus [offload speed]
[ capture speed ] the interval between sequential image scans (or captures) could be likened to the "burst speed" of a rapid fire DSLR, and it is quite good for this scanner.. I'd estimate 1-2 seconds between snaps, you can watch me in one of the videos and while I can overrun the sequential captured images in the cache with the switch at the base of the scanner or the USB hand switch and a twitchy trigger finger.. I "could not" with the USB foot pedal.. and that is not a deficiency of the foot pedal. Its simply my reflexes moving a foot and large calf muscle were not quite as fast as the small muscle and short lever in my finger. -- if an SDK or the usb communications to trigger a snap can be worked out it might be maximized slightly further.. the "snap speed" would ultimately be a function of the software at that point.. perhaps limited by a different trigger.. "EEG perhaps?"
[offload speed] is the interval between downloading fully cached image scans (or captures) this is limited by the speed of the medium the bits and bytes have to cross to their ultimate destination. The USB 2.0 spec says this is 450 Mb/s at most, and in reality it is somewhat less.. and will depend on how many devices are sharing the USB bus port, how busy the PC is with other tasks it is doing, and what the user may be attempting to do while an image is transiting the path from scanner to PC. In the case of Czur Cloud its further complicated by TransPacific or TransAtlantic or Trans(intercontential) oceanic cable media, Internet traffic Weather and how busy the servers are at Czur HQ.
To be Clear :
You can scan at full [ capture speed ] independent of the limits of [ offload speed ]
The really [Good] news is the Czur scanner has up to 1 Gigabyte of storage onboard which is about 1000 Megabytes and each scan is on the order of 3 to 4 Megabytes.. while its possible to imagine a book scan user zoning out in [Terminator] mode and rapidly flipping pages like a madman.. they would have to have the sustained endurance to cache around 250 pages before they would overflow the possible caching onboard the scanner. There is also an apparently "finite" recoil time imposed by the switch or the software in the scanner that limits the upper capture speed to something less than 2 seconds.
So if you do "the numbers" worst case they would have to be flipping pages one per second for almost five minutes to overrun the buffer... that's a long time continuously flipping and without making a mistake. Reality is they will probably have to take a half second or more to position, and or correct for sticky pages, or making sure to separate pages while turning. At one page per second their fingers and the page corners would look like a blurr, or the insides of a blender. -- but that's only if their goal is to "be faster than the scanners ability to keep up with their performance. Sounds like it should be an Olympic sport. <sarcasm>"
I then logged into my czur service cloud services account and found I could browse the images and to some degree correct or manipulate them. However there was far less functionality that what was available in the USB Capture software for Windows 7, 10.
I could rotate left and right, crop, and change the algorithms applied to the image, reverting to a type of unprocessed mode. I could possibly place them into folders to organize them and then share them with other internet connected users.. but that pretty much concluded my explorations and interest in cloud services.
The storage counter on the account seemed to indicate 10 GB of storage space was available, and the uploaded images had taken a portion of that.
I am reticent to use cloud services in anything less than a limited collaborative engagement and judging from the lack of success of many cloud companies offering online storage.. I certainly would not trust them for archival storage.
As an option for Mac or Linux users, this is definitely a method of obtaining 2D and 3D curve corrected images. However various realities of cloud usage may preclude the use of the method in large volume scanning situations.
A Windows pc would appear to be necessary to successfully use the scanner at the present time however it doesn't have to be a powerful pc. I have not looked at the virtual machine or bootcamp options.
But various virtual machine technologies are known for their USB support; Hyper-V basically has limited to no USB pass-through support, VMware has good USB2 support, VirtualBox has good USB2, USB3 is such a different kernel supported feature that even the virtual machine guest operating system may have trouble supporting it.. USB3.0 was not natively supported in Windows until version 8 and then the virtual machine hypervisor authors only implemented a shell of a pass-through with terrible performance.
This has complicated implications even for the vm hosts.. as many new systems have very few if any pure USB2.0 ports.. but are in fact usually USB3.0 ports run in some sort of compatiblity mode.
Other considerations are [Lighting] -- while the provided field of view is well illuminated by the side lit LED arrays, there is a distinctive "Temperature" to them which appears somewhat on the high side. -- A nice option is to turn them off and use "ambient" lighting.
This seems to have been a consideration in the design as one of the toggled illumination modes is to simply turn the LED arrays off. In theatre and lighting for various productions a "key light", "fill light" and "back light" are used to create the color and desired lighting of a scene. CREE LED bulbs for simple desk lamps and swivel lamps are available (in varing Temperatures) widely and conveniently from IKEA which could serve multiple purposes, including personally tailored scan media lighting.
Beyond
The scanner has the potential to be used as a complete 3D scanning platform for obtaining three dimensional scans of objects. The laser guidlines provide a reference set of points and curves which can be used to decontruct or reconstruct the surfaces being scanned.
The process is simply the [inverse] of "flattening" rather its "measuring" the difference between a monochromatic light source on a surface and the chromatic response of a surface and interpolating the distance. A very similar process to flattening image scans.
