Open ashwani-rathee opened 1 year ago
Hi, thanks for brining ImageInpainting.jl to my attention. The method there is very cool, but also very different from this algorithm. I would be happy to consider merging this there if there were different algorithm options and the different applicabilities were well clarified.
Thanks for your interest @andrew-saydjari , let me see what's needed to make things easier to incorporate newer algorithms in terms of API in ImageInpainting.jl. By the way, are you on slack?
Yes. Happy to join the slack discussion if that works better. andrew.saydjari@cfa.harvard.edu
In the example in ImageInPainting.jl,
using ImageInpainting
# inpaint image within mask using algorithm
inpaint(img, mask, algo)
img: This is always likely to be there mask: Again always supposed to be there I think to define the ROI algo: This for your case could be CloudClean which is of InpaintAlgo Type and its parameters can also be specified in kwargs as needed.
If you see: https://github.com/JuliaImages/ImageInpainting.jl/blob/master/src/criminisi.jl
struct Criminisi <: InpaintAlgo
px::Int
py::Int
end
for your case, it will be something like:
struct CloudClean <: InpaintAlgo
parameters1::Int
parameters2::Int
parameters3::Int
end
So I think that would be straightforward for proc_continuous
, but for our proc_discrete
mode, we pass a list of ROI centers, not just the mask. This improves the infill because you are choosing your "training" data to be optimally centered around the regions that you want to infill. I am not seeing an obvious way to fit that into what you describe. It would be hard for me to think about that list of ROI centers as parameters of the algorithm, but maybe an optional keyword to inpaint
that (via multiple dispatch) is only allowed for CloudClean.
Hey Andrew 👋🏻 , Both solve the problem of Image Inpainting(Infilling), I wonder what you think of helping out in developement of ImageInpainting.jl so that it's more sustainable and everyone who uses JuliaImages, benefits from this work which reduces package fragmentation.