Error 0x80040217 The error code passed into imgShowError is unknown

[Megabite]

We manufacture a USB DirectShow camera and supporting application software.  Some of our customers would like to use the camera directly in LabVIEW via IMAQdx.  But we get this error when trying to capture frames from the camera using NI MAX 5.5.0f0 on a Windows 7 64-bit computer.

In doing some research this error seems to indicate a problem finding an appropriate filter.Inparticular that the image cannot be reb\ndered.  Being a DirectShow novice I am not sure what I am saying or where to look for a solution.

The reason I am posting here is that the same camera works fine using NI MAX running under Windows XP SP3. Windows XP also shows the camera and a preview in Windows Explorer. Windows 7 has no such listing or preview. could there be a filter available in Windows XP that is now missing in Windows 7?

Any help or ideas would be greatly appreciated!

[BlueCheese]

You could verify that your installer properly installs/registers all the proper files for both 32 and 64-bit operation when run on a 64-bit system. If you only install 64-bit components then it will not work in 32-bit applications such as MAX. You could see if this might be your issue by testing operation in 64-bit LabVIEW.

[Megabite]

Thank you for your response.  

There are no drivers installed.  DirectShow cameras are supported by the MS driver "usbvideo.sys"

The camera works fine with our application software on all operating systems.

The problem we are having is with IMAQdx on 64-bit Windows 7.

[CertifiNATEtion]

Hi Megabite, 

IMAQdx calls into DirectShow to communicate with compliant cameras. As long as the camera is fully compliant with DirectShow there is no reason it should not work under all operating systems. 

You can try running the dxdiag command on both the x64 and x86 systems and looking at the difference. It may be that a filter is not present in Windows x64. 

-N

[Megabite]

IMAQdx calls into DirectShow to communicate with compliant cameras. As long as the camera is fully compliant with DirectShow there is no reason it should not work under all operating systems. 

There's the rub. The camera is compliant as demonstrated on Windows XP.

Our application uses DirectX calls to collect images from the camera. Since I do not have the IMAQdx souirce code I cannot determine why NI MAX does not work.

You can try running the dxdiag command on both the x64 and x86 systems and looking at the difference. 

It appears that dxdiag does not enumerate DirectShow devices or filters of any kind.

[Megabite]

found a solution direction in an MS DirectShow forum - http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/home?forum=windowsdirectshowdevelopment

[BlueCheese · Accepted solution]

IMAQdx presents an AM_MEDIA_TYPE of MEDIASUBTYPE_RGB8 or MEDIASUBTYPE_RGB32 (depending on source format selected on the camera). Like most DirectShow applications, we then expect Windows to render the final graph with intermmediate filters in place to convert to one of these types.

Since your camera sounds like it is a UVC (USB video class) camera, there are only a few types typically used/supported in that spec. These are usually YUY2 and MJPEG. Both should have default filters installed by the OS for conversion. I suspect that some other installation has messed up your filters. The suggestion of trying this yourself in GraphEdit is what I would suggest as well.

Eric

[Megabite]

Thank you.  That is the information I was looking for.

The camera output is MEDIATYPE_Y8.   I don't know why this was chosen but I will ask. The camera was designed five years ago by a sister company in another country. Getting info and support can be a challenge. Regardless I will be looking into builing an in-house converter.

[BlueCheese]

As far as I can guess, MEDIASUBTYPE_RGB8 should be identical to the "Y8" or "Y800" type, as both simply have an 8-bit greyscale value. However, only MEDIASUBTYPE_RGB8 actually exists in Microsoft's standard definitions. Any references to MEDIASUBTYPE_Y8 online simply point to 3rd-party code that defines the GUID themselves using the standard FOURCC mechanism. Likely this also means that Windows probably has no built-in filters that know of this type. I'm not sure what software you may have on your XP machine that would add a filter for this type.

Since the Y8 subtype is also not known by IMAQdx, it maps the pin it presents to DirectShow as MEDIASUBTYPE_RGB32. This presents two issues:

-A filter must be present to convert the Y8 type to RGB32 (see issue above)

-The user gets RGB32 color data for their monochrome camera, meaning they have to cast it back down to 8-bit monochome to run standard monochrome algorithms

My recommended solution would be to see if you can change/add the MEDIASUBTYPE_RGB8 type to the camera.

Eric

[Megabite]

My recommended solution would be to see if you can change/add the MEDIASUBTYPE_RGB8 type to the camera.

Mine too. They are not interested.

This was the first time (that I know) anyone has asked about using IMAQdx with that camera.  Trying to learn from their mistakes plus maybe solve a problem or two that our customers have had. I am in the process of adding a DirectShow interface to a new camera. The new camera will have much more interest from those who use IMAQdx.

Since the Y8 subtype is also not known by IMAQdx, it maps the pin it presents to DirectShow as MEDIASUBTYPE_RGB32

Actually the filter I stumbled onto outputs RGB8 or RGB32. Since we have no way of knowing what the IMAQdx graph looks like, I would bet on RGB8.

The new camera outputs 15-bit monochrome data.  Can IMAQdx treat MEDIASUBTYPE_RGB555 or MEDIASUBTYPE_RGB565 as monochrome?