Czur Scanner, TWAIN32 (english) version

Here is the download link for the TWAIN32 driver with English prompts and labels.

The 'Official' link provided by Wiston
ET16 Twain Driver

The install file is 12 MB.

You will want to save it to your hard drive and install it. The driver produces a directory with the driver and manufacturer scan (capture) application as a .ds file.

When you run any program that understands TWAIN32 it will search the c:\windows\twain_32 subdirectory for all "datasources" which are actually the driver application combo and offers them as choices when you Select and Acquire from that application. The Application then starts the manufacturer Capture Application and you can then operate the scanner "essentially" manually.. with all of the features the manufacturer configures into the drivers interface.

Again, I do not have the source code for this TWAIN32 driver, so I cannot fix bugs or improve upon it.

Czur also did not package or accept reponsibility for the Chinese to English translations -- that is, the translations have not been [fact] checked.. they are my "best estimates" as to meaning. So you accept some responsibility for using a TWAIN32 driver that was not officially released by Czur. It is their property, but the english strings.. are my fault.

The 42 minute YouTube video demonstrating how to install and use it is here:

And I must apologize for the quality of the video.. I did not have time to edit it. It was produced very late after work and quickly tossed together. The reason it was not further well thought out before hand is I did  not know Czur would grant me the privilege to produce a video about the driver. I had my doubts they would. Because they allowed me to see and use the driver before it was officially released. I take their trust very seriously.. as I do everyones.

But this driver and the extra abilities it grants end users is very exciting.. and I'd like to encourage its use, and encourage the release of a TWAIN32 driver for MacOS and Linux (or at least SANE). MacOS can use SANE drivers as well.. but in general companies prefer to work against a commerically supported specification.. which is why I favor TWAIN32 (its more likely to get done).

TWAIN64 "is not that important" -- in some instances it "might" please a few people, but really in this instance using the TWAIN32 driver on a 64 operating system is completely acceptable. Better to have TWAIN32 support across the board, Windows, MacOS, Linux.. than TWAIN32  and TWAIN64 only on Windows.

Czur scanner, a possible 'mini-sdk'

An SDK by another name perhaps. Until or if an official SDK is released. I have been exploring the possibility of other ways to write programs for the Czur ET16 scanner. Here are some thoughts.

The hardware for the Czur scanner is unique, but its based on very good first principals. The provided software is good, but could use some refinement. They have been totally focused on hardware and delivery of product for several months but appear to be nearing the end of fullfillment.

I have no special contacts with the company, nor access to any source code or special information.

I have also not delved into dissecting or taking apart the software provided.

However it is possible to look at the files delivered and make some guesses as to which are more important than others, and how they might be otherwise repurposed.

First an SDK is a 'Software Development Kit' it does not presume to replace any provided software, but instead seeks to make developing new software to work with the provided software easier for the software developer.

With that in mind.

The simplest example is that of a software library, and possible 'metadata' for how to use the software library, such as header files or documentation.

Looking over the default directory of the provided Czur software

C:\Program Files (x86)\Czur scanner

We can see several things.

The most obvious are the main program resides in the root directory, and supporting projects or files for the main application are in subdirectories.

Of the files in the root directory, many are from well know public projects or sources, like OpenCV, SDL, Microsoft.

Leaving a very few which seem clustered close to the same development time, and which [guessing] likely make calls to the surrounding support software.

The one that really stands out is a file called ETapp.dll -- it looks like it might be based on BCapp.dll and before that ETCore.dll

I make these guesses based on the fact there is a directory called BC_log and fills with troubleshooting data. And that the older BCapp and ETCore files seemed to be developed in a progression.. from simpler to more complex and then slimmed down to the more current ETapp.dll

An SDK if it were to be released, would probably describe the function calls available from the ETapp.dll software library and what their parameters were.

Its also a guess.. but I would assume all of the software is compiled with some form of Visual C++ meaning that a program designed to use this SDK API would import functions from the loaded DLL -- ETapp.dll and then make calls and receive something like the image in a sort of buffer prepared and provided to the library by the calling program. It might even prepare this buffer by calling one of the functions in another supporting DLL.

I would hope that Czurtek would recognize this is a very small file, and probably a very small API which would fully enable third parties to use their hardware and bring a community of users closer together with many choices in specialize software for many purposes.. integration for Outlook with plugins for example.. or integration with Skype for presentations.

On the Mac platform, re-implementing the very small ETapp.dll would probably be very very easy.

As would re-implementing it on Linux.

Its not that a [whole] software suite of programs needs to be written for each platform.. or even a TWAIN driver for each platform.. simply providing sufficient documentation to use the ETapp.dll functions would probably fill that need.

There are many scanners on the market.. many come and go rather quickly.

The ones that are remembered and revered are the ones from the manufacturers that choose to document and release a simple API or SDK explaining how software writers can write plugins for existing software.. or how to create completely new programs to support their product.

This enhances their product at no cost to them, it "differentiates their product" from all others on the market.. and makes their product "sought after" and enticing.. even long after it has left the market.

Czur scanner, TWAIN coming soon

Today I got a chance to preview a new tool for the Czur scanner, a TWAIN32 driver with vendor capture and control panel.. and its awesome!

The user interface is slim and light "minimal" like a scanner configuration dialog is supposed to be -- it very much proves the maxim "Less is More" so incredibly much more.

It is still in development and as provided to me still had its Chinese UI glyphs, but I pulled out my Google Nexus 5x and used the Google Translate App (which is based on acquired technology for augmented reality "LENS") and aimed it at the UI and was instantly provided an English UI.

Its both a blessing and a curse to use a TWAIN32 driver and UI panel on Windows 7x64 but I'm so familar with TWAIN it felt like an old friend.

First I won't post any photos, pics or images until Wiston approves it out of respect. -- its really not a lot to look at, but seeing it work is simply "Amazing".

Second TWAIN is not an "application" but its more than just a driver. It provides a standardized way to open a still image capture session with a dedicated scanning tool and provides a means to expose vendor specific controls for configuring the tool to acquire the highest and most refined image captures the device can provide. It can be dumbed down using the Windows Image Acquisition (WIA) generic interface to just "aim and fire" taking a snapshot for recording images of paperwork like checks and receipts.. or it can [open] the Scanners full vendor provided [dialog panel] with all kinds of configuration controls.

Czur has provided a [complete] driver and vendor dialog panel, so you can "get your cake" and "eat it too".

Vendors in the name of expediency and economics rarely do both.. and usually barely meet the minimal requirements for releasing a driver that qualifies as a TWAIN driver.. more often they release a WIA or Windows driver and leave it at that. Czurtek did not do this.. they went all the way.

Understand this is a Windows only TWAIN driver.. while I would love to see a Mac TWAIN driver and preview that too.. I have not. And I have not seen a TWAIN or SANE driver for Linux. This blog post is strictly about the Windows TWAIN32 driver.

Microsoft has had a love hate, apathy relationship with TWAIN, first competing with it to try and control the standard, then introducing their own (WIA) and finally deprecating and wrapping DirectShow and Media Foundation to provide "similar" functionality as a movie capture and gaming play format.

The end result is TWAIN on windows often comes through a WIA to TWAIN "bridge" that translates Windows application calls into TWAIN calls through a software bridge.. unless the Windows Application is aware and supports "direct" TWAIN device driver support.. and if it does often will "open" the TWAIN device dialog for fine tuning the capture session.

As it arrived it was an InnoSetup exe file which unpacked itself and installed the driver into the

C:\Windows\twain_32\czurtek_twain32 

subdirectory.. with a data source file and an uninstall program to remove it. It appears like any other installed application in the Control Panel Programs and Features menu.

TWAIN drivers and apps are service providers and are not required and generally do not come with standalone applications. So you need to use the driver and dialog box by setting up your preferred application for handling the image acquistion, by configuring it to either use the WIA to TWAIN bridge built into Windows.. or using an application aware of and capable of using the TWAIN driver directly.

Irfanview will do both.. though I used it for TWAIN.

Basically in the mode I used Irfanview, it launched the vendor TWAIN dialog panel and I made all of my fine tuning and captures from there. Once it was setup I also discovered the usual [snapshot] switches on the base of the Czur scanner would also initate a capture and upload the image to the PC. -- the upload speed was about the same as with the Full Desktop Suite of software that originally came with the Czur software. It is still constrained by the limits of the USB 2.0 bus. And it still caches rapid fire images captured on the scanner and uploads them as time and speed allows to the PC.

I won't say much about configuring Irfanview to use TWAIN except that be aware that there are TWAIN32 and TWAIN64 drivers. And on Windows -- 32 bit applications can "see" and "use" 32 bit TWAIN drivers [only] and Windows 64 bit applications can "see" and "use" 64 bit TWAIN drivers [only].. in other areas Microsoft has built "cross bit divide" bridges.. but its very hard and they did not for TWAIN ! -- so be sure the Irfanview you use with TWAIN32 drivers is Irfanview32 [Not] Irfanview64 -- and Irfanview once installed does not expose or tell you which version (32 or 64 bit) it is from the usual Windows About menu.

The symptom that will be noticable if you install the TWAIN32 driver and then Irfanview64 is when you open the Acquire menu in Irfanview and attempt to select a scanner.. the czur scanner will not be listed as an available TWAIN source. If you then install and run Irfanview32 the czur scanner will appear in the list of available TWAIN sources.

As the User Interface is currently laid out there is a navigation panel on the left of configuration options and a large [Preview] window to the right.

Preview resolution (1536 x 1152)
Scan resolution (4608 x 3456 | 3264 x 2488 | 2560 x 1920 | 1600 x 1200)
Media
Print resolution (275 | 300 | 600)
Crop
Exposure (manual slider | auto checkbox)
image format: (jpg | bmp | tiff | png)
image filename: (prefix and calculated incrementals)
image file path: (browseable)
[Scan button]

This is all subject to [change] and its all my translation from Chinese to English, so some could be wrong.. I am the one at fault if something proves inaccurate -- not czurtek

In case your "wondering" an uncompressed bmp format of one image 4608 x 3456 pixels is a 45.5 MB file, the pixels are not artifacted or aliased and blur only upon Zoom factor 2000% or more. So .. yeah.. its a Big deal. This level of control is [much improved] over the original software defaults.

It has a few stability issues, which could be "user" misunderstandings about affirmatively completing a selection change.. it is not released software, so this could vastly improve.. but its very usable the way it is right now.

There are so many usability "improvements" over the original "presets" and "simplified" workflow of the original software its hard to know where to begin to describe them -- but at the same time, the potential to completely mess things up is completely in the hands of the end user.

Choosing resolutions, dpi settings, media type, whether to depend on autocrop to resize margins. Are all within your control, and making the correct and consistent selections are also your responsibility.

Exposure is not [digital] it is an [analog] slider control, you have far more fine grained control to subtly light the scene from complete darkness to "much" brighter than that perceived by human eyesight alone. Or there is a checkbox to engage [autoexposure].

The image format choices are really nice since the original software only permitted lossy jpg captures. Here both lossy (jpg, tiff) and lossless image formats (bmp, png) may be selected and chosen for their intended post processing platform -- especially important since one might choose to capture on one platform, then copy the collection to a different platform or operating system which is more comfortable with a different default image format. (for example a college or university library might have a "Scanning" station where images could be captured and offloaded to a portable usb drive, then taken home and uploaded for viewing or post processing on a Mac)

The image filename dialog is slightly more than just set a static name, it allows "composing" an automatically incremented filename "template" which is used to store subsequent images either captured by clicking the dialog [Scan] button.. or as a result of pressing the [Snapshot] button on the czur scanner base pedestal.. and its assumed similar with the USB hand switch or foot pedal.. or any other sophisticated USB attached trigger device.

In summary -- I've had very little time to run through all the features, but what I did is solid and works. It is not perfect, but its also not released and still in development.. but there are no "show stoppers".. it a very capable and enabling piece of software. And since it is TWAIN standards compliant any Adobe, or Pagemaker or Image management software that understands TWAIN is immediately capable of using this driver as its native front end for acquiring and capturing source images to feed a workflow.

TWAIN is a stable and well thought out standard, its very large and encompassing and cross platform, it places the burden of development on the hardware vendors to best represent their hardware product in its best light under it highest performing conditions.

To a degree USB or memory based transfer protocols like PTP or MTP have replaced capture and transfer between a camera device and a PC.. but those really do not address high resolutions or "performance" of the capture device.. leaving much up to lowest common denominator standards on all fronts.. and often ending up in disappointing results. Many document processing software toolkits are steering towards blurry mediocre image capture libraries suitable for uploading to the cloud.. and really are not suited to archival document rentention tasks. Czur scanner and its TWAIN32 support heads back against that tide and brings a really high potential product to the market.

[Almost forgot] : One of the reasons to use Irfanview as a host for the TWAIN driver and dialog is that Irfanview can also be called from the cmd line to capture from a twain source.. meaning this is one path to a cmd line tool which can be scheduled or "scripted" from within the windows operating system with minimal experience and effort on that part of the end user.

Czur scanner, Ludicrous res 4068 x 3456

Until there is an SDK, there are people finding really cool features of the Czur scanner. One is its amazingly high resolution scan mode in 63 milliseconds. Here is a link to a one such explorers efforts  Using the Czur scanner to emulate a flatbed scanner

Czur scanner, Still Capture at 2304 x 1728

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.

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.

Czur scanner, the USBVideo Class

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.

Czur scanner, Still Image Method #2

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.