LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Draw Flattened Pixmap Oddity/Bug? Picture Control Gurus Needed

Thanks Phillip for your reply. The problem is I only want to load in a portion of the array from the binary file to conserve memory since I'm using the PDA. There will be larger image(s) that I want to load so partial images from the file instead of using the array subset will be needed. Any other thoughts?
0 Kudos
Message 11 of 21
(1,946 Views)
Hi rberger,

Hmmm, well if you simply can't afford loading the complete bitmap first and then perform the subset function there's one other possible solution - although very speculative and most likely not very efficient - that will only load the necessary amount of subset data. The method is to load one line at a time from the bitmap file. By calculating where each of YOUR lines begin in the bitmap file and knowing the size of each of YOUR lines, you can simply read one line at a time from the file and then build the 2D array from all the separate lines.

It would be interesting if you could benchmark this solution compared to reading the complete file.

Have fun!
- Philip Courtois, Thinkbot Solutions

Thinkbot Solutions
0 Kudos
Message 12 of 21
(1,939 Views)
Hi Phillip:

I thought about what you said. I still run across the limitation outlined in reply 8. Please download the VI in reply 8 and play around with it and you'll see what I mean. After you play around with the VI, can you tell me if this is a Windows or LabVIEW limitation? If its a LabVIEW limitation, hopefully LV8.0 will give more control on binary file loading.
0 Kudos
Message 13 of 21
(1,930 Views)
Hi rberger,

My example only reads exactly the data/subset that you request. It reads line by line of the subset and then builds these lines into a 2D-array. Therefore you don't have to be concerned about reading the complete file into memory. Notice that the lines in the subset doesn't "wrap" to the next line, as they did in your original example. Just to be really nice, I have also attached the actual VI (LoadSubsetOnly.vi).



Let me know what you think.

Have fun!

Message Edited by Philip C. on 06-07-2005 11:18 PM

- Philip Courtois, Thinkbot Solutions

Thinkbot Solutions
Download All
Message 14 of 21
(1,921 Views)
Hi Phillip:

I slightly modified your LoadSubset.vi to use the replace array element to avoid on-the-fly memory allocation.

Your VI works pretty good on a desktop computer.

However, I'm saddened to report its insufficient when running under LV7.1 PocketPC2003 edition. Even in the documentation NI states to avoid a lot of loop iterations when writing programs for the PDA.

In my case, my loop counter is set to 261 iterations and the IPAQ H5555 with 624 MHz processor takes more than 6 seconds to go through the loop read.

Thats too bad.

If there was one call to the read.vi in order to control how to load a 2D array, I would have a streamlined app. But for now, I'll just have to load my whole image into the application.

Hopefully, in LV8.0 there will be more control when loading 2D binary arrays.
Message 15 of 21
(1,896 Views)


@rberger wrote:
Hi Phillip:

I slightly modified your LoadSubset.vi to use the replace array element to avoid on-the-fly memory allocation.

Your VI works pretty good on a desktop computer.

However, I'm saddened to report its insufficient when running under LV7.1 PocketPC2003 edition. Even in the documentation NI states to avoid a lot of loop iterations when writing programs for the PDA.

In my case, my loop counter is set to 261 iterations and the IPAQ H5555 with 624 MHz processor takes more than 6 seconds to go through the loop read.

Thats too bad.

If there was one call to the read.vi in order to control how to load a 2D array, I would have a streamlined app. But for now, I'll just have to load my whole image into the application.

Hopefully, in LV8.0 there will be more control when loading 2D binary arrays.




The way the File IO functions work is really not a LabVIEW problem. They are basically stream based and that means you define a starting point into the stream (file offset) and a lenght (bytes to read). Every file-IO API out there works this way and there is no OS I\m aware off, which has file-IO functions like what you would like to have. Reading an image the way you want to do it without some work in the application is not a task file IO functions are meant for. For this you would use specific image load functions in libraries like from Accusoft or Leadtools.

That you are running on PocketPC which seems to have a problem with loop iteration is unfortunate. I'm not sure what the problems are with this but you can hope that LabVIEW 8.0 for PocketPC will improve on this aspect.

Since LabVIEW seems to have a problem with loops in a diagram on PocketPC an alternate approach (more memory intense but maybe faster) would be to read in the entire image as a 2D array and crop it with the Array Subset function. If this is still not satisfactory, there is only one other way writing external code but I'm not sure LabVIEW PDA supports the Call Library Node.

Rolf Kalbermatter
Rolf Kalbermatter
My Blog
Message 16 of 21
(1,888 Views)
Hi rberger,

Good idea to create an array before the loop and then use the Replace Subset function, to avoid dynamic memory allocation. I'm sorry to hear that it is now the speed that is suffering. What Rolf is explaining is correct though, so you have to choose whether memory efficiency or speed is the most important to you.

I'm not the one to ask if the last option, to call external code, will be more efficient for you, but I can tell you that is definitely IS possible to call a DLL from LabVIEW on a PDA that runs Pocket PC. Here's a link to an example program:

Calling External Code in LabVIEW PDA for Pocket PC - Battery Information Example

Have fun!
- Philip Courtois, Thinkbot Solutions

Thinkbot Solutions
0 Kudos
Message 17 of 21
(1,871 Views)
Hi guys:

Thanks for all your input. But another reason not to load the whole image into memory is Palm developers are limited to 64K of memory for each VI developed. Therefore, more control of 2D binary arrays for the read.vi call will also solve this issue because Palm yields out of memory error if I load the whole image into memory. So speed and memory issues could be solved.

I'll check into the call library function for PocketPC. I'm not sure if Palm supports the CLF.
0 Kudos
Message 18 of 21
(1,862 Views)
I'll try to bring some fresh ideas here. Not that I'm a guru of PDA memory management, but because I expect to bump into the same problem within a few months.
What I understand is that the extraction of the map chunk in the Y direction is not a big issue : you can read the map file from line i to line i+480. The problem is the width. What I would do is to slice the original map into narrow bands (how narrow is an optimization problem), creating several files, then read as many required files (from line i to i+480) to collect the 640 pixel wide band, and rebuild the corresponding picture. That way, the memory would be only slightly overused.

Hope this helps.

And if it works, please post the result, since, as I said above, I'll need it soon 😉 😄
Chilly Charly    (aka CC)

         E-List Master - Kudos glutton - Press the yellow button on the left...
        
0 Kudos
Message 19 of 21
(1,853 Views)
But than you still have the speed limitation issue. For PDA development, putting the Read.VI in a loop as shown in the previous bitmap, yields load times of over 6 seconds for ~260 iterations. This is not good is you want to scroll the map and display only a sub-section of the map to condserve memory. Your method still needs to call the Read.VI multiple times in a loop.
0 Kudos
Message 20 of 21
(1,851 Views)