GAAP : "G'MIC As A Plug-in" (work in progress)

(David Tschumperlé) #1

Hi there,

Some interesting news to share with you today ! One of my talented colleague here at the lab has started working on a project named GAAP (a.k.a G’MIC as a plug-in). The idea is to build a generic and self-contained version of a G’MIC plug-in, so that it can be specialized to work with different software (like GIMP, Krita, maybe Photoshop, etc…).


This way, we think it will be easier to have a common plug-in codebase to maintain and to update. The idea is to provide a minimal API for software developers so that the plug-in can be easily invoked from their own software. Basically, this means they’ll have to write only the code concerned with the data transfer from/to the plug-in.

If all goes well, this version should replace the current version of the G’MIC plug-in for GIMP in a near future, and we hope this will attract developers from other painting/image processing software, so that they can help making this G’MIC plug-in available for their software.


Please be aware this is a work-in-progress. The sources are not yet available. They will when it is ready to use :slight_smile:
What we can say about what we have now is :

  • The plug-in interface is based on Qt. Of course, the plug-in is intended to be multi-platforms.
  • The look is actually very similar to the current plug-in for GIMP.
  • The interface has a filter search box to ease finding a particular filter from its name (that is a request we had for years :slight_smile: ).
  • The preview widget allows to zoom in/out on the image with the mouse wheel.


This is a quick video of the current version of GAAP in action, working under GIMP.
You can see the overall look of the plug-in, as well as some of the features (filter search engine, preview window…).

That’s all I can say for now :slight_smile: What do you think?

(Tore Busch) #2

Very exiting news, indeed!
It is always interesting to see when other projects include G’MIC, from Gimp to Flowblade to PhotoFlow to…, and when you make it easier to include, we can only hope that even more projects will use it. And this is a win-win for me as a user :slight_smile:

(paul matthijsse) #3

Looks good David!
For the moment the most exciting part for me is that search field! :wink:
Of course it would be great when existing - good - software could be re-used in other packages.


I realise requests won’t be a priority since it’s early stages, but one thing to consider: an improved custom code interface. Command line and file input is obviously best but in reality most people’s first experience of G’MIC code is likely in that filter. The current one is pretty basic and has some drawbacks. If it was to be improved, some suggestions:

  • Whole image stack sent to G’MIC (it’s currently one layer through the filter at a time).
  • Allow image resize
  • Status output - I have my own version of the filter which displays current number of images, dimensions of the last image and the last status. It’s a lot nicer this way!
  • Output of the G’MIC pipeline (debugging info). I experimented with this in “gmictool” and it’s really great to have.
  • Don’t do any post processing such as normalize, cut. It’s better to learn with the raw output.
  • Use a better textbox for simple features such as undo (a dream would be keyword colouring etc.)

Even if the above isn’t considered it’s great this is being developed at all! :slight_smile:

Edit: here’s what I use: pastebin example

(David Tschumperlé) #5

Except when you change the Input layers option (e.g. 'All layers), right ?
Or do you mean something else ?


Nope, when set to “All” the custom code filter is handed all layers but only one at a time, as if in a loop.

(David Tschumperlé) #7

Ah, if you use the Custom code filter, yes you are right.
But if you write your own filters in a .gmic file, then you’ll get all layers at once.


Yes sorry I didn’t mean to confuse - all the points above relate specifically to “custom code” :slight_smile:

(David Tschumperlé) #9

So, this should be better now:

This is now possible, if no particular image channels are selected for the processing.

This is possible too.

See screenshot, there are quite a lot of debug info that can be displayed now on the preview window.

This was already possible to output the G’MIC log on the console, or on a log file. Nothing changed here, I cannot easily create an image containing the logs at this point.

This is possible.

Kof kof! Not planed for now :slight_smile:


Thank you! I hope the changes are well received by others, blame is entirely on me if not :smiley:

Incidentally the debug output in “gmictool” was a hack - literally loaded the log file and displayed it , which I guess is possible in the filter as well. But that’s ugly, so let’s not try it :wink:

(Francesco Riosa) #11

love the idea, very much!
In other forums you mentioned that G’MIC expect image channels with a typical sRGB gamma, maybe for a generalized plugin is a good idea to accept and return only linear gamma images.
That would standardize the behavior of the G’MIC filters and possibly make life easier for a few of them (or not?) not very sure

(Lyle Kroll) #12

Really cool news, David. This would mean even PS users could benefit using G’MIC. I wonder if qt supports GPU acceleration? Shared the news at GIMPChat. :slight_smile:

(Colin Paul Adams) #13

Does the interface include the selection?

My current workflow, for example, these photos, is to do some standard processing in darktable (crop, velvia, profiled denoise), then export to 32-bit TIFF, import into GIMP, select the area I want to sharpen, invoke G’MIC, apply a tough of octave sharpening, and then export. It would be much nicer to just be able to invoke GIMP as a darktable module, but this wouldn’t benefit me unless I had a way to apply G’MIC filters only to the selected area.

(David Tschumperlé) #14

The selection is intended to be managed by the host software (e.g. GIMP). GAAP will be a plug-in managing multiple inputs and able to generate multiple outputs, but it won’t have anything to create image selections by itself.
There will be still some work from developers if they want GAAP as a plug-in for their software: we try to make this amount of work minimal (just a few lines of code to write), and image selection management will be a part of this work (this shouldn’t be hard to do if the software already manage selections, e.g. with GIMP it’s only a few lines of code to take care of).

(Colin Paul Adams) #15

That’s fine.


For us accountants, GAAP is the acronym for “Generally Accepted Accounting Principles”. It’s a widely used acronym in the international business world. If “GAAP” is intended to be a permanent name for the software, then I would humbly suggest choosing another name for it to avoid confusion by others and improve the result of internet search.

(David Tschumperlé) #17

Ah, that’s interesting to note yes, thanks a lot !

(Colin Paul Adams) #18

But it’s a different domain, so there is no confusion.


True…but if anyone do an internet search on “GAAP”, there is no chance the software will show up in the search which means it’s harder for someone to reach the software site. So why would the developer want to use such name?

(Morgan Hardwood) #20

I agree with @go-go-go that “GAAP” is not an optimal name. I sometimes google for GAAP for work-related things, and anyone searching using just that keyword will not find this project. Searching for “G’MIC GAAP” is guaranteed to succeed, but perhaps not everyone’s choice of search terms.
But there’s another thing. GIMP already has a “GAP” - GIMP Animation Package. Sounds the same in speech, could get confusing outside of the search realm.