I ran the dataset with the following parameters:
I got the following results:
Orthomosaic
Point cloud
I noticed that the number of downloadables have reduced.
Before:
After update:
Kind of same settings, just this time I used split parameter too.
Would definetely make sure next time.
I can see you have increased matcher-neighbors to 40. Is there something else to be done, like preprocessing of images, etc. ?
I donāt think there is anything left to do until we have rolling shutter correction. It really messes with matches when there isnāt enough overlap to compensate, and it appears to be the root of the matching challenges here. Perhaps you can try different match types, but thatās something Saijin has spent more time experimenting with than me.
I understand rolling shutter effect. Just out of curiosity I wanted to ask is that How do they correct the rolling shutter effect. I mean, do they pre-process the image using some rolling shutter correction tool and then process the images?
I was searching on the internet and saw some papers claiming the correction of rolling shutter effect using Artificial intelligence.
Do you have suggestions for any software (be it open-source or paid) which corrects the Rolling Shutter Effect?
If this is the root cause, then I would definetely want to get my hands dirty to solve this problem.
This is a good review of the existing process for Pix4D and MicMac.
Hello, Iām back
As Smathermather said, It is look like (probably) the problem of rolling shutter with your GoPro images.
I test your dataset with Reality Capture
Thanks for trying.
Thank you for the reference. Iāll definetely look into it. I guess Rolling Shutter is a very old problem. Most of the cameras available have rolling shutter including DJIs.
I can see that MicMac is a FOSS. I wonder why no one has looked into it. In my free time, I tried searching on the internet so that I get already baked code but did not find any. Is is something hard to implement? By the way, this statement is not intented to disrespect the developers of WebODM. IMO, they have already done a fabulous job.
Also, If you know any already developed software (be it paid or FOSS) which corrects Rolling Shutter effect from images, please suggest me.
Agisoft and Pix4DMapper correct for Rolling Shutter Distortion.
Iām not sure a stand-alone software for correcting is viable. I believe it needs to be pretty tightly integrated with the rest of the photgrammetric pipeline to work effectively.
If you donāt mind I have one more question. So, is this rolling shutter correction process a kind of pre-processing of the image or something?
Is it something like this, first pixels of each image is corrected and then normal Workflow of Photogrammetric process is followed.
We do have a (now dormant) project called NodeMicmac for integrating Micmac into WebODM. No one has had the time to maintain it, however.
Btw: most of the closed source providers started with Micmac and forked it. With no license that requires it, unfortunately much of the great work on those proprietary solutions doesnāt make itās way back into the project.
Our aim with OpenDroneMap is to be easy to use, easy to contribute to, and great software with a good community. Thereās always more work to do, and rolling shutter is an important feature to implement, and the nature and quality of rolling shutter varies widely by camera.
I have no practical knowlege of the implementation details at this juncture, so I canāt comment, unfortuantely.
From what Iāve read, it seems like that is sort of whatās happening, but seems like less on the pixels of the input image side of things and more about adjusting the vectors of features, etc.
Chiming in :
Iād say thatās the exact opposite happening here : whenever a residual shows āstructureā means that there is a systematic error remaining, as opposite to a random grid of error, which shows that only random noise due to the measurement process is left (which is what most parameter estimations take as assumption, i.e. measurements with gaussian noise).
Having a systematic meaning that the camera model doesnāt match the reality (or the system) of the actual device, whether it is complex deformation or rolling-shutter.
Here, Iād say that there a mismodeled distortion in the DD case. Still, residual seems OK-ish.
Still, the result of the SfM doesnāt say much about the dense point cloud computation. Holes can appear for various reason, here, my gut would say that it is due to the repetitive patterns of the roof that might introduce outliers in individual depthmaps, that further donāt pass consistency checks when fusing depthmaps. Hard to tell without debugging.
Rolling shutter for sure isnāt the only issue, just an exacerbating issue on an dataset with low overlap.
Fully agreed on roofs. This seems to be a smoothness of texture/repeating texture issue. I was able to better results with ODM on the roofs, but symptomatic of smooth, repeating, metal roofs Iāve seen elsewhere:
But rolling shutter is a challenge in this model. Thatās not a good model. This is what Iāve seen when a rolling shutter cameraās effects have been well compensated for in OpenSfM which is considerably less noisey (this is an orbit and a cross hatch to produce this camera model to attempt work around rolling shutter) which is considerably less noisy:
All that to say that I believe that the difference between the results from DD is a combination of factors: low overlap, rolling shutter, + one we havenāt discussed. In the end, having run this through Agisoft which doesnāt turn a textured mesh into a point cloud like Pix4D and DD, we see that Agisoft has holes in the same places:
DDās extra points are likely a result of a suspected colorized mesh-to-point cloud workflow, which solidly places the differences between the point cloud from DD and that from ODM as a question of verisimilitude not veracity, or perhaps more precisely: completeness over accuracy.
We can create something quite similar in MeshLab or CloudCompare with relative ease:
I could spend some time writing up a tutorial, but there are great videos that serve as a good starting point:
We should consider adding this as a feature. We get this question now and again with Pix4D, and Iām not surprised to see something similar with DD. In the meantime though, you may have to roll your own.
Or, (to anyone interested) roll it for all of us! Pull requests are always welcome.
Correcting myself :
Regarding the residual grid of OpenSfM youāre showing, it has some radial pattern, but looking at it, it is actually more anisotropic, hard to tell what is causing it, but for sure thereās an effect that isnāt accounted for (rolling shutter ?).
Regarding the noises, the process of modern approaches for computing depthmaps is the following (whether it is SGM or PatchMatch-based) :
So many things could possibly go wrong and be different between implementation. I do agree with you that meshing might be what DD does very well and is actually filling the gaps. I still wonder if thereās some magic options if OpenMVS that could fix the issue.
Also I canāt access the GDrive folder with the dataset, can someone share it ?
Yann
Ahh, apples and oranges. I didnāt look at these closely enough.
Yup. Reposted here: NH38 - Google Drive
Bookmarking thisā¦
Forgot to mention the last one :
