I have found that GIMP does not always remove closed images from its working memory even if they are not shown.
As you can see here, I have 4 open images, but when I export all of them I actually get 5 JPGs. The extra one was from some earlier image I played with, exported, and saved the XCF just in case I needed it.
It is not my code Since that is more or less directly out of the playbook (see below). Now this is an issue with GIMP, and it explains why I have seen GIMP hugging memory like creasy. You may never see this issue since many people open GIMP work on one to a handful of images and then closes the program. I on the other hand can have GIMP open for weeks so it is ready to run when I need something. I do the same with Word and other programs like the Browser.
Any input is appreciated…
image_list = gimp.image_list()
image_ptr = len(image_list)
for image in image_list:
fullfilepath = os.path.join(output_folder, filename)
fullfilepath = clean_string(fullfilepath)
if (overwrite_index == 1):
fullfilepath = get_clean_filename(fullfilepath)
if (fullfilepath != ""):
raw_filename = filename.encode('utf-8')
pdb.gimp_file_save(image, image.active_layer, fullfilepath, raw_filename)
pdb.gimp_image_clean_all(image)
Is there any reason in particular that you can’t wait the few seconds that it takes for GIMP to be ready after launch? Sure, sometimes it may take as long as ninety seconds for all the fonts and brushes and stuff to load, but it shouldn’t be a problem unless you’re running GIMP on a Windows 95 computer. I do a lot of image processing with GIMP, and I may use as many as six different applications, GIMP being only one of them, to arrive at the finished product, and I always shut GIMP down after I finish an editing session; I’ve never had to worry about images still being in memory. Plus, in GIMP’s settings, I greatly increase GIMP’s memory usage, specifying at least twenty undo levels, ETC. I’ve been using GIMP since around 2010.
I hear you so you are telling me that we should not fix the issue with GIMP, just close it after a session. To me that does not make sense at all. That would be like we had to turn off the computer after we have used it.
I too have been using GIMP for years, even before 2 was released) , but that should not stop us from fixing this issue!
I appreciate your feedback
No, if there is a bug it should indeed be fixed. Some bugs might not be fixed in the 2.10 branch, but only for gimp 3, at this point, but you have supplied code and steps to reproduce the problem, which helps a lot.
Closing GIMP is not at all like shutting down the computer. I note also that you’ve failed to explain why you feel that you mustn’t do as suggested, so I don’t think I can be of any further assistance in this matter. Good luck.
I understand that 2.10 is not really supported, however if this is a bug that is on the design end and not the code, then it should be looked into since it could be move forward to 3
I live and work in an industry where speedy response is important, so it is not just a question of startup time which can be much longer than a few second if you have large amount of fonts, brushes, and automation Plug-Ins to load at startup.
Just to be fair I have several computers and one has been running for months with PhotoShop open. Why do I not then just use PhotoShop? The reason is in the large amount of automation done with my Plug-Ins for GIMP.
One final note: Open GIMP, edit, close image, close GIMP after session just because GIMP has a bug - that is a hack to an issue!
If you use/write that many plugins your problem may be an image left around by a plugin. It is not uncommon for plugins to work on a duplicate image. The plugin code could then forget to delete the work image, or crash before it gets around to this. You can check the existing images (even those without a display window) in the Images dialog. And according to the doc:
if the image has been already loaded without window by a primitive procedure command (such as gimp-image-new, file-png-load, etc.), it can not be unloaded even if its windows are closed to the last.
… if you can delete the image in that window, it was created by a script, so it’s the script responsibility to clean up.
Most of the Plug-Ins are Plug-Ins that I have are written or have fixed up with things like “try | except Exception as e:” that most Plug-Is are missing.
What happen to error handling?
I am trying to (a) get a solid reproduce with step by step description of what was done to gt it to hang and ((b) some debug logging
Good news!
We have finally nailed down that there are “ghost images” floating around in GIMP that the user from the standard user interface can’t get to, and it is eating up memory.
Those “ghost images” are not generated by GIMP itself. From a lot of testing, it looks like those “ghost images” are produced by Plug-In or Filters. This happens when they are creating an image that is invisible to the user to do their magic on, but the Plug-In or Filter does not get to delete those images, thereby freeing up the memory.
We have found a way to detect them, and even better, remove them, thereby free the memory.
