<div dir="ltr"><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><div><div class="gmail_extra"><div class="gmail_quote"><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>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><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><br></div></div></div>