 |
|
|
|
|
|
 |
| ||||||||
 |
 
|
|
|
|
|
|
|
|
|
| ||||||||
|
|
| 
| User list | Rules | You are not logged in.
Pages: 1 2
I use a Lumix FZ200.
Anything automatic is deactived - apart from the IS, but maybe I should also deactivate that too. With my Powershot G9 or the Lumix FZ28 I never had problems with the IS.
That pano on the gigapan site was not made with a merlin. I only once carried up the Merlin onto moutain, and then I decided to do my own thing. Its heavy, and its way too slow. As I wrote, I have panoduino-style platform that I built on my own:
http://sites.google.com/site/thomasnais … maplatform
Last edited by TomNai (2013-02-16 16:38:20)
Offline
How precise is the mechanics? At f=600 mm. Assuming an image with of 4000x3000 pixels. I guess the average variation is maybe +-100 to 200 pixels. Peak variation (wind etc.) maybe something like 400. I imported the XML file to APG (wasn't exactly the panorma from the Gigapan site) and stitching worked pretty well (Global RMS 3.68).
Offline
TomNai wrote:
@mediavets
Just technical details and laziness, and the fact that I programmed a little grid-based stitcher for a scientifc project on my own - long ago. That thing was simple and worked well. So I don't expect a big advantage of the (just a little bit more) precise positions from the XML.
Another benefit of the XML format data approach to image placement when stitching - as opposed to a grid algorithm - is that it can handle an irregular non-grid/matrix shooting pattern.
When shooting spherical panos with longer focal length lenses using robotic pano heads it is desirable to reduce the number of images per row as you approach the zenith and nadir to avoid excessive overlapping and consequent potnetial stitching problems.
Offline
4Gigapixel???? no. you cant say I've 50%overlap so there are less Pixel the stitcher has to hold in Memory.
3.000 x 4.000 Pixel = 12 MP / Image * 1000 Images * 4 (according Hans formula) = 48 GB scratch dísc you Need for the temp.
you have 8 GB Ram so a Ratio of 6:48 = 1:6 ... so ist very likely you will not finish that "small" Panorama with your Hardware.
Again: even upgrading from 8 to 16 GB only gives you some air so lets say up to 300 Images. more you Need more than 16GB.
and ist also needed for loading the Images, the panodetection is also a process where all Images must be loaded and the Content has to taken into Memory... if the Images have no space in the Memory available than swapping will take place and that has to be slow.
Georg
Offline
Your were absolutely right. For Gigapixel panoramas APG wants RAM, RAM and yet more RAM.
Today I built my new PC with an Asus P9X79 Mainboard, an i7-3820 CPU, 64 GB RAM, a 256 GB SSD, and an Nvida Graphics Card with 4GB memory. With that machine working with APG is quite a bit more fun. The editor loads the preview of 1000 images in a few minutes rather than in one or even 1.5 hours. And rendering a reduced size panorama of 1 Gpixel (TIFF which I can still load in Windows image viewer), takes around 15 minutes (requiring at max about 56 GB of RAM).
BTW - is there any FREE software that can display psb image files?
Well, another issue, after rendering (with APG 3.0.3) it doesn't seem to free the memory, it is still using 63.2 GB of RAM... Is there a solution to free the memory (I mean, apart from closing APG) ?
Best regards
Tom
Offline
3.0.3. is not freeing up memory used by the preview function. I had to go back to 3.0.1. because of this.
Online
Pages: 1 2
