It is currently Mon, 29-05-17, 11:28 GMT

All times are UTC




Post new topic Reply to topic  [ 18 posts ]  Go to page Previous  1, 2
Author Message
 Post subject:
PostPosted: Wed, 09-04-08, 11:06 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4445
Location: Hamburg, Germany
bdm wrote:
Often users find ways of applying software tools in ways the designers didn't expect. With just a little work, these tools can be incorporated into a script that can split up a texture of a fixed size into several levels of textures, all placed in the correct level directories, complete with a CLX file as well. If I can do that using the limited capabilities of a DOS script, it's not hard to do it in a shell script as well.


Yes, but I just meant to say that I will NOT invest any time into this.

People have written already convenient scripts based on the F-TexTools/nmtools that allow to generate a complete /monster/ VT setup (64k!) with just a few mouse clicks, based on /scientific binary/ raw data.

That's what I had in mind. It has become a popular issue these days.

To add small custom extensions officially, means comparatively much effort. My tools are always released with binaries for 3 operating systems, of which I only have access to two.

Quote:
Now we don't really need to figure out the width of the image. Other tools can do this as well. But the F-TexTools do also require the users to know the number of bytes per pixel and this is not easy to find out.

Quote:
We also need to include the capability to retrieve the colour type as well and convert it to the "channels" required in many places in the suite. Knowing the colour type is crucial to the correct operation of the F-TexTools suite but unless I missed something in the documentation at present the only way to determine the colour type using the F-TexTools suite is by trial and error. And when you're working with humungous texture files that take a while to process, users may get frustrated if they need to try it more than once. In fairness, there are likely to be only two values to try: "3" and "4".


The bpp value = number of channels should be obvious before any work is started. It 's really trivial. See further below...
Quote:
We don't need to install Imagemagick just to get access to the Identify tool.

ImageMagic should be a standard installation in ANY OS for anyone who wants to do something with images. Are you really addressing your efforts to people who would NOT know the size of the texture they are planning to work with?

There are MANY display programs for any OS, where the required image info can be determined with a simple click initially (GIMP, PS, xnview, Irfanview, ...) . People who have NONE of these standard applications installed might again prefer another solution.

Quote:
We should be able to write a simple utility to interrogate the IHDR chunk in the PNG file to retrieve the height and width.

At the code level it's trivial, of course. Libpng offers all required methods.
Quote:
The one weakness of the F-TexTools script is the need to pass the number of channels to most of the commands. How do we work out this number from a PNG file?

But the number of channels (bpp=bytes per pixel) is really trivial:

grayscale=1, RGB=3 and RGB with alpha channel = 4 (RGBA).

In all relevant formats, after the header part, follows a certain number of bytes associated with each subsequent pixel of the image. In a grayscale image there is 1 byte value for each pixel. It's the brightness value of each pixel. For a RGB image, we have a triplet of bytes, one for the redness, the greenness and the blueness of each pixel. In RGBA images a 4th byte follows the three RGB bytes and characterizes the alpha value (opaqueness, transparency,...). But of course a general PNG image can be much richer than what I described. Only for Celestia texture work it's not needed.

Users who don't know what kind of textures they are working with, might rather want to use other tools ;-) . Bpp = 1, 3, 4 are equally important in practice.

For instance for work with spec-files = watermaps/landmaps or nighttime-lights, one encounters bpp=1 (grayscale) textures. My tools allow to mount such grayscale spec-maps as alpha channel on top of the RGB base texture. That's how 3+1 =4 channels arise. This saves memory which is important for large textures.

But we don't need any kind of programs to tell us the bpp value ;-)

Quote:
t00fri wrote:
Really I don't see why one has to spoil users to an extent that they don't need to know the initial size of their textures!


But what if the users don't know the initial size, or, more to the point, the number of channels used by the texture?


Then they might want to learn how to do this...

I have NO motivation to prepare my tools for use by people who either don't have any basic knowledge about images they want to work with or are unwilling to learn! This community chronically lacks much other elementary know how that is required for using command-line tools. They typically don't know e.g. how to use/locate the standard 'cmd' shell under Windows, let alone any more sophisticated shell to run such scripts....

So next you will get involved into a tutorial "how do I find and use the Windows cmd shell of my computer"? ;-) . I went through most of this repeatedly ;-)

I simply don't have the time and devotion to get involved once more with this sort of stuff.

Quote:
While "identify" provides the width of the texture in an obvious format, I doubt many people would be able to use it to work out how many bytes are used per pixel.

But identify also provides the bpp property:

identify -format "%r" grayscale.png => DirectColorGrayMatte
identify -format "%r" rgb.png => DirectColorRGB
identify -format "%r" rgba.png => DirectColorRGBMatte

Just map the output strings to 1,3,4 in your script and you are done, if you REALLY want to do this...

F.


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 10-04-08, 1:54 GMT 
Offline

Joined: Tue, 01-04-08, 23:47 GMT
Posts: 3
Thank you for your clarifications, they will be helpful. It seems that 1 (greyscale), 3 (RGB) and 4 (RGBA) are the only possibilities. I was working on the assumption that 16-bit colour was also possible in the scientific datasets. I know that 16-bit colour exists in medical imaging and for that reason I assumed that other scientific applications may have also used this depth.

Does any of the currently-available scientific data have a colour depth of 16? The PNG format does support this, but I am unaware of whether any commonly-available high-resolution scientific datasets actually have this resolution.

Do the F-TexTools support 16-bit colour PNG files, even if all it did was convert it to 8-bit for Celestia?


Top
 Profile  
 
 Post subject:
PostPosted: Thu, 10-04-08, 9:27 GMT 
Offline
Site Admin
User avatar

Joined: Fri, 31-08-07, 7:01 GMT
Posts: 4445
Location: Hamburg, Germany
bdm wrote:
Thank you for your clarifications, they will be helpful. It seems that 1 (greyscale), 3 (RGB) and 4 (RGBA) are the only possibilities. I was working on the assumption that 16-bit colour was also possible in the scientific datasets. I know that 16-bit colour exists in medical imaging and for that reason I assumed that other scientific applications may have also used this depth.

Does any of the currently-available scientific data have a colour depth of 16? The PNG format does support this, but I am unaware of whether any commonly-available high-resolution scientific datasets actually have this resolution.

Do the F-TexTools support 16-bit colour PNG files, even if all it did was convert it to 8-bit for Celestia?


  • I don't know of any scientific data set from space missions supporting 16bit color.
  • Celestia does not support 3x16bit color
  • Many image manipulation programs don't support 16bit color satisfactorily. PS 7.x only supports it "a little".
  • As soon as one considers 16bit color, the issue of little-endian vs big-endian storage returns into the game. The behaviour of the F-TexTools under 16 bit color raw data is basically untested. Adaptation to 16bit color should not be a big deal, yet so far there is no need.


F.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 18 posts ]  Go to page Previous  1, 2

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