If USB3 IMAQdX doesn't support a pixel format is there a way to make it do so, or am I hosed?

[MGould]

We recently purchased a HDSDI to USB3 converter from Pleora Technologies (model
IPORT HDSDI-u3).  This adapter is supposedly USB3 Vision and Genicam Compliant.  When I
hook it up to my computer and open MAX it enumerates correctly as a IMAQdX USB3
camera.  When I try to grab video, I can successfully get video if I use the
following pixel modes:  mono8, mono10, mono10p.  If I try to use any of the
color modes, I get a error 0xBFF69037 "No decoder available for selected pixel
format".  I've talked with Pleora support and they said that NI needs to
supplor YCrCB type pixels in order to have this work.  The exact response from
there support was:

"The list of pixel format you see is reading from the XML file of HDSDI. Those
are all the pixel format HDSDI supports.
Apparently MAX doesn't have a decoder for the "YCbCr", that's why you got the
error.
You might need to talk to NI to see if they support this format or not."

Here is the list of enumerated Pixel formats that MAX shows:


Mono8
Mono10
Mono10p
YCbCr601_422_8_CbYCrY
YCbCr601_422_10p_CbYCrY
YCbCr709_422_8_CbYCrY
YCbCr709_422_10p_CbYCrY

The first three (the mono) selections work.  The last four give me the decoder
error.

Is there any help you guys can give me to get this working?

[BlueCheese · Accepted solution]

Hi,

IMAQdx does support various configurations of the YCbCr colorspace pixelformats, but it seems that it doesn't have the new-fangled Pixel Format Naming Convention versions that explicitly list the exact color space (because there are more than one YCbCr colorspaces). IMAQdx's YCbCr decoders are all following the ITU-R BT.601 standard and support up to 8-bits (the 10-bit variants are not supported).

You can edit your local cache of the Pleora XML file (C:\Users\Public\Documents\National Instruments\NI-IMAQdx\Data\XML) and replace the enumeration name "YCbCr601_422_8_CbYCrY" with "YCbCr422_8_CbYCrY" (this is the older, generic name that predated the 601 variant). This should allow the the pixel format to match a one of IMAQdx's known encodings and be properly decoded.

I'll file an internal bug report to get "YCbCr601_422_8_CbYCrY" (and the rest of the similar formats with this issue) added as a proper alias for the decoders we have so that this will "just work" in the future.

Eric

[MGould]

Huzzah!  It worked! Thanks so much Eric!

As an aside is there any chance that NI might support the full 10 bit protocol any time soon?  We actually have a use for those extra two bits in terms of noise testing on our camera systems.

Would it be safe to assume that the additional aliases will be in Vision 2016?

[BlueCheese]

I'm not sure about the 10-bit YCbCr formats being supported anytime soon. I think that Pleora device might be the only GigE Vision or USB3 Vision device I have seen use it, and certainly the only one that doesn't have a multi-byte Bayer option available as well. Generally anyone using a machine vision camera and wanting higher than 8-bit pixels is going to just use a Bayer 10/12/16-bit format and have the color decoding happen on the receiver (and those multibyte bayer formats _are_ supported). It is both more efficient to transfer and allows more intensive decoding algorithms than can be cheaply done on the camera. The YCbCr ends up being the worst of both worlds in that you still decode from a bayer sensor on the camera into YCbCr, send color data over the network, then convert to RGB like most libraries (such as NI Vision) use.  Certainly YCbCr makes sense in the case of your converter where the data coming in is already in that format, so converting it back to Bayer would be silly.

Regarding the aliases, while I can't guarantee that they'd make it into 2016, it seems reasonable to assume that they should be able to get in since they are simply pointing to ones we already support.

[kensign]

Hi, 

I just wanted to update this thread to say that the latest version of Vision Acquisition Software added support for Mono10p as well as some pixel format aliases mentioned in this thread:

From the release notes (http://download.ni.com/support/softlib//vision/Vision%20Acquisition%20Software/February%202016/Visio...

• Support for cameras using the Mono10p pixel format

• Support for cameras using the following aliases for existing decoders:
  • YCbCr601_411_8_CbYYCrY
  • YCbCr601_422_8_CbYCrY
  • YUV422_8
  • YCbCr601_422_8
  • YCbCr601_8_CbYCr
  • RGB10
  • RGB12
  • RGB14
  • YUV411_8_UYYVYY
  • YUV422_8_UYVY
  • YUV8_UYV
  • YUYVPacked

http://www.ni.com/download/ni-vision-acquisition-software-february-2016/5801/en/

-Katie

[MGould]

Hi Katie,

We just updated a PC with the new Vision 2016 and it broke the Pleora solution that was described earlier in this thread.  I've verified that the hardware still works on the 2015 installs we have so I'm pretty sure its the change to 2016 that messed this up.  The sympotoms I'm seeing are that the Pixel Format comes up with "YCbCr709_422_10p_CbYCrY" and when you try to change the pixel format to anything else, it snaps back to the previously mentioned setting.  If you try to acquire with that setting you get the "No pixel decorder" found error.  Do you have any suggestions to try? Thanks.

[kensign]

Hi MGould,

That does sound concerning. I tried to reproduce this with the USB3 and GigE Pleora devices I have but was not able. I definitely don't have the same model that you do though. Have you tried clearing out all of the cached data in C:\Users\Public\Public Documents\National Instruments\NI-IMAQdx\Data?

Katie

[MGould]

I believe I've found the culprit.  There is a setting in the camera attributes that is something akin to "Input Autoselect".  When I disabled the autoselect,  I can now select whatever pixelformat I want and everything works.  It's super weird that this seems to only occur with 2016 though.

[kensign]

Glad you found the culprit! My guess is that the difference in behavior is due to a newer version of GenICam. VAS 15.5 upgraded to use newly-released GenICam 3.0, which could definitely impact behavior related to XML file parsing and getting/setting attributes. It seems like ideally that setting should not be on by default, and perhaps that's something that might be helpful to communicate with Pleora. I'm glad you caught that and posted here just in case others come across the same issue.

Thanks,

Katie

[Ada_S]

Hi, 

I have similar problem with he pixel format. Do you think RGB16_Planar is supported by IMAQdx? According to the file - Pixel Format Naming Convention (http://www.emva.org/wp-content/uploads/GenICam_PFNC_1_1_01.pdf) this format is supported by GigE, however my customer is receiving error: "No decoder avaiable for selected pixel format". 

He is connecting to the Wenglor MLSL123 profilometer which uses GigE to communicate.

I would appreciate any tip.

Ada