"IMAQ Write JPEG File" errors with large 8 bit pictures (14000x12000)

[DOC-doc]

Hi

I have to save this big (14000x12000) 8 bit  image in a jpeg file.

If I run the vi once, it works fine.

If I run it twice on the same image, it says "Error -1074396159 .... not enough memory for requested operation".

To overcome this problem, i set the call setup to this vi to "reload for each call", in order to force freeing ressources.

Further, if I make a small exe file with just the VI to save the jpeg image, then there is no problem, I can call it many times in a row without any error..... any clue from anyone ????

[AdamB]

Hi DOC-doc,

Have you got your code you can paste up on here?

8-bit at 12K by 14K works out to be about 168Mb of data.

What kind of memory do you have on your computer?  Post the small vi and I'll have a look and see if there is anything I can see.

Thanx

AdamB

[DOC-doc]

yes but there are several copies everywhre.... it works perfectly if I run it by itself I mean in a standalone application.

It is running only once if I run it in the main application that needs 750+MB

[DOC-doc]

yes but there are several copies everywhre.... it works perfectly if I run it by itself I mean in a standalone application.

It is running only once if I run it in the main application that needs 750+MB

[AdamB]

You haven't posted the sub VI "03-MV-IMAQ Write JPEG file.vi"

(just out of interest, what sets the "subVI mode"). This mode seems to depict when to dispose of the image.

Another question, where does the error originate from? (If you highlight execution what function creates the error?)

Thanx

AdamB

Message Edited by AdamB on 11-02-2006 11:03 AM

[DOC-doc]

I don't understand your question "what sets the "subvi mode".

The error always appears at the second call of the "03-MV-IMAQ Write JPEG File" call with the big picture. The 1st call for the small one always run (I can chek it saves a file and check the time it saved it)

[DOC-doc]

Again, the vi "Join image" can be run 20 times if it is a standalone application without any problem.

If I call "Join image" from my main application, which uses 500 MB of ram before the first run : it works fine.

At the end of the first run, the RAM use goes up to 750 MB, because I have a big image in memory.

When I call "Join image" for the second time, with 750 MB of RAM used, then I can run the "03-MV-IMAQ Write JPEG File" for the small picture but not for the big picture where the error "Error -1074396159 .... not enough memory for requested operation", reported earlier comes in. The error takes place in the second call of the "03-MV-IMAQ Write JPEG File" which is a renamed version of the original "IMAQ Write JPEG File.vi"

.

[AdamB]

I think that's your problem then.

windows will only ever let a single application use 1Gb of memory at any one time.

Therefore, if your program uses 750Mb+ (in standalone exe) and is trying to run inside of LabVIEW (which also uses about 250+Mb of memory) this will go over the quota for any one application.  In this case it's not just the fact that you aren't getting rid of the memory, it's a case of actually asking for too much memory.

Windows will not let you handle that much memory.  I would say that this kind of image manipulation is not possible inside of your application.

I did notice a lot of coerce dots in your program and these will only make matter worse.

I would suggest that you try and optimise the memory that is used inside of your program as much as possible. 

The following list provides some guidelines to consider when creating a VI. Though they are by no means the only concepts to consider, they do represent a starting point for optimizing memory use.

• Whenever practical, break subvi's out into the main vi.  LabVIE will have to duplicate memory to pass the data to a subvi. you don't want this.
  
• Limit the use of global and local variables. Using global and local variables causes LabVIEW to generate copies of the data in the variables.
  
• Display large arrays and strings on open front panels only when necessary. Indicators on the front panel retain a copy of the data which they display.
  
• Property Nodes cause the front panel of a subVI to remain in memory, which increases memory use. Therefore, if the front panel of a subVI is not displayed, do not leave unused Property Nodes on the subVI.
  
• Use consistent data types for arrays and watch for coercion dots (grey in LV8.0 and earlier.. red in 8.20) when passing data to subVIs and functions. When LabVIEW changes data types, the output is a new buffer.
  
• When designing the block diagram, be aware of any areas where the size of an input is different from the size of an output. For example, frequently increasing the size of an array or string generates copies of data which increases the number of memory allocations LabVIEW must perform. This can fragment memory. (this also applies to images)  try allocating the image size immediatelly and then just place the images ontop of the allocated image.

These are just some of the suggetions I would give to help you out.

AdamB

[DOC-doc]

Hi AdamB,

There was a minor missunderstanding : it is when I call the "join image vi" from the main application that the program fails.

As of image duplication, I can tell you it is reduced to the strict minumum. I have the feeling that the image is duplicated twice in the vi "IMAQ Writw JPEG File"...

So you say that 1 program cannot be allocated more than 1 GB at a time... is there any way to break this limit ?