@paperdigits i do apologize about that. I am not entirely familiar with who does what no offense intended. i do wonder though if appimage slows software down
No offense taken, I’m sure.
It is possible to get a funky mix of libraries with the appimage.
The best would be to compare apples with apples… we would need somebody with an Ubuntu system and that could compare the appimage with the gimp version from the gimp-edge PPA.
I have such a system, but in a virtual machine, so it is not ideal to evaluate performances…
By the way, are you saying that processing at 8 or 32 bits integer precision gives the same performance? Could it be that gimp 2.9.5 actually does the computations internally in floating point regardless of the image precision?
P.S: no offenses taken, don’t worry
16s seems definitely too much! Any chance to test gimp 2.9.5 from another package source, like the gimp-edge PPA?
EDIT: just to make sure, are you using thandard or the CCE version?
hi, I’ll try gimp-edge later. I presume I just follow the notes here: https://launchpad.net/~otto-kesselgulasch/+archive/ubuntu/gimp-edge
And re. the version I tested on yesterday, it’s the “standard” one, not CCE.
I keep a standard (no extra installed plugins) Gimp 2.9.5 appimage here:
As of writing, it is from the latest from otto-kesselgulasch ubuntu gimp-edge - commit c175afbc784…
anyone more than welcome to try it… but absolutely no guarantees.
hi @Carmelo_DrRaw, here are some figures with Gimp-edge. (I think the install etc worked fine, it shows a different (and longer) Commit I.D. to your AppImage)
Well, same timings! 32bit f.point - 15.5s.
This reduced to 10s for the jpg-default 8bit precision image.
Only one cpu core was used.
It was noticeably quicker to load Gimp, as others have alluded to.
I tried adding RGB noise. Same 15.5s at 32bit. 9s at 8bit.
All the above were with the whole photo displayed. If zoomed in, your AppImage went quicker, I assumed that was perhaps because it just did the screen and the rest of the image got done in the background. However zooming in with gimp-edge makes no difference, 16s in fact for the Levels test at 32bit f.p.
Memory usage is 4.2Gb, no swapping going on.
Surely the s/ware is not using a maths package instead of the native floating point cpu instructions?!!
hi, I’ve downloaded and unzipped, so have 91Mb GIMP295.bin in my Documents folder, and it’s set to allow execution. How do I run it please? I looked up some stuff which started off saying go to root with “su -” but I get an authentication error with my password, the only password I’m aware of.
Hi @RawConvert, thanks for this test! If I understand correctly, we can conclude that the AppImage is as fast as the native gimp package, whatever the speed is, right?
Could you try one more test, please? Could you open the Jpeg image, run the PhotoFlow plug-in from the “Filters” menu, and apply some simple editing tool like the RGB curves? Is this more responsive or sluggish as well?
You’ll be pleased to hear Photoflow is massively faster (on my box). It responds effectively instantly when moving a point on a curve (guess <= .25s?). Same with the basic adjustments like contrast, very fast. And it’s not that there’s a big pause when you “ok” back to Gimp, that was quick too.
I set 32bit f.point, like previously, before going into PF. PF was using all cores for the basic edits, and I think for the curves too, can’t exactly remember. I didn’t try layers.
If I was being picky, I’d suggest make the curve points behave like the basic edit sliders in the sense that the latter update the image preview as you drag with the mouse button held down. The curve change isn’t seen until you release the mouse.
I will probably explore PF further. RT does a lot. When I need Gimp (or PF?!) it will usually be to do a few local adjustments, so I mainly need lasso, feather selection, put in new layer, apply changes. I’m guessing PF will do that. But having said that, I do want to explore CCE and the Gimp linear processing that’s currently being developed, in due course.
no need for any root commands
I often start these appimages via my file manager (usually right-click & run)
otherwise open a terminal in Documents then dot-slash to run
edit: either/or something like this http://i.imgur.com/2PuszV0.jpg
OK, so this completely excludes some possible slowness of the appimage itself.
The other big advantage of the phf plugin is that you can replay your edit by calling again the plugin on the layer it has created. This way you can further tweak the parameters even after the plugin was closed.
Concerning the curves, in the past I’ve been considering what you suggest, but I’m afraid this will make large adjustment quite slow. The best is to fine-tune the point position with the keyboard arrows, in which case you’ll get immediate feedback…
Next phf version will have full support for linear RGB, so it should integrate well with future gimp versions.
The latest Gimp CCE (gimp-cce-2.9.5-20170326.glibc2.15-x86_64.AppImage) crashes with the following error when running on Ubuntu 16.04 (64 bits).
/tmp/.mount_bjl0S7/usr/bin/gimp-cce.bin: symbol lookup error: /usr/lib/x86_64-linux-gnu/libatk-bridge-2.0.so.0: undefined symbol: atk_table_cell_get_type
Hi! Thanks for reporting this issue. This might mean that libatk-bridge needs to be bundled into the AppImage, instead of using the system-wide version… maybe @probono has a better idea of how to solve this problem.
Meanwhile, would you be able to also test the “standard” GIMP appimage (https://pixls.us/files/gimp-2.9.5-20170310.glibc2.15-x86_64.AppImage) and check if you have the same issue?
Works ok here in Kubuntu 16.04
Surely the easiest way is is install the missing package.
I am a bit surprised that libatk-bridge is not already there, it is a dependency for all-and-sundry.
example, if I wanted to remove it. http://i.imgur.com/SU4hRxL.jpg
Thanks for checking!
My understanding is that in the case of @caiosouza the libatk-bridge package is not missing, but it is not providing the expected symbols…
@caiosouza: could you provide the exact version of libatk-bridge installed in your system?
i cannot seem to run the appimage at all.
./gimp-2.9.5-20170310.glibc2.15-x86_64*.AppImage gives me errors like:
What distribution are you using?
My version of libatk-bridge is 2.18.1. I’m using Ubuntu 16.04 64 bits. I tried to run both the standard Gimp and the newest Gimp-cce and they stop with the same error. I remember I tested the standard Gimp few months ago and everything worked fine.
debian sid, though i’m currently reinstalling it because i tried to extract the files manually and the libraries were giving me ELF errors.