lumelix wrote:

Hi Klaus
These settings are the stored default settings in the main window from APG.
You can save there other settings if you want.

Hi Martin!

Of course i DID store them in the settings. But as soon as i use the xml import they´re overwritten and it´s "Gigapixel" again - 47 images . . . I then set it to "strong" manually.
I wonder in which way it influences the stitch when i forget to manually set "strong" - with "Gigapixel" it uses different lens-models . . .

best, KLaus

Last edited by klausesser (2013-03-07 13:20:27)

lumelix wrote:

it's better You install it with admin privilege.

Hey Martin!

I did!

Must be in the PW importer - the issue is the same on Mac: importing 47 pictures makes the importer set "Gigapixel" in the optimizer . . 
though i set APG´s optimizer-preferences to "strong".

The issue is on the PC Win7, on my MacBook Pro and on my Mac Pro (both OSX 10.6.8)

best, Klaus

Hello all,

issue 1827 opened.

Thanks,
Thomas

renan wrote:

- if the group is created from an import pluggin, gigapixel preset is displayed but settings are specially set for plugin import (it's not the same settings than default gigapixel preset)

Renan,

Can you expand on that a bit please.

You seem to be saying that when an Import plugin is used - is this the same for all Import plugins? - a single fixed set of undisclosed settings (based on but not the same as the Gigapixel preset?) is applied regardless of the number of images, regardless of the lens type, regardless of whether it's a mosaic (regular grid/matrix) pattern or an optimised pattern for sphericals panos with fewer images per row as you approach the zenith and nadir.

Is that correct?

Last edited by mediavets (2013-04-04 14:36:11)

When the group is created from a plugin, we save a lot of informations which are not displayed in settings and which make stitching easier and more coherent. It explains why even if you have giga pixel or not, fisheye or not, optimization parameters can be the same.
If you modify displayed optimization parameters, additionnal plugin informations are keept.

For us, the main UI issue is that we can't changed default optimization parameters when we are using a import plugin.

When lens models are not set in exif information, you can disable "auto detection" in import plugin. The group is created and you can manually change lens properties in "image properties" before to launch detection. About distorsion models, I think documentation can be the answer:
http://www.autopano.net/wiki-en/action/ … timization

renan wrote:

When the group is created from a plugin, we save a lot of informations which are not displayed in settings and which make stitching easier and more coherent. It explains why even if you have giga pixel or not, fisheye or not, optimization parameters can be the same.

This is becoming something akin to consulting a legendary Greek oracle...you get an answer but no ordinary mortal can understand quite what it means.

What 'lot of informations which are not displayed in the settings' are you saving and where is this data coming from?

Whether they make 'stitching easier and more coherent' is a matter of debate. For example, it seems to me that too often the Papywizard Import procress permits the movement of images far to far from their recorded co-ordinates relative to other images. This is not 'coherent' behaviour in my opinion.

If you modify displayed optimization parameters, additional plugin informations are kept.

I've no idea what you are trying to communicate here.

Could you try again please.

For us, the main UI issue is that we can't changed default optimization parameters when we are using a import plugin.

Huh? Why not and how does this impact users?

When lens models are not set in exif information, you can disable "auto detection" in import plugin. The group is created and you can manually change lens properties in "image properties" before to launch detection.

Is this another example of the 'Auto' in Autopano getting 'lost'. If such user interaction is required should the Import plugin not warn the user appropriately?

Perhaps we need thoroughly documented examples of scenarios in which you can, and cannot, expect the Import plugins to work fully automatically; and a complete description of the user interaction required in those instances when fully automatic operation is not viable.

My expectation of the Import plugins is that they will work fully automatically. It seems this naive 'faith' is probably misplaced?

Last edited by mediavets (2013-04-05 13:18:55)

klausesser wrote:

Regarding the distortion model it seems to me using "automatic" maybe the best way - how would i know which of the other settings
match my lenses resp. which values must i take in account?

Hi

I ran in an "lens distortion"- issue I have posted two weeks ago (but until now unfortunately no answer):
http://www.kolor.com/forum/t17292-apg-3 … s-problems

Unusually, I used a lightweight traveling zoom lens (55-300mm DX) to do a little gigapano.
I used then the gigapan import module and standard setting for detection and optimization.
I got a good stitching and RMS.

But: APG calculates different focal lengths, they are getting longer and longer to the right side of the pano.
So the pano is at the right side 15% smaller than at the left side.

To avoid this, I set the focal length on "identic" for the lens distortion correction.
But then, APG calculates identic but much to large focal lenght and I get only a bad RMS above 8.

Looks as if there is a connection between the import modules and the settings for the lens correction.

klausesser wrote:

Using "automatic" as lens correction-model i never had a major issue - but: how would i know having one?

I haven't one also - until now, when I'm using an unusual lens like this 55-300mm zoom.
What should I do with a "conical" panorama?
I've tried minimum 30 different ways of settings with and without import plugin but did not receive a satisfactory and useful result.
This is probably because we don't know exactly what happens in the background of APG.

So i'm very interested in further information about this.

mediavets wrote:

Yes and no:  it appears from what Renan wrote that the Import plugin also reads some EXIF data when reading the XML file and then tweaks some APP/APG internal settings depending on what it finds in the EXIF.

But there are no lens-parameters at all in the xml - besides of the focal-length and whether it´s rect. or fish. So there can be only global connection or communication about lens-correction-parameters with PapyWizard. Aside via the EXIFs . . . . which on the other hand are not related to PapyWizard-xml at all.

That´s the point where the optimizer comes into play - when this one relates on the EXIFs on one hand AND on PW`s positions/focals/sensor on the other hand THEN the connection is there and the lens-model/-correction can be done properly . . . *IF* the importer interpretes the informations properly from PW as well as from the EXIFs.

But when there are no EXIFs . . . . the importer can´t knoiw anything about the lens-model besides of it´s focal and rect/fish andt the sensor size.

Seems that´s enough anyway - because usually it works pretty well . . . Nevertheless for being able to avoid time-consuming mismatches it would ´be nice to learn what´s under the hood . . .

best, Klaus

Last edited by klausesser (2013-04-05 19:49:38)

mediavets wrote:

Klaus,

The thing that perhaps most puzzles me is that sometimes APP/APG will produce a better result if you don't use the Papywizard Import wizard than when you do.

Have you seen that too?

That seems irrational - you would think that providing the additional image co-ordinate data should improve the result and never make it worse?

Hey Andrew!

Depends on what/how you shoot.

Shooting with a 35mm indoors and having white walls and celings you´re lost without xml-import - you´ll have to move and place by hand image after image.
Using the xml it´s done in seconds.

Shooting outdoors or indoors using an 85mm you´re completey lost without xml - or you´d need two days or so for placing the shots by hand and fine-tune them using the optimizer.

I don´t believe it´s the import-wizard - after having understand what it does, which definitely isn´t easy - i believe it´s the optimization following the import.
You simply can´t estimate what it does - we have no deep informations to reliable and reproducable use it for time-effective working.
With every job i first need to experiment what i need to set the optimizer for - after having placed the images almost perfectly by the xml import.
Finetuning then most likely puzzles them more or less.

Using the Panoneed-generated PapyWizard xml in PTGui the whole thing organizes itself with usually very fine results in seconds.

Here the strategy is different:

FIRST you import the images and align them. If that´s not good enough THEN you import the xml.
You can view then in the editor that mis-aligned images gets placed correctly. ONE run of the optimizer - and the stitch is perfect.

This way i could do stitches easily where APG failed.

MAYBE i would have get them done in APG also - but: HOW? It´s too much try and error - that costs plenty of time only to find wich option does what related to what i need to be done.

best, Klaus

Last edited by klausesser (2013-04-06 13:48:50)

mediavets wrote:

And isn't that just the whole point - Kolor devised the Papywizard Import wizard long before PTGui was able to make use of Papywizard-compatible XML data files.

Seems they didn´t see a need for this. That was a bit short-sighted.

mediavets wrote:

Yet it seems PTGui can produce better results more consistently.

You can reach the same results with APG also - but not as consistently in my eyes, yes. On the other hand you can do very fine stitches using APG where PTGui fails.
And vice versa.
The problem is: you most likely will realize it only after you tried . .

mediavets wrote:

So what's 'broken' in the Papywizard Import detection and stitching process in APP/APG?

At the moment i have no issues at all regarding the import! So i guess there´s nothing "broken" at all.

It´s just a question of transpareny in using the import and the optimizer i mean.

And THIS i guess isn´t related to the optimizer basically - the problem seems to be communicating how to use it in detail.

The "documentation" definitely is just rudimental. Such a complex application NEEDS a - professionally made - handbook!!

I know some dozens PTGui-users who took intense interest in APG - but get horrified after a short time of evaluation. I also guess PTGui implemented PW-import for the growing numbers of gigapixel people - who switched to APG for getting XML support.

PTGui users never expected - and never were promised - any "automation". NOT to promise anything "auto" was rather clever i guess . . . .

best, Klaus

Last edited by klausesser (2013-04-06 14:34:57)