darktable icon indicating copy to clipboard operation
darktable copied to clipboard

FR: retouch: add content-aware fill (inpainting/resynthesizer) mode

Open ralfbrown opened this issue 2 years ago • 4 comments

Is your feature request related to a problem? Please describe.

We have clone and heal algorithms in the retouch module, which copy from a source region to a destination region, but sometimes there is no suitable source region. In such cases, it would be useful to extend the pattern of the surrounding area of the image into the destination.

This or similar has been requested multiple times in the past (#12891, #8649, #2729), and this FR is meant to consolidate the requests.

Describe the solution you'd like

A new mode in the retouch module similar to the existing "fill" algorithm which does inpainting from the surrounding pixels instead of painting a fixed color. Using G'Mic (which already gets linked to handle compressed LUT files) has been suggested.

ralfbrown avatar Aug 04 '23 14:08 ralfbrown

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

github-actions[bot] avatar Oct 09 '23 00:10 github-actions[bot]

Would also like this capability

srk avatar Jul 19 '24 06:07 srk

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

github-actions[bot] avatar Sep 18 '24 00:09 github-actions[bot]

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

github-actions[bot] avatar Feb 13 '25 00:02 github-actions[bot]

Could the content-aware fill maybe outsourced to some AI project? (no idea which - there are many) So this would become more a matter of integrating than implementing the fill itself?

tcurdt avatar Jun 29 '25 17:06 tcurdt

Not really - the fill needs to be computable every time the pixelpipe runs, which implies a tight binding. We could still link in a third-party library for the processing (instead of writing code) as is done with lensfun for lens corrections, but something running on a remote server is basically a non-starter.

ralfbrown avatar Jun 29 '25 18:06 ralfbrown

@ralfbrown I would have imagined it would have to work like this

old: [source]-pipeline->[display]
new: [source + overlay]-pipeline->[display]

...but of course it means the inpainting would need to be stored as another sidecar.

tcurdt avatar Jun 29 '25 18:06 tcurdt

Consider the case where the user changes settings in modules that come before the point where the inpainting is applied, e.g the legacy white balance. If you don't recompute the patch, it won't match the image anymore....

ralfbrown avatar Jun 29 '25 23:06 ralfbrown

That's what I meant with the pipeline coming after the inpaint. But I fear that's a too simplistic view on my side.

I am also not sure how/if inpainting would work on the RAW level.

tcurdt avatar Jun 29 '25 23:06 tcurdt

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

github-actions[bot] avatar Aug 29 '25 00:08 github-actions[bot]

What if in-painting would always be the first step in the pipeline?

tcurdt avatar Aug 29 '25 01:08 tcurdt

This issue has been marked as stale due to inactivity for the last 60 days. It will be automatically closed in 300 days if no update occurs. Please check if the master branch has fixed it and report again or close the issue.

github-actions[bot] avatar Oct 29 '25 00:10 github-actions[bot]