04-05-2012 04:03 PM
I am trying to use Y8 or Y16 pixel format (also called Mono8 or Mono16) on a FireWire camera through DirectShow. However, these formats always showed up as unknown in NI-MAX's "Video Mode" drop down menu. Interestingly, "Snap" worked properly and images were acquired correctly using these two formats in NI-MAX.
I am a bit puzzled why they showed up as unkown. Could this be an issue with camera's own DirectShow filter?
Has any one else used Y8 or Y16 pixel formats successfully in NI-MAX on a FireWire camera? How were they listed in "Video Mode" menu?
Thanks in advance.
04-06-2012 10:18 AM
Hi,
The list of DirectShow pixel formats that IMAQdx knows about comes from the list Microsoft defines here:
http://msdn.microsoft.com/en-us/library/windows/desktop/dd407353(v=vs.85).aspx
Looking at the uncompressed RGB list (includes monochrome as well) and note that there are no 16-bit monochome formats in that list. The only true "grayscale" formats (those where DirectShow does not give us an RGB color image) are RGB1, RGB4, and RGB8. Any other formats will be translated by DirectShow to an RGB image.
Essentially if your camera is returning an image format that is not listed in Microsoft's defined list of GUIDs, it will show up as "Unknown" and IMAQdx will expect it to be an RGB image. DirectShow will convert the image using whatever filters you have installed to that format.
Eric
04-10-2012 12:13 PM
Thanks Eric! Your reply helped a lot.
I guess this also explained why RAW8 and RAW16 pixel formats were also listed as unknown.
04-10-2012 01:46 PM
Hi,
If you can point to some documentation describing those formats with video subtypes and GUIDs, it is possible that those could be added if there was some standard that defined them. As far as I can tell, those are likely vendor-defined subtypes that are not defined by Microsoft/DirectShow.
Eric
04-12-2012 12:53 PM
Hi Eric,
You were right. RAW8 amd RAW16 were indeed vendor defined formats. They were basically 8-bit and 16-bit bayer tile formats.
I'll see if I can their subtypes and GUIDs.
06-05-2012 03:42 PM
I realize this thread is probably dead and buried but I am experiencing something very similar. I have a custom 1394 IR camera that outputs 8 bit grayscale (enumerates as "Mono 8"). We have been building this camera for about 8 years and have been using Legacy 1394 IMAQ drivers for testing. Since NI has discontinued support we are trying to port our test software to IMAQdX. IMAQdX recognizes the camera but when you try to acquire/grab using the same settings that worked in legacy it throws up errors saying it doesn't have the specified pixel decoder or there is a out of range attribute.
Has anyone solved this?
06-05-2012 03:59 PM
Can you show a screenshot of the acquisition tab in MAX?
Thanks,
Eric
06-05-2012 04:21 PM
IMAQdX Settings:
IMAQ 1394 Settings (activily Capturing, same camera as above, only drivers changed)
Bayer settings are set to "None"
06-05-2012 05:03 PM
I suspect that there is some odd interaction between what the camera says is its supported pixel codings and what it is using, but it is hard to guess without actually seeing what the camera is doing.
Have you tried changing the Bayer tab from "Hardware Default" to "None"? It adjusts how the driver tries to select a decoder and might let you work around the issue.
Eric
06-05-2012 05:17 PM
Yes, I've already got Bayer Settings set to "None" and have tried "Hardware Defaults" as well. I have a support ticket with NI open, and if we actually figure this out, then I will post the results.