Machine Vision

cancel
Showing results for 
Search instead for 
Did you mean: 

image ROI filler with Poisson inpainting

I'm looking for an implementation of smooth hole filling in images with Labview (8bit grayscale would suffice). The technique is known (e.g. http://www.insight-journal.org/browse/publication/791), and involves patching a generic ROI of the image with the solution of a Laplace equation, having the values at the ROI edges as boundary condition. The PDE toolbox of Labview has a Poisson solver for rectangular domains, so something may be doable without too much effort for rectangular ROIs, but I would appreciate the extension to generic ROI shape.

Is anybody aware of any lead?

Thx, Enrico 

0 Kudos
Message 1 of 5
(3,149 Views)

Well, I sort of did it myself, but it is painfully slow.

 

HoleX.png

 

I solve the Laplace equation using the general Helmholtz solver, since it is the only one allowing a nonrectangular grid, and hence suits a generic ROI shape. However, I can't help but provide as computational gridpoints the full set of pixels locations inside my ROI, and this makes the computation very slow (possibly, quadratical in the number of inner and and boundary points, but can't say).

Is anyone able to make any better than this? Attached the commented code.

 

Download All
0 Kudos
Message 2 of 5
(3,136 Views)

Hi Enrico,

 

I have to start by saying this is a really interesting application and your program is great! I agree with you that the issue of slow computation could be improved by using a coarser grid. Because it is taking in so many points, the PDE just can't compute it that quickly. 

 

I also ran VI Analyzer and a performance monitor on your code and don't see any major issues with memory leaks or anything of that nature. Really the only way to optimize it would be to stream line your code. I'm going to continue looking at your code to see if I can help you out at all but overall you did a fantastic job. Thanks for posting this!

 

Mychal F

Applications Engineer
National Instruments
0 Kudos
Message 3 of 5
(3,121 Views)

A further thought I had, is that the more than quadratic performance of the solver may have a very simple explanation - LV may use just a vanilla direct matrix method to solve the associate linear system, and not a sparse solver like any decent FEM code. That would be penalizing for memory too. Also its triangulation routine may be suboptimal. I had a cursive look at the hyerarchy buried inside the PDE vis and got lost, but from profiling I see that a lot of time is spent in these innards.

If that is the case, the solutions would either be to outsource the solver to a state of the art routine (which, where, how?), or compromise with the number of inner triangulation points. Are there public VIs for dealing with triangulations and postinterpolating a FEM solution?

Enrico

0 Kudos
Message 4 of 5
(3,119 Views)

The attached one would perform marginally better, letting Define PDE domain.vi choose the gridpoints (seriously, please don't call this a "mesher"). Postinterpolation is achieved via mathscript's intrp2d_uneven(). The choice of a smooth intrp2d_uneven() method may visually mask a coarse gridding of the domain, at a fraction of the processing time cost. The PDE solver, however, remains painfully slow, so the trick doesn't raise the stick too much - a few hundred gridpoints in a few seconds is the maximum practically usable.

0 Kudos
Message 5 of 5
(3,108 Views)