-
Notifications
You must be signed in to change notification settings - Fork 37
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
High memory use without release #205
Comments
I wouldn't be surprised by this at all. Generally, the efforts would go to the libjpeg wrapper JuliaImages/Images.jl#960. There's a newly initialized repo https://github.com/stevengj/JpegTurbo.jl @stevengj I'm not sure what's your plan on this, I could join force the development if you think this a good idea. |
FWIW, I just copied the code example from
So this would be a decent workaround for my case if I can figure out where the created/modified dates are buried. |
@johnnychen94, I have no immediate plans to work on JpegTurbo — I mainly put it there as a starting point for later work. I would be happy to transfer it to JuliaIO or JuliaImages if desired, and/or to add collaborators. See also the discussion on discourse. @IanButterworth also has a repo (https://github.com/IanButterworth/ImageIODevelopment.jl) with a similar Clang-generated wrapper for libjpeg, so it would be good to check with him on the best way forward. |
I don't think my dev repo got much past copying a c example. I would've thought the thing to do would be to build on JPEGTurbo.jl (though I'd rename it JPEGFiles.jl perhaps) and move it to JuliaIO when ready. I can't offer much time but happy to review. |
I don't think libjpeg has anything specifically for EXIF data, which is embedded in a single segment of a JPEG file. You can use libjpeg to extract that segment, I think, but you will have to parse the EXIF data yourself (or wrap another library like |
Hi. I encountered this issue also. With a set of images larger than my RAM.
The behavior is as if each loaded image, is kept in RAM and not purged. When passing in keys, I noticed one or two memory releases before the crash, but never when just getting the keys array. using @threads with the for loop makes no difference to the end result. |
I encountered the same exact issue as @kodintent . Base.GC.gc() after every call to |
JpegTurbo https://github.com/JuliaIO/JpegTurbo.jl is available now and bundled together with ImageIO @ashwani-rathee is working on EXIF wrapper for GSoC'22 JuliaImages/Images.jl#1000 |
That is super promising. Thank you. I'll try to see how I can get date and time created from the exif data. |
Yeah, using @ashwani-rathee's code example in that link works flawlessly: using Dates, libexif_jll
include("LibExif.jl")
function readtag(filepath, tag)
ed_ptr = LibExif.exif_data_new_from_file(filepath)
ed = unsafe_load(ed_ptr)
content_ptr = ed.ifd[1]
make_ptr = LibExif.exif_content_get_entry(content_ptr, tag)
str = Vector{Cuchar}(undef, 1024);
LibExif.exif_entry_get_value(make_ptr, str, length(str))
return rstrip(String(str), '\0')
end
file2dt(file) = DateTime(readtag(file, LibExif.EXIF_TAG_DATE_TIME), "yyyy:mm:dd HH:MM:SS") Thank you both (and all the rest working on this)! |
I am trying to write a bulk image renaming function with outputs based on JPEG EXIF entries, but I am running into a memory issue. Here is the crux of the problem:
Here I have just used a loop to repeat function for the MWE, but this also happens when cycling through different images as well. Two problems seem to arise.
First, the image is only 5.7 MiB, after reading it 15 times I would naively expect a memory use of 15*6 = 90 MiB if the memory never cleared, but after the for loop memory usage goes up by over ~2000 MiB.
Second, after several minutes, the memory still doesn't clear. While writing this post, the memory dropped back into the 3100 MiB neighborhood, but that was only after 10-15 minutes of Julia idle time.
Is there a bug here?
My info:
and via
pkg> st
[6218d12a] ImageMagick v1.2.1`.The text was updated successfully, but these errors were encountered: