WIA philosophy

I just started reading about WIA about 15 minutes ago, so my questions are very general, and may be ignorant/naive. Please forbear…

In the past, I wrote a video kernel driver. WIA did not figure into this, because I did not know there was such a thing. The proprietary hardware/firmware would package image chunks into a USB isoch stream. My driver would assemble these into an image, and notify the waiting application. The app would then pick up the pending image and slap that into the bitmap and presto, moving pictures!
Wasn’t too hard once we figured it all out.

Now, we are presented with a new imaging device. The device will connect via USB and will ( at least at this time ) still send up image chunks in an isoch stream.

This new imaging device has two buttons on it which we will need to capture these events and respond to them.

This new imaging device needs to plug into an existing application. We have license to change the application as needed. The application must run on Vista and XP.

At some level, the application is already using WIA. One can connect a webcam and the app can find this and use this camera (although the features attached to the buttons are not available). This is nice for backward compatibility for earlier versions of the camera.

Questions:
So, from a high level, philosophical point of view, why would one choose to implement this in WIA vs the way I did the first driver (described above)?

What are the advantages/disadvantages of WIA?

Regards

Rick

xxxxx@gnotometrics.com wrote:

I just started reading about WIA about 15 minutes ago, so my questions are very general, and may be ignorant/naive. Please forbear…

That’s really indicative of a marketing failure. WIA has been part of
Windows since Windows 98.

In the past, I wrote a video kernel driver. WIA did not figure into this, because I did not know there was such a thing.

Actually, until Vista, you got WIA (and hence TWAIN) support for your
video capture devices for free, as long as you had an AVStream or Kernel
Streaming driver. All it took was a half a dozen lines in your INF file.

The proprietary hardware/firmware would package image chunks into a USB isoch stream. My driver would assemble these into an image, and notify the waiting application. The app would then pick up the pending image and slap that into the bitmap and presto, moving pictures!
Wasn’t too hard once we figured it all out.

So you didn’t write an AVStream driver? If not, that was a big
mistake. It means the only people who can use your camera are those who
write specifically to your custom API. You don’t get DirectShow, or
AMCap, or NetMeeting, etc.

Now, we are presented with a new imaging device. The device will connect via USB and will ( at least at this time ) still send up image chunks in an isoch stream.

This new imaging device has two buttons on it which we will need to capture these events and respond to them.

This new imaging device needs to plug into an existing application. We have license to change the application as needed. The application must run on Vista and XP.

At some level, the application is already using WIA. One can connect a webcam and the app can find this and use this camera (although the features attached to the buttons are not available). This is nice for backward compatibility for earlier versions of the camera.

Is that using your custom API, or a standard API?

Questions:
So, from a high level, philosophical point of view, why would one choose to implement this in WIA vs the way I did the first driver (described above)?

What are the advantages/disadvantages of WIA?

The advantage of WIA is that it is a standard. Apps that know how to
speak WIA can use your camera without having any custom software at
all. If you go it alone, you have to provide your own API and your own
interface DLL, and you force your clients to rewrite their applications
to call into your DLL. Plus, if you have WIA support, then you work in
the Scanners & Cameras Wizard, and you automatically have TWAIN
support. LOTS of applications already know how to speak TWAIN.

However, there’s an ugly aspect to this. In Vista, Microsoft has
unilaterally, inexplicably, unfairly, and unjustifiably decided that web
cameras are not allowed to swim in the WIA pool any more. You can make
a web cam that works in WIA in XP, but it not operate in Vista. Your
only choice in Vista is to pretend that your device is a still camera or
a scanner. Even then, you have to write the whole WIA minidriver
yourself, whereas in XP much was provided automatically.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Ah yes… let me clarify some things…

concerning the driver that I wrote in the first example, you asked:

So you didn’t write an AVStream driver? If not, that was a big
mistake. It means the only people who can use your camera are those who
write specifically to your custom API. You don’t get DirectShow, or
AMCap, or NetMeeting, etc.

This camera is actually part of a proprietary medical device. It is way expensive and no one would ever dream of using this as a web camera. It is actually desireable to have it closely coupled to the API which we have written. So, in this instance, even if we had known about AVStream, we still would have written it the way we did.

> At some level, the application is already using WIA. One can connect a webcam
>and the app can find this and use this camera (although the features attached to
>the buttons are not available). This is nice for backward compatibility for
>earlier versions of the camera.
>

Is that using your custom API, or a standard API?

What I spoke of here is an existing software app using an existing camera (also part of a medical device). My job is to hook up the ‘replacement’ camera into the exist software. So, WIA is used via a the standard API in this setting.

Thanks for the information, Tim

Rick

xxxxx@gnotometrics.com wrote:

>> At some level, the application is already using WIA. One can connect a webcam
>> and the app can find this and use this camera (although the features attached to
>> the buttons are not available). This is nice for backward compatibility for
>> earlier versions of the camera.
>>
>>
> Is that using your custom API, or a standard API?
>

What I spoke of here is an existing software app using an existing camera (also part of a medical device). My job is to hook up the ‘replacement’ camera into the exist software. So, WIA is used via a the standard API in this setting.

OK, that’s good. Does the old camera driver belong to you as well? If
so, then this means you already have a WIA minidriver that works the way
your software wants. That means it shouldn’t be terribly difficult to
tear the bottom end and make it work with your new device.

The trouble with WIA, as with many Microsoft interfaces, is that it is
big. There are a lot of calls and callbacks in the interface, and
although there is documentation, the docs never talk about which of
those calls and callbacks are the important ones. We all know that in a
driver interface with 200 interfaces, 10 or 15 of them will make up 99%
of the calls. The rest are for unusual circumstances, and can be left
as skeletons most of the time. The problem is figuring out which ones
are the important 15. If you already have an implementation, then
someone has already explored this.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

>>OK, that’s good. Does the old camera driver belong to you as well?

Nope… Old driver/minidriver/camera all wrapped up in an opaque DLL/SYS which was provided by the device manufacturer who could not keep up with demand.

>The trouble with WIA, as with many Microsoft interfaces, is that it is
>big.

Yah, I hear you. With the existing application software, it appears that the WIA implementation is hidden in a 3rd party opaque dll. This is why I am entertaining the idea of not using WIA. We wouldn’t have the bulk of WIA in the product. I wouldn’t have to write the minidriver in addition to the kernel driver. I have to write a replacement to the opaque DLL regardless; by not going with WIA, the only thing I lose is backward compatability to the existing camera. From a business perspective, losing backward compatability is not a bad thing.

Sorry, just thinking aloud. Thanks again for the info. Still gathering info to make an architecture decision.

Rick