NASA\USGS "Original TIF" versions of heightmaps

Started by WAS, February 24, 2021, 03:32:05 PM

Previous topic - Next topic

Kadri

#15
Just wanted to be sure and exported a high quality EXR file and got closer to see if there is any stepping or so.
The landmark is 2 m high. The size of the EXR file is 1 Gb.

Kadri

#16

The exported EXR file from the Heighfield generate node works so it's not a problem,
but i am curious if it is a 16, 24 or 32 bit file, as i saw different properties depending on which program i tested.
There was no option when exporting as EXR (for 16 or 32 bit). I searched the forum and wiki etc. but could not find this information.
I suspect 32 because it looks so clean. But seeing 24 looked strange:

Affinity  : RGBA/32 (HDR)-srgb iec61966-2.1 (linear)
Krita     : Unsupported colour space. Could not open.
Gimp    : Grayscale 32-bit linear floating point.
XnView Classic  : 24 bit RGB

WAS

That is a little strange. Perhaps it's the maximum capabilities of the viewers? Maybe reducing them down.

Kadri


Yeah strange.
I tried with Hitfilm 3 pro it crashed :)
Vegas pro 14 could load it but in the properties i could only see this "22400x22488x128, EXR"...hmm...

Anyway no big deal.

KlausK

Blackmagic Design Fusion also says it is a 32bit float exr.
Perhaps the exr settings on the Renderer tab are used by the exporter.
(Render - Sequence/Output - EXR Options...)
CHeers, Klaus
/ ASUS WS Mainboard / Dual XEON E5-2640v3 / 64GB RAM / NVIDIA GeForce GTX 1070 TI / Win7 Ultimate . . . still (||-:-||)

Kadri

Probably.
And thanks for reminding me about Fusion Klaus. I was confused after the free version 9.
Looks like it is now together with Davinci resolve 17 one install and still free.

Kadri

#21
Klaus i tested with those render settings but the file looked the same.
I think the heighfield generate node saves always in 32 bit.

I just made a last test and made a standard render and saved it as a 16 bit EXR.
Affinity showed it still as a 32 bit file.
Xnview still shows it as a 24 bit file.
But Gimp showed it as 16 bit the right way.
Hard to trust such editors as this is what we are rely on them.
As these 16, 24, 32 bit things are already confusing enough especially for newcomers.

WAS

I think this has to do with the PixelFormat EXIF tag being saved and related viewers capabilities. If it can't read one format, It most likely must fall back to another format else fail to open it. For example, these are all the possible PixelFormat methods:

0x5 = Black & White
0x8 = 8-bit Gray
0x9 = 16-bit BGR555
0xa = 16-bit BGR565
0xb = 16-bit Gray
0xc = 24-bit BGR
0xd = 24-bit RGB
0xe = 32-bit BGR
0xf = 32-bit BGRA
0x10 = 32-bit PBGRA
0x11 = 32-bit Gray Float
0x12 = 48-bit RGB Fixed Point
0x13 = 32-bit BGR101010
0x15 = 48-bit RGB
0x16 = 64-bit RGBA
0x17 = 64-bit PRGBA
0x18 = 96-bit RGB Fixed Point
0x19 = 128-bit RGBA Float
0x1a = 128-bit PRGBA Float
0x1b = 128-bit RGB Float
0x1c = 32-bit CMYK
0x1d = 64-bit RGBA Fixed Point
0x1e = 128-bit RGBA Fixed Point
0x1f = 64-bit CMYK
0x20 = 24-bit 3 Channels
0x21 = 32-bit 4 Channels
0x22 = 40-bit 5 Channels
0x23 = 48-bit 6 Channels
0x24 = 56-bit 7 Channels
0x25 = 64-bit 8 Channels
0x26 = 48-bit 3 Channels
0x27 = 64-bit 4 Channels
0x28 = 80-bit 5 Channels
0x29 = 96-bit 6 Channels
0x2a = 112-bit 7 Channels
0x2b = 128-bit 8 Channels
0x2c = 40-bit CMYK Alpha
0x2d = 80-bit CMYK Alpha
0x2e = 32-bit 3 Channels Alpha
0x2f = 40-bit 4 Channels Alpha
0x30 = 48-bit 5 Channels Alpha
0x31 = 56-bit 6 Channels Alpha
0x32 = 64-bit 7 Channels Alpha
0x33 = 72-bit 8 Channels Alpha
0x34 = 64-bit 3 Channels Alpha
0x35 = 80-bit 4 Channels Alpha
0x36 = 96-bit 5 Channels Alpha
0x37 = 112-bit 6 Channels Alpha
0x38 = 128-bit 7 Channels Alpha
0x39 = 144-bit 8 Channels Alpha
0x3a = 64-bit RGBA Half
0x3b = 48-bit RGB Half
0x3d = 32-bit RGBE
0x3e = 16-bit Gray Half
0x3f = 32-bit Gray Fixed Point
I haven't checked what PixelFormat Terragen uses, but I imagine it's something pretty high fidelity to it's source. And I do know there are all sorts of TIFF readers with all sorts of functionality, some more then others, and I think very few have "all capabilities" because it should only follow under scope of common use. Doing a search for C based readers, and I found tons, ranging in all sorts of character lengths showing a huge variance of code complexity/libraries used.

Kadri

Yes i can kinda relate. There are tons of different files and extensions and what not probably. Still...
That is their stuff so to speak.

D.A. Bentley (SuddenPlanet)

I pulled that tif into Global Mapper and was able to export it into something more readable in Photoshop.  It turned out to be 16-bit though.

As you can see the elevation range is all negative and very deep, but only about 1026m of total range.  That's probably why it was black in Photoshop and hard to find the sliver of data by scrubbing through exposure.

If anyone wants it let me know by Private Message.



Derek

WAS

I wonder if that's the exporter exporting 16-bit, or the tif being 16-bit? I actually haven't heard of any 32bit tifs from DEM/HiRISE but maybe I just haven't found them. Even looking online right now I can't find any but find tutorials on how to upscale/smooth and composite multiple TIFs to make a 32bit tif of  8/16-bit stuff.

I'd definitely be interested in it. I knew there was negative displacement that I wasn't seeing so I actually made a inverted disp map clamped to the flows and lake to push it down a bit in my scene.

I'll take a copy if you don't mind, may save me some time. I'm not sure how big it is maybe my gmail will take it?

KlausK

I found a link on NASA`s website that points to the original colour images used for the map.

"This map is composed of two layers: a grayscale Jezero Crater map, and a true-color base map. The greyscale base map was created with images from the HiRISE camera on NASA's Mars Reconnaissance Orbiter, while the color base map is from the European Space Agency Mars Express High Resolution Stereo camera. Some color processing has been applied to highlight surface features. The original image can be found here. A high-resolution Digital Elevation Model was created from the images to provide critical information for rover drivers, who need to know how steep the hills are as they plan a path forward through this rocky terrain."

https://maps.planet.fu-berlin.de/#map=3/0/0

You can zoom in quite high. Nice.

CHeers, Klaus
/ ASUS WS Mainboard / Dual XEON E5-2640v3 / 64GB RAM / NVIDIA GeForce GTX 1070 TI / Win7 Ultimate . . . still (||-:-||)

KlausK

#27
Something else...

I downloaded to larger images:
"JEZ_hirise_soc_006_orthoMosaic_25cm_Eqc_latTs0_lon0_first.tif" which is about 7GB and
"JEZ_hirise_soc_007_orthoMosaic_25cm_Ortho_blend120.tif" which is about 3.5GB.

When I try to load those into any of the image loader nodes in TG I get an error:
Cannot locate file: blablabla

Any idea why that is, anyone?

CHeers, Klaus

PS: after a some more testing I think the files are corrupt. So, never mind.
/ ASUS WS Mainboard / Dual XEON E5-2640v3 / 64GB RAM / NVIDIA GeForce GTX 1070 TI / Win7 Ultimate . . . still (||-:-||)

Kadri

Klaus i only tried the "JEZ_hirise_soc_006_orthoMosaic_25cm_Eqc_latTs0_lon0_first.tif"
file which is about 7 GB in Terragen too and got the same result as you.

But the file looks ok when you open it in QGIS. Terragen doesn't like the file or maybe does have a file size limit etc. i don't know.

QGIS looks like a very capable package and is free to use open source. There are many options to export the file.
But as i don't work with heigfields much, the options are a bit overwhelming:

https://qgis.org/en/site/

Kadri

#29
This example is from the nearly 10 gb tif file ( JEZ_hirise_soc_006_orthoMosaic_25cm_Eqc_latTs0_lon0_first_dd.tif ).
There is actually quite a detail in there as it looks. I tried to export just that area.

My imported cropped area render is bad. Someone who knows what he is doing can do much better then this.