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