Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

temporary files #194

Open
PointingerMartin opened this issue May 15, 2019 · 3 comments
Open

temporary files #194

PointingerMartin opened this issue May 15, 2019 · 3 comments
Labels

Comments

@PointingerMartin
Copy link

I'm currently cropping and concerting lots of pix/files (over 20.000) and magick creates lots of big temporary files in a folder in C:\Users\xxx\AppData\Local\Temp (Folder e.g. RtmpopLpl0).
The files are named like magick-1532XblcXdSEDs_Q
As I work on lots of files this takes lot of disk space (over 20 GB) and the process gets slower and slower ...
Is this a known issue and is there a way/setting to avoid this?
Thanks! Martin

@jeroen
Copy link
Member

jeroen commented Jul 20, 2019

It is known that imagemagick starts swapping to disk when it runs out of memory. But afaik it should be cleaning up those files, once your image objects in R have gone out of scope.

You can use gc() in R to force cleaning the temp files after the image objects are no longer in your R session. Can you check if this resolves the issue?

If not, you can also help us by creating an example script that we can use to test this problem.

The version of imagemagick we use on Windows is about two years old (6.9.9-9). @dlemstra do you know if there have been fixes on cleaning temp files?

@dlemstra
Copy link

There have been fixes for cleaning temp files but I don't know for sure when this happened. I guess it did happen in the last 2 years but I am not sure.

lcolladotor added a commit to leekgroup/regionReport that referenced this issue Apr 24, 2020
…ound taken

This is also an opportunity to link to the relevant GitHub issues and Bioc-devel
threads.

Cropping images through `magick::image_trim()` as done by default by
`BiocStyle::html_document()` can fail on Linux. This could be an ImageMagick
issue or an issue about lack of resources. The full investigative report is at
https://stat.ethz.ch/pipermail/bioc-devel/2020-April/016650.html.
This is related to:
yihui/knitr#1785 (comment)
yihui/knitr#1796
Bioconductor/BiocStyle#65 (comment)
ropensci/magick#171
ropensci/magick#194
In regionReport version 1.21.10 I have opted by using `crop = NULL` to disable
cropping of images by `BiocStyle::html_document()` and thus avoid the
issues with `ImageMagick` either coming from `magick`, from the version of
`ImageMagick` installed on the Linux Bioconductor build machine and devel
docker, or from resources in these two Linux environments as described in the
investigative report.
About a month ago I also saw failures on Windows on Bioc 3.10. Whether they were
caused by ggbio 1.35.1 or this issue will remain a mystery. But it's likely
that this `magick::image_trim()` issue also affected the Bioconductor windows
builder.
The related bioc-devel threads are:
https://stat.ethz.ch/pipermail/bioc-devel/2020-April/016538.html
https://stat.ethz.ch/pipermail/bioc-devel/2020-March/016365.html
@gsimchoni
Copy link

I was having the exact same issue, @jeroen's suggestion saved me about a week's CPU time. I'm chunking my thousands of images and at the end of processing each chunk I do gc(). Without it R is really slowing down.

process_images <- function(paths) {
  images_list <- image_read(paths) %>%
    image_crop(geometry=str_c(wi_hi, "x", wi_hi, "+330+80")) %>%
    image_resize(geometry = "299x299")
  for (i in seq_along(paths)) {
    image_write(images_list[i], str_c("out/", paths[i]))
  }
}

# processing 1K images in chunks of 10s
ns <- 100
begins <- (seq.int(ns) - 1) * 10 + 1
ends <- seq.int(ns) * 10 + 0

for (i in seq.int(ns)) {
  cat(begins[i], " ", ends[i], "\n")
  process_images(images_paths[begins[i]:ends[i]])
  gc()
}

Thank you for this amazing package. There should be something in the docs about it though 😲

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants