Skip to content

Processing repeated images and memory recovery by GC

7 messages · Steve Rowley, Bert Gunter, Jeff Newmiller +3 more

Steve Rowley
# 
I have a question about repeated image processing and recovering memory via
garbage collection.

A couple images are displayed simultaneously for analysis, using
split.screen().  I'm looping over a large collection of images, using
jpeg/readJPEG(), png/readPNG(), and caTools/read.gif() to load an image
into memory from a file.  Then I use erase.screen() to erase the previous
image, use plot() to set up a plotting area, and display the image with
rasterImage().  Then the user elects some processing, and we move on to the
next image(s).

I'm very carefully not holding references to any of the previous images.
GC is indeed happening, but memory quickly fills up.  It certainly *looks*
as though the image memory is not being released: printing out trace info
using mem_used()[[1]] says memory use increases with each image, by about
the image size.  Forcing periodic GC's, measuring memory used before and
after, shows that no memory is recovered.

Some questions:

(1) Is it known that processing images in this way will lead to allocating
memory that is not recovered by GC?

(2) Are there any tools you'd recommend to see exactly *what* is filling up
memory, just in case it's not previous images, but some other problem?

This is R 4.4.2 (for now).  Running MacOS on an ARM processor.
___________
Steve Rowley <sgr at alum.mit.edu> Zoom: 839 529 4589
<https://us04web.zoom.us/j/8395294589?pwd=dlQ4MUFHK1NFOCtoZFpUNFRtZ2lSQT09>
It is very dark & after 2000.  If you continue, you are likely to be eaten
by a bleen.
Bert Gunter
# 
As I understand it and you, this kind of specialized technical question is
usually not a good fit to this list about general issues in R programming,
though someone may respond here of course. Alternatively, you may find it
useful to post on one (or some?) of the R SIGS (Special Interest Groups)
listed at https://www.r-project.org/mail.html  to see if one of them might
be a better fit. (Though some listed there may be inactive). Note also that
some R packages dealing with image processing have their own dedicated
lists.

Happy hunting.

Cheers,
Bert

On Thu, Sep 4, 2025 at 2:17?PM Steve Rowley via R-help <r-help at r-project.org>
wrote:

  
  


  


      

    

    

      
      

        


  

        

      Jeff Newmiller
    

    

      
      #
    

  


  

      
To expand on Bert's response, I see two directions for this to go: either OP is unaware of some R object references that are in fact still being referenced somewhere, or the specialized contributed packages being used have memory leaks (not unheard of... C can require considerable effort to avoid failing to release resources). (It is also possible but maybe not likely that in the right forum there will be someone who immediately recognizes this issue... but probably not what you should be betting on.)

Both of these possibilities will likely require detailed knowledge (likely maintainer-level, or at least someone with experience debugging memory leaks) of the specific packages involved. In order for such a person to dig into this they will need a reproducible (hopefully short and with small data file requirements) example that they can run over and over as they troubleshoot. 

I recommend that you try to start building this example sooner rather than later ... maybe include a link to it or paste it into your next request (email to maintainer? a last gasp post here?) to give whoever has that very narrow set of abilities an incentive to look at it. Not having such an example can make it easier to just skip your request as being too vague and time-consuming to investigate.

Note that sending your email in plain text (a setting in your email software) rather than the HTML that this was sent in will help avoid us receiving frustrating glitches in your sample code.

Google "cran reprex" and read the vignette for further help on making an example.

        
On September 4, 2025 3:01:08 PM PDT, Bert Gunter <bgunter.4567 at gmail.com> wrote:

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Jan van der Laan
    

    

      
      #
    

  


  

      
On 05-09-2025 01:24, Jeff Newmiller via R-help wrote:

        

            

      
      
      
    

        
And often writing such a minimal example helps in pinpointing the issue 
quite often leading to a solution.

You could start by stripping down your current code. Remove all plotting 
commands: does the problem still exist then it is probably in reading or 
cleaning up the image rasters. Is it just for png's or for all image 
formats? Etc. Another way is 'bottom up': write a script that reads 
images and does nothing with them; does the problem happen there? Then 
start adding stuff until the issue occurs again.

Could it be that you keep opening up new graphics devices without 
closing them? Also split.screen creates a kind of devices that should be 
closed.

HTHT,
Jan

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Ivan Krylov
    

    

      
      #
    

  


  

      
? Thu, 4 Sep 2025 17:16:15 -0400
Steve Rowley via R-help <r-help at r-project.org> ?????:

            

      
      
      
    

        
erase.screen() works by drawing a background-coloured rectangle over
the plot, so the previous images remain in the display list despite
being completely over-painted:

dev.new(bg='white')
split.screen(c(1,2))
# [1] 1 2
recordPlot() |> object.size()
# 57584 bytes
for (i in 1:2) {
 screen(i, FALSE)
 plot(0:1, 0:1, type = 'n')
 rasterImage(as.raster(matrix(runif(2^20), 2^10)), 0, 0, 1, 1)
}
recordPlot() |> object.size() |> print(units = 'Mb')
# 16.2 Mb
for (i in 1:2) {
 erase.screen(i)
 screen(i, FALSE)
 plot(0:1, 0:1, type = 'n')
 rasterImage(as.raster(matrix(runif(2^20), 2^10)), 0, 0, 1, 1)
}
recordPlot() |> object.size() |> print(units = 'Mb')
# 32.3 Mb

How much slower would it be to maintain your own "display list" of
images and redraw the plot from scratch (e.g. using layout()) every
time you change it?

  
    

      
      
    

  


  


      

    

    
2 days later

    

      
      

        


  

        

      Steve Rowley
    

    

      
      #
    

  


  

      
On Fri, Sep 5, 2025 at 5:52?AM Ivan Krylov <ikrylov at disroot.org> wrote:

        

            

      
      
      
    

        
Thank you very much!

This was indeed the issue.  Like most bugs, it is in retrospect obvious,
but as Kierkegaard (approximately) said, we don't live in retrospect. :-)

I used dev.control(displaylist = "inhibit") on the screens created by
split.screen().  This leads to some redisplay problems if the window is
resized, but other than that everything seems to work and I'm happy to live
with that little problem.  (Possibly MacOS is doing some redisplay work
here in the background.)

Reporting memory size after each iteration shows it operates in
approximately constant memory now.  ("Approximately" means that it does
expand a bit for larger images, but GC works to retrieve the memory, so
that's ok.)

Thanks to all who offered an opinion.  (Or even thought about it, that sort
of kindness counts too!).

And especial thanks to Ivan for nailing the problem exactly, just from my
vague description.  I'm really, really impressed with your debugging
prowess.
___________
Steve Rowley <sgr at alum.mit.edu> Zoom: 839 529 4589
<https://us04web.zoom.us/j/8395294589?pwd=dlQ4MUFHK1NFOCtoZFpUNFRtZ2lSQT09>
It is very dark & after 2000.  If you continue, you are likely to be eaten
by a bleen.

  
  


  


      

    

    
7 days later

    

      
      

        


  

        

      @vi@e@gross m@iii@g oii gm@ii@com
    

    

      
      #
    

  


  

      
Jan raises an interesting point. In R, the ggplot2 object can incorporate some of the data you are asking it to plot. So code like:

P <- ggplot2(...) + ... 

The above will save a copy or perhaps "pointer" to the data that remains in memory if not removed even if the original is removed. And thee can be a hidden gotcha as lines of code run in the R interpreter are saved in .Last.value, albeit that is overwritten after each line of code.



-----Original Message-----
From: R-help <r-help-bounces at r-project.org> On Behalf Of Jan van der Laan
Sent: Friday, September 5, 2025 4:21 AM
To: r-help at r-project.org
Subject: Re: [R] Processing repeated images and memory recovery by GC

        
On 05-09-2025 01:24, Jeff Newmiller via R-help wrote:

        

            

      
      
      
    

        
And often writing such a minimal example helps in pinpointing the issue 
quite often leading to a solution.

You could start by stripping down your current code. Remove all plotting 
commands: does the problem still exist then it is probably in reading or 
cleaning up the image rasters. Is it just for png's or for all image 
formats? Etc. Another way is 'bottom up': write a script that reads 
images and does nothing with them; does the problem happen there? Then 
start adding stuff until the issue occurs again.

Could it be that you keep opening up new graphics devices without 
closing them? Also split.screen creates a kind of devices that should be 
closed.

HTHT,
Jan

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        
______________________________________________
R-help at r-project.org mailing list -- To UNSUBSCRIBE and more, see
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide https://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.