FR: retouch: add content-aware fill (inpainting/resynthesizer) mode
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.
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.
Would also like this capability
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.
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.
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?
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 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.
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....
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.
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.
What if in-painting would always be the first step in the pipeline?
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.