GNOME Bugzilla – Bug 667002
Opening large animated GIF locks up GIMP.
Last modified: 2018-05-24 13:07:48 UTC
Created attachment 204327 [details] large animated gif The GIF was converted from an AVI file using VituralDub. It's size 3.6 meg (attached as zip). GIMP valiantly tries to open it but eventually dies.
I misspelled: VirtualDub
Even Irfanview takes quite a moment to load this up. It tells me: 1378 images Gimp successfully (initial-)loads all 1378 frames (counts them up in the status bar), but then takes a lot of time (maybe to create the layers?). My task manager tells me gimp-1.8.exe has read 6 GB now … The status bar changed and the gif image is displayed, as well as the layers view filled with layers. So the gif was indeed successfully loaded. Gimp hangs a bit now though … Unusable until now. I/O read bytes at 7 GB now. 8 GB now. I can still bring Gimp to the back and front, it displays the image and UI. Cursor displays busy though. Moving the mouse a bit, gimp went to the background itself the second time now. Clicking into gimp, it greys out, indicating a frozen application. However, it does still respond (at times), resulting in the grey-out going away, UI displaying normally again, and windows not saying it is frozen. 10 GB read now, says task manager. 5.6 GB written. Maybe some kind of loop? Or just inefficient gif reading? Temp-outputting? I am now killing Gimp. Win7 x64, 8 Gigs of Ram here. Starting up gimp to check the I/O byte numbers of a normal startup (warm startup now): 50 MB read, 1 MB written.
@Steve: When does your Gimp die? Do you get as far as me? On which step does yours die? 1. loading the frames 2. opening the loaded frames 3. loading after listing the listed layers and displaying the original image (layer one) successfully
(In reply to comment #3) It loads frame 1378 and then stops responding. Process explorer shows it is still active but the GUI is unresponsive.
And then? You kill it after some time? How does it die? And after what magnitude of timespan?
...Then I kill it because it's boring watching a program do nothing. I'd say 3 to 5 minutes. There is a bug. It's repeatable. I'm sure it fails differently on different machines. What you're asking is like, "After the brakes failed, did you hit a light pole or a stop sign?" It doesn't matter, it failed.
No, that’s not it. Rather: “Did you push the brakes until you came to a stand-still, or did you instead abandon your vehicle?” As I wrote, waiting long enough does seem to load the frames as layers successfully. And maybe if you wait long enough (I stopped then as well, killed the process) it will finish whatever it is doing afterwards and become usable. Whatever the case, as it currently is it’s not usable for a large gif / gif with large number of frames indeed. Some profiling is necessary to check where the performance bottleneck is and how one can improve it.
Thank you, Steve, for reporting this and sorry for the long time it couldn't get eventually solved, yet. I can confirm the long loading time in the native Mac OS X build of GIMP 2.8.2, too. But GIMP doesn't get frozen, it shows an animated progress bar at the bottom of the Open File dialog and reports the frames loaded. Still I'm a bit wondering what you're trying to achieve with loading a GIF with such a huge amount of frames into GIMP. Is your use case still covered by the product vision at http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision? Your answer within the next 6 weeks is appreciated. Thank you in advance.
>> Still I'm a bit wondering what you're trying to achieve with loading a GIF I was opening the GIF to edit it. >> Is your use case still covered by the product vision... I have no idea what you mean by your question or what that link is supposed to provide.
Thanks, Steve, for your quick reply. Testing with various other programs and operating systems showed that it's mainly a problem of the video itself. It contains many frames and needs big amounts of RAM. The only application I could visit it with *almost* no falters was a web browser. Reducing its size for instance by cutting it before loading it into GIMP could alleviate the problem. I agree with kissaki0, that the handling of big image files needs to be improved, but currently this particular bug is of lower priority because of the following reasons. The document 'product vision' describes what GIMP is for and what it is not for. It's like 'Excel is a spreadsheet application, not a database management system'. GIMP's main purposes are manipulating photos, producing icons, graphical elements of web pages and art for user interface elements, not video editing. You can edit small animations with GIMP, but for more complex tasks it is the wrong tool. I'm sorry to say that, but a dedicated video editing software will meet your needs better.
You don't need to apologize to me. If a "dedicated video editing" program crashed when opening a file, it would also be a bug. A bug is a bug, trying to talk it away isn't doing anyone any favors. If Gimp doesn't handle large gifs, it shouldn't even try. It should post a message saying, "I don't do Gifs larger than X Frames". If I am the only person on the planet who ran into this problem, it is very low priority.
Hi everyone, I tested this file with GIMP master. Well the good news is that it loads fine. I can see a clear loading progress, and after maybe about a minute or 2, it loads all 1378 layers (1356x764, so I count that the whole decompressed image would be nearly 6GB) and GIMP UI was responsive. The bad news is that it takes so much memory that GIMP is slow as hell if you touch anything in the image. It was taking about 52% of my 8GB or memory + GEGL was swapping 4.7G. So obviously when I tried to paint (for the sake of trying) and to change layer visibility, GIMP just hanged (then after maybe 5 minutes, I killed it because it felt hopeless). I feel we are just reaching the limits of what GIMP can do when swapping on a computer with not-enough memory. Technically GIMP does not crash, and theoretically I assume it would succeed any action if waiting a long time, but that's not really usable. I think it would be worth trying on a computer with a lot of RAM to verify it is usable.
For info, I tried again, closing first all programs which takes a lot of memory (like my browser!) and giving as much as possible to GIMP in the preferences so that I got no swapping. That made the image editing much more bearable. Of course on some operations, I had to wait minutes. This is not an ideal case at all. But that's possible.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/390.