Enable multi-threading at least for all demanding G'MIC filters


#1

It would be great if the G’MIC developers could review their code and support multi-threading for at least the more demanding filters, because otherwise they can’t be used in professional environments or trainings, where time is an issue.

One striking example is the filter Repair > Inpaint [patch-based]. It can deliver superb results, but even with images of modest resolution/size, simple operations can take minutes or hours, and this is not something like rendering a SFX scene of a Star Wars movie. :wink:

As a result (speaking from personal experience), I cannot demonstrate this filter (and some others) during talks or trainings, simply because it takes too long to render the result.


(G'MIC staff) #2

Maybe this is something you haven’t noticed, but most G’MIC filters actually use multi-threading for computing their result.
Inpaint [patch-based] is one of the exception, but there is a good reason for that : the algorithm used here consists of iterative copy/pasting of patches that can’t be done simultaneously (one paste has a consequence on all the following). This is a single-threaded algorithm by nature, and there is very few we can do to change it.
Try Inpaint [multiscale] which uses a different inpainting algorithm that can be (and is) multi-threaded.