It is currently Wed, 28-06-17, 17:14 GMT

All times are UTC




Post new topic Reply to topic  [ 109 posts ]  Go to page 1, 2, 3, 4, 5 ... 8  Next
Author Message
 Post subject: Application Reports
PostPosted: Tue, 04-09-07, 18:43 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4447
Location: Hamburg, Germany
Users of the tools are cordially invited to report here about their applications of the tools to textures of various celestial bodies and possibly also about entirely different applications of the tools.

Please share with us your successes and your problems!

Bye Fridger

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Fri, 07-09-07, 15:16 GMT 
Offline

Joined: Fri, 07-09-07, 0:32 GMT
Posts: 19
I hope this is the right place for this.

Anyway, following our e-mail discussions and your response on the other forum (shatters.net), in an attempt to derive from gebco.21601x10801.bathy.bin.gz, I changed the number: resc2pow2 21601 to 21602 and followed your instructions.

Using nmtools I was able to derive a 16kx8k "little end" RAW image which is encouraging. Now all I have to figure out is how to calibrate the hidden DEM data so that it is brighter than the bathymetric layers.

Unfortunately though, using the nms command, I could not create a viable PPM image file. The one I did generate returns an error message in all applications and shows up as a skewed ultraviolet image in Photoshop.


Last edited by richard10 on Sat, 08-09-07, 10:53 GMT, edited 2 times in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sat, 08-09-07, 10:50 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4447
Location: Hamburg, Germany
Richard,

Welcome in our new CM Forums!

Sorry to make you wait a bit longer, but we had someone visiting over yesterday night. Moreover, I first had to do some checks with the ORIGINAL Windows version of my nmtools...

Your present problem is clearly related to the unsatisfactory memory management in the XnView package, including the nconvert commandline tools. nconvert is VERY useful for converting small VT tiles, but quite unsuitable for handling bigger size textures.

I precisely repeated your commandline under Windows XP SR2, with the same version 1.0.1 of my nmtools. This part worked again perfectly by using a width of 21602 in resc2pow2.

BUT: Trying at this point to convert that generated 16k x 8k PPM normalmap file into PNG by means of 'nconvert'

Code:
nconvert -out png gebco.16384x8192.bathy.ppm


gives the same error on my system as in your case:

Code:
ERRor: Portable Bitmap: Bad picture's size !


Please note, this error is NOT related to my tools at all. It just means that nconvert or XnView are unable to handle such big file sizes.

As a proof of this, just load the resulting gebco normalpap file in The Gimp (which I highly recommend anyway) [Photoshop 7.0 does not seem to load PPM format directly!]. You can check in GIMP immediately that the resulting normalmap gebco.16384x8192.bathy.ppm was perfect (the normalmap looks nice) and it has the correct size of 16384 x 8192 pixels (hit the key '1' to display the image in natural size). You may then easily save that image with GIMP into PNG or JPG format, of course. Then you can also load it in Photoshop.

I checked another popular image view program: IrfanView 4.0.0, which also was able to load the gebco.16384x8192.bathy.ppm normalmap without any problems.

But again, I am missing some VERY important base information about your system: how much RAM have you got?? It may well be that IrfanView can load this 16k x 8k normalmap with my 2GB of notebook memory, while it will fail, in case you got less. So ALWAYS specify your system and OS data as detailed as possible in case of problems. The GIMP is very sophisticated and can certainly load that file also with less memory.

Good luck,
Bye Fridger

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Sat, 08-09-07, 11:56 GMT 
Offline

Joined: Fri, 07-09-07, 0:32 GMT
Posts: 19
t00fri wrote:
Richard,

Welcome in our new CM Forums!

Sorry to make you wait a bit longer, but we had someone visiting over yesterday night. Moreover, I first had to do some checks with the ORIGINAL Windows version of my nmtools...

Your present problem is clearly related to the unsatisfactory memory management in the XnView package, including the nconvert commandline tools. nconvert is VERY useful for converting small VT tiles, but quite unsuitable for handling bigger size textures.

I precisely repeated your commandline under Windows XP SR2, with the same version 1.0.1 of my nmtools. This part worked again perfectly by using a width of 21602 in resc2pow2.

BUT: Trying at this point to convert that generated 16k x 8k PPM normalmap file into PNG by means of 'nconvert'

Code:
nconvert -out png gebco.16384x8192.bathy.ppm


gives the same error on my system as in your case:

Code:
ERRor: Portable Bitmap: Bad picture's size !


Please note, this error is NOT related to my tools at all. It just means that nconvert or XnView are unable to handle such big file sizes.

As a proof of this, just load the resulting gebco normalpap file in The Gimp (which I highly recommend anyway) [Photoshop 7.0 does not seem to load PPM format directly!]. You can check in GIMP immediately that the resulting normalmap gebco.16384x8192.bathy.ppm was perfect (the normalmap looks nice) and it has the correct size of 16384 x 8192 pixels (hit the key '1' to display the image in natural size). You may then easily save that image with GIMP into PNG or JPG format, of course. Then you can also load it in Photoshop.

I checked another popular image view program: IrfanView 4.0.0, which also was able to load the gebco.16384x8192.bathy.ppm normalmap without any problems.

But again, I am missing some VERY important base information about your system: how much RAM have you got?? It may well be that IrfanView can load this 16k x 8k normalmap with my 2GB of notebook memory, while it will fail, in case you got less. So ALWAYS specify your system and OS data as detailed as possible in case of problems. The GIMP is very sophisticated and can certainly load that file also with less memory.

Good luck,
Bye Fridger


Thanks for the welcome.

The problem isn't really about generating a 16k normal map. Nmtools produced a PERFECT bin file readable as a RAW file in Photoshop. It's the same 16384x8192 you're talking about.

The trouble I am having is getting the full 21600X10800 image from gebco_bathy.21601x10801.bin.gz.

For the record I have a total of 1.25 GB of RAM at my disposal.

Let's start again with the objective of deriving a 21600X10800 greyscale image (either as a bin or a viable PPM) from the gebco bin file... if possible.


Top
 Profile  
 
 Post subject:
PostPosted: Sat, 08-09-07, 13:28 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4447
Location: Hamburg, Germany
richard10 wrote:

Thanks for the welcome.

The problem isn't really about generating a 16k normal map. Nmtools produced a PERFECT bin file readable as a RAW file in Photoshop. It's the same 16384x8192 you're talking about.

The trouble I am having is getting the full 21600X10800 image from gebco_bathy.21601x10801.bin.gz.

For the record I have a total of 1.25 GB of RAM at my disposal.

Let's start again with the objective of deriving a 21600X10800 greyscale image (either as a bin or a viable PPM) from the gebco bin file... if possible.


But now I am confused:

  • Originally, you contacted me about making a 16k gebco normalmap with my tools.
  • After this worked, you sent me a screen dump that displayed errors from your attempted conversion of the resulting PPM file into PNG format, using nconvert from the XnView package.
  • After I told you the reason for the problem (memory management!), you then stated above that you are not interested in a 16k normalmap and instead want to just load the full-sized original gebco BIN file...So what do the nmtools then have to do with your project??


Before I spend further unnecessary time with checking things for you that you are not really interested in, please try and describe clearly the aim of your project! ;-)

With so little memory (1.25 GB only), it seems obvious that you are simply unable to load the full-sized 21600X10800 image into your machine. Note that unlike most other image manipulation and viewer programs, my tools are specialized to handle VERY large textures. A back-of-the-envelope estimate should show you easily that the full-sized gebco image requires a factor of 1.74 times the memory of the corresponding 16k image. You can also calculate easily that you simply don't have the required memory available.

Bye Fridger

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Sat, 08-09-07, 16:45 GMT 
Offline

Joined: Fri, 07-09-07, 0:32 GMT
Posts: 19
I just yesterday ordered some additonal memory for this very task. Next week I will have 2.5 GB RAM.

The point is, if I wanted to derive that full image could it be done with your tools?

I downloaded the JPG file offered from the NASA Blue Marble site and changed a few things in order to get it to display. It's a whole 21601x10801 and my machines handle it without any problems. The file is a mere 6MB.

All I wanted to do (originally) was generate the file myself from the bin file.

I can understand your confusion, seeing as I already have the 16k version, but really what I wanted to do was get hold of the highest resolution normal map possible, including the DEM for land features as well as the bathymetric data.

If it can't be done, I accept that and apologize for causing you the mild distress detected in your last response.


Top
 Profile  
 
 Post subject:
PostPosted: Sat, 08-09-07, 17:43 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4447
Location: Hamburg, Germany
richard10 wrote:
I just yesterday ordered some additonal memory for this very task. Next week I will have 2.5 GB RAM.

That's always good if you want to work with images...
Quote:
The point is, if I wanted to derive that full image could it be done with your tools?


But my nmtools as published so far, are exclusively for making normal maps to be used in Celestia!?? Didn't you have a look at my detailed tutorial that describes the meaning of normal maps in multi-texture overlay displays?

You still did not describe clearly what you have in mind after the original full-sized 21601x10801 gebco elevation graymap has been loaded into your computer? Do you know precisely what such elevation maps are and how they have to be used? Note that they DO NOT look like this image I showed in shatters.net:

Image

You did not even tell, whether you are planning to use Celestia for displaying whatever you are out to produce. I can hardly give you good advice without knowing the aim of your efforts.

The original gebco file is a file that contains for each point on Earth the respective elevations as 2 byte signed integers, such that a height difference of 65536 meters can be described altogether on Earth. Normal viewers including Photoshop are preferably made for 8 bit =1 byte displays, however! Therefore, independently of the file's BIN format such 2 Byte elevation maps cannot simply be displayed in a standard viewer program. In Photoshop you might use special S-shaped curve profiles to do so, but this is really for experts and hard to describe in words.

If you had instead told me that you want to display the results in Celestia, the story would be entirely different. Celestia can both read elevation graymaps or preferrably normalmaps. If you wanted to reproduce an image as I displayed it in the shatters.net forum thread, it's easy. But I need to know what you want. Instead, as we are now, I am just BLINDLY guessing...
Quote:

I downloaded the JPG file offered from the NASA Blue Marble site and changed a few things in order to get it to display. It's a whole 21601x10801 and my machines handle it without any problems. The file is a mere 6MB.


But that's obvious, since JPG is a LOSSY format and limited to 1 byte per channel. So it does compress huge files into MUCH smaller ones. The main point of the JPG file from the snowy server you were referring to is that it has been converted to 8bit = 1 byte level and thus can be displayed in standard viewers.

Quote:
All I wanted to do (originally) was generate the file myself from the bin file.


Why and to do WHAT with it?

Quote:
I can understand your confusion, seeing as I already have the 16k version, but really what I wanted to do was get hold of the highest resolution normal map possible, including the DEM for land features as well as the bathymetric data.


Once more, did you read carefully my tutorial about the nmtools and notably section 2) about The Purpose of Noprmalmaps in a Nutshell?? I am not sure whether you really know what this all means and we seem to be "bypassing" each other...

http://www.forum.celestialmatters.org/v ... c.php?t=18

Bye Fridger

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Sat, 08-09-07, 21:04 GMT 
Offline

Joined: Fri, 07-09-07, 0:32 GMT
Posts: 19
t00fri wrote:
richard10 wrote:
I just yesterday ordered some additonal memory for this very task. Next week I will have 2.5 GB RAM.

That's always good if you want to work with images...
Quote:
The point is, if I wanted to derive that full image could it be done with your tools?


But my nmtools as published so far, are exclusively for making normal maps to be used in Celestia!?? Didn't you have a look at my detailed tutorial that describes the meaning of normal maps in multi-texture overlay displays?

You still did not describe clearly what you have in mind after the original full-sized 21601x10801 gebco elevation graymap has been loaded into your computer? Do you know precisely what such elevation maps are and how they have to be used? Note that they DO NOT look like this image I showed in shatters.net:


You did not even tell, whether you are planning to use Celestia for displaying whatever you are out to produce. I can hardly give you good advice without knowing the aim of your efforts.

The original gebco file is a file that contains for each point on Earth the respective elevations as 2 byte signed integers, such that a height difference of 65536 meters can be described altogether on Earth. Normal viewers including Photoshop are preferably made for 8 bit =1 byte displays, however! Therefore, independently of the file's BIN format such 2 Byte elevation maps cannot simply be displayed in a standard viewer program. In Photoshop you might use special S-shaped curve profiles to do so, but this is really for experts and hard to describe in words.

If you had instead told me that you want to display the results in Celestia, the story would be entirely different. Celestia can both read elevation graymaps or preferrably normalmaps. If you wanted to reproduce an image as I displayed it in the shatters.net forum thread, it's easy. But I need to know what you want. Instead, as we are now, I am just BLINDLY guessing...
Quote:

I downloaded the JPG file offered from the NASA Blue Marble site and changed a few things in order to get it to display. It's a whole 21601x10801 and my machines handle it without any problems. The file is a mere 6MB.


But that's obvious, since JPG is a LOSSY format and limited to 1 byte per channel. So it does compress huge files into MUCH smaller ones. The main point of the JPG file from the snowy server you were referring to is that it has been converted to 8bit = 1 byte level and thus can be displayed in standard viewers.

Quote:
All I wanted to do (originally) was generate the file myself from the bin file.


Why and to do WHAT with it?

Quote:
I can understand your confusion, seeing as I already have the 16k version, but really what I wanted to do was get hold of the highest resolution normal map possible, including the DEM for land features as well as the bathymetric data.


Once more, did you read carefully my tutorial about the nmtools and notably section 2) about The Purpose of Noprmalmaps in a Nutshell?? I am not sure whether you really know what this all means and we seem to be "bypassing" each other...

http://www.forum.celestialmatters.org/v ... c.php?t=18

Bye Fridger


I think I have at least a rudimentary comprehension of what a normal map is and what an elevation map is. I use normal maps, bump maps and displacement maps to create textures (static and variable) for 3D animations using high end 3D software and have done so for some time.

I am well aware though that I don't know all there is to know about particular things (DEMs etc.,), but to clarify:

I need the highest resolution normal map to render an extremely detailed image of the earth without oceans using as rudimentary a polygon object as possible. Normal maps hold more channels and can replicate the surface of a high density polygon model using a low resolution mesh. I could use a simple greyscale JPG bump map, but the quality of the displacement geometry in VRAY will look razzy at the edges. Instead I need data VRAY can work with to produce as sharp a displacement as possible. .PNG, .DDS, .VRIMG, even older formats are good for utilizing modern adaptive tessellation techniques to produce from texture maps the requiste micropolygons for a good sharp detailed image.

Gebco is (as far as I know) the best source at my disposal. I thought it would be a simple task deriving from it the data required. I also never thought I'd need to answer so many questions.


Top
 Profile  
 
 Post subject:
PostPosted: Sat, 08-09-07, 22:21 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4447
Location: Hamburg, Germany
richard10 wrote:
I thought it would be a simple task deriving from it the data required. I also never thought I'd need to answer so many questions.


Of course it is a simple task to derive a normal map from the 21602x10801 full-size gebco elevation map provided
  • one has enough memory, which you DON'T have.
  • one expresses clearly what one wants to do, which you were not. Cf further below.
With my 2 GB of memory, I just generated a 21602x10801 full-size normalmap from the gebco elevation map input within less than 1 minute, using only my nms tool with obvious parameters. I assume I don't have to write the respective command line down anymore.

I loaded the resulting gebco_bathy.21602x10801.nm.ppm into GIMP, and saved it as a PNG file from there. The resulting normalmap looks very nice as always. If this is what you want, it's trivial, but you first need more memory to do it.

That's what I said right from the beginning, since anyone working with BIG textures should first estimate the required storage.

However...

In two consecutive mails you seemed to contradict yourself, which made me asking you many questions in return...:

richard10 wrote:
Let's start again with the objective of deriving a 21600X10800 greyscale image (either as a bin or a viable PPM) from the gebco bin file... if possible.

richard10 wrote:
I need the highest resolution normal map to render an extremely detailed image of the earth without oceans


Since normalmaps are RGB and NOT grayscale images, I had no idea what you really wanted.

I hope you can understand that your requests are really confusing.

Bye Fridger

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Sun, 09-09-07, 1:22 GMT 
Offline

Joined: Fri, 07-09-07, 0:32 GMT
Posts: 19
t00fri wrote:
richard10 wrote:
I thought it would be a simple task deriving from it the data required. I also never thought I'd need to answer so many questions.


Of course it is a simple task to derive a normal map from the 21602x10801 full-size gebco elevation map provided
  • one has enough memory, which you DON'T have.
  • one expresses clearly what one wants to do, which you were not. Cf further below.
With my 2 GB of memory, I just generated a 21602x10801 full-size normalmap from the gebco elevation map input within less than 1 minute, using only my nms tool with obvious parameters. I assume I don't have to write the respective command line down anymore.

I loaded the resulting gebco_bathy.21602x10801.nm.ppm into GIMP, and saved it as a PNG file from there. The resulting normalmap looks very nice as always. If this is what you want, it's trivial, but you first need more memory to do it.

That's what I said right from the beginning, since anyone working with BIG textures should first estimate the required storage.

However...

In two consecutive mails you seemed to contradict yourself, which made me asking you many questions in return...:

richard10 wrote:
Let's start again with the objective of deriving a 21600X10800 greyscale image (either as a bin or a viable PPM) from the gebco bin file... if possible.

richard10 wrote:
I need the highest resolution normal map to render an extremely detailed image of the earth without oceans


Since normalmaps are RGB and NOT grayscale images, I had no idea what you really wanted.

I hope you can understand that your requests are really confusing.

Bye Fridger


You don't seem as helpful as I thought you were to begin with and I'm sorry but that has nothing to do with my requests.

Searching for "trivial" inconsistencies in my comments is not what I expected from you.

If you don't want to help you've certainly made yourself clear.

I notice you refuse to post the working command line "anymore". Does this mean you posted it before, because if you did I must have missed it?

Your tools obviously do not work with this particular dataset. This can be the ONLY reason you expect me to take your word alone that they work or that it's an issue of memory.

If I am wrong, if you do have a working method, basic, trivial or obvious -- simply post it. I will test it next week with my 2.5GB.

Edit:
BTW the "really confusing" remarks you quoted were separated by my comment: "to clarify..."


Top
 Profile  
 
 Post subject:
PostPosted: Sun, 09-09-07, 1:39 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4447
Location: Hamburg, Germany
richard10 wrote:

You don't seem as helpful as I thought you were to begin with and I'm sorry but that has nothing to do with my requests.

Searching for "trivial" inconsistencies in my comments is not what I expected from you.

If you don't want to help you've certainly made yourself clear.

I notice you refuse to post the working command line "anymore". Does this mean you posted it before, because if you did I must have missed it?

Your tools obviously do not work with this particular dataset. This can be the ONLY reason you expect me to take your word alone that they work or that it's an issue of memory.


This must be a joke.

I really had assumed you have meanwhile executed nms numerous times without parameters and learned from the resulting help output, how to insert the appropriate numbers into its command line. But apparently, you did not even care to glance at my tutorial...

Actually, the required commandline is virtually the same as you used before, except the tool resc2pow2 is of course missing this time in the pipeline. In exchange, the endedness correction (1) must now appear as last parameter on the /nms/ commandline.

OK here you go:

Code:
gzip -dc < gebco_bathy.21601x10801.bin.gz | nms 6378.140  21602  2.7  1 > gebco_bathy.21602x10801.nm.ppm


This exceedingly simple expression gives a beautiful 21602x10801 full-sized normal map in less than 1 minute on my machine. It might well also work with your present low memory, since my tools are optimized to use little memory. But certainly you will get a memory error when converting the result to PNG format with some other tools. If you are VERY lucky, perhaps The Gimp might work, since it cleverly swaps excessive memory requests to the harddisk.

_________________
Image


Last edited by t00fri on Sun, 09-09-07, 2:07 GMT, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sun, 09-09-07, 2:03 GMT 
Offline

Joined: Fri, 07-09-07, 0:32 GMT
Posts: 19
t00fri wrote:
richard10 wrote:

You don't seem as helpful as I thought you were to begin with and I'm sorry but that has nothing to do with my requests.

Searching for "trivial" inconsistencies in my comments is not what I expected from you.

If you don't want to help you've certainly made yourself clear.

I notice you refuse to post the working command line "anymore". Does this mean you posted it before, because if you did I must have missed it?

Your tools obviously do not work with this particular dataset. This can be the ONLY reason you expect me to take your word alone that they work or that it's an issue of memory.


This must be a joke.

I really assumed you have meanwhile executed nms numerous times without parameters and learned from the resulting help output, how to insert the appropriate numbers into its command line. But apparently, you did not even care to glance at the tutorial...

Actually, the required commandline is virtually the same as you had before, except the tool resc2pow2 is of course missing this time in the pipeline. In exchange, the endedness correction (1) must now appear as last parameter on the /nms/ commandline.

OK here you go:

Code:
gzip -dc <gebco_bathy> gebco_bathy.21602x10801.nm.ppm


This exceedingly simple commandline gives a beautiful 21602x10801 full-sized normal map in less than 1 minute on my machine.


I entered that exact formula (the first of the two) earlier today (before you posted it) and the result was a 667mb ppm which doesn't open in anything I have on my systems.

Of course it must be a lack of memory. I'll try again next week.


Last edited by richard10 on Sun, 09-09-07, 2:19 GMT, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sun, 09-09-07, 2:16 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4447
Location: Hamburg, Germany
Please note:

The reason why I did not quote that simple commandline earlier was due to a problem with the forum editor, persistently swallowing parts of the commandline. You can see how it looks by comparing the form that you quoted with the complete one in my post!

Only much later I found out that one has to deactivate HTML in the editor, in order to have the commandline printed correctly. Please, see also the further comments at the end of my previous post that I was just writing when you came in.

I suggest you compare the commandline as it is NOW /carefully/ in my above post! I have no idea whether it was already correct, when you looked at it!

What did you mean when stating that you used the /first/ of my /two/ commandlines earlier yourself?? There was only ONE commandline throughout (extending over 2 lines, of course!).

The correct normal map in PPM format that I generated above had 699969625 bytes.

_________________
Image


Top
 Profile  
 
 Post subject:
PostPosted: Sun, 09-09-07, 2:27 GMT 
Offline

Joined: Fri, 07-09-07, 0:32 GMT
Posts: 19
t00fri wrote:
Please note:

The reason why I did not quote that simple commandline earlier was due to a problem with the forum editor, persistently swallowing parts of the commandline. You can see how it looks by comparing the form that you quoted with the complete one in my post!

Only much later I found out that one has to deactivate HTML in the editor, in order to have the commandline printed correctly. Please, see also the further comments at the end of my previous post that I was just writing when you came in.

I suggest you compare the commandline as it is NOW /carefully/ in my above post! I have no idea whether it looked already correctly, when you looked at it!

What did you mean when stating that you used the /first/ of my /two/ commandlines earlier yourself?? There was only ONE commandline throughout (extending over 2 lines, of course!).


Code:
gzip -dc <gebco_bathy> gebco_bathy.21602x10801.nm.ppm


445MB PPM. It doesn't come up in anything I am using. Nconvert: Error: Don't know how to read this picture.


Last edited by richard10 on Sun, 09-09-07, 2:32 GMT, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Sun, 09-09-07, 2:30 GMT 
Offline

Joined: Fri, 07-09-07, 0:32 GMT
Posts: 19
t00fri wrote:
Please note:

The reason why I did not quote that simple commandline earlier was due to a problem with the forum editor, persistently swallowing parts of the commandline. You can see how it looks by comparing the form that you quoted with the complete one in my post!

Only much later I found out that one has to deactivate HTML in the editor, in order to have the commandline printed correctly. Please, see also the further comments at the end of my previous post that I was just writing when you came in.

I suggest you compare the commandline as it is NOW /carefully/ in my above post! I have no idea whether it was already correct, when you looked at it!

What did you mean when stating that you used the /first/ of my /two/ commandlines earlier yourself?? There was only ONE commandline throughout (extending over 2 lines, of course!).

The correct normal map in PPM format that I generated above had 699969625 bytes.


Why won't this thing allow the full command line?



gzip -dc < gebco_bathy.21601x10801.bin.gz | nms 6378.140 21602 2.7 1 > gebco_bathy.21602x10801.nm.ppm

Hmmm.

I had this result earlier today, but it wouldn't convert or load into anything.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 109 posts ]  Go to page 1, 2, 3, 4, 5 ... 8  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


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

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group