How do I force Autopano to blend more between images.

[kurt765]

How do I force Autopano to blend more between images.

by kurt765 » Thu Mar 24, 2011 6:39 pm

I can't recall having this problem before, but Autopano Giga 2.5 is really doing a bad job of blending a couple of images. I think I've tried every setting I can think of.

How can I force Autopano to do more blending here? Even a simple feathered mask would do the trick. There's no lens distortion to speak of or anything. I don't want to have to do it manually in photoshop.

Here's what it looks like:



Look at that obvious vertical line! There are several hundred pixels of overlap, and no matter what I do it has this bad blend at this spot.

-K

[gkaefer]

by gkaefer » Thu Mar 24, 2011 7:07 pm

can you post 2 source image so we can play with?
Georg

[klausesser]

by klausesser » Thu Mar 24, 2011 7:49 pm

Here's what it looks like:

Is this where the left and the right end of the pano meet? What is it that you show here? The equirectangular rendering or two stitched images? Did you use automatic settings on your camera? Did you use colorcorrection?

best, Klaus

[AlexandreJ]

by AlexandreJ » Fri Mar 25, 2011 9:11 am

This seems typical of a setting bug we had when installing version 2.5 over 2.0. Please uninstall v2.5 and reinstall it again.
It should be good then.

[marzipano]

by marzipano » Fri Mar 25, 2011 12:30 pm

I have exactly the same problem as this posting

As advised I have now tried a re-install of APP 2.5 (it would have been nice if someone had mentioned this when I posted the same blending problem 3 weeks ago!)

It didn't make any difference unfortunately

I have done more tests on blending between 2.0 and 2.5 and I still maintain 2.0 is noticeably better. I have attached some evidence to this posting

It seems that the best blending results in 2.5 are obtained when using Multiband at the -4 level (default) and unchecking the Anti-Ghosting box whilst checking the Exposure Fusion box (and leaving everything else unchecked). However, the ghosting errors then become unacceptably severe. So it looks like an either/or problem that you can either have good anti-ghosting or good blending in 2.5 but not both at the same time

I'm talking here about "average" original photos taken hand-held on automatic with a budget priced pocket digital camera (I use a Nikon Coolpix 7900 At 7.1 MPixels res). I accept that using a tripod with a motorised head and full manual controls will always give much better results but There is a large market for a good quality panorama product that gives acceptable results on "everyday" photos

Anyway I have annotated the attachments below and they all represent the overlap area of part of a larger panorama where this part was formed of 3 originals

[klausesser]

by klausesser » Fri Mar 25, 2011 1:30 pm

I'm talking here about "average" original photos taken hand-held on automatic with a budget priced pocket digital camera (I use a Nikon Coolpix 7900 At 7.1 MPixels res). I accept that using a tripod with a motorised head and full manual controls will always give much better results but There is a large market for a good quality panorama product that gives acceptable results on "everyday" photos

Hi Marzipano!

APP/APG´s ability to stitch even somewhat adventurously taken shots really is great without any doubt. I tried all stitchers which are around - in my eyes APG is the very best one.

On the other hand we should not forget that stitching spherical panos or mosaic panos is mathematically challenging - and not only for the stitcher but also regarding the way the photographs are taken.

It´s always a question of what you want to do and what´s the goal. For panographing using compact cameras you shouldn´t expect a really good quality because of the - honestly - mediocre quality those cameras provide in respect of resolution, sharpness, noise, colors and so on.
And using those cameras in full automatic mode ruins the rest.

So better accept that shooting for panos to get appropriate results you have to regard some basics: Nodal point when shooting at average distances and definitely no automatics.
You don´t need a motorized panohead - you don´t even need a tripod necessarily . . but you need to try turn around a virtual NPP as exactly as possible and you need to switch off automatic WB, AF and time/aperture.

Get a monopod and an adapter which puts your camera to meet the NPP at least approximately. That´s not too much to ask for shooting panos . .

best, Klaus

[marzipano]

by marzipano » Fri Mar 25, 2011 2:18 pm

Hi Klaus

I agree with you - having looked at and trialled a number of the products on the market I can say I fully agree that APP and APG are by some way the best stitching / panorama generation products on the market right now

However, of the two main products I can see that APP is more aimed at the mass market whilst APG is more aimed at professional photographers (I use APP). For this reason I would really hate to see APP move from being a "User Friendly" to "Expert Friendly" product.

I do generally take care with the panoramas I take (including a lot of your advice) but I treat it as a hobby not a profession

No-one as yet has properly explained my findings on both the stitching and blending problems which seem to exist in 2.5 but weren't so apparent in 2.0.9

best
Martin

[renan]

by renan » Fri Mar 25, 2011 4:36 pm

Actually, the most pertinent comparison is between 2.09 smartblend and 2.5 antighost preset. Other algorithms does not exist in 2.09 version.

Exposure fusion algorithm is useful for blending bracketed pictures. If bracketed pictures are not well aligned (without tripod), blur edges will appear. Remove HDR ghost algorithm try to remove theses misalignment but the result can't be perfect.

Antighost algorithm is applied on each APG layer and exposure fusion on all pictures. So in present case, antighost + fusion will have the same result that antighost only. Antighost will kept one pixel per position and the fusion on one pixel only has no effect.

More details can be found at this page :
[url]http://www.autopano.net/wiki-fr/action/view/Autopano_Giga_2.5_-_LDR_/_HDR_:_Comment_ça_marche[/url]
The English version must come soon.

[klausesser]

by klausesser » Fri Mar 25, 2011 5:18 pm

The English version must come soon.

How right you are . . :cool::cool:

best, Klaus

[leedsjoe]

by leedsjoe » Sat Mar 26, 2011 7:50 am

D'accord!

[DrSlony]

by DrSlony » Mon Mar 28, 2011 12:59 am

"Must" I love it :]

[AlexandreJ]

by AlexandreJ » Mon Mar 28, 2011 12:15 pm

In fact, this page was forgotten by the translator ... We are so unlucky.
It should / must / Has to be done soon.

[gkaefer]

by gkaefer » Mon Mar 28, 2011 4:06 pm

To be honsest: this is a backcoming issue as it seems and it is still unconvinient for all. the pdf documentation did take very long time to be released after the software was available....

If I look abroad to other products from other companies, I've to say that there's lot of place for optimization for kolor ... ;-)

have a look at just released OS for the fortinet Fortimail (its a mailfirewall). The docu has about several hundret pages more than the autopano docu and there the docu is always released together with the software:
http://docs.fortinet.com/fmail40.html
(and PS: the pdf is not only a printed website converted to a pdf, it has a formations of a printed book, searchable indexes, cklickable links etc...)

Georg

[AlexandreJ]

by AlexandreJ » Tue Mar 29, 2011 8:13 am

I totally agree with you Georg.

[[bo]]

by [bo] » Tue Mar 29, 2011 10:07 am

Still, if any of you, fellow Autopano users, had to choose between:
1) faster development and deployment of new features and bug fixes
2) better documented features and more testing before releases

What would you choose? I'd go with 1) any day!

I think it's better to have daily/weekly builds with poor documentation, while the official stable releases (like 2.0, 2.5, etc) should take more time and arrive with complete documentation.

Re: PDF version, maybe someone at Kolor should look at WIKI-to-PDF solutions like PediaPress or HTMLDoc?

[AlexandreJ]

by AlexandreJ » Tue Mar 29, 2011 10:50 am

'Re: PDF version, maybe someone at Kolor should look at WIKI-to-PDF solutions like PediaPress or HTMLDoc?

It's already installed and should work. We just need to fix some layout issue to make it available.

[klausesser]

by klausesser » Tue Mar 29, 2011 11:53 am

']Still, if any of you, fellow Autopano users, had to choose between:
1) faster development and deployment of new features and bug fixes
2) better documented features and more testing before releases

What would you choose? I'd go with 1) any day!

I think it's better to have daily/weekly builds with poor documentation, while the official stable releases (like 2.0, 2.5, etc) should take more time and arrive with complete documentation.

Re: PDF version, maybe someone at Kolor should look at WIKI-to-PDF solutions like PediaPress or HTMLDoc?

2) Definitely.

What do new features help me if i can´t use them appropriately because i either don´t know about them nor don´t know how they work nor they work as expected?

Instead i need hours and hours and nights of trying and erroring to find out what´s going on with those new features - how they work and how i can integrate them into my workflow.

best, Klaus

Last edited by klausesser on Tue Mar 29, 2011 12:00 pm, edited 1 time in total.

[GURL]

by GURL » Tue Mar 29, 2011 1:59 pm

']Still, if any of you, fellow Autopano users, had to choose between:
1) faster development and deployment of new features and bug fixes
2) better documented features and more testing before releases

Both ...and this is not a joke!

Interactions between Autopano users and Autopano developers differ from the way this is carried out by usual software companies (for example PTgui) and by open source groups (for example Hugin):

- Some users pay a given amount of money for Autopano, an application which, they hope, is more easy to use than the competing ones but is able to stitch the panos these applications can stitch (or about.) Don't forget that "more easy" means the shorter the manual the better, so that in my opinion some difficult to use features should be excluded from this Autopano manual. This could includes features that work fine but nobody still know how to explain in a simple and clear way (like stacks + anchors + layers for fusion or HDR. Another example of inappropriate stuff is this thread http://www.autopano.net/forum/t11304-panorama-360*180-avec-deux-appareils-et-un-intervalloma-tre where I am the culprit .

- Some others are willing not only to spend some money but to spend an unknown amount of time because they want to stitch panos the other applications can't stitch or would stitch with not good enough results. They enjoy a much faster stitching, incredible amount of source images, large levels of bracketing. They endure bugs, interface approximations and even absence of updated documentation as a regrettable but unavoidable necessity.

In my opinion that these categories of peoples are sharing the same Autopano versions and the same forums is causing many frustrations. Documentation problems can't be solved when the very same document is supposed to describe bug-free "simple features" and more or less buggy "advanced features" nobody really mastered yet.

Probably more than 1000 books where published about Photoshop but - in my opinion at least - many more than 900 of them are pertaining to not recommendable category. Writing a decent documentation for Autopano is as difficult as this was for PS. The number of readers would be much lower and, last but not least, its obsolescence much faster...

Last edited by GURL on Tue Mar 29, 2011 2:05 pm, edited 1 time in total.