Image Correction

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Image Correction

Cole
I have a image calibration class up at 


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
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Image Correction

Stephen Mather-2
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 <[hidden email]> wrote:
I have a image calibration class up at 


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
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev



_______________________________________________
OpenDroneMap-dev mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Image Correction

Cole
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 <[hidden email]> 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 <[hidden email]> wrote:
I have a image calibration class up at 


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
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev




_______________________________________________
OpenDroneMap-dev mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Image Correction

Alex Mandel-2
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 <[hidden email]>
> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
>>>
>>>
>>
>
>
>
> _______________________________________________
> OpenDroneMap-dev mailing list
> [hidden email]
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
>

_______________________________________________
OpenDroneMap-dev mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Image Correction

Stephen Mather-2
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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
>>>
>>>
>>
>
>
>
> _______________________________________________
> OpenDroneMap-dev mailing list
> [hidden email]
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
>



_______________________________________________
OpenDroneMap-dev mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Image Correction

Stephen Mather-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
>>>
>>>
>>
>
>
>
> _______________________________________________
> OpenDroneMap-dev mailing list
> [hidden email]
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
>




_______________________________________________
OpenDroneMap-dev mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Image Correction

Stephen Mather-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
>>>
>>>
>>
>
>
>
> _______________________________________________
> OpenDroneMap-dev mailing list
> [hidden email]
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
>





_______________________________________________
OpenDroneMap-dev mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Image Correction

Cole
I just finished a major project at work as well as finals, I will definitly have time to work on ODM over the next few weeks.

v/r
NJK

On Sat, May 9, 2015 at 8:44 AM, Stephen Mather <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
>>>
>>>
>>
>
>
>
> _______________________________________________
> OpenDroneMap-dev mailing list
> [hidden email]
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
>






_______________________________________________
OpenDroneMap-dev mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
Reply | Threaded
Open this post in threaded view
|

Re: Image Correction

Stephen Mather-2

Awesome to have you back. Hope you get some good rest in too.

Cheers,
Steve

On May 9, 2015 11:52 AM, "Cole" <[hidden email]> wrote:
I just finished a major project at work as well as finals, I will definitly have time to work on ODM over the next few weeks.

v/r
NJK

On Sat, May 9, 2015 at 8:44 AM, Stephen Mather <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
> 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 <[hidden email]> 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
>>> [hidden email]
>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
>>>
>>>
>>
>
>
>
> _______________________________________________
> OpenDroneMap-dev mailing list
> [hidden email]
> http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev
>






_______________________________________________
OpenDroneMap-dev mailing list
[hidden email]
http://lists.osgeo.org/cgi-bin/mailman/listinfo/opendronemap-dev