"Kenneth" <kdw### [at] gmailcom> wrote:

> I've been wondering if the result you're after is anything like Norbert Kern's
> 'position finder' code from 2006. Thomas De G and I spent time in 2018 trying to

It's a similar idea, and if you recall, I played with that code as well.

> IIRC, you first render a scene, then pick an x/y pixel position in that image
> render and feed it into the code, and it gives you the actual 3D position in the
> scene that the pixel corresponds to.

The difference here is that we don't have the underlying scene code and
therefore the "actual 3D objects" to trace back to.  That code takes a pixel,
shoots a ray out from the camera position through that screen/image plane
position, and returns the result of a trace () call, which is how we get the
z-coordinate, the actual x & y coordinates at that z, and even the surface
normal vector.

But we don't have any of that - we only have the image.

What photogrammetry does is reason backwards through that process and eliminate
all of the "cheats" like trace () and using the camera properties and knowledge
of geometry, figure out where the object would have actually been.

It's "easier" with more images of the same scene taken at different camera
locations and positions, because you can cross rays and get the z-coordinates
that way.

If I understand things correctly, using a single image is like trying to look at
an oncoming sine wave and determine where the curve is.  There are an infinite
number of sinusoidal peaks and troughs, so, you just pick the one that makes the
most sense in the present case.   It's also like "which of the infinite
reflections of you in the fun house is the 'first' one?"

- BW

Post a reply to this message