Status

[ghost]

first of all, thanks a lot for sharing!

I would like to contribute to this project but would like to know your opinion first. Does it make sense to use Daisy for dense matching or is this obsolete today? The kermit.ply file provided in the project looks like there is still some space for improvements yet. :)

However, I guess that you are not doing any consistency checks yet before exporting the ply, right?

[cbalint13]

@mojovski ,

I try respond:

• Yes, DAISY is still excellent descriptor performing very well in the baseline scan. It is very fast, whole image pixels can be pre-described apriori for its the pixels and it fits in decent amount of RAM. I believe other NCC approaches like dot-product (see PMVS or other more modern) are suboptimal but can be compensated with fact that on modern GPU may gain advantage doing extensive and vast amount of dot-product even on the fly. But what if we have DAISY on GPU too ? (i am planning such implementation for OpenCV), then dot-product and other NCC approaches can be outperformed by large margin.
• EMVS main and most important advantage is that is using very smart uniform sampling in baseline, thus much of computation coming from (some time) extensive search in the basline is relaxed. But this is tricky to do see Uniform Sampling, see in the paper.
• The main problem I face with this is that its hard to tackle DAISY's scale invariance as also the paper states, for this we have to warp sampling daisies using H or try some way to pre-project one camera image at same scale/rotation against other camera.

Actual implementation does not do proper consistency check except the basic check related to have minimum of 3 point from 3 different cameras meeting together within a small distance constrain.

[ghost]

thank you very much for your comments!

as for the scale invariance, would it make sence to rectify an image pair? Iam currently working on such a preprocessing step to enable standard stereo matching e.g. geigers to work for multiview. Unfortunately, the opencv implementation did not work for me here. I assume that they factorize the matrices assuming a too general case, which can be restriced given known/preestimated camera poses.

[pogilon]

What consistency checks or other improvements do you suggest to add to this repo?