02-19-2021 03:49 AM
Hi Labview users,
Currently, I am looking for some high speed image processing. I watched that ImagetoEDVR is more suitable than Imagetoarray, especially for memory management and CPU ressource. (i.e. https://zone.ni.com/reference/en-XX/help/370281AG-01/imaqvision/edvr_with_vision/)
Before starting to write a program, I just compare the processing speed to get data using either ImagetoEDVR or Imagetorray.
Surprinsingly, for a same image the while loop with ImagetoEDVR took 4ms to display a table and Imagetoarray 0.04ms.
ImagetoEDVR seems to be very slow (about 100 times) by comparison with Imagetoarray. Firstly, I thought that displaying data at every while loop run was time consuming. However, even without displaying any data ImagetoEDVR is slower than imagetoarray.
So the question: Did I make a mistake somewhere to explain the low processing speed?
Thank you in advances for your help
Best regards
02-19-2021 05:34 AM
Disclaimer: I've no idea if this is what is happening, and no prove of it. It would be a plausible explanation.
ImageToArray might not do anything, except returning a pointer. Unless you use the data, it remains a pointer, and it will be fast. No copying of data.
The ImageToDVR probably has to copy the data, to get it into the DVR container.
The real test will be how it performs when you actually start using it. The ImageToArray pointer will be copied when you use it (although a lot of operations will not, but in stead create sub arrays around the pointer).
I'd be biased against DVRs anyway, as they're terrible to debug.
02-19-2021 08:58 AM
Thank you for your reply wiebe@CARYA
According to the weblink: https://zone.ni.com/reference/en-XX/help/370281AG-01/imaqvision/edvr_with_vision/
---
The IMAQ ImageToArray VI provides access to the pixels of a Vision image by copying the image pixels from the Vision image into a 2-D LabVIEW array.
By using the IMAQ ImageToEDVR VI, you create an external data value reference to the pixels in the Vision image. Using an external data value reference avoids the data copy and reduces CPU overhead.
---
So I was thinking that ImagetoEDVR should be faster because EDVR avoid the data copy.
I do not really understand what is the interest of ImageToEDVR. Especially if the acces to the data is 100times slower than the ImageToArray vi.
If Labview users could help me to understand I will glad to learn.
Best regards,
02-19-2021 09:05 AM
Here is a simple labview program to illustrate the difference of speed to get the pixel values of an image.
02-22-2021 05:55 AM
I'm curious about your problem. Could you save the file as an older version-- 2017 or older?
02-22-2021 06:13 AM
Well, the DVR solution is doing exactly the same as the Image2array solution (show data in an indicator) but has to do more (wrapping the data in a DVR).
So as the DVR solution has to do more, why do you expect the DVR solution to be faster?
I'd never use a DVR unless I have to. And that's almost never.
I'd for sure not use a DRV because they ' should be faster' (because they are more complex?).
DVRs only help to be faster if they are used to prevent copies. But if you can prevent copies in another way, that will be (marginally) faster, as it won't have the overhead of the DVR. The code usually is easier to read, maintain and debug without DVRs.
As mentioned, initializing the DVR probably forces a copy, that is not needed without the DVR. Without the DVR, the compiler can use dataflow to see there's no need for a copy. Array data is not copied until needed. And even if it's needed, it's data pointer is often wrapped in a subarray structure.
02-22-2021 06:43 AM
Hi,
Here is the file in the LV version 2013.
02-22-2021 07:34 AM
Disclaimer (same as wiebe@CARYA😞 I've no idea if this is what is happening, and no prove of it. It would be a plausible explanation.
The speed difference between the VIs itself is not much.
The difference comes from an additional copy of the data in the EDVR case. In addition there is the Delete Value Reference, the error case structure, Merge Errors and you do not write the data back to the image.
The optimizer might switch to the user interface thread because you display the data inside the case structure.
The might be situations where ImageToArray is faster (you created an example for this).
I tried to create an example with simple image processing (increment each pixel) which shows similar execution times.
02-22-2021 09:42 AM
Hi wiebe@CARYA,
Thank you again for your message and your explanations.
I just slightly modify the vi to add a processing step (increment+1 every pixel value) and the results observed seems to explain why it slower.
Indeed in the case ImagetoEDVR, the pixels in the image continuously increase as a function of time (it's look like the structure 'in place element structure' act as a while loop). Consequently the time to process an image using imagetoEDVR is longer than imagetoarray because every pixel is process many many times.
So my new question is: how to force the 'in place element structure' to run only once.
Thank you in advance for your help
02-22-2021 09:58 AM
Hi Martin_Henz,
Sorry for my late reply and thank you for your comment.
I tested your vi and I am aggree that the processing speed of imagetoarray is the same as imagetoEDVR in your vi.
However, I still have a trouble with the in place element structure which looks like to work as a while loop.
Did you have any idea to stop the 'in place element structures' in order to process only once at each while loop run?
Thank again for your kind help