I have released a new version of the AlgorimancerPG rangefinder and photogrammetry tool. It is currently up to version 2.6. The latest addition provides Sol/time data for each image, plus calculates the 3D angle spanned by the last two targets (as seen from the rover). The latter feature struck me as potentially useful in navigating Victoria's ejecta blanket, and much easier than counting pixels.

As usual, the latest version can be found here:

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

And here's a screenshot:

Click to view attachment

Let me know if there are any suggestions/problems.

For those unfamiliar with the application, the details of how it works have been extensively discussed in the "Range Finding - Parallax Calculations" thread, which you'll find here: http://www.unmannedspaceflight.com/index.php?showtopic=1768. It also includes a user guide in the zip file, and another quick user guide under the Help menu.

I'm looking for information on the positions of the masthead azimuth and elevation axes in the rover frame. I have the instrument kernels and other files from that location, but they only describe the different frames in terms of basis axes orientations, they don't mention coordinates or offsets in coordinates (or at least not that I've been able to decipher).

My reason for this is that I'm working on integrating rover position and orientation information into the next version of AlgorimancerPG, which will permit wide baseline photogrammetry, enabling long range rangefinding (which strikes me as very useful for navigation as we move out onto the apron).

I'm currently working with a very simple test case, involving a pair of adjacent images taken at the same location with a small azimuth/elevation change between them (about 12 degrees altogether), and this rotation is sufficient to have a noticeable effect on the cameras' principal points' positions. My plan to deal with this at the moment is to assume that the principal points lie on the elevation angle axis, and that the azimuth axis lies exactly midway between the principal points. This is undoubtedly a bit of a simplification, but hopefully not too much of one. Realistically any photogrammetric errors due to the simplification will fade to insignificance as the distance between rover positions increases (worst at 0 in my test case); nevertheless I'd like to get it as precise as possible.

If anyone can point me towards any relevant documents, it would be much appreciated.

A major new release of AlgorimancerPG, version 3.0, has been posted to the usual site,

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

Screenshot:
Click to view attachment

This is a version optimized for long range navigation and cartography, with the potential to take advantage of rover and masthead orientation information to yield topocentric coordinates, leading to the capacity for long baseline photogrammetry, for measurements at much longer ranges and greater accuracy. Default rangefinding behavior is essentially unchanged (aside from shifting the origin from the masthead to the rover), additional capabilities require importation of image database files.

Changes from the last version include:

--Somewhat simplified interface.

--Changed rangefinding origin from midway between cameras to the rover's navigational origin (approx center of rover).

--Coordinates are now output in the rover frame by default, or topocentric frame following importation of image database file.

--Long baseline photogrammetry using images from two rover locations is now an option for measuring to longer ranges and with greater accuracy - see the extensively revised AlgorimancerPG.doc documentation of this feature.

--Better error detection (convergence of rays behind the cameras now yields an error rather than a distance).

--Removed batch processing utility.

--Packaged with windows installer utility, to help ensure compatibility (it uses .Net 2.0).

Unzip the installer to a convenient directory and run the setup application. AlgorimancerPG will be installed in your Programs directory, with shortcuts in your Start menu and the Desktop. A shortcut to the user's guide is included in the Start menu - if you intend to use the wide baseline capabilities, you'll really need to read the discussion of that capability in the latter half of the guide. Image database files for Sols 1 through yesterday (both rovers) are included in the Programs directory for your convenience, and instructions for creating more are in the documentation (I may post additional files on my website periodically).

This was a tough version to complete, principally due to having to resort to something of an experimental programming approach to decipher the documentation on camera and rover orientation. Mike Howard, of Midnight Browser fame, was very helpful both directly and indirectly (via MMB itself) sorting this out, as well as leading the way in acquiring image and rover orientation data.

As discussed in the documentation, with the new wide baseline capability I have been able to use images from separate Opportunity rover locations (Sols 877 and 878, about 28 meters apart) and measure the range and topocentric coordinates of a target 130 meters away to an accuracy of less than a meter. I have likewise used the same baseline to range the Gamma and Delta craters to rather poorer accuracy (perhaps 10%), as they are nearly in line with the baseline vector (orthogonal measurements are best). In principal, with a sufficiently wide baseline established (100 meters would be nice), it ought to be feasible to measure features kilometers or even tens of kilometers away. I'm thinking that it would be helpful to begin accumulating some reference baseline vectors between different rover sites (these can be acquired from the route maps alone to tolerable accuracy, I think).

In a later version I may see about outputting the target's topocentric azimuth and elevation - although fitting it into the dialog box is a little tight.

Enjoy, and as always please let me know of any problems or suggestions.

Wow! I'll be reading the docs when I get home from work tonight. It sounds amazing.

Ok, I read the documentation tonight and I have a question. For long-baseline calculations, if I want to use a pair of locations whose baseline vector is not nearly orthogonal to the direction to the target, can I use the orthogonal component of the vector? I suppose that wouldn't be strictly correct, but might it give better results than using the actual vector?

The thing is, the baseline vector connects the two rover positions from which the long baseline image pairs originate. If the vector points to anywhere other than the (right) rover [as seen from the left rover], then the results will be meaningless, although approximations are okay. Orthogonality to the target isn't necessary, only ideal. For example, I was able to get a pretty good measurement from rover positions at sols 877 & 878 to craters Gamma & Delta, in spite of them being pretty near parallel to those positions; there was enough effective orthogonal baseline (in comparison to that between the cameras on a single rover), that the results were still tolerably good. Consider the following example, in which we would like to measure from rover positions A and B to a Target:

Click to view attachment

The effective baseline is the component of the actual baseline which is orthogonal to the target. We don't have to isolate that orthogonal component, it is implicit in the geometry, so all we need to do is specify the true baseline vector from A to B.

It is important to decide which position to use as our origin, A or B. If A, then the offset vector is simply B-A, and images from A will need to be the left images in APG, while images from B will need to be on the right. (the rover associated with the left image will be used as the origin for all wide baseline measurements wiithin AlgorimancerPG). If we would prefer to make B the origin, just swap the left and right images and negate the offset vector.

The following may be helpful. Yesterday I took some measurements from Phil Stooke's route map and compiled the following pixel positions and corresponding topocentric positions for Oppy's recent activities (all the column formatting is lost when I post, so use the link instead):

http://www.clarkandersen.com/SiteCoordinates.txt

Sol Locat Pix X Pix Y TopoX TopoY TopoZ
848 194 23 -11.5 -97 0
849 196 71 -35.5 -98 0
850 198 141 -70.5 -99 0
851852 204 193 -96.5 -102 0
853854 211 267 -133.5 -105.5 0
855856 223 352 -176 -111.5 0
857589 236 465 -232.5 -118 0
860861 233 540 -270 -116.5 0
862863 237 592 -296 -118.5 0
864868 250 653 -326.5 -125 0
869 248 735 -367.5 -124 0
870 261 774 -387 -130.5 0
871872875 282 815 -407.5 -141 0
873874 289 822 -411 -144.5 0
876 272 835 -417.5 -136 0
877 264 884 -442 -132 0
878882 262 944 -472 -131 0
883 269 1005 -502.5 -134.5 0
884 320 1051 -525.5 -160 0
885890 310 1057 -528.5 -155 0
891895 415 1015 -507.5 -207.5 0
896897 456 986 -493 -228 0
898899 448 976 -488 -224 0

Compare the Sol 877 & Sol 878 offset with that used in the APG example. Sol 877 position is (-442,-132,0), Sol 878-882 position is (-472,-131,0). Using the Sol 877 position as the origin (left), then I can find the offset as (-472 - -442, -131 - -132, 0 - 0) which gives an offset of (-30,1,0) ... very close to that which you get using the APG to measure to from the Sol 877 position to the estimated Sol 878 position, particularly considering the error. Of course these map-derived coordinates could be improved further if we could provide a Z component, but that becomes less important as the distance between the positions increases. The next version of APG should include Azimuth/Elevation information which will assist in this correction.

Anyway, one thing I am looking forward to is working with a nice wide baseline which is relatively orthogonal to the future drive direction towards Victoria. Just at the moment I'm thinking that a good baseline will be that between Oppy's Sol 883 and current Sol 898+ positions, I'm just waiting for them to take some more pancams towards the south. Using the Sol 898+ position as the origin, the offset vector to the Sol 883 position is (-502.5 - -488, -134.5 - -224, 0 - 0) = (-14.5, 89.5, 0). I might further estimate that Z might be something like -2 or -3 or thereabouts. That's a healthy baseline, triple the baseline between the Sols 877 - 878 positions, and we ought to be able to meaure pretty much anything we can see to really good accuracy (meters). At some point I may also have a go at measuring the range of the twin peaks way off to the east, once I establish a north-south baseline of 100-200 meters.

I hope that helps a little

Thanks. I misunderstood earlier and thought the baseline vector had to be mostly normal to the direction to the target. I appreciate the importance of knowing which positions are left and right. In fact, if one wants to use the same long baseline images to measure distance to multiple targets, it may be necessary to switch the left and right positions depending on which side of the baseline vector the target lies.

I'm glad you mentioned that you wanted to do the one from sol 883 to the present location, and the really long baseline view toward twin peaks. Those are exactly the two I was thinking about. I'll refrain from doing them, since you deserve the fun after doing all the hard work.

Sorry to drop in the middle of the conversation....

It's funny: when the very long baseline range measurements were discussed in earlier in the thread, I instantly thought of the two distant peaks.

My question: would the images of the peaks on / near sol 774 provide any notable improvement in measurement?


-- Pertinax

No problem, please join in. Yes indeed, the view from near Sol 774 would indeed help a great deal in establishing that long baseline, however the trick will be getting coordinates for it in the current context, so as to extablish a topocentric offset vector between it and our current position. Seems like I estimated a while back (don't trust my memory) that a 200 meter baseline would yield about a 1 degree offset between those peaks. More would be better.

Lately I've been spending most of my free time on getting APG 3.1 ready to post (should go out later today or tomorrow, w/ integrated Azimuth/Elevation and pre-loaded image orientation data thru today). I had a quick go at doing some measurements towards the south with a long baseline (Sol 883 to present position, I think it was). I kept getting ranges which were about 20% short of what the map showed, though with that baseline I think it ought to have been much better than that. I would be really interested in what sort of results others get using other baselines, so please feel free to do as you please in that regard CosmicRocker The differences have me wondering about the drift rate in the rover orientation quaternion (may be more substantial than I'd expected), so comparing results from different site-pairs may clarify that question. Alternately the north reference direction reported by the rover may differ from that shown on the map view (APG 3.1 should help address that question). Finally there may be a flaw in my code. There's also the problem that many of these more distant targets tend to be a bit "fuzzy", which I suppose shouldn't be surprising.

AlgorimancerPG version 3.1 has been released:

http://www.clarkandersen.com/RangeFinder.htm
Click to view attachment

As mentioned earlier, version 3.1 adds ground referenced azimuth and elevation information, both from the cameras' perspectives when you click a point in an image, and in the calculated result (the latter referenced to the rover origin). Additionally it automatically imports archived rover and camera orientation data which is complete and current as of today; additional image data files will be posted periodically to the AlgorimancerPG website. Refer to the documentation file for additional information.

In order for everything to work nicely, it is recommended that you not modify the default installation path. Enjoy.

I just had a quick go at testing the stability of the azimuth measurements. I used APG to measure the Azimuth of the right (southernmost) peak of the Twin Peaks for 11 rover positions between Sol 862 and Sol 898. Using the changes in topocentric x (north-south) coordinate, and the known range to the peaks of 35 km, I calculated the relative and absolute change in angle at each position, and did the same with the azimuths I'd recorded previously. Here's a graph of the results, which essentially shows the angle at a particular site with regard to the Sol 862 position, for both the map derived and rover derived angles.

Click to view attachment

And here's a graph comparing the relative (site to site) angles:

Click to view attachment

Based upon this, it looks to me like the rover orientation quaternion has a fairly noticeable drift (and there're signs of periodic adjustment).

Would anyone happen to have more detailed information about this? For example, is there somewhere a record of the particular occasions on which they recalibrate the rover orientation? Likewise, a report that discusses the drift rate would be helpful.

I got a bit sidetracked this weekend with some elder care issues and the newly mentioned Half Pipe formation, so I haven't tried the new capabilities yet. Regarding your question about rover orientation quaternion drift, that is way over my head. I do think some of the updates have mentioned something about occasional drift corrections to navigational parameters, but I couldn't find an example tonight.

I just slipped a version 3.2 of AlgorimancerPG onto the usual site. After a bit of exploring I found that the long baseline ranging works pretty well if I constrain it to a 2D solution, using only the horizontal components of the pixel direction vectors. The new version has a 2D checkbox which, when checked, constrains the results to the local horizontal plane.

Using the 2D approach I used images from the Sols 877 and 898-306 positions and ranged Delta and Epsilon and Hawking Rock to within about 30 meters, a largish error which I guess is to be expected considering the apparent +/-1 degree error in the IMU orientation and the fuzziness of the targets. It appears that much of that brightness on the horizon to the left of Hawking Rock is actually the crater Epsilon ... not surprisingly very similar in appearance to Delta from the Sol 898-306 perspective. I was not able to find a good target on Victoria (good target meaning distinctly identifiable from both rover locations) ... just too fuzzy.

Anyway, here's a labeled Pano from the Sol 898+ position, and a labeled section of the latest route map as well (the squiggly crossed regions are the predicted positions from APG).

Click to view attachment
Click to view attachment

Well, I've managed to get a better handle on rover orientation accuracy (thanks to mcaplinger pointing me towards the relevant papers). Looks like the rover orientation is established within 1.5 degrees, and needs recalibrated about every 20 Sols (1.5 degrees being the required pointing accuracy of the HGA). This is loosely in agreement with the azimuth variation I mentioned previously.

The next question is what APG can do about it. If we can use APG to measure the azimuth of a target to which we can establish a reference azimuth (perhaps the twin peaks, for now), then in principal we can simply measure the deviation in rover azimuth from each rover position, and use that deviation to apply a correction within APG, hopefully allowing it to get somewhere closer to the expected accuracy during wide baseline measurements. To do this right, I'll need to be able to establish the rover position in planetary latitude/longitude coordinates, and do the same with the reference target, then it comes down to straightforward quaternion math... this may take some time. Perhaps I'll get to it in the next week. Meanwhile, if you're doing wide baseline measurements, bear this angular error in mind; it has no effect on normal, single site measurements with AGP.

I agree that a firm reference azimuth is the way to go. I'd love to try your new version of APG, when I get time! In the mean time, I tried to locate Hawking by a simple triangulation using this sol 883 pancam frame and this sol 904 frame.

I measured the angular separation from Hawking to Epsilon on both frames. Both features are in each frame, so no splicing was needed. The biggest source of error is in identifying the same point on Epsilon in the two frames. I'd guess I could be out by 10 or 20 metres, most of that uncertainty is along the line of sight.

Here's the result - Hawking is near the arrowed intersection of thin lines:
Click to view attachment
The really freaky thing is that my position agrees with the little circle in your Hawking scribble to within 2 or 3 metres! Like I said, unless I'm lucky I expect larger errors, so I'd say this is a bit of a coincidence. Nevertheless, the rock is somewhere near there. There's no very obvious candidate in the orbital view.

Good to see some validation - I've been shooting in the dark to some extent, depending upon the route maps for verification. Yeah, aside from being fuzzy, matching up two views of those distant craters is tough! Their appearance changes a lot from different perspectives. I had hoped to get a fix on Zeta, but it's just way too amorphous to get a lock on, though there's some hope for Victoria itself.

I'm about a third of the way along to figuring an azimuth correction based upon the Twin Peaks (surely that crater has a real name...). Tim53 managed to come up with lat/lon coords, next I need to do the same for the rover locations, then finally build the math into APG. It occurs to me that it would be really helpful to overlay the route map on Google Mars... (there is a Google Mars, right?)

Speaking of APG, are there any problems with the Windows Installer version as opposed to the plain .exe file that I used to post? I'm still a little new to the Installer configuration, and there are lot's of settings I don't have a clear handle on just yet. In my case, I find that whenever I start APG from the Start menu it acts like it is extracting a compressed file prior to activating the application. Next version I'll try turning off compression, though this may yield a larger download file.

I was still using v2.5 until yesterday when I downloaded v3.2.
I'm getting the same problem as you plus another one which is related to the default installation directory; I'm affraid that anyone using Windows in international editions (e.g. German, French, Italian, Spanish) will suffer the same inconvenience.

The default installation directory in the Spanish edition is "C:\Archivos de Programa\..." instead of "C:\Program Files\..." like on US/UK editions. No problem at all until you execute APG. The first trouble indication is a pop-up window saying "Unable to open c:\Program Files\AlgorimancerPG\ImgDat"; after that the program opens as usual and I can select a pair of L-R images as always. But when I try to measure a distance by clicking on the left image, then right image, then <spacebar>, the program aborts exactly after hitting the spacebar. Actually, the following pop-up window opens asking if a report should (or not) be sent to Microsoft.

Click to view attachment

A raw translation is "TODO: <File description> has detected a problem and must be closed... Inform Microsoft about this problem. An error report has been created and can be sent to us... Send error report / Don't send"

A workaround to the problem is to re-install APG again manually changing the default directory to the english default "C:\Program Files\...". Doing that, APG works fine.

I had no time yet to work with the long baseline, but I'll probably do it during the weekend.

Sorry about that, I had no idea that international versions used a different default programs directory. I'll have to see about finding a more elegant solution - though I'm very glad that you found a reasonable workaround.

Oh yeah, that bit where it seems to be decompressing when you run APG from the Start menu? I noticed last night that if I run APG from the executable in the Programs directory it behaves normally. Not sure what's going on, as I have two very similar Windows Installer apps at work with virtually identical configurations, and neither of them behaves that way. Weirdness.

As of last night I have an Excel worksheet in which I've converted route map coordinates to Mars latitude/longitude coordinates, and further determined the anticipated azimuth to each of the Twin Peaks from each of those locations. Also recorded the corresponding azimuths measured in APG from several rover sites. Next step is to integrate a means of applying the azimuth difference within APG as a correction, which should dramatically improve the accuracy of the wide baseline measurements. It will likely be Saturday before everything is tidied-up and the new version of APG posted.

There is a Google Mars but the required API that allows you to specify non earth maps\image overlays\tilesets isn't open yet AFAIK.

Google Mars is fairly low res - even the very best coverage would have an entire MER traverse in the space of 100 pixels...
http://www.google.com/mars/#lat=-14.584912...mp;map=infrared

Doug

Had a look at that yesterday, and I agree it's not ready for primetime. Of course thats the web interface similar to Google Maps, rather than the standalone app like Google Earth (which they imply they're working on). In principal they ought to be able to pull up the same hires images from MGS and others that we browse ourselves, but I'm guessing it's not a big priority for them. If I had more time on my hands I'd see what I could put together, but I've got plenty to keep me busy lately.

Actually we might just be able to use the existing Google Earth application. Check out this link, specifically scroll down to part 6, Making Overlays. Seems like if we turn off terrain and add route map images as overlays, we could potentially do all sorts of neat things. No reason not to overlay Mars imagery on top of Earth imagery... of course measuring distances will be problematic.

http://bbs.keyhole.com/ubb/showflat.php/Ca.../0/page/0#16256

Then there's more involved stuff like this:

http://earth.google.com/kml/kml_tut.html#descriptive_html

With a bit of research, modify the planetary radius, modify the terrain map to use MOLA data, and overlay the right set of images, it seems very feasible. Now who has the time?

I've had a first try at correcting the azimuth error in the Sols 877 and 898+ locations and re-doing the photogrammetry to Delta, Hawking Rock, and Epsilon, and here's the results overlaid on a recent route map:

Click to view attachment

I'm not sure this is a big improvement over the last time, I may have gotten a sign wrong. Still within a crater diameter though, and this time I managed to range a fuzzy target near the entry ramp into Victoria (just a few meters below the bottom of the image. I'll mess with it some more over the next couple of days, I'm not ready to post the next APG version just yet.

On the plus side, based upon the azimuth offsets I've measured with reference to the twin peaks, it appears that the rover locations on Sols 875 and 898-906 have nearly zero error in their azimuths, so you can work with images from those site without any adjustment needed. Other sites with minimal errors include 870 (.1 degree), 891-895 (.3 degree), and 896-897 (0.2 degree). I'd be interested to see what sorts of results someone else manages.

I was doing a similar exercise yesterday evening trying to match Delta and Epsilon headings (taken from 907 and 909 nav/pancams) with the route map -- a sort of triangulation dry-run -- when I realized the differences between my basemap (R15-00822) and that new one used by Tim Parker to pinpoint the "beacon" (S11-00471) and recently posted here by Pando; similar effects when including the basemap on Phil's route into account.
The point is that Delta looks to be located on a different position (i.e. different heading) in relation to Beagle. For instance, measuring the heading to Delta from sol 891 position on R15-00822 and on S11-00471 I get aprox. 176º and 177.5º respectively. Epsilon, however, is located at 148º on both images.

What's the reason for that? I've discussed this point some months ago on the Route Map thread with James Canvin and my take was it is a consequence of the different incidence angles when the MOC images were taken, in combination with the elevation of the ground.
Perhaps Phil or Tim could help us on this issue.

At the end, I think we'll have to live with those +-1.5º uncertainties.

AlgorimancerPG Version 3.3 is released. Please try it and let me know whether it misbehaves. New features include:

- A menu option to automatically download the latest image database data from the APG homepage, simultaneously updating the local database file (this was Tesheiner's suggestion).

- Modified the Installer to handle International versions of Windows (I hope); you can set the default directory to wherever you like upon installation (also for Tesheiner's benefit).

- Manual azimuth adjustments are now possible for each image site location.

As usual you can find it here:

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

Click to view attachment

I have also included an Excel spreadsheet which includes such things as conversions from Route Map image coordinates to Topocentric coordinates, derivation of azimuth corrections based upon measurements towards the Twin Peaks, and conversion of wide baseline derived Hawking Rock Topocentric coordinates to Route Map image coordinates. Also includes azimuths to Hawking Rock from several site locations. May take a little study to see what I was up to.

Documentation has been reasonably updated, but at some point this will require a thorough re-write due to all the recent changes.

Oops, found a bug in APG 3.3, where it crashed when finding the range to a target in images lacking image database information (forgot to account for a null pointer). Sorry about that. Fixed it, posted corrected Version 3.3.1.

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

I'm still not sure what to do about the app's misbehavior in which, when you launch APG from the Start menu or the Desktop, it behaves as if it is extracting the application (or installing it again). Launching it directly from the executable file in the Program Files/AlgorimancerPG directory solves the problem, and if it bothers you simply execute it from there, or create your own shortcuts to that file from the Desktop and/or Start menu. Someday perhaps I'll figure out a more permanent fix, or perhaps simply leave-off having it install those defective shortcuts.

AlgorimancerPG 3.4 is released.

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

Some days ago I put out a request for a planar projection of the Sol 917 (oppy) images; should instead have asked for sharks with freakin lasers on their heads. Set out to figure out how to use the CAHVOR model and rover orientation data in APG to project images to the local plane (do it myself). I've had moderate success. Here's my Sol 916 plane projection, 40 meters square and North at top, following anti-vignetting via MarsRoverCenterAntiVignetting_R1 (nice),

Click to view attachment

Not perfect, and I have yet to figure out how to fix the edge pixel problem (edit, it's the orig. images, I'll fix it shortly), but I'm reasonably pleased with the results. Somewhere down the line I'll have to try some more interesting projections. Anyway, the capability to generate a plane projection of the images about a single site is now built into APG, under the File menu. Warning: plan on going off for a while (minutes to tens of minutes) while the projection is working; my fanless/water-cooled computer's radiator tower gets pretty toasty after running a few of these.

Also added a few other minor tweaks. Provided a beep following various load operations, as well as at the end the plane projection operation. Found a minor bug in the azimuth correction (forgot to rotate the camera's principal point per the correction), and fixed it. Cleaned-up the installation so that it no longer adds shortcuts in the Start menu and Desktop, since those were screwed-up (what was MS thinking?). Started storing the last-used directory in the Registry, as I got tired of the app forgetting where I last was.

I think that's about it.

Oh yeah, you'll probably want to map your own shortcut to the application's executable (located in the Program Files directory). You'll find the documentation there as well (no changes).

Enjoy

Sol 917 projection (APG v4.4.1) - no more white lines:

Click to view attachment

That's supposed to be a 60 meter square. It's not quite correct (Hawking is way too close) because my offset from rover frame to ground frame is not quite correct in this version (I have it set at 0.5, I think it's closer to 0.3). I'll update again later [EDIT: DONE]. I'm not clear about the origin of the color shifts, but that's a minor distraction.

hi algorimancer,

you makes a linear interpolation between your pixels, i think ?

if you want I have the C# code to make an polynomial interpolation. Conversion into C++ will really not be difficult.

the result will be well best.

as you want…

Hi Indian. Actually I believe that what I'm doing is a form of raytracing, which explains why it takes so darned long. I take the vectors corresponding to each vertex of each pixel in the source images (vectors are obtained via the camera model and camera/rover orientation), find the intersection of those vectors with the local plane, then simply find which pixels in my output image happen to intersect those quadrangles, and assign the output pixels the intensity of the pixel in the source image. In my first attempt I thought it would be a good idea to blend the intensities of overlapping projected pixels, but later decided that wasn't such a good idea (for example, blending a projected pancam image with a projected navcam image would be bad). So I'm not doing any interpolation whatsoever at this point, but thank you for the offer of code. Image projections and raytracing are new to me, and I'm sure there are more efficient techniques. Nevertheless I'm pleased that this works as well as it does.

arfff, I do not think that my code can help you,

in general, I make the opposite way, I leave the result and I seek the data in the image source to define the intensity of the final pixel…

in your case it is rather from the plan which is the pixel in the source which represents it, and I make my interpolation on the pixel of the source, which requires of reverse the model of the camera…

but it is a very good job

One approach might be to create a scaled up, smoothed texture file - that would at least reduce the pixel boundaries when using the raytrace approach.

Airbag

I am concerned that smoothing would reduce the data quality. When I see pixel boundaries I know that they are real limitations in the data set, and not an artifact of processing the data. I'm more interested in producing a useful picture than a pretty picture. Then of course there are trade-offs in quality vs. (time) performance. One thing I'm not doing at the moment is accounting for cases where a partial intersection occurs between a source pixel and target pixel, although it works tolerably well as long as the projected pixel is generally larger than the target pixel. I have not yet decided how best to handle this, but it is something I have been thinking about.

If your smoothing is on the same order of magnitude as the scaling, then you don't really lose anything, especially in the near region, where you probably have more source than destination pixels anyway. But it will make the far region look better.

Airbag.

Okay, let's say I'll investigate smoothing in a subsequent release. Just at the moment there are several things in the queue ahead of it. Currently I'm working on a cylindrical projection, then I want to do a better job at projected pixel intersections, and of course the interface to all of this could stand improvement. Meanwhile several other projects with similar aims are already well advanced or well underway (MMB, Indian3000's projects, Autostitch, etceteras, and of course there's those neat projections that Dilo is doing using Pov-Ray), so I'm mostly pursuing this for my own edification (I've wanted to explore image projection and ray-tracing for many years), and because I suspect that the CAHVOR camera model in APG brings a little something extra to the party.

General question here regarding AlgorimancerPG (a fantastic piece of software, by the way): How exactly do you output calculation results in topocentric frame coordinates?

I imported what I believe is the correct image database file, meaning the 100 Sol chunk that corresponds to the stereo pair of interest. The calculation results always seem to be in the local (i.e., rover) coordinate frame. I tried loading the database first and then the images, and the reverse order, to no effect. Any help is appeciated.

Cheers,
Brad

Hi Brad,

If you're using the current version of APG (3.4.2), it should contain all the image database data current up to a few days ago as soon as you start it, so that you won't need to load a separate image database; it is handled automatically by the recent versions, though you still have the option to manually update. Just to be safe you can do a web update of the database (option under the files menu), which will bring it up to August 29'th, which was the last day I bothered to update the file since I haven't seen any new navcams/pancams since then. I'll check on that.

Assuming that the image database is current, when you load the images you should see check marks next to their positions - this verifies that the database data is indeed present for each image. If you don't see the check marks, either the database is incomplete (meaning I need to do an update, perhaps you're looking at a file which is more recent than my last update), or something has gone awry.

If you're still having trouble, let me know which images are the problem and I'll look into it.

[edit]Just updated the web database file to today's date.

Clark

Clark,

Many thanks for the quick reply. After some investigation, I see check marks in the boxes labeled "Img Left" and "Img Right" in the Calc Control window of AlgorimancerPC only on images after Sol 100. There does not appear to be an image database file info for images in Sols 0-100. Perhaps it got dropped somewhere along the way?

Also, thanks for clarifying what the topocentic frame actually is. I am going to re-post your reply here for the edification of others:



If I could humbly suggest a modification for the next version, one suggestion would be to add a label that identifies the frame of the coordinate output (i.e., image frame or topocentric frame).

You're welcome

Thank you for bringing to my attention the missing data for Sols 1-100. I have just merged that data into the web update file, so if you do a quick web update now it should fix the problem.

Details about the image frame are buried in the documentation. Basically if you've got a pair of checks you've got Topo frame.

Motivated by the drive to the Sol 930 site near Epsilon, I updated the website and updated AlgorimancerPG to version 3.4.3. The cylindrical projection option is still very much in beta version, but mostly functions. Planar projection has a few more options. Provided an option to disable the beeps if they get distracting. As usual:

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

For the first time in at least a couple of months (it's been slow for awhile) I have updated the image database file (ImageDatabase09000999.txt) on the website, so those of you using AlgorimancerPG can constructively do a web update (under the file menu) if you make use of that additional information. I assume that the heavy users know how to generate this information themselves from the appropriate website, otherwise if you need the information and I've gotten behind, send me a message and I'll deal with it.

No additional updates to APG to worry about, I think it is working pretty well as-is, and the real world is keeping me plenty busy. I'm looking forward to updating it to cope with Phoenix and MSL images, but that will be awhile.

Did another update of the image database file (ImageDatabase09000999.txt) on the website. Incidentally, for those users who haven't tried it, the quick way of handling this update is option 4 under APG's File menu. One click and a few minutes later it will let you know that it is done.

Some day I'll figure out some way of automating the database update. As it is, I do it when I think about it, which pretty-much means when I notice that something interesting is going on somewhere.

Since it looks like things are about to get interesting at Meridiani, what with Oppy finally preparing to enter Duck Bay, I have again updated the image database file on the APG website. I also cleaned-up the website a bit, purging version information and out-of-date prior versions of AlgorimancerPG. I also updated the version of APG posted on the site, but only to the extent of disabling some experimental menu options which I haven't had time or motivation to pursue, as well as updating the image database packaged with the installation - but I did not update the version number, so if you have the latest you needn't download again (just do a web update, as mentioned previously). As usual, it is to be found at:
http://www.clarkandersen.com/RangeFinder.htm

Major update to AlgorimancerPG, adding support for the Phoenix SSI camera, improved image rendering, and faster image properties database.

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

Details:

Current Version 4.0 (May 2008)

The AlgorimancerPG application has lately undergone some very major revisions, principally to support the Phoenix lander in addition to the MER rovers.

1) Support for the Phoenix lander's SSI stereo camera has been added, thanks to support from the camera's PI, Mark Lemmon. This will allow ranging and photogrammetry within a stereo pair of images, however at this time there is no database support available (from the mission), which means that such things as true azimuth and elevation are not available.

2) The internal MER database, which provides rover position and camera orientation so that true azimuth and elevation can be determined, has been extensively revised. The local database file (the ImgBinDat file in the executable directory) is now in a binary format supporting subsequent extension as needed. More importantly, within the application the database is now in a sorted format, which means that it is much quicker to search and update than in prior versions, and handles updates more robustly than before.

3) Image rendering now uses the CxImage library rather than the prior (very slow) Microsoft .Net approach. This means that images will render almost instantly, and they now follow the cursor when dragged. One consequence of making the dragging behavior flicker-free has been a change of the background color from white to black (the only real difference from the screenshot below).

In spite of all of these changes the behavior of the application is otherwise virtually unchanged.

-------------------------
Between now and the Phoenix landing there may be one (possibly two) additional releases of APG strictly related to Phoenix. The Phoenix sol/time conversion from the image header is currently incorrect, and is on my TODO list. If some sort of image database support similar to the Pancam Tracking database becomes available for Phoenix I am contemplating adding support for the RAC (the camera on the robotic arm); currently this is not in the cards. Meanwhile, MER users should appreciate the vastly faster database handling and image dragging.

For those not following the Phoenix thread... Current version of APG is 4.0.5. I identified a few bugs with version 4 this morning when I had a look at the first Phoenix stereo pair, the worst of which would have left that version effectively unusable - the result of doing my testing with a debug rather than a release version. Fixed that bug, validated (as best I could) the Phoenix camera model (by correctly measuring the diameter of the landing pad), plus fixed the Phoenix Sol/Local-time display. The 4.0.5 version should be it for awhile, unless some other bugs turn-up or a Phoenix tracking database is made available.