Cast from U16 to HSV32 - bit depth behaviour?

[b.ploetzeneder]

So, I've been playing around with IMAQ Cast (VDM2014, LV2014/32b) and the rather obscure conversion form U16 to HSV32.

As a simple example, I'm converting a "one-line" image with 5 pixels:

From 1/32.676/32.678/10.000/65535

I'm expecting the luminance plane to be 0/128/128/39/255.
I'm getting the luminance plane 0/128/0/39/0

This looks like a bit depth problem for me.

However, the manual says for conversion from U16 to HSV32

The VI sets the luminance component of the destination to the source value. If the source value is greater than 255, the VI sets the luminance to 255. If the source value is less than 0, the VI sets the luminance to 0. The VI sets hue and saturation component of the destination to 0. If the source image has a specified bit depth, the VI uses the bit depth when performing this conversion.

This is pretty much exactly the text for the conversion from U16 to RGB32, where I get

Each color component of the destination is set to the source value. If the source value is greater than 255, the VI sets each color component to 255. If the source value is less than 0, the VI sets each color component to 0. If the source image has a specified bit depth, the VI uses the bit depth when performing this conversion.

In practise, that means my L component should be the same as the R/G/B component, and the other planes are 0... no matter what my bitdepth may be. 
This works well for conversion from other datatypes, including I16.

It is only U16->HSV32 that gives me this behaviour.

Can you reproduce this issue? 
I'm not interested in a workaround (which is trivial anyway), more in whether I should reinstall my system or not, or if I'm misunderstanding something.. 🙂

[GuenterMueller]

Confirmation.  I can reproduce this behaviour in LabVIEW / Vision, both 2013 SP1.
It seems that is something wrong when using the U16 data type with the U16 image type.  
Using a 2D array of I16 values with a I16 image type works as expected.

[b.ploetzeneder]

Thanks a lot, I was slightly doubting myself.

I did some extensive testing of IMAQ Cast after. Anyone else reading this can be reassured that it works as explained in the manual.. except for 2 obscure cases.. The one as described above, and .. when casting from CSG to RGB32. I haven't figured out what exactly goes wrong here.

[GuenterMueller]

I did not check the code in your previous post. However, I did report this behaviour here.