Jump to content

Out of memory error when using Picture Control


Recommended Posts

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?

Link to comment

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 by A Scottish moose
Link to comment

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. 

Link to comment

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.

  • Like 1
Link to comment
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.

Link to comment
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. 

Link to comment

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.

 

  • Like 1
Link to comment

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!

Capture.PNG

Edited by Neil Pate
Link to comment
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!

Capture.PNG

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 by rolfk
  • Like 1
Link to comment

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!

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.