I have changed the title of the topic since I think the AppImage is now ready for a wider testing.
The link in the “Community-built Software” now points to a package hosted in the pixls.us/files area.
Announcements about new features and bug reports related to the GIMP appimage should be posted in this thread, so that they can easily be tracked.
Next addition to the appimage will be the amazing “liquid rescale” plug-in!
The inclusion of the Liquid Rescale plug-in was straightforward, and it works like a charm!
An updated GIMP AppImage including liquid rescale is ready for download from the “Community Software” page.
Happy editing!
[quote=“Carmelo_DrRaw, post:14, topic:1959”]
I think this an unavoidable price to pay… as far as i understand it, the appimage is a compressed disk image. Each time it is launched the system needs to uncompressed the image and mount it via a loop back device. [/quote]
Yes, but what is slowing down the GIMP start is that GIMP re-scans for plugins each time the location of the plugins changes, which it does every time the AppImage is mounted. Discussing this with GIMP developers right now.
The 8-30 build is failing for me on Debian Jessie.
Seems I have permission denied when trying to mount in /tmp.
The relivant messages seem to be:
(gimp.bin:7788): LibGimpBase-WARNING **: gimp.bin: gimp_wire_read(): error
GIMP-Error: Unable to run plug-in "gmic_film_cluts.gmz"
(/tmp/.mount_G8kn8P/usr/lib/gimp/2.0/plug-ins/gmic_film_cluts.gmz)
Failed to execute child process "/tmp/.mount_G8kn8P/usr/lib/gimp/2.0/plug-ins/gmic_film_cluts.gmz" (Permission denied)
GIMP-Error: Calling error for procedure 'gimp-plugin-help-register':
Procedure 'gimp-plugin-help-register' has been called with value '(null)' for argument 'domain-uri' (#2, type gchararray). This value is out of range.
gimp_display_shell_profile_update
gimp_display_shell_profile_update
(gimp.bin:7788): Gtk-WARNING **: Error loading theme icon 'image-missing' for stock: Unrecognized image file format
gimp_display_shell_profile_update
Otherwise there are a ton of GdkPixBuf errors.
This is “normal”, in the sense that the G’MIC film cuts need to be stored in the plug-ins folder, and then GIMP is trying to interpret the CLUT as a plug-in executable and load it, which obviously fails. But this failure is not fatal.
This is new to me…
Does GIMP actually start, or the appimage stops with a fatal error?
Could you post one example? I do not see any GdkPixbuf errors on my test system.
Thanks!
New GIMP AppImage version available in the community software page.
The main improvement in this version is that the start-up time has been greatly reduced by avoiding the re-scanning of plugins at each execution. Now the AppImage launches practically as fast as the standard GIMP.
If you are interested in the full story behind this improvement, you can read it here and here. A BIG THANK YOU to @probono for discussing the issue with the GIMP developers and getting a fix in a very short time!
The size of the AppImage package has also been reduced from 130MB to 90MB by stripping the debugging symbols from the GIMP code and removing some unnecessary executables.
Thanks @Carmelo_DrRaw,
When I ‘install’ this, will it keep my recently added plugins and settings, or will I gave to reload them afterwards?
Cheers.
It will keep the existing .config/GIMP-AppImage/2.9 folder and only replace the .desktop file.
So all your custom plugins and configurations should be preserved. If it doesn’t, please post a message here.
Maybe it will be a good idea to make a backup copy of .config/GIMP-AppImage/2.9, just in case…
OK thanks. Under what tab should I see the ‘Liquid Rescale’ plugin?
Under the “layers” menu.
“Heal selection” is under “Filters → Enhance”
Thanks again.
I think it’s a bit faster at loading, but not by much. But any gains are very welcome!
What I’d like to see gimp do, if it makes sense to them, is have one menu item that is devoted to plugins. Probably best called ‘Plugins’. From there one could find all post-installed plugins in one place. The way it is at the moment really does seem a mess, they’re all over the place - in no logical order.
For example, I now have plugins in 'FX Foundary, Python fu, script fu and various other places. It takes a while to find them, and to remember where they are. But if they were all in one place…
I know that’s not so much an issue with the appimage itself, but just an idea to make gimp more user friendly.
I’m going to play with this some more, get used to PhF and G’mic, then promote the crap out of it!
Is there any chance we can get the preview window in G’mic to respect the working profile from Gimp as it’s passed through, @patdavid @David_Tschumperle?
I’ve been using prophoto with success using PhF and Gimp, but when passed through to G’mic, the colours in the preview window don’t reflect what’s seen in Gimp. This seems OK, as any changes made in G’mic seem to respect gimps working space when passed back through to Gimp.
The problem is, you can’t be sure when using G’mic for subtle colour changes what the effect will be until you pass it back through to Gimp.
I hope that makes sense.
The first time you run the new appimage, it will be as slow as before. This is because it needs to re-scan all plug-ins to detect of something has changed. But the second time you run the appimage, the plug-in scanning phase should be skipped and it should start much faster…
That would be really helpful!!! Today or tomorrow I’m planning to record a good screencast, with speech and everything, about how to install and use the appimage and how to play with the available plug-ins. I’ll post a message once it will be on youtube.
I can offer some help on that if needed… in fact, it should take into account both the working colorspace and the display profile defined in GIMP preferences.
That would be awesome!
IMO, this is pretty much all that is required for the appimage to go prime-time…
While this may feel like a restriction at first, it is one of the best things of gimp plugins. Because: It means that from a gimp plugin you have access to most of the internals of gimp, even the menu system. That means that the plugins can plug into many of gimps internal functions and even the user interface, which allows for sophisticated plugins with complex functionality. Of course, a bit more organization for the “filter-like” plugins would be good, but please, please, not by imposing restrictions to plugin authors.
In fact, I believe that what @Fotonut is discussing here is only related to the menu layout, not the way plug-ins interact with the rest of the GIMP ecosystem. The plug-in infrastructure of GIMP is really awesome and we should not put restrictions to it, but the place where plug-ins are found in the menus definitely needs some improvements.
One example: the “liquid rescale” plug-in has to be searched for in the “Layers” menu!!! 
Why it is like that I have no idea, but the net result in my opinion is that 90% of the unexperienced users will not discover this awesome tool!
I have plans to patch the plug-ins so that they appear in more intuitive places (maybe just an “Extra plug-ins” sub-menu in the “Filters” menu?), and I might also get help to patch some of them so that they take full advantage of the high bit depth capabilities of GIMP 2.9
As this is work in progress, any suggestion and feedback is highly appreciated.
I don’t think I can do that easily. The G’MIC plug-in relies mainly on the default GimpPreview widget provided by the GIMP plug-in API, and as far as I know, it doesn’t take the color profile into account.
Changing this would imply modifying the code of this preview widget, which is something that should be done probably by the GIMP developers.