Calculating the perfect non-parallax point, part 2
Joergen Geerds
parallax-point (commonly known as the nodal point) that started with
dimitri's question. the discussion then drifted into a direction that
wasn't very productive (mostly pointing to various RTFMs), but didn't
really netted out somewhere.
Today I stumbled over Max Lyons calculator page, where he offers a
parallax error calculator:
http://www.tawbaware.com/maxlyons/calc.htm
It lets you calculate the error in pixels for a given fov/resolution/
object distance.
My question is: why can't we have a reverse tool in ptgui, that looks
at the horizontal error between 2 CPs near the horizon (fov & lens are
known at the point due to exif data or otherwise, and assuming that
the camera is at least centered around the horizontal rotation point),
and suggests to move the camera by X mm back or forth. I really
believe that it can't be that hard to implement that tool.
any thoughts?
joergen
John Houghton
> My question is: why can't we have a reverse tool in ptgui, that looks
> at the horizontal error between 2 CPs near the horizon (fov & lens are
> known at the point due to exif data or otherwise, and assuming that
> the camera is at least centered around the horizontal rotation point),
> and suggests to move the camera by X mm back or forth.
PTGui doesn't know the distances to the features marked by control
points, which seems to be essential information.
John
Erik Krause
> Today I stumbled over Max Lyons calculator page, where he offers a
> parallax error calculator:
> http://www.tawbaware.com/maxlyons/calc.htm
>
> It lets you calculate the error in pixels for a given fov/resolution/
> object distance.
...and the formulas are here:
http://wiki.panotools.org/Parallax#Calculation
However, as John pointed out: the distance information is missing.
Perhaps it would be possible to get meaningful data if you enter the
distance manually (per control point). But I doubt this would make
anything easier...
Many modern SLRs have LiveView with zoom now. I still think it is far
easier and faster to use this than to shoot, import the images into
PTGui and get a value that can be interpreted in different ways...
My personal impression is that other factors - namely wrong lens
calibration - are far more of an issue.
--
Erik Krause
http://www.erik-krause.de
Joergen Geerds
necessary... but I think in the long run this can be used for a
robotic algorithm for automatic no-parallax calibration (a robot could
measure the distance via the focus inside the camera). yes, I do use
live view to calibrate my setup, and I really never had big problems
with it. but this is a "professional" setup, and the moment you enter
the world of consumer products, things need to get a whole lot easier,
because your average consumer will not understand the manual procedure
that we all use at the moment. besides, we build machines so we have
less work to do, not more (imo).
joergen
Erik Krause
> but this is a "professional" setup, and the moment you enter
> the world of consumer products, things need to get a whole lot easier,
> because your average consumer will not understand the manual procedure
> that we all use at the moment. besides, we build machines so we have
> less work to do, not more (imo).
In some star trek film I think Scotty says: "Never send a human to do a
machines job" But it applies the other way round, too: "Never use a
machine to do a human job". Well, distinguishing between near and far
objects in a (single) two dimensional image is a typical human job.
If it comes to the "average consumer" a table based solution will be
much easier, faster and more foolproof than any semi-automated
calculation done by a computer. It should be mandatory for a
manufacturer of pano heads to provide a database with all cameras and
lenses and an easy understandable instruction for setup. Heck, people
are able to assemble Ikea furniture, why shouldn't they be able to set
up a pano head.
If you want to do it image based you must exclude so many other factors
that it will be anything but foolproof...
However, a NPP-helper could work somehow different:
- Require the user to shoot something from the pano head with near and
far details once with those details on the right, once on the left of
the image frame.
- Display those details undistorted (remap to a rectilinear view with
the details in the center)
- Ask the user to manually align the nearer object for both images.
- Ask the user to manually align the far object for both images.
(eventually the user could mark the region and the CP detector would
find the features)
- Ask the user for a distance estimate of both objects.
- Calculate NPP displacement.
- Ask the user to adjust the pano head.
- Start over.
Do you really think this is easier to understand and use than the manual
procedure as we use it now?
In any case I don't think PTGui would be the right place to do this.
This would be an application for a device connected to the camera which
can capture the images directly.
Dimitri
On Mar 5, 12:10 pm, Erik Krause <erik.kra...@gmx.de> wrote:
> In some star trek film I think Scotty says: "Never send a human to do a
> machines job" But it applies the other way round, too: "Never use a
> machine to do a human job". Well, distinguishing between near and far
> objects in a (single) two dimensional image is a typical human job.
Chiming in here.... one of the reasons a human can distinguish between
near and far is that he or she has not one optical input, but two.
With the current craze of 3D (really stereographic) recording taking
off (see avatar, upcoming flatscreens, upcoming camcorders with dual
lens systems)... does it seem all that impossible for there to be a
still "3D" camera on the market? If such cameras are made available,
then why wouldn't you be able to triangulate the objects' distances?
No need for lens or camera lookup tables... you wouldn't even need to
use focus data.
Please don't flame... not really constructive... if anyone else can
come up with ideas that _add_ to the _solution_, please do.
Thank you
Dimitri Katsaros
Ken Warner
http://www.loreo.com/pages/products/loreo_3dcap.html
But you still need one or more reference points for distance to
calculate the location other points in 3Space.
Dimitri
in such a system... that is, the location of the two lenses/sensors.
From there, unless I'm missing something, one should be able to
triangulate any position.
On Mar 6, 5:17 pm, Ken Warner <kwarner...@verizon.net> wrote:
> There are already 3D cameras. Fuji has one. There is the Loreo lens.http://www.loreo.com/pages/products/loreo_3dcap.html
Erik Krause
>> > In some star trek film I think Scotty says: "Never send a human to do a
>> > machines job" But it applies the other way round, too: "Never use a
>> > machine to do a human job". Well, distinguishing between near and far
>> > objects in a (single) two dimensional image is a typical human job.
>
> Chiming in here.... one of the reasons a human can distinguish between
> near and far is that he or she has not one optical input, but two.
Which isn't relevant here. The only benefit a human has in estimating
the distance of objects *in a singel 2D image* is experience. Both
knowledge of the usual size of things and knowledge of the usual form
and function help to determine their relative distance.
BTW.: Stereoscopic triangulation was a part of panotools since ages:
http://wiki.panotools.org/PTStereo
Jeffrey Martin
anything?? :-)
Dimitri
If you read my post a little more closely, you'll see I refer to a
_dual_ lens system.
Erik Krause
> Right. which is why 3D content is not created from a single 2d image.
> If you read my post a little more closely, you'll see I refer to a
> _dual_ lens system.
I fully understood what you mean. But to be honest I think it's
ridiculously complicated to use a stereo camera only to determine the
correct no parallax point of one of it's lenses (or, which would be even
more complicated: to find the NPP of another camera). Of course it can
be done, but why should it be done?
Finding the NPP is easy enough, much easier than synchronizing a stereo
camera with a SLR or using a stereo camera for shooting panoramas.
michael crane
> Finding the NPP is easy enough, much easier than synchronizing a stereo
> camera with a SLR or using a stereo camera for shooting panoramas.
anybody got any tutorials for making the red green separations ?
regards
mick
Erik Krause
>> > Finding the NPP is easy enough, much easier than synchronizing a stereo
>> > camera with a SLR or using a stereo camera for shooting panoramas.
> anybody got any tutorials for making the red green separations ?
You mean stereo anaglyph images, I suppose...
http://www.stereoeye.jp/software/index_e.html
http://anabuilder.free.fr/welcomeEN.html
and loads of other programs that do that for you.
michael crane
> You mean stereo anaglyph images, I suppose...
yes, the holy grail for movies( the 3Dsmurfs have changed everthing)
regards
mick
Bjørn K Nilssen
Agreed.
It reminds me of some of the wonderful inventions by the Danish humorist Storm P, like
this one of 1910: http://www.skoveniskolen.dk/media/GP_stormP_citronpresser_500p.jpg
Translation: Citronpresser = lemon juicer.
Why make it simple if it can be done complicated ;) ?
--
Bjørn K Nilssen - http://bknilssen.no - panoramas and 3D
Jeffrey Martin
Has anyone, anywhere, ever used PTStereo??
michael crane
> Did I miss a reply?
No
> Has anyone, anywhere, ever used PTStereo??
Not yet
mick