<div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 9:54 AM, Pau Gargallo Piracés <span dir="ltr"><<a href="mailto:pau@mapillary.com" target="_blank">pau@mapillary.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Anna,<div><br></div><div>It is not possible at the moment to provide values for the distortion parameters k1 and k2. The code you mention will set the initial values of k1 and k2, but they will be modified freely during the reconstruction.  The reconstruction method assume that k1 and k2 are small and forces them to be close to 0.</div><div><br></div><div>If your images have significant radial distortion, it can very well be that the deformation on the reconstruction is caused by our bias towards small distortion coefficients.</div></div></blockquote><div><br></div><div>they don't have significant radial distortion, what I am trying to get rid of is the bowl effect (in literature called doming effect) caused by the images being taken vertically, no oblique photos. This effect is related to the computation of the radial distortion, from what I understood, correct me if I am wrong. For example Agisoft corrects this error using GCPs.</div><div><br></div><div>Thanks for your expertise!</div><div><br></div><div>Best,</div><div><br></div><div>Anna</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div><div>Adding prior values to k1 and k2 is something i want to do soon, so that we can better handle fisheye cameras such as GoPros.</div><div><br></div><div>Bests,</div><div>pau</div><div><br></div><div><br></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 6, 2015 at 4:52 AM, Stephen Mather <span dir="ltr"><<a href="mailto:stephen@smathermather.com" target="_blank">stephen@smathermather.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Oct 5, 2015 at 10:47 PM, Anna Petrášová <span dir="ltr"><<a href="mailto:kratochanna@gmail.com" target="_blank">kratochanna@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Mon, Oct 5, 2015 at 10:27 PM, Stephen Mather <span dir="ltr"><<a href="mailto:stephen@smathermather.com" target="_blank">stephen@smathermather.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Hi Anna,<div><br></div><div>Good news. I've been bad here and cc'd Pau who an hopefully answer your question on parameters.</div></div></blockquote><div><br></div></span><div>I found this function in OpenSfM:</div><div><a href="https://github.com/mapillary/OpenSfM/blob/master/opensfm/exif.py#L50" target="_blank">https://github.com/mapillary/OpenSfM/blob/master/opensfm/exif.py#L50</a></div><div><br></div><div>which undistorts a gopro  camera, so I guess I can inject my values there (not tested yet)</div></div></div></div></blockquote><div><br></div></span><div>Ha, yes. Hopefully that works. Also: <a href="http://www.janeriksolem.net/2014/05/how-to-calibrate-camera-with-opencv-and.html" target="_blank">http://www.janeriksolem.net/2014/05/how-to-calibrate-camera-with-opencv-and.html</a></div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>That said, if you have all the parameters, is there any reason to not undistort before feeding into ODM?</div></div></blockquote><div><br></div></span><div>True, what would be the simplest way to do that? But then how do you tell ODM to not try to undistort the pictures again? During the processing with opensfm, I can see:</div></div></div></div></blockquote><div><br></div></span><div>Hmm, I don't know if one can tell ODM not to undistort, but perhaps one should be able to, now that you mention it. Still, there's very little harm, I think, in ODM attempting to undistort an undistorted image. This is something I've been meaning to test for a few months now... .</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>running "/odm_app/OpenDroneMap/bin/RadialUndistort" "/vagrant_data/June19_subset/reconstruction-with-image-size-2402/list.txt" opensfm/bundle_r000.out pmvs</div><div>[ReadBundleFile] Bundle version: 0.300</div><div>[ReadBundleFile] Reading 126 images and 49430 points...</div><div>Undistorting image ./dsc01522.jpg</div><div>Undistorting image ./dsc01523.jpg</div><div>Undistorting image ./dsc01524.jpg</div><div>Undistorting image ./dsc01525.jpg</div></div><div><br></div><div>Sorry if I am missing something</div><div><br></div><div><br></div><div>Best,</div><div><br></div><div>Anna</div><div><div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Cheers,</div><div>Best,</div><div>Steve</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Sun, Oct 4, 2015 at 6:04 PM, Anna Petrášová <span dir="ltr"><<a href="mailto:kratochanna@gmail.com" target="_blank">kratochanna@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div><div dir="ltr"><span><br><div>On Thu, Jun 25, 2015 at 11:04 PM, Stephen Mather <span dir="ltr"><<a href="mailto:stephen@smathermather.com" target="_blank">stephen@smathermather.com</a>></span> wrote:<br></div></span><div><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">If memory serves, Anna has proper survey points, so Z is pretty good.<br>
<br>
Regarding the alternate branch -- there's nothing wrong with it, and<br>
it may be the FUTURE, but TBH, I haven't had a chance to test it<br>
properly... . I was hoping you'd try it, since you have such good<br>
secondary data to verify how it does... .<br>
<br>
Cheers,<br>
Best,<br>
Steve<br>
<div><div><br>
<br></div></div></blockquote><div><br></div><div><br></div></span>Hi,<div><br></div><div>finally tested the OpenSfM now when it's merged. It gives better results in terms of the bowl effect - there is still some, but not as huge (and it seems faster). Does anyone know if I can pass calibration parameters of the camera to OpenSfM? In the configuration file, there is:</div><div><br></div><div>radial_distorsion_k1_sd: 0.01 # The standard deviation of the first radial distortion parameter (mean assumed to be 0)</div><div><br></div><div>but I have k1, not its standard deviation? Should I rather ask on the mapillary forum?</div><div><br></div><div>Thanks,</div><div><br></div><div>Anna</div><div><div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><div>
<br>
<br>
<br>
On Wed, Jun 24, 2015 at 2:20 AM, Alex Mandel <<a href="mailto:tech_dev@wildintellect.com" target="_blank">tech_dev@wildintellect.com</a>> wrote:<br>
> On 06/22/2015 06:24 PM, Anna Petrášová wrote:<br>
>> On Mon, Jun 22, 2015 at 6:00 PM, Stephen Mather <<a href="mailto:stephen@smathermather.com" target="_blank">stephen@smathermather.com</a>><br>
>> wrote:<br>
>><br>
>>> Ah, ugly. Well, pretty really, but ugly from a data perspective. So<br>
>>> systematic bias in structure from motion is an issue with all systems, and<br>
>>> difficult to overcome with drone imagery in particular, if the drone is<br>
>>> flown in a single Z plane, particularly over relatively flat terrain.  This<br>
>>> is an indictment of the data, just stating a known difficulty. This is why<br>
>>> balloon and kite flights, aside from areal coverage, are so pleasant to<br>
>>> process -- plenty of x, y, and z movement, so less chance for systematic<br>
>>> bias. I've been wondering if once a dataset like Open Terrain (a global<br>
>>> highest-available) is available, if it might be helpful for compensating<br>
>>> for bias in datasets, and also help with data classification pipelines that<br>
>>> can have separate meshing mechanisms for ground, vegetation, and human<br>
>>> structures.<br>
>>><br>
>><br>
>> I was thinking about compensating for the bias based on the lidar data I<br>
>> have, but I haven't tried it yet.<br>
>><br>
>>><br>
>>> That said, let's get a little more context on the dataset and processing<br>
>>> -- did you use ground control and if so, how was it distributed? It would<br>
>>> be interesting to know if you had ground control in the center of the<br>
>>> scene, if ODM is ignoring this extra info. Also, what kind of camera is it?<br>
>>> It is possible that the three parameter corrections that ODM is performing<br>
>>> are inadequate, and a 6-parameter model would be better.<br>
>>><br>
>><br>
>> There isn't really any gcp in the middle of it:<br>
>> <a href="https://drive.google.com/file/d/0B7CQoT4YE2mMNzJSbEZsaGtrZ3hnRUdPQ3VDbF9DS0o2SS1j/view?usp=sharing" rel="noreferrer" target="_blank">https://drive.google.com/file/d/0B7CQoT4YE2mMNzJSbEZsaGtrZ3hnRUdPQ3VDbF9DS0o2SS1j/view?usp=sharing</a><br>
>><br>
>> but how could the GCPs help? Georeferencing won't really change the shape,<br>
>> isn't it just rotation and translation?<br>
>><br>
><br>
> The ODM format for a GCP file is X,Y,Z so yes there is height data if<br>
> you are providing GCPs. Of course if the Z is provided from a standard<br>
> GPS unit that might not be super useful.<br>
><br>
> -Alex<br>
</div></div></blockquote></div></div></div><br></div></div></div>
<br></div></div><span>_______________________________________________<br>
OpenDroneMap-users mailing list<br>
<a href="mailto:OpenDroneMap-users@lists.osgeo.org" target="_blank">OpenDroneMap-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-users" rel="noreferrer" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-users</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>