Hello there,

We have been working hard these last days on a new surprise feature for the next version of G'MIC, and I'm happy to say that there is one beta version available which provides this feature.
This is still *highly* experimental, time consuming, memory consuming, so please do not consider this is the final version of the algorithm, and do not try this at home if you don't have a very powerful computer.
You have been warned

Now, let us say a bit more about this feature. We have added a new (native) command '-repair' to the G'MIC framework, able to reconstruct (a.k.a inpaint) masked image regions. But this time, it uses a patch-based copy/paste algorithm so it can reconstruct parts with texture and grain too. Here is a little example of use below :



It's a bit like the 'Content Aware Filling' feature of Photoshop, but available for free for GIMP (and other interfaces able to use the G'MIC framework). The example above takes several minutes to compute on my netbook, with blending disabled. Just to warn you again one more time !
The algorithm has been written by Maxime Daisy (one of my current PhD student) during his Master thesis. Thanks to him for his great piece of code.

I've posted beta packages for Linux on the G'MIC website. No windows versions right now to test, but I'll try to build the 32bits plug-in this afternoon, if you are interested by it of course.
This new filter (for the GIMP plug-in) is available only in latest beta 1.5.5.1, and after an Internet update of the filters. If you succeed in using it, you are welcome to post results, so we can see if this is working well or not.

We will try to optimize the algorithm a little bit more in the future, as it seems to be hardly usable right now (particularly when the blending option is activated!). This is work in progress though.

Hope you'll enjoy this little suprise !

That looks very promising...I am looking forward to it

Exciting!

Wow. This looks really really useful.

Excellent news David. Not sure how fast G'MIC's inpainting will be over Resynthesizer's heal (hit or miss with it's results by the way), but look forward to giving it a try soon.

Here is a quick comparisons of inpainting results I've get on a single color image.
I compare three inpainting methods : G'MIC Inpaint[Diffusion], Resynthetizer and G'MIC Inpaint[Patch-based] (the new one).



By the way, the resynthetizer plug-in is the fastest one to render the result.

I've just posted beta packages of the GIMP plug-in for Win32 on the G'MIC sourceforge site.

ronounours: a great surprise, the examples you posted look impressive. look forward to trying this - though probably in a later version because of the warning.

Bonjour,

Here is a development version of G'MIC for Gimp 64bit Windows (20130315).
Compilation settings are different and gives a 4% improvement in speed.

EDIT 20130317 : file deleted

David, too much of a surprise .. my eyebrows fell off .. are you roughly solving a PDE in patch-space?

Anyway, amazing, looking forward to that on windoze.

A single "inpaint" mask raises the segmentation/connectivity problem of choosing which patches are the best clone sources .. I was recently segmenting image by chroma (YUV without Y) to have multiple source types and was going to re-synth from those .. maybe you can do some similar trick with your patch method .. i.e. a complex version to return multiple inpainted layers each using a distinct potential archetype (rather than fitting to the inpaint region's boundary)

The algorithm has been optimized a little bit. A new source archive for the 1.5.5.1 beta version has been released as well. Still work in progress though !

Here are some new results I've done using the G'MIC plug-in for plug-in, filter 'Enhancement / Inpaint [patch-based]'. Looks promising to me !

Hi everyone,

Thanks a lot indeed for this new, amazing filter!

I am wondering whether It may be possible to expand this filter in order to get a new opposite option?

In short, as with Gimp, with the foreground select tool, IMHO, it would be very useful to have this same option with G'mic with this new filter.

More precisely, with G'mic:
1. You might "paint" on the image you want to extract from the background;
2. When you are done, you might apply this filter in order to "delete" all background (all pixels should be deleted).

In essence, the filter should be able to delete all unnecessary pixels (the ones NOT selected) in order to extract your image from the background.

For example, in the picture where there is the bird (the image just posted by Ronounours) you might be able to extract the bird from the background (that is, the opposite of what the filter is doing right now....).

The Siox algorithm implemented in Gimp allows to get the same result.
Maybe this new filter with G'mic might be more powerful compared to Siox on top
In addition of requiring a minor amount of clicks to get the job done (namely extract your image from the background).

P.s: Some years ago (2009) there has been a Google - Summer of Code which was aimed to improve the Siox algorithm version on Gimp.
Unfortunately, this Gsoc work was never merged to Gimp
To my knowlege, the Siox algorithm version implemented on Gimp has not received any improvement these past years...
Two years ago the Krita team tried to implement the Siox algorithm on Krita, through a Google Summer of Code project, but this student failed as well

Best regards!

I don't get it sylvio.
The mask must be selected by the user to inpaint its content. So, all the segmentation work is done by the user, not by the algorithm. I don't see how the inpaint method could be used to automatically segment foreground objects from the background.

Thanks Ronounours and Maxime Daisy. Wonderful performance.

New progress on the patch-based inpainting algorithm has been made. Another gain in terms of speed, and another beta release, so you can test it if you wish. This is now quite usable, the following example has been computed on my small netbook (with a CPU of 1.1ghz). It took like 3 minutes to achieve on this very slow machine :


I would be interested to get your feedback on this. Didn't have time today to compile it for Windows and Linux64, but I'll try to do it on next monday.

Thank you very much David and Maxime Daisy!
These kinds of filters are always very helpful for photomanipulation.

I wonder what would happen in an image with many colors, where you can not choose a color for the mask that does not exist in the image. Would it be better that the repainting is done through a selection rather than a colored mask?


Would be nice if you share an image with the mask already done and the values ​​of the parameters that you used in the filter, to do the benchmark over the same image and so we share the results of computation times and CPU characteristics.

The inpaint filters have now two different modes to select the mask to fill in. Either you define it with a prescribed color (as I did above), either you define it as an opaque region on a top layer.

Oh, now I see.
I've compiled G'MIC 1.5.5.1 beta for Linux 64bit.
I am applying the filter in the following image, over the yellow wire:
http://www.fileswa/Qby5At5/inpaint-patch-based_test(not download this to test).html

Something does not work well. If I select "opaque region in top layer" the filter does nothing.
If I merge the layers and then I apply the filter with red mask (#FF0000) selecting "Mask by color", then something strange happens, the mask edges still appear. But if I paint new regions in red, the filter works on the new regions. The original red line over de yellow wire still having the problem that I had mentioned.
Using GIMP 2.8.4, Kubuntu 64bits

Edit: Now I have done another test and the problem also occurs in the new regions that I paint. I really do not know when the problem occurs, or when not.
Edit2: This file is that works:
http://www.fileswap.com/dl/muk1p6GMiV/i ... 1.xcf.html

Indeed, there was a bug with the top layer masking mode. It should be fixed now (you need to refresh your filters).
Note also that your red mask is *not* perfectly red, so using the 'color mask' mode will not select all your shape, but will exclude pixels that are aliased red, that explains you don't get the desired mask at the end.