[OpenDroneMap-users] "bowl" effect

[Stephen Mather]

On Mon, Oct 5, 2015 at 10:47 PM, Anna Petrášová <kratochanna at gmail.com>
wrote:

>
>
> On Mon, Oct 5, 2015 at 10:27 PM, Stephen Mather <stephen at smathermather.com
> > wrote:
>
>> Hi Anna,
>>
>> Good news. I've been bad here and cc'd Pau who an hopefully answer your
>> question on parameters.
>>
>
> I found this function in OpenSfM:
> https://github.com/mapillary/OpenSfM/blob/master/opensfm/exif.py#L50
>
> which undistorts a gopro  camera, so I guess I can inject my values there
> (not tested yet)
>

Ha, yes. Hopefully that works. Also:
http://www.janeriksolem.net/2014/05/how-to-calibrate-camera-with-opencv-and.html


>
>> That said, if you have all the parameters, is there any reason to not
>> undistort before feeding into ODM?
>>
>
> 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:
>

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... .


> running "/odm_app/OpenDroneMap/bin/RadialUndistort"
> "/vagrant_data/June19_subset/reconstruction-with-image-size-2402/list.txt"
> opensfm/bundle_r000.out pmvs
> [ReadBundleFile] Bundle version: 0.300
> [ReadBundleFile] Reading 126 images and 49430 points...
> Undistorting image ./dsc01522.jpg
> Undistorting image ./dsc01523.jpg
> Undistorting image ./dsc01524.jpg
> Undistorting image ./dsc01525.jpg
>
> Sorry if I am missing something
>
>
> Best,
>
> Anna
>
>
>> Cheers,
>> Best,
>> Steve
>>
>>
>>
>>
>> On Sun, Oct 4, 2015 at 6:04 PM, Anna Petrášová <kratochanna at gmail.com>
>> wrote:
>>
>>>
>>> On Thu, Jun 25, 2015 at 11:04 PM, Stephen Mather <
>>> stephen at smathermather.com> wrote:
>>>
>>>> If memory serves, Anna has proper survey points, so Z is pretty good.
>>>>
>>>> Regarding the alternate branch -- there's nothing wrong with it, and
>>>> it may be the FUTURE, but TBH, I haven't had a chance to test it
>>>> properly... . I was hoping you'd try it, since you have such good
>>>> secondary data to verify how it does... .
>>>>
>>>> Cheers,
>>>> Best,
>>>> Steve
>>>>
>>>>
>>>>
>>>
>>> Hi,
>>>
>>> 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:
>>>
>>> radial_distorsion_k1_sd: 0.01 # The standard deviation of the first
>>> radial distortion parameter (mean assumed to be 0)
>>>
>>> but I have k1, not its standard deviation? Should I rather ask on the
>>> mapillary forum?
>>>
>>> Thanks,
>>>
>>> Anna
>>>
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Jun 24, 2015 at 2:20 AM, Alex Mandel <
>>>> tech_dev at wildintellect.com> wrote:
>>>> > On 06/22/2015 06:24 PM, Anna Petrášová wrote:
>>>> >> On Mon, Jun 22, 2015 at 6:00 PM, Stephen Mather <
>>>> stephen at smathermather.com>
>>>> >> wrote:
>>>> >>
>>>> >>> Ah, ugly. Well, pretty really, but ugly from a data perspective. So
>>>> >>> systematic bias in structure from motion is an issue with all
>>>> systems, and
>>>> >>> difficult to overcome with drone imagery in particular, if the
>>>> drone is
>>>> >>> flown in a single Z plane, particularly over relatively flat
>>>> terrain.  This
>>>> >>> is an indictment of the data, just stating a known difficulty. This
>>>> is why
>>>> >>> balloon and kite flights, aside from areal coverage, are so
>>>> pleasant to
>>>> >>> process -- plenty of x, y, and z movement, so less chance for
>>>> systematic
>>>> >>> bias. I've been wondering if once a dataset like Open Terrain (a
>>>> global
>>>> >>> highest-available) is available, if it might be helpful for
>>>> compensating
>>>> >>> for bias in datasets, and also help with data classification
>>>> pipelines that
>>>> >>> can have separate meshing mechanisms for ground, vegetation, and
>>>> human
>>>> >>> structures.
>>>> >>>
>>>> >>
>>>> >> I was thinking about compensating for the bias based on the lidar
>>>> data I
>>>> >> have, but I haven't tried it yet.
>>>> >>
>>>> >>>
>>>> >>> That said, let's get a little more context on the dataset and
>>>> processing
>>>> >>> -- did you use ground control and if so, how was it distributed? It
>>>> would
>>>> >>> be interesting to know if you had ground control in the center of
>>>> the
>>>> >>> scene, if ODM is ignoring this extra info. Also, what kind of
>>>> camera is it?
>>>> >>> It is possible that the three parameter corrections that ODM is
>>>> performing
>>>> >>> are inadequate, and a 6-parameter model would be better.
>>>> >>>
>>>> >>
>>>> >> There isn't really any gcp in the middle of it:
>>>> >>
>>>> https://drive.google.com/file/d/0B7CQoT4YE2mMNzJSbEZsaGtrZ3hnRUdPQ3VDbF9DS0o2SS1j/view?usp=sharing
>>>> >>
>>>> >> but how could the GCPs help? Georeferencing won't really change the
>>>> shape,
>>>> >> isn't it just rotation and translation?
>>>> >>
>>>> >
>>>> > The ODM format for a GCP file is X,Y,Z so yes there is height data if
>>>> > you are providing GCPs. Of course if the Z is provided from a standard
>>>> > GPS unit that might not be super useful.
>>>> >
>>>> > -Alex
>>>>
>>>
>>>
>>> _______________________________________________
>>> OpenDroneMap-users mailing list
>>> OpenDroneMap-users at lists.osgeo.org
>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-users
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/opendronemap-users/attachments/20151005/7ebca2a5/attachment-0001.html>