Thanks @rich2005, this will be a great help!
EDIT: I’ve tried a few from the above scripts and pligins, and all work wonderfully. None of the last ones you mention though, I didn’t try them.
Just out of curiosity, is there any way I can avoid this? Usually I just click ‘Page 1’ and then import, but to have it not appear at all, and still open as expected would be much better. It happens in regular Gimp too.
Thanks in advance.
Those are layers in your tiff file, what if at some point you need layers?
I see. So how would they have been created? I always merge down layers before exporting.
Whenever I open a tiff that I have worked on, I get this box appear. When I click ‘select all’, I get a blank canvas and a number of errors show, but selecting ‘Page 1’ gives me the image I last worked on, usually with no error box.
So I think I’m not understanding something…
Wait, you are using TIFF as an intermediate file format while working in GIMP? You should really consider using XCF for that.
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!
1 Like
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!
2 Likes
[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.
2 Likes
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!
1 Like
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.
1 Like
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.