HiRISE DEM's |
HiRISE DEM's |
Nov 25 2010, 06:47 AM
Post
#121
|
|
Newbie Group: Members Posts: 19 Joined: 17-June 09 Member No.: 4825 |
Hi all, I've finally had enough free time to do some more animations based on the HiRISE DTMs. I hope you like them. Absolutely amazing. I love your animations. I do have a question if you don't mind. How do you handle the large .25m images and in real time no less? Do you chop them up into more manageable pieces? Or do you just have a really powerful computer/graphics card? I've been using 3dsmax and it really doesn't like large images, so I have to chop mine up into small bits, which can be a bit of a pain. I'm just wondering if you have a better technique or solution. Thanks. |
|
|
Nov 25 2010, 07:36 PM
Post
#122
|
|
Junior Member Group: Members Posts: 37 Joined: 26-January 10 From: Reading, UK Member No.: 5192 |
Hi JRA,
I have 4GB of ram (only 3GB is usable because I'm running a 32bit OS) The maximum image size I have been able to load into system memory is 32768x49152. Because its greyscale it uses 32768x49152x1 bytes which is 1.6GB. The image is then broken into tiles in memory and a cache of visible tiles are stored on the graphics card, so although I have a graphics card with 1.5Gb of RAM I think 512MB of video RAM would work ok to. Some of the dataset images are bigger than what I can load into system memory e.g. Mojave, so I have to crop them. A 64bit OS with 6GB of RAM would allow me to not crop any of the datasets and run at the maximum resolution. I am using a dual core CPU @ 1.8Ghz, CPU speed is not a limiting factor and mid range GPUs can handle the number of polygons I'm rendering. The biggest issue is the high system memory requirement. I don't know 3dsmax so I cant give you any advice on that. |
|
|
Nov 26 2010, 06:25 AM
Post
#123
|
|
Newbie Group: Members Posts: 19 Joined: 17-June 09 Member No.: 4825 |
Hey, thanks for the reply and information. I think I'll have to stick to chopping them up into bite sized pieces for now then.
|
|
|
Aug 22 2013, 06:45 PM
Post
#124
|
||
Newbie Group: Members Posts: 12 Joined: 17-July 13 From: Earth Member No.: 6973 |
These are all great visualizations of the HiRISE elevation data, Doug your flyovers are simply superior. I am still crashing my spacecraft through the surface or veering off into the vast whiteness of space. I also think your layover here is outta this world, literally.
I wanted to visualize how the Gale Crater (msl study site) surface projects itself in terms of different sensors, as well as between the 10 adjacent HiRISE dtms listed on the map. A two-framed “flashing” movie here is an example of feature dislocation at the edge of the orthographic images. The map below projects those differences at 50-meter breaks spanning the 10 HiRISE dtm extent. The difference at the edges (featured in red) is most apparent in the Northern portion of the image. The hilly terrain to the south values are offset slightly compared to the Northern portion, but still visibly offset by some tens of meters in places. This offset affects the mosaic, and every model I run afterward, which is in conflict with my longing for order, especially in the overlapping regions of the map at larger extents. I have a couple ideas I may try but my mars time is slipping away rapidly to studies of a more earthly nature.... If anyone has experience geo-referencing or creating orthos I would greatly appreciate your comments. |
|
|
||
Aug 22 2013, 07:19 PM
Post
#125
|
|
Founder Group: Chairman Posts: 14434 Joined: 8-February 04 Member No.: 1 |
Any HiRISE DTM (and I assume HRSC DTM ) gets matched to the reference MOLA data. In same cases, there might only be one or two MOLA points within an entire DTM with which to do that.
The uncertainty of MOLA, the sparsity of its data compared to the HiRISE or HRSC footprint, the size of a MOLA footprint, and os on and so forth - this results in the differences between neigbouring DTMs. It's a non-trivial task to remove those differences - one which I know some developers here on lab have tried to solve using a gradient domain solution that took several months. |
|
|
Aug 22 2013, 07:48 PM
Post
#126
|
|
Member Group: Admin Posts: 976 Joined: 29-September 06 From: Pasadena, CA - USA Member No.: 1200 |
RRussman, each DTM is ortho rectified an as such they are projected on a flat plane but each DTM is projected on a different plane so at the edges the planes exhibit the largest co-registration error. You would need to re-project all DTMs on a common plane but besides being non-trivial, the map you obtain is not really "ortho" anymore as you would have significant distortions. The other thing you could do is to project each DTM on the spheroid and then do a cylindrical projection. There's no good solution and what I do is to just work on one DTM at a time (currently still on PSP_010573_1755).
Paolo -------------------- Disclaimer: all opinions, ideas and information included here are my own,and should not be intended to represent opinion or policy of my employer.
|
|
|
Aug 22 2013, 07:48 PM
Post
#127
|
|
Solar System Cartographer Group: Members Posts: 10226 Joined: 5-April 05 From: Canada Member No.: 227 |
One lesson to take from this is that DEMs and associated orthophotos look beautiful but are not gospel. You have to treat them with a bit of suspicion.
Phil -------------------- ... because the Solar System ain't gonna map itself.
Also to be found posting similar content on https://mastodon.social/@PhilStooke Maps for download (free PDF: https://upload.wikimedia.org/wikipedia/comm...Cartography.pdf NOTE: everything created by me which I post on UMSF is considered to be in the public domain (NOT CC, public domain) |
|
|
Aug 24 2013, 11:35 PM
Post
#128
|
|
Newbie Group: Members Posts: 12 Joined: 17-July 13 From: Earth Member No.: 6973 |
Doug, I’m pretty sure everything is matched to MOLA after 2000, but as you point out, the sampling is sparse even along track. By sparse I mean there are 48,211 mola points (PEDR) over several tracks/orbits in the map extent, and yes, some dtms are far more populated than others are. The HRSC and HiRise products are continuous data sets with much finer resolution. An excerpt from the literature on the resolution mismatch:
“Because of the low horizontal resolution of the MOLA data set compared to HiRISE images, vertical accuracy will likely be governed by the difference between localized topographic features and the broader-scale relief as measured by the altimetry, and may be several meters. The resolution mismatch between the two data sets is likely to make direct use of MOLA for horizontal control almost impossible. Our approach is to control lower-resolution images to a shaded relief product generated from MOLA data gridded at 1/256 or 231 m/pixel, then to transfer control from these images to the high-resolution stereopair.” (McKewen, etal, 2007) (from Wiley/JGR, access required for full text)The discontinuity is most noticeable in the northern portion of the map with the DTEEC_010573_1755_010639_1755_U01 appearing offset more, relative to the adjacent overlapping regions, as well as the general flow of the collective model at multi-product extents. It might simply be that this model received less rigorous processing to the north and away from the msl region of interest. “Since editing is extremely time-consuming, it is usually done on easily corrected errors and in the areas of most interest to the researcher.” (From the About DTMs page) Paolo, I appreciate your suggestions and will experiment with re-projecting the dtms. I have experimented with re-geo-referencing the orthos (3rd order polynomial RMS:~0.7). The distortions were minimal, but as you mentioned, they lose their distinct relationship to the dtm and coordinate system, not to mention time consuming, tedious work. It makes your solution sound very appealing. Phil, I am suspicious of every data set I open, especially my own |
|
|
Lo-Fi Version | Time is now: 23rd September 2024 - 03:06 PM |
RULES AND GUIDELINES Please read the Forum Rules and Guidelines before posting. IMAGE COPYRIGHT |
OPINIONS AND MODERATION Opinions expressed on UnmannedSpaceflight.com are those of the individual posters and do not necessarily reflect the opinions of UnmannedSpaceflight.com or The Planetary Society. The all-volunteer UnmannedSpaceflight.com moderation team is wholly independent of The Planetary Society. The Planetary Society has no influence over decisions made by the UnmannedSpaceflight.com moderators. |
SUPPORT THE FORUM Unmannedspaceflight.com is funded by the Planetary Society. Please consider supporting our work and many other projects by donating to the Society or becoming a member. |