[OpenDroneMap-dev] Image Correction

[Stephen Mather]

Alternatively, integrating a generalized version of Alex' work here:
https://github.com/wildintellect/lenscorrection would be welcome.

Cheers,
Best,
Steve



On Sat, May 9, 2015 at 8:42 AM, Stephen Mather <stephen at smathermather.com>
wrote:

> Hi Cole,
>
> Have you had time to do more with this? With Daryl, Alex, and others
> proposing a python port, perhaps we could integrate it, and do distortion
> correction at the front end of the processing chain for images that require
> it by using this class + a user-built calibration library.
>
> Thoughts?
> Best,
> Steve
>
>
>
> On Thu, Mar 19, 2015 at 12:58 PM, Stephen Mather <
> stephen at smathermather.com> wrote:
>
>> It seems that the portion of the CMOS used, or effective chips size,
>> would be different between video and stills, so calibration would be
>> different for video and stills.
>>
>> On Thu, Mar 19, 2015 at 11:51 AM, Alex Mandel <tech_dev at wildintellect.com
>> > wrote:
>>
>>> You don't want a video, you want still images. I can upload some later.
>>> The problem with the video is that it's much lower resolution than time
>>> lapse shots from the same camera and you end up grabbing frames from it
>>> anyways.
>>>
>>> Measuring the checkerboard loss from really close up shots is exactly
>>> how I guessed the new sensor size.
>>>
>>> Thanks,
>>> Alex
>>>
>>> On 03/19/2015 05:41 AM, Cole wrote:
>>> > I was just going to email the list about that.  I would like to make a
>>> test
>>> > use case for this.  Since the ARDrone is probably not within our
>>> normal use
>>> > case, and I do not own a GoPro, would somebody be able to take a video
>>> of a
>>> > checkerboard pattern (
>>> >
>>> http://wiki.ros.org/camera_calibration/Tutorials/StereoCalibration?action=AttachFile&do=get&target=check-108.pdf
>>> )
>>> >  and share it.  Make sure you pan the camera so every part of the
>>> sensor is
>>> > covered by the pattern in at least one frame.  Orientation, skew, etc
>>> does
>>> > not matter.  Make sure you get it as some different distances as
>>> well.  I
>>> > think we can also calculate the CCD width of the cropped image based
>>> on the
>>> > width of the checkerboard cells.
>>> >
>>> > The next logical progression in this work would be to take video and
>>> find
>>> > the minimum number of overlapping frames to create a desirable result
>>> --
>>> > using RANSAC.  So if y'all have some aerial gopro video footage with
>>> the
>>> > exact same camera, I would appreciate that as well.
>>> >
>>> > As the I have a use case for my application with video inside and
>>> outside
>>> > of ROS, I will be posting a test case using the ARDrone, which uses a
>>> > wide-angle camera.
>>> >
>>> >
>>> > v/r
>>> > NJK
>>> >
>>> >
>>> > On Wed, Mar 18, 2015 at 11:33 PM, Stephen Mather <
>>> stephen at smathermather.com>
>>> > wrote:
>>> >
>>> >> Very interesting, I'll check it out. I'm thinking through the
>>> implications
>>> >> of no cropping, and while this won't affect matching, it likely will
>>> cause
>>> >> issues at the texturing stage, so a default cropping with optional
>>> no-crop
>>> >> would be useful. I assume a crop will affect the effective CCD width,
>>> so
>>> >> that will need calculated.
>>> >>
>>> >> Is there any sharable wide-angle data for testing this?
>>> >>
>>> >> Thanks,
>>> >> Best,
>>> >> Steve
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Mar 17, 2015 at 4:09 AM, Cole <colek42 at gmail.com> wrote:
>>> >>
>>> >>> I have a image calibration class up at
>>> >>>
>>> >>>
>>> >>>
>>> https://github.com/colek42/TrackIt/blob/master/catkin/src/stabilize/src/calibrate.py
>>> >>>
>>> >>> It is working great.  I'll add a main function and comments in the
>>> next
>>> >>> day or so and do a pull request.  I am using an ARDrone camera, but
>>> this is
>>> >>> agnostic to the type of camera.  There is no cropping done, so the
>>> edges
>>> >>> are curved with a black background.  If it needs to be cropped let
>>> me know
>>> >>> and I'll add an arg for that.  The interface also needs a bit of
>>> work.
>>> >>>
>>> >>> I was expecting the result to be symmetric, they are not.
>>> >>>
>>> >>> v/r
>>> >>> NJK
>>> >>>
>>> >>>
>>> >>>
>>> >>> _______________________________________________
>>> >>> OpenDroneMap-dev mailing list
>>> >>> OpenDroneMap-dev at lists.osgeo.org
>>> >>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
>>> >>>
>>> >>>
>>> >>
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > OpenDroneMap-dev mailing list
>>> > OpenDroneMap-dev at lists.osgeo.org
>>> > http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
>>> >
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/opendronemap-dev/attachments/20150509/8072067b/attachment.html>