MiniPanoBot new shooting pattern

[vklaffehn]

MiniPanoBot new shooting pattern

by vklaffehn » Wed Jun 05, 2013 5:19 pm

Hi!

Coming from here http://www.kolor.com/forum/t17752-warped-images-in-pano I changed the software on my selfmade miniPanoBot, so instead of only shooting in a grid pattern like the GigaPan I scratched my head to find out how I could calculate more optimal image positions while using my small PowerShot A590is at 35mm equiv. Now I have reduced the needed photos from 60 to 34 and optimized the moving pattern, reducing the shooting time for a 360x180 pano from about 6 to about 3 minutes, doing bracketed shots reduced from 10 to 6 minutes(180 vs. 102 photos), speeding up detection time and image quality. I'm shooting 6 rows, starting at 75° up, ending at 75° down with 30° steps, images taken per row where 3 - 6 - 8 - 8 - 6 - 3.
Photos where thrown at APG 3.0.5 64bit Windows 7 / I5 2570K 32GB RAM, detection quality set to high.

See attached results :

[mediavets]

by mediavets » Wed Jun 05, 2013 9:50 pm

You seem to have achieved an excellent result for your efforts.

[Christian Stüben]

by Christian Stüben » Thu Jun 06, 2013 6:54 am

When you search for new shooting pattern, have a look here: http://www.wackel3d.de/shootpatterngenerator.aspx

You have several predefined sensor sizes (click on the + befor sensor sizes), you have to enter the focal length, and click on calculate landscape / calculate portrait.

Or if you already know the horizontal and vertical angle in degree, you can enter them manualy.

The calculator is for rectilinear lenses, for fisheye it is nearly unuseable.

greetings from germany
Chris

[klausesser]

by klausesser » Thu Jun 06, 2013 10:35 am

You seem to have achieved an excellent result for your efforts.

Yes! I agree!

best, Klaus

[vklaffehn]

by vklaffehn » Thu Jun 06, 2013 5:23 pm

Thanks a lot!

the challenge is not to find or calculate optimal shooting patterns (although it's not THAT easy...), but to get the two small microcontrollers to calculate them. The 2 stepper motors are driven by an Atmel Tiny2313 with only 2 KB ROM, which usage jumped from 68% to 77% just by adding some arithmetics which adds an addiditonal step for the motors every 99th step (turn 1° needs 33,33333 steps, 360° are 12000 steps), and the main µC is an ATMega8 with 8KB ROM, there are still 4KB left :-) Jut got some ideas to optimize it a bit more, and to get it more flexible.

MfG
Volker Klaffehn

[vklaffehn]

by vklaffehn » Sun Jun 09, 2013 9:41 pm

Hi!
Thanks, Christian, for the link, but I managed to get the necessary math implemented in my panohead using a lookup table and some fix point aritmethics :-)
You set the angle between the shots on the horizon and it will automatically calculate the reduced numer of shots needed when looking up/down a certain angle, i.e. setting the starting angle to 45° it will nicely produce the above pattern. The software will also reduce the angle between the shots to an angle wich the FOV can be divided through without rest. For example setting the start angle to 45° on a 360x180 will work fine, giving exactly 8 positions, but looking up/down a certain angle, the calculated angle between shots could be something like 163, so you need 3 images to get all 360° covered, now my routine uses the number of shots needed to calculate a proper angle, in this case 360/3 = 120°. So I always have a nice regular pattern like you can see above. The nice thing is that this also optimizes panoramas with another FOV, so shooting something with a FOV of 80° will automatically use 40° steps, without the need to chamge the setting.
That was a lot of head scratching and generating big excel tables with many formulas to get it reduced enough to get it in this small AVR ATMega8 controller :-)
I even reduced the back lash of my gears, so the noise level was reduced a lot and I was able to drive the motors a little faster, so bracket shooting a 360x180 at +-5EV is done now in about 5 minutes, resulting in an image set consisting of 102 images :-)

So, good night for today!!!

[Christian Stüben]

by Christian Stüben » Mon Jun 10, 2013 7:15 am

Hi!
Thanks, Christian, for the link, but I managed to get the necessary math implemented in my panohead using a lookup table and some fix point aritmethics :-)
You set the angle between the shots on the horizon and it will automatically calculate the reduced numer of shots needed when looking up/down a certain angle, i.e. setting the starting angle to 45° it will nicely produce the above pattern. The software will also reduce the angle between the shots to an angle wich the FOV can be divided through without rest. For example setting the start angle to 45° on a 360x180 will work fine, giving exactly 8 positions, but looking up/down a certain angle, the calculated angle between shots could be something like 163, so you need 3 images to get all 360° covered, now my routine uses the number of shots needed to calculate a proper angle, in this case 360/3 = 120°. So I always have a nice regular pattern like you can see above. The nice thing is that this also optimizes panoramas with another FOV, so shooting something with a FOV of 80° will automatically use 40° steps, without the need to chamge the setting.
That was a lot of head scratching and generating big excel tables with many formulas to get it reduced enough to get it in this small AVR ATMega8 controller :-)
I even reduced the back lash of my gears, so the noise level was reduced a lot and I was able to drive the motors a little faster, so bracket shooting a 360x180 at +-5EV is done now in about 5 minutes, resulting in an image set consisting of 102 images :-)

So, good night for today!!!

And all this in a 2 kb rom? Great work!

And yes, my generator had been a lot of headscratching too. You can either enter the vertical and horizontal angle of your lens, or it can calculate the angles by focal length and sensor size. Useable for wide angle up to telephoto. For superwideangle, let me say 14mm on full frame, or for fisheye, my algorithm is unuseable.

Plus the desired minimum overlap horizontal and vertical gives the final steps.

greetings from Wuppertal
Chris


ps i see you come from Braunschweig. When you ever come near Wuppertal, phone me. I am curious to se your little machine.

[kalain]

by kalain » Thu Jun 13, 2013 7:34 am

Thanks a lot!
the challenge is not to find or calculate optimal shooting patterns (although it's not THAT easy...), but to get the two small microcontrollers to calculate them. The 2 stepper motors are driven by an Atmel Tiny2313 with only 2 KB ROM, which usage jumped from 68% to 77% just by adding some arithmetics which adds an addiditonal step for the motors every 99th step (turn 1° needs 33,33333 steps, 360° are 12000 steps), and the main µC is an ATMega8 with 8KB ROM, there are still 4KB left :-) Jut got some ideas to optimize it a bit more, and to get it more flexible.
MfG
Volker Klaffehn

Hi Volker,
I'm always excited to see how people are genius in their home made pano head. Always interesting to see some new concepts.
Is there some pictures to see and share ?

Regards

Last edited by kalain on Thu Jun 13, 2013 7:35 am, edited 1 time in total.

[Artisan S.]

by Artisan S. » Thu Jun 27, 2013 11:26 am

I use a lookuptable but then I have a lucious 32.256 bytes to play with :-) on my Arduino One. The whole program will be about 16 Kb.....but it can use lenses from 15mm FE to 150mm tele and Gigapans using 90mm till 400 mm FF, now I could make it calculate but I've decided against it. I want the Arduino to be controling positions not calculating them (so I use brute force but only once and that is of my i5). But your approach is of course great.

Greets, Ed.

[vklaffehn]

by vklaffehn » Wed Jul 10, 2013 10:25 pm

Hi, I just put up some pictures of the history of my panorama robot journey :-)

http://panografie.klaffehn.com/?page_id=2
Only in german at the moment ....

MfG
Volker Klaffehn