Earth without oceans

[Malenfant]

Isn't it that the continents are mainly granitic and the oceans mainly basaltic? If so, wouldn't the oceans have darker rock (on average) than the land?

Generally, yes. And even if you stripped away all life from the land, you'd still get some variation because of deserts, different rock types exposed on the surface etc. The seafloor would be covered with sediment anyway (except near the mid ocean ridges which would probably appear darker), which might lighten the exposed seafloor a bit.

I'm unsure if a 'bare earth' would be brownish or greyish in colour. Maybe a lot of it would be the colour of say, the north american desert regions?

[t00fri]

As to the data itself, it is 16bit integers (what bi2 refers to) at 1min
lat/long intervals. Registration is -180/180/-90/90

Then the simplest way to decide is making a corresponding normalmap. Only takes 1.5 minutes.

I really don't feel very competent here, since normally I am not interested in bathymetry. It has just turned out to be a nice additional application for our new normal map tools.

Is the 2 byte ordering in big or little endian? I can work with both, but need to know.

Bye Fridger

[t00fri]

Oh no... that site is too slow for my patience. I only get 200KB/sec instead of (750Kb/sec). Not enough time for that. Also couldn't find any clearcut specs of the raw format

--signed ints?
--byteorder?
--width
--any headers?

Bye Fridger

[scaddenp]

Hi. It is signed 2 byte ints, bigendian, no headers.

[t00fri]

Hi. It is signed 2 byte ints, bigendian, no headers.

Thanks, but the most crucial lacking parameter is the width. The rest fit's my normalmap tools perfectly.

Bye Fridger

[scaddenp]

From the registration, its 21600x10801. Is that what you meant? That
matchs the file size.

[Adirondack]

I've added a 2nd version of "Earth without water" to the CML.
This version shows the Earth without oceans and with dried out continents:



You get this version here.


Adirondack

[m1omg]

What about creating a future Venuslike bone dry Pangea Earth map?
That would be more realistic, because the continents will eventually merge and because the Sun is brightening the Earth will dry out and it will have a dense runaway greenhouse atmosphere.

[Xarthat Xio]

Yes, I'm together with m1omg, Earth about 5 billions years in future will look surely at another way. It would be a kind of Pangea, but joined in the Pacific line, instead of Atlantic (like original was).

[Richard10]

What is your data source for the sea floor? (I can see it is not ficticious). The
best global bathymetry I know of is
ftp://falcon.grdl.noaa.gov/pub/walter/G ... _blend.bi2

Its a 1minute blend of the Gebco bathymetry (properly registered) with the
smith and sandwell predicted bathymetry grid derived from gravity inversion.

Certainly, the latest Gebco data represent the best available bathymetry. Back in 2003, I also used the available Gebco data, of course.

Just getting a bit curious from this discussion, and given my new powerful normal map tools, I quickly did the following interesting exercise:

I use DIRECTLY the binary bathymetry data in (signed) 16bit integer format that Reto Stoeckly/NASA/BMNG recommends. This way there will be NO noise whatsoever in my resulting normal map!

http://snowy.arsc.alaska.edu/nasa/topog ... 801.bin.gz

The descriptive paper is here. Most of us know it by heart, I suppose...
http://snowy.arsc.alaska.edu/nasa/bmng.pdf

The biggest available size of 21600x10800 is a bit small for my taste but this way the making of a noise-free, highest-quality normal-map of the sea-floor only takes 1.5 minutes with my nmtools

Starting from the gzipped input bathymetry data file
gebco_bathy.21601x10801.bin.gz, the entire process of unpacking, reducing to the nearest power-of-2 size (16k), the required big-endian -> little endian flip and finally the normal-map generation is just one piped command on any platform (Win32, Mac-Osx/Intel, Linux):

Code: Select all

gzip -cd < gebco_bathy.21601x10801.bin.gz | resc2pow2 21602 1 | nms 6378.140 16384 2.7 > gebco_bathy_nm16k.ppm 


The ppm format of the resulting normal map can then quickly be converted to jpg or png e.g. with GIMP.

I'm sorry to trouble you but I am having difficulty getting it to work the way you described.

Using: gebco_bathy.21601x10801.bin.gz

I'm getting: gebco_bathy_nm16k.ppm with a file sze of 393,217 Kb (384 MB (402,653,202 bytes) / 384 MB (402,657,280 bytes) on disk).

This is using your formula:

gzip -cd < gebco_bathy.21601x10801.bin.gz | resc2pow2 21601 1 | nms 6378.140 16384 2.7 > gebco_bathy_nm16k.ppm

The thing either lists number blocks in single blocks or in double blocks until it reaches "[7168]" and then it stops and reports: "gzip: stdout: Broken Pipe".

The PPM file appears as a block of noise in Photoshop CS2 and using
XnView browser the image will not load.

Do you know where I am going wrong?

[t00fri]

I wrote this to you by email:

-----------------------------------------------------
Hi,

I downloaded that bathymetry file from the snowy server and tried your 16k normalmap generation pipeline of commands. The result was perfect as always. So far I have not heard of any problems with my tools that were due to the tools.

You did not tell me your operating system which is a must of course. You spoke of Photoshop so I assume you are on Windows, although this is not compelling. E.g., I always work with a Win XP and a Linux machine in parallel .

Another remark is that this file really does not satisfy the basic assumption of a 2:1 aspect ratio. This may become possibly problematic on some OS. The broken pipe statement at the end looks like if there are a few pixels missing or too much in the pipe... It's easy to correct the size to exactly 2:1 using e.g. Photoshop, of course.

Anyway under Linux everything went AND looked fine in my test run. But truncations may work slightly differently in Windows. I did not have exactly the published version of my nmtools on my machine anymore, since I coded already a much faster update. But this really should not have influenced things along your lines.

Did you try also to unzip the bathymetry file first, independently of the rest? Like just this command: gzip -d <file>
And then to work with the unzipped file as input to resc2pow2? Perhaps your gzip is broken...?

To further debug your problem, you may test each step in the pipeline separately.

Like so:

resc2pow2 21601 1 < gebco_bathy.21601x10801.bin >out16k.bin

Then you can e.g. load that .bin file in Photoshop and look whether you got the correct number of pixels assuming 16384 x 8192. If even one pixel is missing or in excess in the height or in the width, you'll have a problem and the pipe breaks.
Computers are VERY accurate "animals"

Good luck
----------------------------------------------------

But then I noticed that you did not follow my instructions above, really:

Instead of my

Code: Select all

resc2pow2 21602 1


you used instead one pixel less,

Code: Select all

resc2pow2 21601 1


despite the incorrect 2:1 aspect ratio! In any case your problem is almost certainly due to this issue.

Bye Fridger

[Richard10]

I wrote this to you by email:

-----------------------------------------------------
Hi,

I downloaded that bathymetry file from the snowy server and tried your 16k normalmap generation pipeline of commands. The result was perfect as always. So far I have not heard of any problems with my tools that were due to the tools.

You did not tell me your operating system which is a must of course. You spoke of Photoshop so I assume you are on Windows, although this is not compelling. E.g., I always work with a Win XP and a Linux machine in parallel .

Another remark is that this file really does not satisfy the basic assumption of a 2:1 aspect ratio. This may become possibly problematic on some OS. The broken pipe statement at the end looks like if there are a few pixels missing or too much in the pipe... It's easy to correct the size to exactly 2:1 using e.g. Photoshop, of course.

Anyway under Linux everything went AND looked fine in my test run. But truncations may work slightly differently in Windows. I did not have exactly the published version of my nmtools on my machine anymore, since I coded already a much faster update. But this really should not have influenced things along your lines.

Did you try also to unzip the bathymetry file first, independently of the rest? Like just this command: gzip -d <file>
And then to work with the unzipped file as input to resc2pow2? Perhaps your gzip is broken...?

To further debug your problem, you may test each step in the pipeline separately.

Like so:

resc2pow2 21601 1 < gebco_bathy.21601x10801.bin >out16k.bin

Then you can e.g. load that .bin file in Photoshop and look whether you got the correct number of pixels assuming 16384 x 8192. If even one pixel is missing or in excess in the height or in the width, you'll have a problem and the pipe breaks.
Computers are VERY accurate "animals"

Good luck
----------------------------------------------------

But then I noticed that you did not follow my instructions above, really:

Instead of my

Code: Select all

resc2pow2 21602 1


you used instead one pixel less,

Code: Select all

resc2pow2 21601 1


despite the incorrect 2:1 aspect ratio! In any case your problem is almost certainly due to this issue.

Bye Fridger

Hello.
Thanks for a quick response.

I managed to get the my hands on the data by writing some new bytes over the header with Xnview!!!

Still, you did go to the trouble of finding the problem so I am going to try again with your formula. Surely your method produces a better file. I really didn't notice the 2 there yesterday.
For the record, I am using Windows XP SP2 and I'm using the data to pproduce 3D terrains using Photoshop CS2 and some 3D packages.

I'm not an expert with any of this but I can quickly grasp a concept if the person explaining knows his stuff.
Anyway, thanks again.

Just one more question though.

Is there a correct procedure for combining Topographic elevations with Tidal/Bathymetric data? I tried a couple of times in photoshop but the results don't seem accurate.

[t00fri]

Good to hear ...

In case you forsee more detailed and/or more regular questions about applications of the nmtools or about my forthcoming set of tools for general textures (F-TexTools? ), let me cordially invite you (and everybody else) to our newly opened

+++++++++++++++++++++++++++++++
Celestial Matters Forums within our CM Website.
+++++++++++++++++++++++++++++++

There is a special Forum dedicated to my texture tools including the nmtools, of course. I will be happy fo discuss all sorts of further related issues with interested users...

Bye Fridger