TomNai wrote:

Software: Autopano Giga 3.0.1, Win 7,  64bit

Don´t know whether that helps: the actual version is 3.0.3

best, Klaus

see Memory calculation formula from Hans for scratch disc and Memory and the Ratio of both...
http://www.kolor.com/forum/p87033-2011- … -58#p87033
with 8GB I assume you have a bader Ration than 1:4...
so make sure your scratch disk listed in first place is big enough to not be forced to Switch to second listed and preferred the temp dir should be a SSD.
so try to delete the temp HD from your listing so only the SSD is listed.

than calculate the Ratio from Hans formula. if preview is slow nwo than if Ratio is 1:3 or worse than the Rendering will take very very Long

test if the GPU is enabled and if yes if the GPU test in apg does succeed. make sure to sue the most recent Drivers for your GPU. if you use them ist also possible thsat the second newest Drivers work better...

PS: with 200 Image pano I even have with 16GB a very slow System.... so for gigapixels doing on regular Basis, try to upgrade your System to 64GB ram or more.

Georg

Last edited by gkaefer (2013-02-16 00:06:50)

@Klaus: Yes of course I tried with the lastest version first (but I had the same problem). Some  posts in this forum recommended using 3.0.1 rather than the newer releases.

@mediavets: I meant the panorama editor, when it is opened, it puts the panorama together, image by image - and that process is rather slow on my machine. I did the GPU check and it seems to be is working fine.

@Georg: I assume that formula for memory consumption refers to stitching. However I didn't get that far, I am still stuck in the panorama editor.

So whats my progress so far?

I let the panorama editor complete the preview image overnight. Now, that its  morning, it has crashed saying"unexpected error". Another message box generated from APG says  "computer has not enough memory".  Okay, thats what you already told me.

I thought that in case of a memory shortage the machine would resort to the temporary folder (specified in the apg settings) on my SSD (170 GB), and get (maybe quite) a bit slower?

I retried once more, now the tempory folders are reduced to the SSD only (as suggested by Georg).
I realized that the temporary folder on the SSD is not even used by the panorama editor. Rather it seems to use RAM only, but its slow from the beginning when there is still sufficient memory available. The task manager shows, that while the panorama editor is drawing the panorama, the RAM usage of APG gradually increases. Now the RAM is almost completely used, but APG continues drawing the panorama preview.


Now I try the following: I increased the pagefile.sys to 60 GB and put it on the SSD. So the virtual memory is increased, and faster than if it were on a harddisk.
The panorama editor is still as slow as before, but I hope it will finish its job this time.


BTW I recently stitched a 10 GPixel Panorama on the same machine using PTGUI Pro, in just a few hours - not a big deal, the final image had about 30 GByte. Moreover, the panorama editor of PTG, even though it doesnt't put together the panorama preview instantly, it takes only a short while (a few minutes at most - after optimization, usually faster) to completely update the preview. To me it doesn't seem that my hardware is the limitation.


How fast is  the preview image drawn in the apg panorama editor on your machines? (assuming you have a something like a 4 GPixel panorama)

But anyway, I thought that the panorama editor is working with the GPU and therefore needs a lot of Graphics card memory... Did I get that wrong?
Initially I tried with the GPU disabled: in that case the editor finished drawing the preview, of course at very low resolution, actually too low to check if all images are positioned correctly...

Next, I'll try to render the panorama (skipping the panorama editor). Just to see if that works.

@ mediavets
I didn't mean to offend your product, not at all.
There are quite a few reasons for APG: In the other SW I use  vignetting correction doesn't seem to work with my camera, the editor is a bit limited (I hoped I can do better, and faster in APG), support for automated platform in this other SW is still very limited... and Kolors Neutralhazer seems to be an interesting feature too.

The kolor website says about the recommend hardware configuration:
    The 64-bit version of your operating system if your hardware can handle it (eg. Windows Vista 64 bits, Mac OS 10.8 - 64 bits, Ubuntu 9.04 - 64 bits, etc)
    A 2 GHz processor or more
    Multi-core processors
    4 Gb of RAM or more
    A recent graphics card with dedicated memory

There is also a minimal configuration given which has much less performance...

My hardware is quite a bit better than the recommended configuration. And as the softwares name is autopano GIGA it would expect it can handle gigapixel images also with the recommend configuration? 

Everybody here is telling me that I need much more RAM, that means I have to buy a new computer... makes me not so happy.


Anyway - possibly  I have solved my problem and the new computer can wait:
Now apg did finish the preview image  in the panorama editor (unlike before) - probably the additional virtual memory on the SDD was the solution. Once that the image is finished I can now zoom in and out, scroll etc. - fine.


When does apg make use of the temporary folders? Only for the rendering?

Last edited by TomNai (2013-02-16 12:30:39)

At the moment I avoid the need for vignetting correction by employing a lot of overlap (about 50%). 
PTGUI supports XML and  I am using this. It also has a grid function (like Gigapan). However, it doesn't seem to care about adjacent images when it is searching for control points. So there is a lot of manual work to do in the panorama editor (e.g. connecting gaps,  manually shifting images showing sky and clouds only). My hardware is a homebrew setup, panoduino-style, remotecontrolled via a netbook, quite precise ( I am regulary imaging at f=600 mm (35 mm equiv)), and pretty fast (about 1.7 s/image).

TomNai wrote:

At the moment I avoid the need for vignetting correction by employing a lot of overlap (about 50%). 
PTGUI supports XML and  I am using this. It also has a grid function (like Gigapan). However, it doesn't seem to care about adjacent images when it is searching for control points. So there is a lot of manual work to do in the panorama editor (e.g. connecting gaps,  manually shifting images showing sky and clouds only). My hardware is a homebrew setup, panoduino-style, remotecontrolled via a netbook, quite precise ( I am regulary imaging at f=600 mm (35 mm equiv)), and pretty fast (about 1.7 s/image).

Hey Tom!

I haven´t read about your hardware before my first reply, sorry.

Fact is - as others mentioned already - you need a very capable machine to get done what you need.
Definitely 50% overlap is much too much! I usually use 20-25%: http://360impressions.de/Wuppertal/

PTGui´s PapyWizard import runs very well - it "cares about adjacent images" by searching control points when you run the optimizer. This way it produces rather perfect results rather quick.
APG also produced very good results - but you need to do rather complex optimizing. In my experiences you need to do much more manual work in APG than in PTGui - sorry, Kolor

The procedere of importing the images FIRST without xml, havinvg the imgages positioned by control points and only THEN import the xml for placing the images again lets you see where the issues are. You can see how the first hand orphaned images are placed precisely by the xml - and that shows where the issues are.
Running the optimizer after that usually provide very good results. I mean that is a very good strategy.

But in the end i definitely prefer APG over PTGui because of several reasons - APG´s strategy maybe a bit cumbersome sometimes - but sometimes it gets things done which PTGui can´t.

The major question is: how good does your head-/controller-generated xml match with the xml-import!?

best, Klaus

@Klaus: You are absolute right, 50% is too much. Its a problem that I have since I am using the FZ200 (usually at long focal lengths). The vignetting doesn't seem seem to be centered at a fixed position, but varies a little bit from image - maybe the electronic stabilizer? Actually vignetting correction makes thing worse... But thats yet another issue.

The xml my panohead generates is adopted from papywizard, it loads without problems by PTGUI and by APG.
But for  convenience I normally use the grid function.  PTGUI often fails putting control points between adjacent images (according to the forum its planned to be included, some post from the end of 2011). Well, maybe I should give  the papywizard import another try.

Lets get back to Autopano.

Well, 4 GPixel isn't that large... I shot that panorama in about half an hour ;-). Actually Idon't care about a race for bigger and bigger panoramas, I just wan't to image the world every detail, and I'like to catch a panorama in snapshot, at least as fast as possible. Well,... I end up with bigger and bigger panoramas.

A question about workflow:  It seems to take a while (about 1.5 h) until the editor shows the complete panorama consisting of 1000 images. When its  loaded (even before)  I can do all kind of editing - I got it working! 
I am now wondering if some high end-machine allows much more fluent working in the editor. For exampe,  if the panorama editor shows a section of 70 images, scrolling the image by one step  takes about 3 seconds (maybe its loading data from the SSD). For now thats okay. If somebody could  tell me this can be done much faster on a better machine... then maybe I should consider spending money on  a faster machine...


Anyway, I am still playing with the editro , I haven't tried stitching yet... hope it works.

TomNai wrote:

The xml my panohead generates is adopted from papywizard, it loads without problems by PTGUI and by APG. But for  convenience I normally use the grid function.  PTGUI often fails putting control points between adjacent images (according to the forum its planned to be included, some post from the end of 2011). Well, maybe I should give  the papywizard import another try.

Why is it so much more 'convenient' to use the grid rather than the XML file? I presume you are talking abiout PTGui is this instance?

The whole point of utilising the XML format data of shooting positions - at leasst with APP/APG - is that it enables adequate placing of images even in those cases where it's not possible for the software to identify control point because adjacent images appear to lack matching features. And this should produce better results than using support for a simple 'grid/amatrix' defined just be number of rows and columns with an estimate of overlap.

Anyway, I am still playing with the editor , I haven't tried stitching yet... hope it works.

I guess you mean you haven't tried rendering yet? The stitching is effectively complete by the time you load the pano image in the Panorama Editor.

Anyway be prepared to a LONG wait - if it manages to complete the rendering task at all - judging by the time it takes to load into the Panorama Editor on your system.

Last edited by mediavets (2013-02-16 15:36:35)

TomNai wrote:

The xml my panohead generates is adopted from papywizard, it loads without problems by PTGUI and by APG.

What i meant: how precise is the mechanic following the xml? Only with a VERY accurate mechanic you can be sure the positioning according the xml is as precise as the xml states!

I read: "My hardware is a homebrew setup, panoduino-style, remotecontrolled via a netbook," - but which head are you using?

best, Klaus

PS: sorry - seems you use a Merlin.

Last edited by klausesser (2013-02-16 15:53:10)

klausesser wrote:

TomNai wrote:

The xml my panohead generates is adopted from papywizard, it loads without problems by PTGUI and by APG.

What i meant: how precise is the mechanic following the xml? Only with a VERY accurate mechanic you can be sure the positioning according the xml is as precise as the xml states!

I read: "My hardware is a homebrew setup, panoduino-style, remotecontrolled via a netbook," - but which head are you using?

best, Klaus

PS: sorry - seems you use a Merlin.

No, Tom is not using a Merlin (despite his sig) - see:  https://sites.google.com/site/thomasnai … maplatform

TomNai wrote:

@Klaus: You are absolute right, 50% is too much. Its a problem that I have since I am using the FZ200 (usually at long focal lengths). The vignetting doesn't seem seem to be centered at a fixed position, but varies a little bit from image - maybe the electronic stabilizer? Actually vignetting correction makes thing worse... But thats yet another issue..

What camera settings, and focal length, are you using when you experience this variable 'vignetting'?

Can we see some examples?

@mediavets:
This is an example:  http://www.gigapan.com/gigapans/119662    Here the vignetting is not corrected. And also, the overlap was too small, which is not so good on a windy mountaintop (there are quita a few stitching errors...)

Imaging parameters - typically f=600 (35 mm eqiv) aperture 2.8, all parameters fixed.

I did some 'research' on that making "blue sky" shots - to extract the intensity profiles.
Actually the magnitude of the vignetting is relatively moderate. It just seems that the position of the vignetting is moving laterally, randomly from one image to another by several hundred pixels - and I suspect the image stabilizer.