[OpenDroneMap-users] "bowl" effect
Anna Petrášová
kratochanna at gmail.com
Wed Oct 7 19:43:03 PDT 2015
Hi,
On Tue, Oct 6, 2015 at 9:54 AM, Pau Gargallo Piracés <pau at mapillary.com>
wrote:
> Hi Anna,
>
> 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.
>
> 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.
>
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.
Thanks for your expertise!
Best,
Anna
>
> 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.
>
> Bests,
> pau
>
>
>
> On Tue, Oct 6, 2015 at 4:52 AM, Stephen Mather <stephen at smathermather.com>
> wrote:
>
>>
>>
>> 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/20151007/7296f625/attachment.html>
More information about the OpenDroneMap-users
mailing list