Viewpoint correction in PTGui Pro
PTGui Support
correction, which allows to add a nadir image taken from a different
viewpoint. This makes it easier to shoot the nadir, and allows to
completely remove the camera shadow from the panorama.
I presented it at the PanoTools meeting in Luzern, and have now created
a tutorial:
http://www.ptgui.com/examples/vptutorial.html
Joost
Serge Maandag
> correction, which allows to add a nadir image taken from a different
> viewpoint. This makes it easier to shoot the nadir, and allows to
> completely remove the camera shadow from the panorama.
Sounds like a real time saver. Very nice.
I haven't used the blend priority feature yet. I hope it works well, otherwise I'll
keep adding circular masks to my nadirs.
> http://www.ptgui.com/examples/vptutorial.html
To make an honest comparison, I think you should do the optimization without
viewpoint correction with individual d/e/fov optimization for the nadir image. But
otherwise, nice tutor!
Serge.
PTGui Support
>> http://www.ptgui.com/examples/vptutorial.html
>
> To make an honest comparison, I think you should do the optimization without
> viewpoint correction with individual d/e/fov optimization for the nadir image. But
> otherwise, nice tutor!
I've been doing that for years too, but the results are pretty bad
especially in this extreme case.
The problem with d/e optimization is that it also shifts the center of
the lens remapping. For rectilinear lenses this only affects the a/b/c
correction, but for other lenses it results in a completely different
lens remapping.
Same with fov optimization: for non-rectilinear lenses this is not the
same as varying the distance between camera and subject.
And finally, even for rectilinear lenses d/e always shifts in a plane
perpendicular to the yaw/pitch angle, it cannot handle the case where
the camera is tilted towards the floor.
But the tutorial is long enough already, I don't want to make it more
complicated..
Joost
Serge Maandag
> the lens remapping. For rectilinear lenses this only affects the a/b/c
> correction, but for other lenses it results in a completely different
> lens remapping.
Yep, have struggled with that too. In extreme cases it helps a bit if you correct
a/b/c for the nadir shot before you load it in the project, but it's a bit of a
hassle.
> Same with fov optimization: for non-rectilinear lenses this is not the
> same as varying the distance between camera and subject.
That's a hard one to grasp. I always assumed it was..
> And finally, even for rectilinear lenses d/e always shifts in a plane
> perpendicular to the yaw/pitch angle, it cannot handle the case where
> the camera is tilted towards the floor.
I always assumed optimizing d/e and y/p/r would be able to do exactly the same as
the viewpoint correction does, but that was only based on gut feeling..
I'm anxious to see how the viewpoint correction performs!
Serge.
michel thoby
VP is an awesome improvement!
By a quick test, I have compared the outputs of two different
methods, both using PTGui pro7.3 beta1:
1- Your new (Viewpoint + Blending priority) method
Vs
2- (Smart circular offset Cropping + Individual lens and Shift
parameters) specifically for the nadir shot.
I did this for a nadir shot not so badly offset as your example. It
was only "moderately" deviating from NPP by about 15 to 20 cm in the
horizontal plane and 5 cm in altitude (1,6m) which is imho a more
realistic casual case than your exaggerated (but spectacular) example.
Both methods yielded about the same excellent precision for stitching.
Apparently, the new "blending priority" feature makes the nadir
blending seam shading off smoother but the sharpness near these seams
resulting from "smart cropping" looks better.
It seems that both methods may be conjuncted in some cases (if
needed) to give even better result than any of both.
Michel
PS: I could not resist and I moved few of your (step7) nadir "worst"
CP' pairs to a better match;
Max. distance error was immediately reduced by 100% and the average
error by 60%!-)
Le 22 août 07 à 10:08, PTGui Support a écrit :
michel thoby
the" send" button.
Please read 50% and 30% respectively.
Michel
Le 23 août 07 à 12:13, michel thoby a écrit :
PTGui Support
I admit that it's an extreme example. But using such a large offset can
be useful to remove your shadow (and the camera's) from the panorama.
Usually I could not get it perfect using d/e/fov optimization. But at
least now you have two methods..
Joost
1drey
Does blend priority feature work with PTGui blender only?
A.
zbooy
optimized nadir shot and it worked perfectly while I always had
problems with d/e/fov optimization. I believe it is the first one
(from 600+ stitches) that required no nadir patch-up at all!
(Actually, I have done a bit of layer work in PS but it wasn't nadir-
related.)
Joost - many thanks :)
zbooy
1drey
the nadir?
michel thoby
I ran an experiment to try approaching that magic (minimum) number.
With four images around and a very oblique Nadir shot (a la Joost)
from a Shaved Tokina 10-17 @ 12.5 mm on EOS 5D on a tripod and a home
made precise L-bracket.
After addition of the nadir shot, I tried unsuccessfully to get a
good optimization result by manually putting only two Control Points
on every four side image, i.e. eight CP on the Nadir image.
Adding another CP on each side image led to an excellent optimization
and an excellent output panorama (8244 x 4122 pixels optimal max. size).
In this specific case, between 8 and 12 was probably the required
minimum number of CP pairs..
I have got the same result with a separate and different set of image.
BTW: I shall use some more in my future routine workflow...
Here is the project file:
http://michel.thoby.free.fr/PTGui6Beta_test/Number_of_CP_is_3.pts.zip
Michel
Le 26 août 07 à 01:08, 1drey a écrit :
zbooy
> How many CP's did you place for each pair of images while inserting
> the nadir?
It's a 5D+15mm combo, so I'm shooting 6+1+1. Out of these six, I used
just three with 3, 3, and 1 CP respectively.
zbooy
1drey
I was resting this new feature for images produced with similar setup
- new Sigma and D200.
Satisfactory optimisation was achieved with onlt 8 CP's - maybe
because the correction required was not extreem, I kept the camera as
close to the original position as possible.
And this is great because I can't call 'time saving' the proces of
manual CP placement ;) On relatively uniform object without distinct
details it can be real pain.
I found that the resolution of Sigma 8/f3.5 falls noticeably to the
edge of the image circle (by my guess >160) and this difference in
resolution is very noticeable if nadir is formed by the object with
fine texture like grass or asphalt pavement. It forces me either tilt
camera down a bit while shooting or make extra nadir shot.
Does Tokina 107 behaves better is this aspect?
Andrey
On 26 авг, 20:16, michel thoby <thobymic...@wanadoo.fr> wrote:
> Hi,
>
> I ran an experiment to try approaching that magic (minimum) number.
>
> With four images around and a very oblique Nadir shot (a la Joost)
> from a Shaved Tokina 10-17 @ 12.5 mm on EOS 5D on a tripod and a home
> made precise L-bracket.
>
> After addition of the nadir shot, I tried unsuccessfully to get a
> good optimization result by manually putting only two Control Points
> on every four side image, i.e. eight CP on the Nadir image.
> Adding another CP on each side image led to an excellent optimization
> and an excellent output panorama (8244 x 4122 pixels optimal max. size).
> In this specific case, between 8 and 12 was probably the required
> minimum number of CP pairs..
>
> I have got the same result with a separate and different set of image.
>
> BTW: I shall use some more in my future routine workflow...
>
> Here is the project file:http://michel.thoby.free.fr/PTGui6Beta_test/Number_of_CP_is_3.pts.zip
>
> Michel
>
> Le 26 ao t 07 01:08, 1drey a crit :
1drey
D200+10,5+360precision setup.
Thank you.
Andrey
michel thoby
my solution, I felt compelled to study the problem a little further.
It is in fact possible to use much less (than 8) with a very careful
selection of the location of the relevant CP on the Nadir image.
After some experience, I could use only one CP per round-shot (i.e.
four CP pairs total) for a successful excellent optimization.
However that solution is unstable as it requires a very accurate
manual prior yaw positioning of the nadir image on the panorama
editor before PTGui optimization.
Adding just one more point on any of the four round-shots allowed to
get easily and consistently a stable excellent optimization.
Conclusion:
With some experience and with an adequate choice for the CP location
and if the shooting was precisely done, only few CP are necessary. In
the tested case, five CP pairs were sufficient. There may be a better
solution though...
Here is the project file just before hitting the optimizer button
(all VP parameters being reset to default):
http://michel.thoby.free.fr/PTGui6Beta_test/
Number_of_CP_is_less_than_2.pts.zip
Michel
Le 26 août 07 à 18:16, michel thoby a écrit :
Serge Maandag
> four CP pairs total) for a successful excellent optimization.
Michel,
shouldn't you be looking for an excellent result instead of an excellent optimization?
If you use a very small amount of control points, the optimizer will always find a
way to make those control points fit. By blowing up the b parameter for instance.
Only if you use many control points (evenly spread), you can find out whether the
optimizer can make all parts fit. If they do, that'll be the sign of an excellent
result.
Serge.
michel thoby
In principle and before performing this experiment, I would have
totally agreed with you. But actual observed facts seem not to
confirm your suppositions.
The first steps of the method with four round-shot images only were
performed as usually: I found the output excellent and undistorted.
During the rest of the process, neither the lens correction
coefficients nor other parameters were optimized further than the
optimum found prior to the addition of the nadir image. All (except
position y, p, r) were then also locked for the Nadir image as well.
As the round-shots stay unchanged from one case to the other, the
only possible visible differences were confined in a very small area
near the Nadir and impacted only by the VR five parameters (and y, r,
p). This smallness is due to the relative value of the blend priority
factors. In other words, above a certain critical minimum figure, the
Nadir image final "useful" mapping doesn't depend much on the number
of CP. Below that number there is no really stable solution.
In the number of CP reduction routine, to make sure that I was not
getting distorted panorama while still getting "excellent"
optimization, I have carefully previewed and compared the output
panoramas corresponding to the decreasing number of CP. Visual
inspection did not reveal change in the concerned small area. I have
therefore concluded that in this case (4 + 1N), five CP on the Nadir
image are enough as long as they are well and evenly spread apart.
BTW, for the oblique last shot, I tried to aim the best I could at
the (former) center of the tripod triangle base on the floor with the
help of the viewfinder center bull eye. This probably helps in many
ways for a good optimization and good image quality after the
unavoidable severe Nadir image patch interpolation.
To totally make sure that your fears are actually unfounded, I should
also have increased step by step the size of the patched nadir zone
area by setting a higher relative value to the Nadir image blend
priority. But as I have designed the precise "slim rotator" just to
avoid having operationally to do this, I feel quite reluctant to
perform this test. Shall somebody else do it?
Michel
Le 28 août 07 à 12:27, Serge Maandag a écrit
MacUser
That's so true if the panohead is not precisie and/or the tripod is
not stable, then indeed many control points (evenly spread) are
needed.
But if the panohead is precisie and the tripod is stable then with 4
round + 1 nadir shot the results of both the optimizer as the stitched
output could be very fine with no more then 25 well placed and
spreaded CP's in total for the project.
So the the keywords in this matter are "precise, stable, well placed,
spreaded"
Best,
Wim
Serge Maandag
> not stable, then indeed many control points (evenly spread) are
> needed.
>
> But if the panohead is precisie and the tripod is stable then with 4
> round + 1 nadir shot the results of both the optimizer as the stitched
> output could be very fine with no more then 25 well placed and
> spreaded CP's in total for the project.
Wim,
you are reversing the logic. Your presumption is that everything is precise and
stable. In that case (and with known a,b,c,d,e parameters) you wouldn't even need as
much as 25 control points.
But Michel is testing whether his combination *is* stable and precise. To measure
that you'll need more measure points to prevent false positives.
Michel disagreed in his last mail, but I need some time to overthink his arguments..
Serge.
Serge Maandag
> performed as usually: I found the output excellent and undistorted.
> During the rest of the process, neither the lens correction
> coefficients nor other parameters were optimized further than the
> optimum found prior to the addition of the nadir image. All (except
> position y, p, r) were then also locked for the Nadir image as well.
Your earlier statement:
> I ran an experiment to try approaching that magic (minimum) number.
Made me believe you were calibrating your setup by letting the optimizer results be
the judge. But what I'm reading here suggest that you're not looking for a result
judged by numbers. You're more into judging the results by the naked eye.
> As the round-shots stay unchanged from one case to the other, the
> only possible visible differences were confined in a very small area
> near the Nadir and impacted only by the VR five parameters (and y, r,
> p).
Hmm.. by saying "VR five parameters", do you mean a,b,c,d,e?
> This smallness is due to the relative value of the blend priority
> factors. In other words, above a certain critical minimum figure, the
> Nadir image final "useful" mapping doesn't depend much on the number
> of CP. Below that number there is no really stable solution.
I'm willing to believe that. You surprised me before with thoroughness.
I'm not seeing the logic though. :(
> In the number of CP reduction routine, to make sure that I was not
> getting distorted panorama while still getting "excellent"
> optimization, I have carefully previewed and compared the output
> panoramas corresponding to the decreasing number of CP. Visual
> inspection did not reveal change in the concerned small area. I have
> therefore concluded that in this case (4 + 1N), five CP on the Nadir
> image are enough as long as they are well and evenly spread apart.
somehow this "feels" like something logical. The errors you can have is trapezoid
distortion in one direction, trapezoid distortion perpendicular to that direction
and scale. I'm not sure that would translate to 2 cp's + 2 cp's + 1 cp = 5 cp, but
perhaps it is.
> To totally make sure that your fears are actually unfounded, I should
> also have increased step by step the size of the patched nadir zone
> area by setting a higher relative value to the Nadir image blend
> priority. But as I have designed the precise "slim rotator" just to
> avoid having operationally to do this, I feel quite reluctant to
> perform this test. Shall somebody else do it?
Nope :)
Since you were doing these tests, I was assuming it was an scientific experiment,
but by now I understand that wasn't the goal. You are just looking for the minimum
amount of cp's you can get away with. Just like the rest of us..
Serge.
michel thoby
Le 29 août 07 à 22:42, Serge Maandag a écrit :
>> As the round-shots stay unchanged from one case to the other, the
>> only possible visible differences were confined in a very small area
>> near the Nadir and impacted only by the VR five parameters (and y, r,
>> p).
>
> Hmm.. by saying "VR five parameters", do you mean a,b,c,d,e?
No, I was meaning VP X, VP Y, VP D, VP Pan and VP Tilt.
> Since you were doing these tests, I was assuming it was an
> scientific experiment,
> but by now I understand that wasn't the goal. You are just looking
> for the minimum
> amount of cp's you can get away with. Just like the rest of us..
>
> Serge.
Yes, that was my humble goal. This time, I used a purely empirical
approach: no science, or so little of it;-)
I had read the tutorial by Joost where I had been impressed when he
put so many CP's all over this Nadir floor.
I felt challenged to find if it is really needed to do so when the
shots are all done with a good setup (e.g. sturdy tripod and precise
head).
Sorry to have induced you in a wrong track.
BTW: Early during this experiment, I have found that a classical
bracket (or spherical pano-head) was not best suited for a favorable
process with this new VP function.
I wanted to have a naturally stable platform allowing low light shot
(i.e. no time limit for the oblique shot).
I have therefore quickly designed and made a new type of pano-head
that can, during the last phase of shooting (the oblique view), let
the camera and the lens being pushed much forward of the normal NPP
position.
My "slim rotator" visual clutter being much smaller than the top of
the tripod itself,
http://michel.thoby.free.fr/Nadir/Slim/Slim_rotator.html
--> with this new bracket, the nadir oblique image is now
consequently "almost" unobstructed by the top or the legs of the tripod:
http://michel.thoby.free.fr/PTGui6Beta_test/New_VP-head.jpg
Be sure that the different positions shall be pin registered in the
near future.
Regards,
Michel
PTGui Support
> Yes, that was my humble goal. This time, I used a purely empirical
> approach: no science, or so little of it;-)
>
> I had read the tutorial by Joost where I had been impressed when he
> put so many CP's all over this Nadir floor.
> I felt challenged to find if it is really needed to do so when the
> shots are all done with a good setup (e.g. sturdy tripod and precise
> head).
Yes I was concerned about the fact that the optimization is not very
stable. Ideally the parameters to be optimized are orthogonal: changing
one parameter does not affect the optimum solution for the other
parameters. But in this case the parameters are quite dependent. More
CPs help the optimizer refining the solution.
But I agree, CP distribution is the key: if the control points are well
spread across the area, the solution becomes more stable and you can do
with fewer control points.
Joost
MacUser
I looked at the images of your slim rotator and I noticed that the
last modification introduced a way to make the nadir shot with a
negative tilt at the same height as the other round images. Because
the footprint of your setup is small you only have to change the
position of the tripod less then 1 meter I guess. It's a nice
solution, you can look trough the viewfinder to see if the position is
right (lens aimed at the original position) and adjust the position if
neccesary but I am curious what the advantages are compared with a
simple change of the position of the tripod of approx. 1 meter and
then bending over the tripod ( 1 leg free of the ground) a little.
Are the results then indeed better, can you check that (or perhaps you
already did) and post your findings?
Best,
Wim.
> the tripod itself,http://michel.thoby.free.fr/Nadir/Slim/Slim_rotator.html
michel thoby
Le 30 août 07 à 08:17, MacUser a écrit :
> I looked at the images of your slim rotator and I noticed that the
> last modification introduced a way to make the nadir shot with a
> negative tilt at the same height as the other round images. Because
> the footprint of your setup is small you only have to change the
> position of the tripod less then 1 meter I guess. It's a nice
> solution, you can look trough the viewfinder to see if the position is
> right (lens aimed at the original position) and adjust the position if
> neccesary but I am curious what the advantages are compared with a
> simple change of the position of the tripod of approx. 1 meter and
> then bending over the tripod ( 1 leg free of the ground) a little.
> Are the results then indeed better, can you check that (or perhaps you
> already did) and post your findings?
>
> Best,
>
> Wim.
While I am convinced that with VP they can provide identical result,
I have not formally compared the two configurations because I have
deliberately decided not to use the other solution.
Bending the tripod over is usually done by holding it manually (and
possibly with a foot as a wedge) in the required unstable oblique
position. I personally cannot hold it steady this way for more than a
limited time (several second at the most)... not good enough for HDR
as an example.
Further more I have incidentally discovered that this new
configuration has some unexpected other practical virtues that I
currently explore...
After some past radically opposite tries, I must also confess that I
felt compelled to study more in depth the first digital solution that
frees us all from this damned fish-eye NPP constraint:-)
Ken avo,
Michel