Processing repeated images and memory recovery by GC
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:
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.
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
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:
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:
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.
[[alternative HTML version deleted]]
______________________________________________ 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.
[[alternative HTML version deleted]]
______________________________________________ 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.
______________________________________________ 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.