That would be awesome!
1 Like
IMO, this is pretty much all that is required for the appimage to go prime-time…
1 Like
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.
For me it makes sense. It is something that operates on a layer, such as rotation, scale or offset. Some of the operations in the “layers” menu are “duplicated” in the “image” menu, but there they will operate on the whole image. I would think of “liquid rescale” as something like a “intelligent offset + scale” operating on a single layer.
I agree that within the menus beyond “tools” are a mess. I have filters, fx-foundry, g’mic and script-fu, and e.g. inside filters there is are two “photo” sub-menus. As an example, in the second of them, there is only one item, “exposure blend”. For me, just as an example, this belongs more to the “file” menu, below “open as layers”, because it is an intelligent version of that. In general, I would put all extra functionality that is not filter-like at the places it belongs to, and all filter collections as sub-menus in the filter menu. Maybe, an icon after the menu entry or another text colour could highlight extra functionality that is brought by an external plugin, to make it easier to find these and to know what is not part of the core gimp.
A plugin only menu will result in a “hamburger menu” approach where we end up with a bunch of random stuff that makes no sense in context.
The menus are not optimal as they are, but we should work towards a better taxonomy for menus, not just shove everything into an addons menu.
Edit: @Carmelo_DrRaw I’d be happy to help with the taxonomy; not sure I have the skill to patch things.
2 Likes
Yes, @Carmelo_DrRaw @chris, this is exactly what I mean. Love the concept pf plugins, just needs to be easier to find them all, in one place.
We might take a different approach, which might easier to follow from the practical point of view…
If the GimpPreview widget is not colormanaged, and from what you said I guess it isn’t, we might feed it with pixel values already converted to the GIMP display profile.
This would imply adding (conditional) LCMS2 support to the G’MIC plug-in, and then do the following:
- retrieve the working colorspace and display profile from GIMP, and set-up the appropriate ICC transform
- convert the pixel data processed by g’mic from the working colorspace to the display profile, using the transform created in 1.
- show the converted pixel data in the GimpPreview widget
If you agree, I will check how easily this could be implemented and then I will provide a patched version for testing through the AppImage. You can then decide it it is worth being included in the official G’MIC sources…
I think this is a very important aspect that we can improve with a relatively small effort.
Now, if we go down this hill we might also ask what G’MIC actually does when the input pixel data is not in sRGB. As far as I know, many G’MIC filters assume that the input data is sRGB. Should one convert the input data from GIMP to sRGB before sending it to G’MIC, and back to the GIMP working colorspace when the plug-in is closed?
Anyhow, the first step will be to provide a fully colormanaged preview of the G’MIC filters, if you agree…
@Carmelo_DrRaw, well I’m definitely not an expert in color management (nor really interested by it to be honest), so I cannot say if that is easy or not. If you want to have a try, of course you are welcome 
In fact, it is by design that the location of a script/plugin within the menus of GIMP are left to the authors (of the plugins/scripts).
Small simple tip, at the end of a script file you’ll usually see a line similar to something like this:
(script-fu-menu-register "script-fu-sg-luminosity-masks" "<Image>/Filters/Generic")
If you were so inclined, you could change that last part of the registration to have the menu item show up somewhere else. There’s something similar for Python as well.
If you had a better idea for an entries location, I would consider pushing the changes back upstream to the original author to see if they’re up for changing things.
2 Likes
I have recorded a screencast to show how to download and run the GIMP 2.9.5. AppImage and how to use the additional plug-ins that are included in the package.
Here is the video:
I’m not totally satisfied by the quality (sound is choppy is some places, and I had few technical problems during the recording), so I might redo it if I have some time. Nevertheless, I would really appreciate some feedback before I share it on G+ and other places.
@Fotonut: in the video you might find some useful tips on how to process RAW images with photoflow…
Thanks in advance for looking!
1 Like
That is very awesome @Carmelo_DrRaw, though I think the choppiness does req some attention when you get time. It seemed to be that it would be choppiest when your PC was under load, IE: processing something of an image. Not either side.
I learnt a lot more out of this with regard to PhF as well. Thanks!
I could reproduce the same issue on a Ubuntu 16.04 system, but I could not find a proper fix yet… still working on it.
Let me know if I can do anything else!
The latest version from the pixls.us download link runs under a kubuntu 16.04 live CD (apart for missing pygtk that I need to fix). Could you try it and send me the terminal dump? Thanks!
Which desktop environment are you using? Tomorrow I’ll get a Jessie live CD and do some tests…
I’m using i3-wm with LightDM, no full desktop environment. I wouldn’t be surprised if I’m just missing a package or something, but none of the output makes it obvious as to what package that might be.
The results of dpkg --get-selections are here.