I'm new here so I'd like to say hi first. We're Parasol Island an animation and vfx studio in DÃ¼sseldorf Germany which is why and how wo found interest in Nasa's Blue Marble data and photographs. Of interest for us is the fact that the data is in high res, freely available and that everything aligns nicely.
To process the binaries from Nasa we initially found an old version of Fridgers tools which didn't work at all so I contacted him which was when he informed me about the existence of this forum, about the download link for the latest versions of his software and about his nmtools tutorial.

After being able to actually run all the tools on both of our platforms (we use fast Macs and PCs) and understanding the piped workflow (we're using node based compositing software which follows the same principle ) we're now stuck with always the same problem. No matter (seemingly) which command from which tool we run the result is always a 0kb sized, correctly positioned and named output file and a "commandname: command not found" in the terminal or command prompt acompanying it.

I searched this forum for this error but failed to imediatly find a comparable thread. One thread was similar but was due to older compiles which thanks to a recompile by Fridger is now fixed.

Any ideas would be greatly appreciated.

Wilfried

(Edit: Maybe to complete this post, our "larger goal" is to extract the data in the different bins as high-res, high-bit depth sRGB images.)

Please study also the examples given there! Notably, the fact that for 16 bit input you must take the correct endedness settings into account. The 16 bit BMNG data are stored in 'big endian' format. Hence on 'little endian' PCs and Intel MACs you got to add the option byteswap=1 as also explained in the tutorial.

Hi,
I solved the issues which were all related to rights management.
Running as an admin everything worked flawlessly.
In the end it was actually very simple, I used nms.exe on a little endian pc workstation in combination with the command
"nms 6378.140 86400 2.5 1 < srtm_ramp2.world.86400x43200.bin > nm86k_wK_byteswap.ppm".

Thanks so much for your support and for the app Fridger!

Wilfried

Edit: Actually I'd still like to achive a depth (greyscale) map in combination to the normals map the command I posted above created.... researching this now.

Hi,I solved the issues which were all related to rights management.Running as an admin everything worked flawlessly. In the end it was actually very simple, I used nms.exe on a little endian pc workstation in combination with the command "nms 6378.140 86400 2.5 1 < srtm_ramp2.world.86400x43200.bin > nm86k_wK_byteswap.ppm".

Thanks so much for your support and for the app Fridger!

Wilfried

Edit: Actually I'd still like to achive a depth (greyscale) map in combination to the normals map the command I posted above created.... researching this now.

Actually I'd still like to achive a depth (greyscale) map in combination to the normals map

the 16 bit signed raw image you started with IS a Height map
the pixel values ARE in meters( well 0.5 M) above/ below sea level

there are many tools that can convert the SINGED 16 bit raw image into a unsigned 16 bit tiff or a 32 bit float tiff

for images UNDER 4 gig as a 32 bit float
-- that is a file size max for a program i like , it is still a work in progress
G'Mic
http://gmic.sourceforge.net/only the terminal version works with 16 and 32 bit images

it is a 32 bit float command line image tool
like ImageMagic but using 32 bit float to work with images

Thanks for the answers ;D
Its a pitty that non of Fridgers tools can "free" the hight map data into a greyscale image out of that Nasa Bin.
Does any of you happen to know any links to a specific guide or tutorial to do just that using GMic? (Its time consuming to learn yet another command line tool)
At the studio we're looking into ways to create a DEM out of the NMS created normalmap but Im not sure this will be successful because normals tell only about angle to camera, not distance and our lead compositing td told me yesterday to have more than just 8 bit per channel would be very advantageous to have. I told him that on something that is as unspecific as an organic landscape we might be able to get away with this data but when I open the normals png in Photoshop and look at the 8bit the ranges are also very compressed, so even the 8 bit per channel seem to be poorly used (that is with the normals calculated at Fridgers suggested 2.5 value, not the 20 he used in his tutorial)

Its a pitty that non of Fridgers tools can "free" the hight map data into a greyscale image out of that Nasa Bin.

what ?
that *.bin file IS a raw 16 bit singed integer HEIGHT map DEM , it is only in a RAW format .

Photoshop should be able to use it ????
but PS can also import a raw image

but
for LARGE images - i work with some very big ones
-- my Venus map is 12 GIG --

I use Nip2 ( dose NOT yet support RAW images)
http://www.vips.ecs.soton.ac.uk/index.php?title=VIPSit is a gui to the VIPS image lib
( this program IS explicitly designed to work with images that can be larger than 24 or 50 or 100 GIG in size
and on multi-layer images

here is an example that "srtm_ramp2.world.86400x43200.bin "
resized down to 4096x2048
from left to right to below
the 16 bit DEM
The NormalMap ( made using NMS )
then the 8 bit bmp Normal to height ( made with njob)
so USE the Original DEM

I think it would be great if Wilfried told us in more detail what exactly he and his colloeagues are planning to do? Sounds kind of confusing so far...

Fridger

Good morning guys,

we're an animation studio as I told you in my little intro so we'd like to use DEMs to displace flat geometry to result in a detailed Earth surface in 3D that we can use for Animations. Instead of modelling the whole planet which would take 13 years or so

Im also very aware that getting a DEM from a Normals map is sluggish at best and working backwards but my starting point of this whole topic (I never worked with a bin before) was fridgers tools and they are for normals so thats how I got them

Photoshop cant accuratly use the RAW format though. Nasa even admits that on the blue marble site for the bin: "Although it is possible to import the file into Photshop CS and later, Photoshop will not read the signed data correctly: elevation values above sea level start at 0, while negative elevations "wrap" to values near white (65535), which is sea-level."

This was the first thing I tried but the result is indeed very messy.

John Van Vliet wrote:

Quote:

Its a pitty that non of Fridgers tools can "free" the hight map data into a greyscale image out of that Nasa Bin.

what ?that *.bin file IS a raw 16 bit singed integer HEIGHT map DEM , it is only in a RAW format .

Photoshop should be able to use it ????but PS can also import a raw image

but for LARGE images - i work with some very big ones -- my Venus map is 12 GIG --

I use Nip2 ( dose NOT yet support RAW images)http://www.vips.ecs.soton.ac.uk/index.php?title=VIPSit is a gui to the VIPS image lib ( this program IS explicitly designed to work with images that can be larger than 24 or 50 or 100 GIG in size and on multi-layer images

as I emphasized already in our early PM conversations, grayscale DEMs represent the INPUT data for my tools. It seems to me that your task is rather a mere format conversion of the published 16bit DEM data file (BMNG) into a grayscale TIFF or PNG, for example. My NM tools could be helpful to handle e.g. size reductions at the full 16bit DEM level.

The purpose of my NM tools is really to generate highest quality normalmaps from DEMs, which is not what you are after. I fully agree with John that you should NOT try to proceed via an intermediate normalmap. The latter involves numerical gradients and hence is a sort of "sensitive" object numerically.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum