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.
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.
> 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.
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.
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 22.214.171.124153 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.
Any news on this? It has been almost two years since the CAR was submitted.
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?
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 ?
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.