Help - Search - Members - Calendar
Full Version: Experimental Rhea DEM animation
Unmanned Spaceflight.com > EVA > Image Processing Techniques
Bjorn Jonsson
It works!! For months I've been trying to get my program for generating DEMs from stereo images to work properly. A recent 'rant' of mine can be found here.

Well, to make a long story short my software now at last works:

Click to view attachment

The only drawback is that the DEM has a somewhat 'contoured' appearance. This shows up in renderings of the DEM, even after I smoothed it considerably using Photoshop. Still this is much better than the infamous horizontal lines I got in my shape from shading experiments. A rendering showing the DEM:

Click to view attachment

However, 2-3 meters away from the monitor this looks very nice (the thumbnail image also looks nice smile.gif ). It turns out that the software has managed to detect most of the craters except for the really small ones. If someone finds a way to process the DEM image and remove the 'contours' without excessive loss of details I'd like to know. Please note that the DEM is a 16 bits/pixel image.

Some additional notes on the DEM: The DEM is a section from a 4320x2160 pixel simple cylindrical map and has an altitude range of approximately 16 km. The lowest points (black) are 778.6 km from Rhea's center and the highest ones (white) are 794.5 km from Rhea's center. This is odd (Rhea's dimensions are 768x763x763 km) and is probably due to inaccuracies in the viewing geometry information that came with the PDS files I used. The overall lower elevation of the upper part of the DEM compared to the lower part is probably another manifestation of this.

I used these two images obtained in January 2005:

Click to view attachment

Click to view attachment

North is to the right in the images.

Looking at the images it is apparent that the DEM's heavily contoured appearance at upper left is (probably) due to the fact that there wasn't a very big difference in the viewing geometry in that area whereas in the lower part of the DEM the difference is significant.

Taking a section of Steve Albers' map and draping it over the DEM produces interesting results (The crater at ~(315,260) in the DEM is at ~(3440,1160) in Steve's map). Here is a quick-and-dirty animation:

Rhea experimental DEM animation (4.6 MB)

In contrast, without Steve's map things get less realistic:

Click to view attachment

However, now the lightsource can be anywhere.

Needless to say I'm happy. The only problem is the huge number of DEMs I want to do: All of Saturn's major satellites (everything that can be done - global if at all possible), various sites on Mars etc. This is a lot of work, the DEM of Rhea required 100+ manually measured control points and then took almost 4 hours to compute on a 3 GHz machine. Also the viewing geometry needs to be refined.
ugordan
It's probably saying something you already know, but the contoured appearance of the rendering looks to be directly related to the low number of discrete elevations. The DEM looks like a 16 level grayscale in other words, quantized elevations. Is this due to limitations of your software or limitations of the data?

Needless to say, this is a most impressive undertaking of yours!
scalbers
Interesting work Bjorn. For the contouring, perhaps an algorithm could determine the direction of the gradient, then interpolate between the contour levels along that direction to smooth out the steps?

On the AVI file, is there a player other than Quicktime that can show it? Unfortunately this wasn't working on my laptop.
Bjorn Jonsson
Regarding possible quantized elevations there are many different elevation values (definitely thousands or even tens of thousands) - the contoured appearance is not an artifact of a conversion to 16 bit unsigned integers. It may be possible to get at least marginally better results - I'm still getting a feel for how various different parameters affect the resulting DEMs. The program does not calculate anything to subpixel accuracy - instead I decided to be lazy and simply enlarge the images in Photoshop when I want subpixel accuracy (this also makes it easier to measure the control points). In this case I was using images enlarged by a factor of four. I'm going to try a factor of 8 instead and see what happens. The only problem is that using a factor of 8 the DEM takes a much longer time to calculate than when I use a factor of 4.

The AVI file is encoded using DivX. Those who cannot view the animation should take a look at http://www.divx.com/ .
MouseOnMars
Well, that's great. I've been frustrated by things like the tiny number of Mars Express DEM's.

Are you planning on releasing this software ? I know that if you can get coders interested then there are people who are very experienced with optimising software. You could use a site like sourceforge ( sf.net ) to manage a project but there are other ways as well.

mouseonmars
angel1801
I downloaded the the .avi file and it runs perfectly using Winamp 5.35 . Winamp plays .avi files very well and here's the site to download it from.

http://www.winamp.com
scalbers
Great - winamp works well for me. And that's a nice fly around Rhea Bjorn.
edstrick
"...I downloaded the the .avi file and it runs perfectly using Winamp 5.35 ...."

I had no problem playing the file with Media Player Classic with a codec megapack <open source plays damn near everything> One thing I can't play is the current version of Quicktime movies. I havent migrated off Win98se and there's no codec for them in 98se.
algorimancer
Bjorn, that is indeed very nifty - impressive even. I have lately been messing-about doing something similar with the MER images (integrated within my APG software). The big trick for me is automatic feature co-registration between image pairs, which I see you have sidestepped by simply doing it manually. At best I'm getting about 50% accuracy at matching up features, probably rather worse; afterward there's a lot of clean-up to do - which requires a combination of stereo viewing to clearly distinguish between good and bad vertices, along with 3D control and editing - neither of which is a feature of APG, and must be done separately. The trick I have not yet mastered (yet you have) is transferring images onto the resulting triangulated surface - though with a fine enough mesh it becomes more a matter of assigning colors than images. For me this remains an ongoing project; it is nice to see your results, and I look forward to seeing more.

I'm curious as to one aspect... are you able to pull the camera positions and orientations relative to the satellite neatly out of some database, or are you having to solve for them as part of the optimization? Bundle adjustment, perhaps?

Your link to the StereoMatcher page may be helpful - at the very least there are some nice references there, though I haven't tried the software.

I have a little fantasy that by the time MSL gets to Mars we dilettantes may be able to routinely generate DEM's for the MSL mission the way we do route maps for MER, and perhaps be a jump ahead of the pro's. Technically this is feasible even now, but not in a quick & automated fashion, and I have a day job smile.gif
Bjorn Jonsson
Generating DEMs for MSL the way route maps are generated now would be fun but there are performance issues so I have some doubts. Manually measuring control points also takes a lot of time (I'm using 112 control points for the Rhea DEM) but I may be able to partially automate the process in the future.

More significantly, I have now managed to make some optimizations and changes with the result that my software is at least 5 times faster than it was a week ago but I still really need more speed. As I suspected the 'contoured' appearance of the DEM was because I was computing the DEM to a subpixel accuracy of only 0.25 (4x4 points per pixel). After increasing this to 6x6 things look much better but now take about 8 hours to compute despite the aforementioned optimizations. Increasing this to 8x8 or even 10x10 would be preferable but is not feasible as the DEM would take several days to compute sad.gif. I obviously need a much faster computer.

The DEM now looks like this:

Click to view attachment

The contours are less obvious now. Also the DEM is no longer 'tilted' (the upper half of the earlier DEM was at lower altitudes than the lower half). This is because I'm using improved viewing geometry - the subspacecraft_line_sample in the PDS files was off by roughly 30 pixels. Black (0) now represents points 760 km from Rhea's center and white (65535) 768.33 km. This agrees well with Rhea's mean radius of 764.4 km.

Not unexpectedly, the 'contours' are also less obvious in rendered images of the DEM:

Click to view attachment

Not perfect but much better than the earlier version. Apparently the size of central peaks somehow gets overestimated rather often but overall I'm happy. I even think this is accurate enough to estimate the depth of some of the craters. For example, the crater at (325,270) in the DEM is approximately 4.5 km deep and its central peak 2-2.5 km high.

QUOTE (algorimancer @ Jul 24 2007, 02:42 AM) *
I'm curious as to one aspect... are you able to pull the camera positions and orientations relative to the satellite neatly out of some database, or are you having to solve for them as part of the optimization? Bundle adjustment, perhaps?

This is one of the things frustrating me - the PDS files contain information on the viewing geometry but as previously indicated, it's not accurate enough. Apparently I can assume the spacecraft position to be correct but the camera pointing needs to be updated - a 30 pixel error in the position of the subspacecraft point in the image is huge.

Now the next thing to do is to generate some additional DEMs, possibly of Tethys' Ithaca Chasma and Odysseus, Enceladus hi-res, Iapetus etc. - the list is endless. Disappointingly, there do not seem to be any nice images to use for generating DEMs of Mimas' Herschel crater. However, after checking the recently released SPICE stuff for the extended mission it seems to me that great images should be possible during the 10,000 km flyby in Cassini's extended mission.
Michael Capobianco
Perhaps not surprisingly, I vote for the Iapetus Saturnshine images next. The relationship between the dark material and topography is crucial to understanding what's going on.

Michael
algorimancer
QUOTE (Bjorn Jonsson @ Jul 27 2007, 12:34 PM) *
I obviously need a much faster computer.


If you happen to have a multi-processor (or dual/quad-core cpu), and you're developing in C++ or Fortran, you might try using OpenMP to parallelize some of the loops. I've found it fairly easy to learn and use, and have had good results with a dual-processor system - now I'm wishing for a quad-core smile.gif
tfisher
QUOTE
This is one of the things frustrating me - the PDS files contain information on the viewing geometry but as previously indicated, it's not accurate enough. Apparently I can assume the spacecraft position to be correct but the camera pointing needs to be updated - a 30 pixel error in the position of the subspacecraft point in the image is huge.


Yeah, I've seen the same thing looking at Titan. Really it makes sense though. They do know the spacecraft position to an insanely high degree of accuracy. They have to do design the trajectory out for years including flybys. And since they have the accurate model of the Saturn + moons gravitational system, and the spacecraft doesn't do thrust adjustments very often, they can generate a highly refined position model using observations from throughout the mission.

Contrast this to roll information. For mission objectives, they need to know pointing accurately enough to aim the antenna at earth and the cameras at the right targets. A 30 pixel error in pointing is 3% of the camera's field of view. That kind of error isn't going to make or break any observation. And in absolute terms, the narrow-angle camera has a field of view of 0.35 degrees, so the error is about 0.01 of a degree. On the other hand, Cassini controls its pointing using momentum wheels which are designed to control accuracy to about 1mrad = 0.0579 degrees. [ref] And its constantly slewing this way or that to aim at a different target or communicate with Earth, so modeling is out. That means the only way to get high accuracy information about pointing is to look at the output of the science instruments and match these with what you expected to see. This is a harder task, and highly dependent on what was being observed, so it isn't a great surprise they didn't do this for the PDS data release.
FordPrefect
Bjorn, this is VERY interesting! Your results are truly awesome. I've been trying unsuccessfully to find any free software, which could generate DEM's from stereo photos, and I am far from having the knowledge to code anything like this.

In a semi-similar attempt I created an elevation map using maps of the Lunar Topographic Orthophotomap (LTO) Series available on the website of the Lunar and Planetary Institute. It took a tremendous effort and a lot of time to manually vectorize all elevation contour lines in order to make a greyscale elevation (bump)map. My goal is to produce a realistic 3d model auf the Taurus-Littrow Valley and the surrounding area. A recent edit of two renders can be seen here and here.

Bjorn, I am watching this thread closely, can't wait to see more of this awesome piece of work. May I humbly ask if you can imagine that one day your program could be available to other users as well?

Anyway, keep the updates coming. smile.gif
Bjorn Jonsson
This is a preliminary DEM of Mimas' Herschel crater:

Click to view attachment

The DEM is very 'contoured' and the only real features detected are Herschel and its central peak. This is because the source images are of relatively low resolution (~1.5 km/pixel) and the subspacecraft point moved only ~7° between the two images I used. Distance from Mimas' center ranges from 182.9 to 202.0 km in the DEM, roughly consistent with Mimas' dimensions (207.4x197.2x190.7 km). This DEM implies the depth of Herschel is probably ~15 km where it is deepest and the height of the central peak about 10 km. This is probably (very?) inaccurate for the reasons mentioned above (low-res/similar subspacecraft point).

Images have been obtained that will probably result in a better DEM than this one but these are recent so they haven't been released to the PDS yet.

QUOTE (algorimancer @ Jul 28 2007, 01:14 PM) *
If you happen to have a multi-processor (or dual/quad-core cpu), and you're developing in C++ or Fortran, you might try using OpenMP to parallelize some of the loops. I've found it fairly easy to learn and use, and have had good results with a dual-processor system - now I'm wishing for a quad-core smile.gif

Multithreading is an excellent idea, actually my 3D renderer is already multithreaded and making my stereo software multithreaded as well is trivial. Actually the performance gain in my case is only about 20% as I have a fairly old machine with hyperthreading only but I'm hoping to get myself a quad-core system next year.

QUOTE (FordPrefect @ Jul 28 2007, 06:45 PM) *
In a semi-similar attempt I created an elevation map using maps of the Lunar Topographic Orthophotomap (LTO) Series available on the website of the Lunar and Planetary Institute. It took a tremendous effort and a lot of time to manually vectorize all elevation contour lines in order to make a greyscale elevation (bump)map. My goal is to produce a realistic 3d model auf the Taurus-Littrow Valley and the surrounding area. A recent edit of two renders can be seen here and here.

This looks great - very realistic.

I may make this software available one day but doing so requires considerable work so I don't know when it might happen. Right now I'm too busy producing DEMs wink.gif.
malgar
QUOTE (Bjorn Jonsson @ Jun 20 2007, 02:10 AM) *
I've been frustratingly close to generating DEMs of Saturn's satellites for some time using my own software that generates DEMs from stereo pairs. The problem is that the resulting 'DEMs' are far too noisy and contain too many spurious features and artifacts to be useful. If just this $%#€% thing worked as I want it to I would also be able to generate DEMs of Mars using two images (a stereo pair).
http://www.unmannedspaceflight.com/index.p...3&hl=stereo


Hello Bjorn! I wrote myself a software that generated DEMs from stereo pairs. It isn't perfect but noise isn't so high in most of the images.
I posted a work on the Moon section of this forum.. check here: Stereo from Apollo
Can you give me your stereo pairs where you tested your program?

Click to view attachment

Ciao,
Alessio
Bjorn Jonsson
This looks very impressive but it would be very interesting to see this same rendering without any texture draped over it (or even to see the DEM itself). I have noticed that a texture draped over a DEM adds a great deal of realism and also 'hides' many of the unwanted DEM artifacts ('contours' and noise).

I will post the images I used as stereo pairs in a day or two, I'm away from my main computer at the moment. It would be interesting to see how your DEM compares to mine.

BTW I will probably be posting a DEM covering a significant fraction of Mimas' surface within a week.
malgar
QUOTE (Bjorn Jonsson @ Aug 23 2007, 02:33 AM) *
This looks very impressive but it would be very interesting to see this same rendering without any texture draped over it (or even to see the DEM itself). I have noticed that a texture draped over a DEM adds a great deal of realism and also 'hides' many of the unwanted DEM artifacts ('contours' and noise).


You have right, for example as I said in the Apollo thread, I used a low resolution (50px) to avoid noise and then interpolated to 1 px. Only larger features are visible. A better resolution shows smaller carters but noise is a bit high. The left border doesn't show the ridge of the big crater.
It works but it could be much better. I would be glad to share each other ours code and work together. Two is better than one. If you want.. rolleyes.gif

In the attachment (half size due space limitations) the original image and the DTM.

Alessio

Click to view attachment Click to view attachment
Bjorn Jonsson
QUOTE (malgar @ Aug 22 2007, 08:56 AM) *
Can you give me your stereo pairs where you tested your program?

The two images of Herschel I used are these ones:

http://www.mmedia.is/bjj/3dtest/rhea_dem/N1501625473_1.png
http://www.mmedia.is/bjj/3dtest/rhea_dem/N1501627117_1.png

Viewing geometry:
N1501625473_1.png
Subspacecraft lat=-24.5768010
Subspacecraft lon=127.6508400
Range=251180 km
Subspacecraft line sample=558.331660
Subspacecraft line=397.742371
North azimuth=269.274119

N1501627117_1.png
Subspacecraft lat=-25.2006590
Subspacecraft lon=133.7466500
Range=227797 km
Subspacecraft line sample=476.255632
Subspacecraft line=507.076670
North azimuth=269.235065


For Rhea I used these images:
http://www.mmedia.is/bjj/3dtest/rhea_dem/N1484600736_1.png
http://www.mmedia.is/bjj/3dtest/rhea_dem/N1484607379_1.png

Viewing geometry:
N1484600736_1.png
Subspacecraft lat=-12.3275880
Subspacecraft lon=97.8282730
Range=172101 km
Subspacecraft line sample=341.191670
Subspacecraft line=-146.888170
North azimuth=0.220007

N1484607379_1.png
Subspacecraft lat=-13.5285270
Subspacecraft lon=113.2800300
Range=185439 km
Subspacecraft line sample=426.510190
Subspacecraft line=-193.320590
North azimuth=0.177863

The field of view is 0.351549 degrees.

In all cases I have modified the subspacecraft line sample and the subspacecraft line values from the values in the PDS-released files.
Bjorn Jonsson
Here is a fairly big DEM of Mimas:

Click to view attachment

This is a section of a 1800x900 pixel simple cylindrical map. It covers latitudes -76.6 to 47.6 and longitudes 158.4 to 283.2. The distance from Mimas' center ranges from 186.8 (black) to 209.6 km (white).

This DEM is a mosaic of two DEMs derived from one stereo pair each. One problem is immediately apparent: A ~2.5 km altitude difference near the left edge of the seam. This is due to viewing geometry errors. I am using significantly more accurate viewing geometry parameters than in the PDS files but they are still not accurate enough. At the moment I don't know how I'm going to correct this.

Comparing this DEM to the DEM of Rhea is interesting, for example comparing the crater depth/diameter ratios.
um3k
QUOTE (Bjorn Jonsson @ Aug 27 2007, 08:13 PM) *
At the moment I don't know how I'm going to correct this.

High pass filter! tongue.gif
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2024 Invision Power Services, Inc.