Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

Vision 2009 ArrayToImage Method difference

Is there any news on getting this fixed or is this permanent? Right now I am transposing the arrays before storing but for a large number of images (6000/inspection) this takes a long time. If this is permanent I will switch my code and tell all my customers that they will have to upgrade their software to remain compatible.

John A. Lively
NDE Engineer
Pratt & Whitney
0 Kudos
Message 11 of 23
(1,454 Views)

Hi John,

 

It seems that this is still in the works for updating. I have checked CAR 205929 and the LabVIEW R&D are still aware of and working on the issue.

Ricky V.

National Instruments
Applications Engineer
0 Kudos
Message 12 of 23
(1,434 Views)

John

 

> was told I should have a reply within a week.

 

Did you receive a reply?

 

I'm wondering what "corrective action" to the library code NI can resonably take here, since if they switch the dimensions back again, they'll break the code of everyone like me who is writing for the current behaviour.

 

I think actually the real problem is that NI did not originally define the order of the dimensions in the definition of PixelValue2D. Hence everyone who has been relying on the empirically discovered order has being relying on undefined behaviour. This lack of definition (and the practices/polcies/standards that permitted it) is the first thing requiring corrective action.

 

Chris

0 Kudos
Message 13 of 23
(1,355 Views)

The last reply I received from NI was the beginning of this year. I have since received another software update with no change also. The data format was defined back when NI had real paper manuals. I have been using the code since version 1.0. When they switched to online documentation all detailed help was lost. For a few years the only online help available was for VB even though I was programming in C#. After this long I can not see how NI can correct the mistake now unless it is provided as an option or overloaded method. I already have quite a bit of code in the field now with the new orientation. To me it is just another Dilbert cartoon!!!

 

Note: NI also did the same thing with their NIDAQ software a year ago. For 20 years the output of their A/D board was raw Int16 data. Last year the data output was changed to scaled Double voltage data which requires four times the storage space and may not be what the user wants. I now have to convert the data back to the units I need. Again the addition of an option or an overloaded method would have saved a lot of programming time and wasted execution time.

John A. Lively
NDE Engineer
Pratt & Whitney
0 Kudos
Message 14 of 23
(1,346 Views)

Thanks John. I agree - the current state of affairs is rather a shambles. For the record, the library module on which I've found this particular fault (PixelValue2D changed to column-major order) is assembly NationalInstruments.Vision.Acquisition.Imaq 4.60.20.49153 which I installed from Vision Acquisition Software Sept 2011.

 

The workaround I am using is to rotate the array back to row-major order.

 

I had considered switching from the .NET library to the IMAQ.DLL itself, but having found that the .NET library is running IMAQ.DLL, I conclude that the fault is in IMAQ.DLL itself and so would not be evaded by that switch.

 

A further problem is: how to run program that relies on the new, faulty ordering in the same NI Vision installation as earlier programs relying on the correct ordering. In the absense of documentation, I see no way of finding out whether a given application requires the old ordering... until I install the new NI driver software and the old application breaks. If anyone does have the version number of the more recent IMAQ.DLL that preceeded the appearence of the fault, I would very much like to known it, for the record. Thanks.

 

 

 

Message 15 of 23
(1,340 Views)

Any news on this? It has been almost two years since the CAR was submitted.

John A. Lively
NDE Engineer
Pratt & Whitney
0 Kudos
Message 16 of 23
(1,316 Views)

Hello John,

 

R&D is still aware of this issue.  Unfortunetely, we do not have a timeline on which patch will resolve this issue.  

 

I've reviewed the existing information you've provided us in past Service Requests.  Are there any new developments pertaining to this issue that you would like us to be aware of?

 

David A

0 Kudos
Message 17 of 23
(1,298 Views)

A similar situation (same basic underlying issue perhaps ? ) exists in using IMAQdx Image to Array function to convert an IMAQdx acquired image to a 2D array and then using an Intensity Graph to display that 2D array.  The image on the intensity graph is rotated 90 degrees to the left counterclockwise.  This requires a transpose array followed by a for loop with reverse 1D array to make the intensity graph's image orientation match that of the IMAQdx image.

 

Is there a standard definition for how a 2D array's rows and columns should be arranged when it contains an image ?

 

Steve

 

0 Kudos
Message 18 of 23
(1,246 Views)
Hi Steve,

How are you determining that the image is rotated?  Can you post the code that shows this behavior?  I am curious to see if the rotation could be happening somewhere else?
Regards,
Kira T
0 Kudos
Message 19 of 23
(1,227 Views)

Kira,

 

The 2D array from IMAQ Color Image To Array when displayed onto an Intensity Graph can be seen to be rotated by comparing the images as displayed on an IMAQ Image vs the Intensity Graph.  I have attached the Grab.vi example modified to show this behavior along with Transpose Array followed by a For Loop using Reverse 1D Array to reorient it.

 

Steve

0 Kudos
Message 20 of 23
(1,217 Views)