Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

IMAQ Read File, code : -1074396159 max file size smaller in run time mode

HI,

I want to load large images using LavbVIEW 8.5 and NIVision 8.6.
My program is basically very simple: 'IMAQ create' (grayscale (I16) followed by  'IMAQ Read File' and 'IMAQ Dispose'.
When I run this program in development mode it is possible to load 16 bit tiff files of 20kx20k pixels (780MB).
When I run the executable (run time) it is only possible to load 13kx13k images (330MB)

Development mode:

load program: used memory 50MB; load image (20kx20k =>780MB): used memory 1230MB; Dispose image still used a memory space of 445MB. NO Error.
load program: used memory 50MB; load image (13kx13k =>330MB): used memory 550MB; Dispose image still used a memory space of 220MB. NO Error.

Run time (.exe) largest tested image what can be loaded: 13kx13k (330MB).

load program: used memory 25MB; load image (13kx13k =>330MB): used memory 522MB; Dispose image still used a memory space of 190MB. NO Error.
Loading larger images results in an error: IMAQ Read File, Not enough memory for requested operation.
code : -1074396159

WHY is it not possible to load a large image in run time mode??

How can I resolve this problem?

Thanks.

0 Kudos
Message 1 of 5
(4,905 Views)
You are probably running into limitations of virtually contiguous memory space in a 32-bit process. I would suggest building a 64-bit app instead and you should have no problems going up to 2GB images.
0 Kudos
Message 2 of 5
(4,894 Views)
The difference between a built app and the editor is that I think older versions of LabVIEW did not set the Large Memory Aware bit in built executables and thus was limited to a total of 2GB memory space per process rather than 3GB.
0 Kudos
Message 3 of 5
(4,893 Views)

I see extra info is necesarry. 

The OS of my pc (laptop) windows7 64 bit version, LabVIEW 8.5 and NIVision are installed in 'programs(x86)', Physical memory is 8GB.

I loaded several standard programs and Fiji (ImageJ). With Fiji I've loaded 3 images 400MB + 300MB + 1.45GB (total 2.15GB ).

total used memory 5.25GB.

When I load the LabVIEW ReadFile program in development mode and load 20kx20k image total used memory is getting to 7.3GB NO Error.

When I load the runtime program and load the 13kx13k image memory usage up to 5.79GB. NO Error.

Well it is still the same problem.

I've increased the used memory by loading an extra image of 1.5GB (using Fiji) so total used memory including LV runtime program is 7.4GB  !!

loading the image 13kx13k the maximum used memory is 7.75GB No problem, NO Error. But loading a larger image (15kx15k) causes an error.

 

I guess that LabVIEW itself is limitating the size of loadable images. 

So it would be nice when somenbody from NI would respond.

 

Jos

 

0 Kudos
Message 4 of 5
(4,876 Views)

The amount of physical memory in your system is not a factor in this error, since the system will just use disk swapping if needed. The image buffers are all virtual memory and don't need to be page-locked for use in this case. Please keep in mind that LV 8.5 is a 32-bit process, regardless of whether you are running on a 64-bit OS.

 

Please see this KB: http://digital.ni.com/public.nsf/allkb/AC9AD7E5FD3769C086256B41007685FA

 

While they say LV 8.5 is " large address aware", I think this only applies to the developer environment. I believe built applications did not have that flag set (this was a bug that was corrected in later versions, I believe). This would be why you see differing amounts in built apps versus development.

 

The problem also isn't the total available memory versus how much you are allocating, but rather how much *contiguous* virtual memory space there is. The problem is that a 32-bit address space starts to look like swiss cheese once a process has run for a while and loaded various DLLs and such all over the space. You can use a tool like VMMap (http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx) to explore the memory space on the LV process and see what the biggest block available is. It is generally rare to find many blocks larger than a few hundred MB free in a 32-bit process, and your huge images will require them.

 

Really your best solution is to use a 64-bit version of LabVIEW. Then this problem goes away and you can allocate any number of images of any size up to the internal constraints (roughly 2GB each).

0 Kudos
Message 5 of 5
(4,856 Views)