Range Finding - Parallax Calculations Options

[algorimancer]

I know JB's out the office at the moment, but I'm sure he'd help you out if you needed more info - his email addy is easily googlable.

Doug

I was actually on the verge of resorting to emailing questions yesterday, about the time I stumbled upon a paper which provided an algorithm for transforming from an image coordinate to a vector directed out from the camera's principal point (using the CAHVOR model), which was all I needed to get this thing working. Otherwise I'd found lot's of references to the inverse transformation. I was also giving Mathematica a workout trying to figure it out myself. At this point the camera model of the application seems to be working great, and the photogrammetry results speak for themselves. It might be nice to spot check it with some calibrated images, but there's not a lot of room for error in the approach I've used. At this point I'm pretty jazzed about adding more capabilities ... I see what people are doing in terms of projecting images using the camera pointing angles, and it seems that photogrammetry capability would be complementary. I'm looking forward to seeing what transpires

[MaxSt]

Thanks, algorimancer.

I was using these simple formulas for NAVCAM (results are very close to Joe Knapp's calculator):

CODE

  
//NAVCAM
object_distance = 0.2*1024*14.672/(12.29*(Xl-Xr));
object_dimension  = 0.2*size/(Xl-Xr);

But I notices some distortions, so I was looking for CAHVOR model data too... So thanks for the links.

[algorimancer]

Thanks, algorimancer.

I was using these simple formulas for NAVCAM (results are very close to Joe Knapp's calculator):

CODE

  
//NAVCAM
object_distance = 0.2*1024*14.672/(12.29*(Xl-Xr));
object_dimension  = 0.2*size/(Xl-Xr);

But I notices some distortions, so I was looking for CAHVOR model data too... So thanks for the links.

You're welcome I tried some similar formulas initially, plus tried to interpolate between the derived vectors listed in the CAHVOR files, but just couldn't make myself be happy with the results. Once I had all the pieces together it was actually relatively easy to get it working, but 3D graphics and motion analysis is part of my day job, so I have a well-stocked bag of tricks. It's been entertaining.

[algorimancer]

While it's only a day since the initial announcement, I've just implemented a few improvements to my MER RangeFinder application. It's now version 1.1 There are two major (visible) changes:

1. Integrated the CAHVOR parameters for Opportunity in addition to Spirit. It turns-out to be noticeably more accurate with the correct rover selected.

2. Added a batch processing option, to permit processing files full of rows of pairs of pixel coordinates. It occurs to me that the ImageJ application might be very helpful in quickly acquiring lot's of pixel coordinates, perhaps combined with Excel to handle organizing the data files.

I looked into the notion of providing separate CAHVOR calibrations for each pancam filter, but there doesn't seem to be any difference in the parameters between the filters, so I won't bother.

Here's the link and updated screenshot:

http://www.clarkandersen.com/RangeFinder.htm



Enjoy. Please let me know of any problems or suggestions; I've done a fair amount of testing, but not exhaustive.

[MaxSt]

Batch Process seems to work fine, that's very useful.

But could you explain "position", please? Where is the center?

[Tesheiner]

Thanks for this new tool, algorimancer.

It occurs to me that the ImageJ application might be very helpful in quickly acquiring lot's of pixel coordinates, perhaps combined with Excel to handle organizing the data files.

Do you mean (semi-)automatically pick pairs of pixel coordinates from both L & R images? That would be great!
I'm not familiar with ImageJ, and it's home page gives me no hint about such capability.
Any help?

[djellison]

Then once you have a fairly populated array of values, you can generate a mesh......and put the image back on it...and bingo - the full on 3d navigable environment we've been dying for

Doug

[MaxSt]

Actually, that's exactly what I'm playing with right now...

I found this nice program for automatic point selection... It's the same method used in Autostitch, so it's quite good:
http://www.cs.ubc.ca/~lowe/keypoints/

I already got some quick-and-dirty 3d models from NAVCAMs. But the model from one pair of images is just not enough - looks like a small patch. What I really want is to stitch them slices into the whole pizza... but that's kinda hard.

[djellison]

Alternatively, just write a convertor for the released data which includes meshes

Oh yeah- hint hint

Doug

[algorimancer]

Batch Process seems to work fine, that's very useful.

But could you explain "position", please? Where is the center?

The position is oriented in the pancam masthead reference frame (using a pair of center coords is illustrative, (512.5,512,5) for each camera), and the center/origin is set by the application as the midpoint between the two pancam's principle points (essentially the focal points). This means that you can generate a set of points in a consistent reference frame for one stereo pair of images. If you do this for multiple pairs of images you'll have to apply a rotation to the resulting points (and possibly a translation if the origin doesn't coincide with the masthead's center of rotation). One solution would be to have at least 3 overlapping points between them, figure the absolute orientation transformation, and apply it as needed. Or perhaps it's adequate to get the pancam orientation corresponding to the images and apply that rotation.

I can provide a capability to transform coordinates sometime in the next couple of days, I think. Meanwhile, there's an open source (free) application out there called Blender, which I haven't used, but apparently is popular among the 3D animation crowd, and may or may not be helpful.

To answer Tesheiner's question, "I'm not familiar with ImageJ, and it's home page gives me no hint about such capability. Any help?", I believe that once you get ImageJ running you'll find a "measure" option under one of the menus. My recollection is that measure allows you to capture pixel coordinates, in addition to measuring distances. On the other hand, the application that MaxSt mentioned above may be more targeted to capturing coords from image pairs and worth a look.

Generating meshes... possibly Blender would be helpful. Other ideas?

[jmknapp]

If you do this for multiple pairs of images you'll have to apply a rotation to the resulting points (and possibly a translation if the origin doesn't coincide with the masthead's center of rotation). One solution would be to have at least 3 overlapping points between them, figure the absolute orientation transformation, and apply it as needed. Or perhaps it's adequate to get the pancam orientation corresponding to the images and apply that rotation.

I think that--at least conceptually--once you have the position of a point in the masthead frame as your app provides, the SPICE kernels released to the NAIF website can be used to transform it to whatever coordinate system desired. In this case I guess one would want the Mars body-fixed frame IAU_MARS (essentially latitude-longitude-altitude). So if one had a point in the masthead frame MER-1_PMA_HEAD stored in a vector pmaxyz, these would be the SPICE calls:

// load SPICE kernels for MER1
furnsh_c("mer1_surf_roverrl.bsp") ; // rover position
furnsh_c("mer1_struct_ver10.bsp") ; // rover structures position
furnsh_c("mer1_surf_pma.bc") ; // rover PMA pointing

// et is ephemeris time
spkezr_c("MER-1_PMA_HEAD",et,"IAU_MARS","LT+S","MARS",headbf,&lt) ; // get PMA head position headbf, Mars body-fixed
pxform_c("MER-1_PMA_HEAD","IAU_MARS",et,pma2bf) ; // generate pma->body-fixed rotation matrix pma2bf
mxv_c(pma2bf,pmaxyz,marsiauxyz) ; // multiply rot matrix times pma vector to get body-fixed pma vector
vadd_c(headbf,marsiauxyz,pointbf) ; // add to head position to get point position, body-fixed
reclat_c(pointbf,&radius,&longtitude,&latitude) ; // convert to radius, lon, lat

So most of the automagic would be provided by NASA. The SPICE kernels must be a lot of work for them to generate, with rover slippage complicating matters, but I think they may do a lot of the eyeball work you refer to and release updated SPICE kernels daily. To wit, this is from the SPK (position kernels) README:

mer[1,2]_surf_roverrl_YYMMDDHRMN

MER-1/2 rover and site position SPK file generated daily from rover TLM combined with the latest bundle-adjustment position input from Dr. Ron Li. The latest of these files supersedes all previous files.

The latest such file for MER1 is mer1_surf_roverrl.bsp (currently 54 MB) released yesterday, covering the rover position from 25JAN2004 through 02MAR2006. The position of various fixed points on the rover (such as the PMA head) are given in another file mer1_struct_ver10.bsp. The file mer1_surf_pma.bc (currently 21MB) gives the pointing info for the PMA, also udpated daily.

That said, I haven't actually tried this for MER...

[algorimancer]

...
masthead frame MER-1_PMA_HEAD stored in a vector pmaxyz, these would be the SPICE calls:
...
That said, I haven't actually tried this for MER...

Is SPICE available via the web? I was reading through the user guide a few days ago and it had some interesting options, but I saw no mechanism for remote access. Fundamentally, simply knowing the transformation from the pancams' principal points to the mast head's center of rotation would be of tremendous assistance when combined with camera orientation parameters.

[MaxSt]

The position is oriented in the pancam masthead reference frame (using a pair of center coords is illustrative, (512.5,512,5) for each camera), and the center/origin is set by the application as the midpoint between the two pancam's principle points (essentially the focal points).

That's what I was hoping for... but I'm still a bit confused.

For example, I give coordinates (465,402),(453,402), and I get position (-19.7276,-0.0000,-0.3330).

What's the second number means? Why it's zero? The original point is not on center or anything...

[algorimancer]

That's what I was hoping for... but I'm still a bit confused.

For example, I give coordinates (465,402),(453,402), and I get position (-19.7276,-0.0000,-0.3330).

What's the second number means? Why it's zero? The original point is not on center or anything...

Well, it's an (x,y,z) coordinate describing a position in space. In this case the x axis direction is positive in the direction behind the camera, the y-axis is positive to the left, and the z axis is positive towards the ground. This forms a right-handed coordinate system. Personally I wouldn't worry too much about what the numbers in the coordinates mean in and of themselves, but rather focus on how the vertices relate to each other. For example, I see a rock in a pair of spirit navcam images, find the position of a point on its left side is about (-2.133,-0.056,-0.468) and that of a point on its right is about (-2.097,-0.204,-0.418), subtract those and calculate the magnitude of the resulting vector and I find that the rock is about 16 centimeters across (a calculator that handles vectors makes this a lot easier). Better yet, sample a variety of points in a scene, graph the resulting vertices in a 3D grapher, and get a better sense of the topography and how it varies from different perspectives. Eventually it would be nice to be able to do this with meshes and overlay the images on the meshes (Photomodeler can do this, but is beyond my price range).

Having said all that and re-reading your question I see that I've gone off on a tangent a bit; sorry about that. Why is the middle coordinate 0? I notice that the x-coordinate of each of your pixels is near the center of the images. Bear in mind that the x-coordinate of the pixel is an indicator of the y-axis in the coordinate system, and it appears that you have a point whose y-coordinate just happens to be aligned with the midpoint of the 2 cameras principal points.

EDITED: After further consideration, it appears that I have muddied the waters a bit when I said that the origin was the midpoint between the cameras principal points. The cameras princpal points are given by the CAHVOR parameter C, which in one paper is described as "the camera center vector C from the origin of the ground coordinate system ... to the camera perspective center". In other words, neither camera's C is at coordinate (0,0,0), nor is the midpoint between them. For Spirit, the left and right C's are (0.382152,0.149178,-1.246381) and (0.443429,-0.142099,-1.246638 ), and the midpoint between them (which is what my application measures the distance to) is at (0.412791,0.00354,-1.24651), and the distance between them is 0.297653 [30 centimeters]. This is not very useful as an origin, and I have the impression that the coordinate frame is different from that resulting from the image - to - world transformation, so I'm going to make a modification to the application to make the origin coincide with the midpoint between the cameras perspective centers. I'm also inclined to modify to frame of the resultant coordinates to a more user friendly system in which x-axis is positive to the right, the y-axis is positive towards the sky, and the z-axis is positive towards the rear of the camera. Yes, this implies that the z coordinate will be negative in the viewing direction, but that is necessary to preserve a right-handed coordinate system. None of this will affect the distances measured, but it will be easier to understand in terms of the images and the x-y-z coordinate system we all learned in school.

[Done. Version 1.2 has these updates; origin is midpoint between camera perspective centers, new x is last -y, new y is last -z, new z is last x. Ranges are unchanged, as is relative orientation between points.]

If anyone disapproves, we can discuss it. This is a quick and easy change to make to the application.

[Tesheiner]

To answer Tesheiner's question, "I'm not familiar with ImageJ, and it's home page gives me no hint about such capability. Any help?", I believe that once you get ImageJ running you'll find a "measure" option under one of the menus. My recollection is that measure allows you to capture pixel coordinates, in addition to measuring distances. On the other hand, the application that MaxSt mentioned above may be more targeted to capturing coords from image pairs and worth a look.

I had a look to the application mentioned by MaxSt but it seems to not solve my "problem".
I was thinking in something like what is available in PTGui to match same pixels/features in two images. The idea is to automate just a bit the now manual process of identifying the (x,y) coordinated of e.g. a rock on both L and R images.