Page 1 of 2

stdin for ppm?

Posted: Sun Feb 25, 2007 6:26 pm
by guest_jo
Hello,
I use an application to create normalmaps on 3D- spherical bodies that outs ppm - format on stdout.

http://www.celestialmatters.org/cm//hos ... 03.shtml#2

Is it possible to convert this directly via stdin into png with nconvert ?
I tried some syntax but I failed with it ...

Maybe you can help me ?

Jörg

Re: stdin for ppm?

Posted: Tue Feb 27, 2007 8:38 am
by xnview
guest_jo wrote:Hello,
I use an application to create normalmaps on 3D- spherical bodies that outs ppm - format on stdout.

http://www.celestialmatters.org/cm//hos ... 03.shtml#2

Is it possible to convert this directly via stdin into png with nconvert ?
I tried some syntax but I failed with it ...

Maybe you can help me ?
Do you have tried stdin as input file?

stdin

Posted: Tue Feb 27, 2007 11:26 am
by guest_jo
Yes I tried:

nms 6718.14 4096 20 < srtm_ramp2.world.4096x2048.bin | nconvert -out png stdin

the first tool gives a .ppm-file on stdout but stdin can`t find it.
The author of the normalmap-tool also failed with this (fridgers column,link above), so I thought I ask if nconvert supports stdin at all. But from your answer I suppose it should, so maybe I should contact the author of nms again if he wants to do further efforts...
Can you confirm if my syntax I posted is correct ?

Jörg

Re: stdin

Posted: Tue Feb 27, 2007 12:55 pm
by xnview
guest_jo wrote:Yes I tried:

nms 6718.14 4096 20 < srtm_ramp2.world.4096x2048.bin | nconvert -out png stdin

the first tool gives a .ppm-file on stdout but stdin can`t find it.
The author of the normalmap-tool also failed with this (fridgers column,link above), so I thought I ask if nconvert supports stdin at all. But from your answer I suppose it should, so maybe I should contact the author of nms again if he wants to do further efforts...
Can you confirm if my syntax I posted is correct ?
Yes, the syntax is true, but could you send me the ppm to test?

sent !

Posted: Tue Feb 27, 2007 10:40 pm
by Guest
Hi Pierre,
I wanted to send you the 4096x2028 ppm-file but it is too big for me to send.
I made a version 2048x1024 and zipped it with 7zip and if thats not ok I also made a ppm with 1024x512

Both sent files I can´t get them into nconvert via stdin.

I also tried another syntax cause I had the feeling I would need a specific output-filename but this also failed for both example-files:

nms 6378.140 4096 20.0 < srtm_ramp2.world4k.bin | nconvert -o srtm_ramp2.world4k.png stdin

Maybe you can find out something...

Many thanks for spending your time.
Jörg

sent !

Posted: Tue Feb 27, 2007 10:44 pm
by guest_jo
Forgot to say that I sent both files to the MSN Messenger adress I found in your profile.
Bye,
Jörg

new test with gzip for stdin

Posted: Wed Feb 28, 2007 11:14 pm
by guest_jo
Hi Pierre, to make this issue independent from the quite unknown nms-tools I did the same test with gzip as generator for stdout:

1.) gzip -dc srtm_ramp2.world4k.bin.gz | nms 6378.140 4096 20.0 > srtm_ramp2.world4k.ppm

2.) gzip -dc srtm_ramp2.world4k.ppm.gz | nconvert -out png stdin

The first line is only to test stdout from gzip. It works good and at the end of the pipe the ppm is generated and ok.

The second line I made a gzipped ppm-file and wanted to hand it over to nconvert. I didn´t succeed ! I tried several things: -in ppm ; -o test.png ; -in stdin ; > test.png ; different combinations of it, I give up.
Maybe the test with gzip is better for looking into it.

Jörg

Posted: Thu Mar 01, 2007 9:33 pm
by Guest
Being a longstanding developer and co-author of the 3D space simulation Celestia

http://www.shatters.net/celestia/

I first of all want to express our strong interest in NConvert. As Joerg mentioned above, I have been writing a set of dedicated, cross-platform tools (in C++ ) specialized in generating HUGE planetary textures (~10 GB each ;-) ) of highest quality directly from the published scientific data, cutting these into tiles etc.

http://www.celestialmatters.org/cm/index.shtml
http://www.celestialmatters.org/cm/host ... s/nmtools/

Besides my nmtools for normalmap generation, there is now a complementary set, my txtools, that perform analogous tasks for base and specular textures, do high-quality DXT1..3 and notably DXT5nm compression and many other specialized tasks, like mounting RGB + A -> RGBA etc.

NConvert would be a great format conversion tool for us, except it has substantial weaknesses where I need it to be VERY strong ;-)

-- I need perfect operation wrto STDIN/STDOUT such that nconvert may be piped together with my other tools.

-- I need optimized dynamic memory management, since we start to work with texture sizes, where other tools hopelessly give up.

-- among the strongest weakness of nconvert is the lack of fast AND high-quality DXT compression for ALL standard flavors, DXT1..3 and notably DXT5nm. The latter being a highly quality optimized DXT5 (RGBA) format specialized to normalmap compression, which has to be of very high smoothness. It was invented by NVIDIA.

As Joerg emphasized already, nconvert only works partially OK with STDIN, also depending on the OS. Take any .ppm RGB texture, for example

and do the simplest possible STDIN action:

nconvert -o test.png stdin < file.ppm

This works in Linux, but NOT under windows XP. In my tools I use the following code to make them work perfectly under STDIN/STDOUT

Code: Select all

   	#ifdef _WIN32
		if (_setmode(_fileno(stdin), _O_BINARY) == -1 )
    	{
    		cerr<<"Binary read mode from STDIN failed\n";
    		return 1;
    	}

		if (_setmode(_fileno(stdout), _O_BINARY) == -1 )
    	{
    		cerr<<"Binary write mode via STDOUT failed\n";
    		return 1;
    	}
   	#endif
Also I am told by my OSX-friends that nconvert is quite buggy on MACS...This I can't test myself, but since we always work totally cross-platform, we would need stable performance under MAC-universal (PPC & Intel Macs)

Bye Fridger

Posted: Fri Mar 02, 2007 11:11 am
by Fighspit
Hey t00fri, I recognize you :wink:

Posted: Fri Mar 02, 2007 11:45 am
by Guest
Fighspit wrote:Hey t00fri, I recognize you :wink:
Hey Fightspit!

perhaps I should write my posts in French to provoke a little more reaction here...it is so far not exactly "overboarding".

Bye Fridger

Posted: Fri Mar 02, 2007 11:47 am
by Guest
Anonymous wrote:
Fighspit wrote:Hey t00fri, I recognize you :wink:
Hey Fightspit!

Ça va?

Perhaps I should write my posts in French to provoke a little more reaction here...it is so far not exactly "overboarding".

Bye Fridger

Posted: Tue Apr 17, 2007 7:29 pm
by Tech2000
Unfortunatly this thread doesn't wake any intrests from the developer. To bad since, as Fridger said, this would be of great use for the celestia community too.

Regards, Anders

Posted: Tue Apr 17, 2007 7:37 pm
by helmut
Tech2000 wrote:Unfortunatly this thread doesn't wake any intrests from the developer. To bad since, as Fridger said, this would be of great use for the celestia community too.
Hmm, a month's time is long enough to wait for an answer.

Pierre, could you give a short status what the situation is?

Posted: Wed Apr 18, 2007 8:30 am
by xnview
Tech2000 wrote:Unfortunatly this thread doesn't wake any intrests from the developer. To bad since, as Fridger said, this would be of great use for the celestia community too.
There is a problem with stdin & nconvert for some formats, it's not possible to write the file before to send it to nconvert??

Posted: Mon Apr 23, 2007 7:55 pm
by Guest
xnview wrote:
Tech2000 wrote:Unfortunatly this thread doesn't wake any intrests from the developer. To bad since, as Fridger said, this would be of great use for the celestia community too.
There is a problem with stdin & nconvert for some formats, it's not possible to write the file before to send it to nconvert??
Many thinks are possible ;-).

Yet in Celestia, we are dealing with VERY large sets of image tiles indeed: typically for a 64k x 32k texture of Earth, ~2500 1024 x 1024 pix PNG and or DXT5 or DXT5nm images. That fills O(10 GB) of data for each kind of format. So we are not exactly keen to vaste another 10 GB for intermediate storage. ;-)

Since the reaction/interest here was more than "poor" ;-), I have meanwhile made another choice which does not involve nconvert anymore. Since the new OpenSource NVIDIA (squish based) DXT compressor code is out now, this great DXT algorithm has opend much better perspectives together with my own DeVIL-based format converter that is part of my new txtools package. nconvert is very weak on DXT format anyway. My converter works with STDIN/STDOUT without any problems in all OS's.

Bye Fridger