MSL landing site: Gale Crater |
  |
MSL landing site: Gale Crater |
 Jul 23 2012, 02:53 PM
Post
#196
|
|
 Member  Group: Admin Posts: 976 Joined: 29-September 06 From: Pasadena, CA - USA Member No.: 1200  |
The mosaic that I work on is at 1mpp, 30000x46256 pixels and is definitely manageable. As I said I wrote teh code myself but it is not that difficult. I used the orthophotos that are part of the DTMs not the map-projected HiRISE images. The map-projected are projected to MOLA while the orthos are a cylindrical projection which are much easier to deal with. I basically just shifted in X and Y the orthos and spliced them together. When I need to take a look at closer than 1mpp I work on one HiRISE image at a time. Do you know how to write code? If so, I can give some suggestions on how to write the mosaicing software. Actually, I will try and see if the netpbm tools can handle this.
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.
|
 |
 
|
|
Jul 23 2012, 04:17 PM
Post
#197
|
|
 Senior Member Group: Members Posts: 1465 Joined: 9-February 04 From: Columbus OH USA Member No.: 13 |
QUOTE (RoverDriver @ Jul 23 2012, 10:53 AM)  The mosaic that I work on is at 1mpp, 30000x46256 pixels and is definitely manageable. Hmmm... any chance of sharing that?  QUOTE I used the orthophotos that are part of the DTMs not the map-projected HiRISE images. The map-projected are projected to MOLA while the orthos are a cylindrical projection which are much easier to deal with. I basically just shifted in X and Y the orthos and spliced them together. When I need to take a look at closer than 1mpp I work on one HiRISE image at a time. Do you know how to write code? If so, I can give some suggestions on how to write the mosaicing software. Actually, I will try and see if the netpbm tools can handle this. I've written C code for ImageMagick, SPICE, mysql etc.--but seems like you mentioned something about 15,000 lines of code? Now that is some real work! I'll PM you with any further image processing questions as this thread is about Gale Crater. Thanks again. QUOTE (djellison) Tanya's mosaic is CTX, not HiRISE. Didn't say it was, but it's the highest-resolution map of the whole landing ellipse that's publicly out there, no? -------------------- |
|
|
|
|
Jul 23 2012, 11:01 PM
Post
#198
|
|
|
Member Group: Admin Posts: 976 Joined: 29-September 06 From: Pasadena, CA - USA Member No.: 1200 |
QUOTE (jmknapp @ Jul 23 2012, 08:17 AM) Hmmm... any chance of sharing that? I'm not sure it is OK for me to share, I don;t want to get into trouble. I will see if I can use the netpbm tools to do the mosaicing and will let you know. QUOTE I've written C code for ImageMagick, SPICE, mysql etc.--but seems like you mentioned something about 15,000 lines of code? Now that is some real work! I'll PM you with any further image processing questions as this thread is about Gale Crater. Thanks again. 15K lines of code includes everything, from mosaicing to traversability analysis, to traverse duration. Th stitching code is about 100 lines of code but as I was saying I will look and see if netpbm will do. If it was up to me I would gladly share the code but I think my bosses would be quite upset. I hope you understand. 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.
|
|
|
|
|
Jul 23 2012, 11:27 PM
Post
#199
|
|
 Merciless Robot Group: Admin Posts: 8783 Joined: 8-December 05 From: Los Angeles Member No.: 602 |
Paolo, please don't stress. If there's any doubt in your mind, just don't do it.
 UMSF is not, nor will it ever be, a place where the pros who grace us with their presence should ever have to feel pressured in any way to release info that they shouldn't. Period. -------------------- A few will take this knowledge and use this power of a dream realized as a force for change, an impetus for further discovery to make less ancient dreams real.
|
|
|
|
|
Jul 24 2012, 01:29 AM
Post
#200
|
|
|
Member Group: Admin Posts: 976 Joined: 29-September 06 From: Pasadena, CA - USA Member No.: 1200 |
Joe (jmknapp) sent me a PM whose reply might be of interest to others so I asked him if he would mind if I replied publicly to his queries.
QUOTE I was looking at the map-projected images, but I guess you're saying that they are harder to work with than cylindrical projections. I guess that means the seams don't line up quite right with a simple translation in X and Y? It is my inderstanding that "map projected" HiRISE images are projected on MOLA. Trying to stitch them together requires a real GIS tool where you can define tie points do rubber-sheet warping. While this has been done, I did not want to introduce re-sampling artifacts in the DEM so I opted to mosaic the orthophotos directly. These images are cylindrical projections and therefore a simple X and Y shift is sufficient. QUOTE Ideally, I think it would be very cool to have a program that takes a range of latitude and longitude as inputs, along with the desired resolution (mpp), and which outputs a mosaicked map pieced together from all available HiRISE images covering the desired region. I saw the label (LBL) files which give the information about each image. If the label file data were in an sql database, one could do a query to identify all images covering a given area. The rectangular sections of interest from each HiRISE file could be extracted via system() calls to kdu_expand and then downsampled to the desired resolution if necessary. Then ImageMagick calls could be made to assemble the mosaic. Unfortunately I have found that the georeferencing in either teh MAP and ORTHOs are not very accurate. If I compute the offsets from the georeferencing included in the image headers I end up with incorrect mosaics. They are useful to have a first order idea of where each image is, but not accurate enough for meter or submeter mosaicing. QUOTE .... 1) The lighting conditions vary between HiRISE images, so some kind of normalization would be necessary. Just a thought, although it might be complicated, is to allow overlap between the tiles and then make the overlapped regions similar in brightness. Alternatively, I suppose one might come up with an algorithm based on the sun angle, etc. I ended up keeping the different shadowing from each HiRISE ortho becasuse it allows me to see the seam for each one of them. There are algorithms to blend these seams, I'm going to let the fantastic people who generate the amazing panoramas to tell us how they do it. QUOTE 2) The map-projected images have triangular regions with no data, so that would have to be accounted for. The HiRISE images are taken while MRO is orbiting around the planet and therefore there is a slight angle between the HiRISE image and true North. In the Non Map Projected image North is roughly downward, if you rotate each image about 172 deg clockwise you have North side up but it leaves four triangles where there is no data, typically they paint that area black. QUOTE BTW, I coded something up that cropped a small rectangular region in latitude and longitude from whatever HiRISE images included it. The test region was from -4.40 to -4.42 in latitude and from 137.60 to 137.62 in longitude. That region matched these (grayscale, map-projected) images: ESP_011417_1755_RED.QLOOK.JP2 ESP_011562_1755_RED.QLOOK.JP2 ESP_024102_1755_RED.QLOOK.JP2 ESP_024735_1755_RED.QLOOK.JP2 ESP_025368_1755_RED.QLOOK.JP2 I used the label files to identify the min and max lat and lon for each image and calculate the cropping parameters for kdu_expand. It worked fairly well except that there were very slight differences in the cropped region from each file, like maybe there was about 5% play (maybe 0.01 degree). That would mean that an automated mosaic would have seams & manual tweaking would be required. Maybe I'll try it with the cylindrical projected files to see if it's any better. That is what I would expect. This is likely a combination of the projection on MOLA and the inaccuracies in the georeferencing. 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.
|
|
|
|
|
Jul 24 2012, 02:21 AM
Post
#201
|
|
|
Member Group: Admin Posts: 976 Joined: 29-September 06 From: Pasadena, CA - USA Member No.: 1200 |
While I can't share my mosaic, I developed an independent method to stitch the various orthos together.
Software: 1) Download and install the free kakadu software 2) Download and install the free netpbm tools. Dataset: 3) Download the 12 orthophotos from the HiRISE website, for example http://hirise.lpl.arizona.edu/dtm/dtm.php?ID=ESP_011417_1755 4) using the kdu_expand, part of the Kakadu Software, convert and resize each orthophoto image to PGM format at 1mpp, for example CODE kdu_expand -i ESP_011562_1755_RED_A_01_ORTHO.JP2 -reduce 2 -o ESP_011562_1755_RED_A_01_ORTHO.PGM 5) Run the script but before you do make sure you have lot of disk space in /tmp, this script as it is written uses around 33GB but once you understand how it works you can optimize the passages and trim it down. The result will be in GaleMosaic.pgm How does the script work: The script first creates a canvas using pgmmake, then it uses pnmpaste to paste each ortho to a copy of the canvas using offsets I determined empirically, finally it uses pamarith to merge the various images into groups and finally into one mosaic. I use the -max switch in pamarith to handle the black area surrounding the ortho. pgmmake, pnmpaste and pamarith are all part of the netpbm tools. It will take quite some time to run, this is mostly I/O bound, so the faster your disk, the faster it will run. OK, here is my ugly script. Don't laugh, usually my code is more efficient and better written. Paolo CODE # make a canvas
pgmmake 0 30016 46253 > /tmp/GaleMosaicBase.pgm # paste each image onto the canvas at the appropriate location pnmpaste ESP_011562_1755_RED_A_01_ORTHO.PGM 22218 295 /tmp/GaleMosaicBase.pgm > /tmp/ESP_011562_1755.pgm pnmpaste ESP_018854_1755_RED_A_01_ORTHO.PGM 10288 12027 /tmp/GaleMosaicBase.pgm > /tmp/ESP_018854_1755.pgm pnmpaste ESP_023957_1755_RED_A_01_ORTHO.PGM 15536 9483 /tmp/GaleMosaicBase.pgm > /tmp/ESP_023957_1755.pgm pnmpaste ESP_024234_1755_RED_A_01_ORTHO.PGM 1586 14795 /tmp/GaleMosaicBase.pgm > /tmp/ESP_024234_1755.pgm pnmpaste PSP_001488_1750_RED_A_01_ORTHO.PGM 4736 27509 /tmp/GaleMosaicBase.pgm > /tmp/PSP_001488_1750.pgm pnmpaste PSP_009294_1750_RED_A_01_ORTHO.PGM 11453 24893 /tmp/GaleMosaicBase.pgm > /tmp/PSP_009294_1750.pgm pnmpaste PSP_009505_1755_RED_A_01_ORTHO.PGM 15144 0 /tmp/GaleMosaicBase.pgm > /tmp/PSP_009505_1755.pgm pnmpaste PSP_009716_1755_RED_A_01_ORTHO.PGM 4546 8793 /tmp/GaleMosaicBase.pgm > /tmp/PSP_009716_1755.pgm pnmpaste PSP_010573_1755_RED_A_01_ORTHO.PGM 10412 5850 /tmp/GaleMosaicBase.pgm > /tmp/PSP_010573_1755.pgm pnmpaste ESP_024102_1755_RED_A_01_ORTHO.PGM 20972 11256 /tmp/GaleMosaicBase.pgm > /tmp/ESP_024102_1755.pgm pnmpaste ESP_019698_1750_RED_A_01_ORTHO.PGM 8970 27983 /tmp/GaleMosaicBase.pgm > /tmp/ESP_019698_1750.pgm pnmpaste ESP_012551_1750_RED_A_01_ORTHO.PGM 0 26236 /tmp/GaleMosaicBase.pgm > /tmp/ESP_012551_1750.pgm # merge pairs pamarith -max /tmp/ESP_011562_1755.pgm /tmp/ESP_018854_1755.pgm > /tmp/1 pamarith -max /tmp/ESP_023957_1755.pgm /tmp/ESP_024234_1755.pgm > /tmp/2 pamarith -max /tmp/PSP_001488_1750.pgm /tmp/PSP_009294_1750.pgm > /tmp/3 pamarith -max /tmp/PSP_009505_1755.pgm /tmp/PSP_009716_1755.pgm > /tmp/4 pamarith -max /tmp/PSP_010573_1755.pgm /tmp/ESP_024102_1755.pgm > /tmp/5 pamarith -max /tmp/ESP_019698_1750.pgm /tmp/ESP_012551_1750.pgm > /tmp/6 # merge quadruples pamarith -max /tmp/1 /tmp/2 > /tmp/12 pamarith -max /tmp/3 /tmp/4 > /tmp/34 pamarith -max /tmp/5 /tmp/6 > /tmp/56 # merge octuples pamarith -max /tmp/12 /tmp/34 > /tmp/1234 # merge one octuple and one quadruple into the final mosaic pamarith -max /tmp/1234 /tmp/56 > GaleMosaic.pgm -------------------- Disclaimer: all opinions, ideas and information included here are my own,and should not be intended to represent opinion or policy of my employer.
|
|
|
|
|
Jul 24 2012, 04:05 AM
Post
#202
|
|
|
Solar System Cartographer Group: Members Posts: 10153 Joined: 5-April 05 From: Canada Member No.: 227 |
I have not looked at the HiRISE images from the mosaic point of view, but i did not have the impression they were projected onto MOLA - that would be more like an orthophoto with relief distortions taken out. But look at HiRISE of Victoria where each image has the central dune field offset by different amounts. I think they are just projected onto the standard Mars ellipsoid. And one other qualification - each one is probably projected in its own unique projection system (such as a sinusoidal projection centered on its own central longitude, or conformal conic on its own latitude) - and they won't automatically line up with each other because some projection parameters are different.
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 PD: 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) |
|
|
|
|
Jul 24 2012, 04:18 AM
Post
#203
|
|
|
Member Group: Admin Posts: 976 Joined: 29-September 06 From: Pasadena, CA - USA Member No.: 1200 |
QUOTE (Phil Stooke @ Jul 23 2012, 08:05 PM) I have not looked at the HiRISE images from the mosaic point of view, but i did not have the impression they were projected onto MOLA - that would be more like an orthophoto with relief distortions taken out. But look at HiRISE of Victoria where each image has the central dune field offset by different amounts. I think they are just projected onto the standard Mars ellipsoid. And one other qualification - each one is probably projected in its own unique projection system (such as a sinusoidal projection centered on its own central longitude, or conformal conic on its own latitude) - and they won't automatically line up with each other because some projection parameters are different. Phil Phil, It is possible that my understanding is wrong about the map projection. I'm not really an expert in cartography, but as you say, stitching map projected images is quite more difficult than prthos. 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.
|
|
|
|
|
Jul 24 2012, 05:25 AM
Post
#204
|
|
|
Founder Group: Chairman Posts: 14432 Joined: 8-February 04 Member No.: 1 |
The one HiRISE DTM I helped make ( with Pete Grindrod, of the Pathfinder site ) it's my understanding that the workflow involving SOCET SET reprojects orthphotos onto the HiRSE DTM itself. Biggest giveaway I think is the fine granularity of the distortion one can see over larger topographic excursions along the Orthophoto edges.
I seem to remember that the MPF DTM we made had only one MOLA point in its entire coverage (and that's not uncommon, especially away from the poles) That point ties it to the global frame, but the DTM itself is used to generate the Orthophoto I think. |
|
|
|
|
Jul 24 2012, 10:50 AM
Post
#205
|
|
|
Junior Member Group: Members Posts: 53 Joined: 15-July 09 Member No.: 4867 |
It seems that ISIS3 considers the MOLA DTM for map projection. Thanks to my heavy computer, ISIS3 collected automatically all the needed HiRise Gale Crater images for me, and map projected all of them. There is an option to make the borders fit and look smooth, but basically each tile is projected independantly from orbital Spice data and local DTM.
Finally, the map is about 600 Go. I use Red Hat on a Pentium i7 and 42Go RAM computer. |
|
|
|
|
Jul 24 2012, 12:02 PM
Post
#206
|
|
|
Senior Member Group: Members Posts: 1465 Joined: 9-February 04 From: Columbus OH USA Member No.: 13 |
QUOTE (RoverDriver @ Jul 23 2012, 09:21 PM) I developed an independent method to stitch the various orthos together. Thank you! I'll give that a try (downloading the ortho JP2 files now). One thing: I can't find the mysterious ESP_024102_1755_RED_A_01_ORTHO file. Searching for ESP_024102_1755 yields a hit in the regular area, but there's no DTM page for that one as far as I can see. -------------------- |
|
|
|
|
Jul 24 2012, 01:09 PM
Post
#207
|
|
|
Member Group: Admin Posts: 976 Joined: 29-September 06 From: Pasadena, CA - USA Member No.: 1200 |
QUOTE (jmknapp @ Jul 24 2012, 04:02 AM) Thank you! I'll give that a try (downloading the ortho JP2 files now). One thing: I can't find the mysterious ESP_024102_1755_RED_A_01_ORTHO file. Searching for ESP_024102_1755 yields a hit in the regular area, but there's no DTM page for that one as far as I can see. That will be released soon. Let me know how it goes. 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.
|
|
|
|
|
Jul 24 2012, 01:14 PM
Post
#208
|
|
|
Member Group: Admin Posts: 976 Joined: 29-September 06 From: Pasadena, CA - USA Member No.: 1200 |
QUOTE (Lightning @ Jul 24 2012, 02:50 AM) It seems that ISIS3 considers the MOLA DTM for map projection. Thanks to my heavy computer, ISIS3 collected automatically all the needed HiRise Gale Crater images for me, and map projected all of them. There is an option to make the borders fit and look smooth, but basically each tile is projected independantly from orbital Spice data and local DTM. Finally, the map is about 600 Go. I use Red Hat on a Pentium i7 and 42Go RAM computer. Here at JPL they use ARCGIS but I did not want to resample the data, that's why I rolled my own ;-) It is nice to have a beefy system. At home i have old stuff but at work I managed to get a Mac Pro, 12 cores, 64GB RAM, two 30" cinema displays, and I think I have a total of 14TB on line but the actual is much less since I keep five (!!) daily backups of my MSL data 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.
|
|
|
|
|
Jul 24 2012, 06:20 PM
Post
#209
|
|
|
Senior Member Group: Members Posts: 1465 Joined: 9-February 04 From: Columbus OH USA Member No.: 13 |
QUOTE (RoverDriver @ Jul 24 2012, 08:09 AM) That will be released soon. Let me know how it goes. Paolo OK, it works, but it required a couple of minor tweaks. Here's a thumbnail of the resulting mosaic:  For the time being the script needs to be modified to account for the missing file, i.e., comment out this line: #pnmpaste ESP_024102_1755_RED_A_01_ORTHO.PGM 20972 11256 /tmp/GaleMosaicBase.pgm > /tmp/ESP_024102_1755.pgm And change this line from: pamarith -max /tmp/PSP_010573_1755.pgm /tmp/ESP_024102_1755.pgm > /tmp/5 to: pamarith -max /tmp/PSP_010573_1755.pgm /tmp/PSP_010573_1755.pgm > /tmp/5 ...so it just composites the same image on top of itself. Also, when running it the first time I got a couple of error messages when it tried to create two of the intermediate files, ESP_011562_1755.pgm and ESP_019698_1750.pgm. The error messages were, respectively: pnmpaste: x + width is too large by 1 pixels pnmpaste: y + height is too large by 1 pixels In each case a zero-length file was created, which caused downstream processing to blow up. So I increased the size of the base image by one pixel in each direction, changing: pgmmake 0 30017 46254 > /tmp/GaleMosaicBase.pgm to: pgmmake 0 30018 46255 > /tmp/GaleMosaicBase.pgm Then it went through and automagically created the mosaic! Thanks again. -------------------- |
|
|
|
|
Jul 24 2012, 10:08 PM
Post
#210
|
|
|
Member Group: Admin Posts: 976 Joined: 29-September 06 From: Pasadena, CA - USA Member No.: 1200 |
QUOTE (jmknapp @ Jul 24 2012, 10:20 AM) ... Then it went through and automagically created the mosaic! Thanks again. That is almost identical to the mosaic I have! Good job at understanding all of it, making the appropriate changes and fixing the script. Now, if *you* want to share it on UMSF, that one is "royalty" free. If not others can follow Joes's steps and roll their own. 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.
|
|
|
|
|
|
Lo-Fi Version | Time is now: 28th April 2024 - 10:49 AM |
|
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. |
|
