Out of memory error when using Picture Control

[Neil Pate]

Hi gang,

I have just gotten to the bottom of a rather nasty bug that can cause an out of memory error in LabVIEW.

It seems that under certain conditions that I cannot easily recreate in simple code the Picture To Pixmap primitive will attempt to allocate infinite memory. This manifests as a virtually instantaneous increase in the LabVIEW (or built exe) process up to the 2 GB limit and then the "out of memory" dialogue.

The only input to this function I am using is the picture which I have formed using the standard primitives (so no trickery going on with me attempting to create the picture using string manipulation that I know is possible but have not attempted).

Anybody else seen this?

[A Scottish moose]

I did a project recently that had quite a few large pictures that I convert to Pixmap during initialization.  The images were static throughout the program so there wasn't a lot of access to this function, just at the beginning.  I have not seen this problem with my program.  Do you do this often during your execution perhaps frequency has an impact?  I haven't seen this issue in my case.

Hope that information is helpful, 

Cheers,

Tim

 

Edit: I use 2016 SP1

Edited July 20, 2017 by A Scottish moose

[Neil Pate]

Tim, I am updating the picture control once per second with (potentially) an entirely new picture of 540x960 pixels, although I could easily cause the condition using the same image that has already been successfully displayed.

[Neil Pate]

It is interesting to peek inside the picture control VIs and realise they really just implemented as strings. Also it is useful to know most operations are additive (i.e. makes the string longer, even if you perform the same action like draw the same line twice). The offending VI that was causing me problems is password protected, but it just wraps the DLL call PictToPix so this did not really help me. 

[hooovahh]

Norm posted a while ago on this neat string implementation and how it can be used to do things like translate an image by shifting all of the components of the image as strings by setting new offsets.  Very fascinating and I've used it several times.

Sorry No I haven't seen this memory issue with the picture controls I use.

[Neil Pate]

Nice link. I had seen some of Norm's earlier stuff on the internal implementation.

For now I have worked around my problem by not using that VI, when I get a moment I will investigate my problem further as I would like to understand why it is happening.

[ensegre]

14 hours ago, Neil Pate said:

I am updating the picture control

If relevant, I got the impression that the picture indicator queues its updates. I don't know what is really going under the hood, but presume that whatever it is, it should be happening in the UI thread. In circumstances also not clear to me, I observed that the picture content may lag many seconds behind its updates, with a corresponding growing memory occupancy, and seemingly weird, kept streaming in the IDE even seconds after the containing VI stopped. I suspect that a thread within the UI thread is handling the content queue, and that this might be impeded when intensive UI activity is taking part. Is this your case?

I actually observed this most, while developing an Xcontrol built around a picture indicator. My observation was that invariably after some editing the indicator became incapable of keeping up with the incoming stream, for a given update rate, zoom, UI activity, etc. However, closing and reopening the project restored the pristine digesting speed.

[drjdpowell]

1 hour ago, ensegre said:

I actually observed this most, while developing an Xcontrol built around a picture indicator.

That queueing behavior is a know issue with XControls, which are running even when the VI is stopped, so it may have nothing to do with the picture per se. 

[mje]

I see this issue regularly. I do a lot of work where the "real" UI is just a big picture indicator. One stray coordinate on that blue picture wire will send the Picture to Pixmap VI into a tizzy as that's the first time a flattened 2D map is made of the image data. That VI also has horrible error handling-- which is to say it has none-- it'll just crash LabVIEW with the out of memory error if asked to do something absurd.

Some general guidelines for interfaces I write rely on the Picture to Pixmap VI:

• Constrain dimensions to some reasonable maximum density. I usually do 25 MP or something. Your mileage may change depending on expected system power and color depth.
• Test VIs which create picture data. Those pictures have 32-bit coordinate space (16-bit for each axis) which allows for some very unreasonable map sizes if you're not careful. Any VIs you use to generate picture data should have their edge cases well defined and tested to make sure you're not trying to draw data which may demand terabytes worth of RAM when converted to a map.
• Be aware of vector vs (bit)map data. The native picture controls and indicators can work fine with pure vector data which will be more tolerant of large map spaces but generally perform really poorly if there's any real data density. Rendering maps is far quicker, but demands the use of the offending Picture to Pixmap VI. 
• Cringe with fear that you've been reduced to having to work with the LabVIEW picture API. There's really no good way out if you have to go down this route.

 

[Neil Pate]

I do not do too much vector darwing, but under some (error) circumstances I have realised the coordinates of my drawing instructions could actually get quite big (as in 32k *32k), I just assumed the picture would be constrained in size to the size of my pixmap data which is not huge, but probably given what you say this is actually causing the out of memory error.

Knocked up a test VI to simulate this error condition and I think this is exactly what is happening for me. A line being drawn from (0,0) to (32000, 32000) and then an attempt to get the pixmap will definitely cause problems!

Edited July 24, 2017 by Neil Pate

[Rolf Kalbermatter]

17 hours ago, Neil Pate said:

I do not do too much vector darwing, but under some (error) circumstances I have realised the coordinates of my drawing instructions could actually get quite big (as in 32k *32k), I just assumed the picture would be constrained in size to the size of my pixmap data which is not huge, but probably given what you say this is actually causing the out of memory error.

Knocked up a test VI to simulate this error condition and I think this is exactly what is happening for me. A line being drawn from (0,0) to (32000, 32000) and then an attempt to get the pixmap will definitely cause problems!

A yes! I remember that. The Picture control does maintain a background pixmap that is redrawn on front panel refreshes and pixmap extractions. And it is in fact independent of the size of the actual Picture Control although I think that for refreshes of the image it will clip the drawing operations to the visible area.

But did you notice the rect input to the Picture to Pixmap.vi function? With that you can define a clipping rectangle to which the returned image will be restrained!

From the help to that function:

rect is a cluster that contains coordinates that describe the bounding rectangle of the image you want to convert. The default is to return the entire image. Horizontal coordinates increase to the right, and vertical coordinates increase to the bottom.

Edited July 25, 2017 by rolfk

[Neil Pate]

Rolf, I did see the Rect input, but at the time I did not really consider it useful as I did not know that the problem was related to the image size. Now that you have pointed this out I think that would definitely have helped. I am still getting strange out of memory errors which I have no been able to track down but I strongly suspect are also due to the Picture control functions. Time to use the Rect input I think!