Still a work in progress, but runs and can be built with docker.
I’m getting some really good preliminary results.
If I am reading the paper correctly, it looks like the DSP functionality could potentially be applied to other feature descriptors, like HAHOG/ORB/et al?
I didn’t explore that possibility. HAHOG probably.
That could be really interesting, especially for non-georeferenced reconstructions.
We have a number of folks who do archaeology or preservation work, and having a way more robust HAHOG would be a boon.
DSP SIFT is now available in the latest docker images.
Try it out via --feature-type dspsift
1 Like
Hooo, that’s really cool, that’s a great choice ! 
I remember having some 5-15% improvement with DSP (actually a custom AKAZE variant with SIFT pooling) compared to non-DSP (not on OpenSfM, at a previous job).
Always weird that people always benchmark against SIFT, when DSP-SIFT is a simple and proven alternative to SIFT.
Oooh, so pooling can be added onto the other methods?
We could have DSP-ORB et al? 
@YanNoun I’d be happy to open a PR upstream for OpenSfM if there’s interest in merging it.
Ha! Great orthophoto topic.
Looks like it doesn’t make use of the GPU, even when the settings are such that it would be used with SIFT.
What effect does it have on camera calibration and the bowling effect?
I think bowling is best controlled via image acquisition techniques, rather than looking for a solution in processing.
Image acquisition is a big part but the matching techniques does affect the result a great deal.
Correct, our SIFT is CUDA accelerated, but any other feature detection and extraction would need to be ported to CUDA for acceleration, including dspsift.
Are both sift variants Cuda accelerated?
No, anything other than our current SIFT implementation will need to be manually ported/re-coded to take advantage of acceleration.
Why didn’t I read that line to the end?
Wishful thinking 
