Page 1 of 1

Multiple viewpoint challenge

PostPosted: Wed Sep 14, 2011 7:23 am
by gddxb
Hi -

I was just wondering how Autopano Giga would cope if presented with image sets taken from multiple locations - there are two scenarios I am considering.


I know this is discussed here - http://www.autopano.net/wiki-en/action/view/Stitching_aerial_photos , but in the examples I'm considering, I would be shooting multiple images from multiple locations.

For ease of discussion (although this is not strictly accurate), assume that I would be shooting in each of the following two scenarios:

Scenario 1:
4x 100 degree horizontal** by 180 degree vertical panoramas from the four corners of a building roof, with the desire to have a single 360x180 spherical panorama as the output.

In this scenario, it's the actual roof of the building itself which I need to "remove" from the resulting panorama in order to create a satisfactory spherical output.


Scenario 2:
3x 130 degree horizontal** by 180 degree vertical panoramas from very close locations (assume all within a 2 metre radius) where I need to move the camera locations in order to avoid extremely close (1m distant) immovable objectsthat would otherwise block the parts of the fields of view were I to shoot from the central point. Again - desired output is a 360x180 spherical.

In both scenarios, ideally the problem would be solved by simple raising the shooting point vertically, but unfortunately this is not an option in either case.

I'm aware of parallax challenges, but these would hopefully be minimized by the height of the locations, and relative lack of other buildings in the immediate vacinities.

These would be very large (##-gigapixel) panoramas.

(** - any thoughts/advice on how much overlap between the separate panoramas I should be planning on? Can this be calculated based on distance between shooting locations?)

Many thanks in advance,


Gerald.

PostPosted: Wed Sep 14, 2011 8:12 am
by digipano
I have done something similar to Scenario 1 shots from a top of an industrial chimney moving at the circumference but that was round & it stitched well but not sure how will you do from a square/rectangular rooftop to get 360. Shooting from pole seems the option but you say that's not possible.

PostPosted: Wed Sep 14, 2011 10:25 am
by gddxb
digipano wrote:I have done something similar to Scenario 1 shots from a top of an industrial chimney moving at the circumference but that was round & it stitched well but not sure how will you do from a square/rectangular rooftop to get 360. Shooting from pole seems the option but you say that's not possible.

For scenario 1, I do have the option to erect a 10 meter high scaffold in the middle of the roof (the building is around 250m high). The roof itself is squarish, with sides ranging from 35m to 55m. If my trigonometry hasn't totally failed me, then by my calculations it means the edges of the roof will cut off from the field of view everything within around 650m of the building in the best case, and up to around 1km in the worst case.

This isn't actually as bad as it sounds, because there is very little in close proximity to the building, so it's certainly an option, but the ideal scenario would I believe be to be able to shoot from the corners, if APG could then stitch.

I've just shot a test set of images from each corner so will have a play and see what happens.

PostPosted: Wed Sep 14, 2011 12:58 pm
by digipano
My concern in doing this is
what focal length do you plan to use
how much overlap do you intend to keep
how much of 3d objects will you be having near to the building, distant objects would not have much problem.

all these will make your stitch complicated, APG can handle each 4 sides of the building as a straight line stitch with using multiple viewpoints method but how well it stitch at the /corner/joints will depend on above factors.

PostPosted: Thu Sep 15, 2011 8:17 am
by AlexandreJ
Both scenarios are possible. In fact, London 80 gigapixels was shoot with scenario 1 !
I don't know if multiple viewpoint will work well with such an amount of image, but nevertheless, it's possible to create 4 stitchs and then glue them together in a giant panorama ( that's what Jeffrey did ).

PostPosted: Fri Sep 16, 2011 8:54 am
by Castillonis
I have been merging panoramas captured from several locations using Photoshop. I have used two different methods

For both methods I Iterate merging the rendered panoramas in pairs
a. Load as different layers
b. Use the v / move tool to aproximately align the layers
c. Use the v/ move tool to aproximately scale the images to the same size
d. Use the edit->transform->warp tool to match the layers in an area that is not a focal point of the image

Now I either merge with a gradient mask or use photomerge. If you use photomerge you need to crop extra overlap to get better results. Some times photomerge works well, other times it mangles your image.

Once I have assembled the pairs I repeat these steps to put the merged pairs together. In order to avoid many Photoshop crashes and frustration you should use a machine with as much system memory as possible.

PostPosted: Sat Sep 17, 2011 7:38 am
by gddxb
Thanks everyone for the thoughts and suggestions.

I'll report back with my test findings hopefully later today.

PostPosted: Sat Sep 17, 2011 7:58 am
by gddxb
Quick question - looking at this link http://www.xnview.com/en/formats.html that details supported file formats for input photos, Photoshop .psd is listed, but not .psb.

Can input files in .psb format be used by APG?

PostPosted: Mon Sep 19, 2011 8:34 am
by AlexandreJ
No. We prevented the use of PSD / PSB as input format in APG ( but not in Panotour ). That was a design decision.
Here's why :
* You have a folder, you do a detection, edition then rendering in PSD most of the time to be able to make some retouch.
* If you do again a detection on the same folder and if PSD is allowed, it will try to stitch the rendering and the input images.
* Other problem : the PSD doesn't have a quick preview embedded, so, it takes year before the interface can display anything.