Hillshade en falso color de Marte

[Guillermo Luijk]

Con datos de la NASA he dibujado un hillshade (sombreado en pseudo 3D) del relieve de Marte, coloreando las altitudes en falso color con curvas en Photoshop. Como Marte no tiene océanos las altitudes se suelen referir a su altitud media. El punto más alto es Olympus Mons, un volcán con la extensión de Francia y 21,9km de altitud (casi 3 veces lo que el Everest sobre el nivel del mar), y el más bajo es la gigante depresión Hellas Planitia (-7,2km) situada en el hemisferio sur pese a que la mitad norte del planeta tenga las altitudes más bajas.

Fuente datos DEM:
https://astrogeology.usgs.gov/search...ic_global_463m

La imagen la he construido a 32Mpx, pero es que el mapa de elevaciones de la NASA tiene una resolución brutal de 1Gpx!

http://guillermoluijk.com/datosimagensonido/mars.jpg

Arriba a la izquierda del mapa, el Olympus Mons es un volcán marciano extinguido de la extensión de Francia y una altitud respecto al área circundante de casi tres Everest (21,9km), siendo la mayor montaña conocida del Sistema Solar.

Con un mapa digital de altitudes de Marte de la NASA se ha generado por un lado el color de la imagen en función de la altitud, y por otro la luminosidad de un relieve hillshade calculando las pendientes del terreno respecto a una luz incidente. Finalmente se añade un gradiente para simular el amanecer.
Todo el código en R base sin usar ningún paquete. Coloreado con curvas en Photoshop.



Salu2!

[u420067]

Como siempre, Guillermo, gracias por compartir tus creaciones.
Un saludo

[NerveNet]

Excelente Guillermo.

Vale, ya tenemos un mapa. ¿Y dónde están las playas?

[pepelahuerta]

Gracias Guillermo, el tamaño del Olympus Mons es una pasada, difícil de imaginar. Saludos

[mikelius]

Tremenda la foto y los datos !!!.
Gracias por compartir.

[Dr. Mabuse]

Muy interesante. La altura máxima de montañas y volcanes viene determinada por la gravedad del planeta y la de Marte es menos de la mitad de la Tierra. En nuestro planeta no podría existir el Olympus mons.

[Guillermo Luijk]

Por cierto a modo de curiosidad, los datos de la NASA (he puesto el enlace) indicando la altitud en cada punto de Marte, están en un archivo TIF monocromo que puede abrirse en Photoshop, pero en una codificación poco habitual: enteros de 16 bits con signo, donde cada unidad es 1m (es decir si un pixel vale 12.000 está 12km por encima de la altitud media del planeta, uno que valga -5.000 está 5km por debajo). A lo que voy: Photoshop no admite valores negativos así que abre el archivo pero lo interpreta mal, partiendo el histograma de modo que las partes de menor altitud quedan en las altas luces y las más altas (como el volcán) en las sombras, con una franja vacía enorme entre ellas. Numéricamente se corrige muy fácil, pero en Photoshop la cosa está más jodida.

Si no tenéis un ordenador un poco potente se os puede quedar bastante frito del PC al abrir el TIF.

Salu2!

[NerveNet]

Por cierto a modo de curiosidad, los datos de la NASA (he puesto el enlace) indicando la altitud en cada punto de Marte, están en un archivo TIF monocromo que puede abrirse en Photoshop, pero en una codificación poco habitual: enteros de 16 bits con signo, donde cada unidad es 1m (es decir si un pixel vale 12.000 está 12km por encima de la altitud media del planeta, uno que valga -5.000 está 5km por debajo). A lo que voy: Photoshop no admite valores negativos así que abre el archivo pero lo interpreta mal, partiendo el histograma de modo que las partes de menor altitud quedan en las altas luces y las más altas (como el volcán) en las sombras, con una franja vacía enorme entre ellas. Numéricamente se corrige muy fácil, pero en Photoshop la cosa está más jodida.

Si no tenéis un ordenador un poco potente se os puede quedar bastante frito del PC al abrir el TIF.

Salu2!

¿Entonces has tenido que generar un TIF trasladando los valores de cada pixel de enteros con signo a enteros sin signo?

[Guillermo Luijk]

¿Entonces has tenido que generar un TIF trasladando los valores de cada pixel de enteros con signo a enteros sin signo?

Exacto, pero la transformación la he hecho numéricamente, mira qué sencillo resulta en R:

DEM[DEM>=32768] = DEM[DEM>=32768] - 65536

Lo curioso de la librería de R que lee el TIFF es que te avisa de que está en formato entero con signo, pero aún así la lee mal y por eso obliga a la corrección anterior. Que digo yo, tío jodido si sabes en qué formato está, por qué no la interpretas correctamente no? éste es el mensaje que sale al leer el TIF de la NASA:

"tiff package currently only supports unsigned integer or float sample formats in direct mode, but the image contains signed integer format it will be treated as unsigned"

Salu2!

[NerveNet]

Exacto, pero la transformación la he hecho numéricamente, mira qué sencillo resulta en R:

DEM[DEM>=32768] = DEM[DEM>=32768] - 65536

Lo curioso de la librería de R que lee el TIFF es que te avisa de que está en formato entero con signo, pero aún así la lee mal y por eso obliga a la corrección anterior. Que digo yo, tío jodido si sabes en qué formato está, por qué no la interpretas correctamente no? éste es el mensaje que sale al leer el TIF de la NASA:

"tiff package currently only supports unsigned integer or float sample formats in direct mode, but the image contains signed integer format it will be treated as unsigned"

Salu2!

El código me es rarito, ten presente que programo en C, Perl (que también se la trae) y Python.

Lo de la librería lo veo normal, ya sabes, depende del programador y de las librerías que dependan de ello.

[Guillermo Luijk]

El código me es rarito, ten presente que programo en C, Perl (que también se la trae) y Python.

La sintaxis es más práctica que la de Python. C directamente no es rival para este tipo de procesados, en C cualquier programa R sería una colección interminable de bucles. seguro que si te pongo esto deduces lo que hace:

DEM[DEM<0] = 0

Luego hay usos que pueden parecer más ofuscados pero una vez se conocen resultan obvios. No creo que pueda existir un lenguaje que haga lo que hace esta rutina HDR con menos líneas:

https://github.com/gluijk/hdr-r/blob/master/hdr.R

- Lee dos imágenes en TIFF
- Calcula la exposición relativa de una respecto a la otra y dibuja el histograma de exposiciones relativas
- Genera una imagen sintética indicando los canales/píxeles usados en el cálculo anterior
- Fusiona las dos imágenes igualando previamente sus exposiciones y tomando siempre los canales no saturados de mayor nivel (menor ruido), guardando el resultado en TIFF con gamma
- Para terminar genera otra imagen sintética con el mapa de fusión que indica de qué imagen proviene cada canal/píxel

Salu2!

[u420067]

La sintaxis es más práctica que la de Python. C directamente no es rival para este tipo de procesados, en C cualquier programa R sería una colección interminable de bucles. seguro que si te pongo esto deduces lo que hace:

DEM[DEM<0] = 0

Luego hay usos que pueden parecer más ofuscados pero una vez se conocen resultan obvios. No creo que pueda existir un lenguaje que haga lo que hace esta rutina HDR con menos líneas:

https://github.com/gluijk/hdr-r/blob/master/hdr.R

- Lee dos imágenes en TIFF
- Calcula la exposición relativa de una respecto a la otra y dibuja el histograma de exposiciones relativas
- Genera una imagen sintética indicando los canales/píxeles usados en el cálculo anterior
- Fusiona las dos imágenes igualando previamente sus exposiciones y tomando siempre los canales no saturados de mayor nivel (menor ruido), guardando el resultado en TIFF con gamma
- Para terminar genera otra imagen sintética con el mapa de fusión que indica de qué imagen proviene cada canal/píxel

Salu2!

Lástima que estas cosas me pillan mayor, con lo que me ha gustado programar...