Texture file format

I have been using standard Windows bmp files for my textures, but now I am trying to do some stuff with transparent textures, and I’m not sure that Windows bmps are the best way to store the Alpha values for blending.

What file format do you people like using for your textures, and why?

Targa (TGA). Its very flexible, supporting 8-bit grayscale, 16 and 24 bit RGB, and 32-bit RGBA formats. Also, a lot of the popular/good image editing programs support it. It also supports lossless RLE compression. There is plenty of sample code you can use to load/decompress the data. Its also a pretty simple format if you are the type that likes to do it yourself. I researched the format and wrote a loader in less than a day. My loader is under 200 lines of code including support for all 4 bit depths and RLE and non RLE encoding, so you can see its not a terribly complex algorithm

Unfortunately, TGA stores RGB in reverse
order from GL. I ended up pre-compiling my
textures and meshes into my own format by
just writing a simple header + the raw data
to disk in a format of my own, and made my
world load much faster.

Of course, the gain from saving/loading raw
vertex arrays + drawing data over loading
.3ds was faster than the gain from not having
to swap the TGA, but it was still a win :slight_smile:

where can i find info on RLE compression/decompression?

Originally posted by bgl:
Unfortunately, TGA stores RGB in reverse
order from GL. I ended up pre-compiling my
textures and meshes into my own format by
just writing a simple header + the raw data
to disk in a format of my own, and made my
world load much faster.

Yes, but you are talking about a miniscule amount of work, and a minuscule performance hit(which should only occur at level loading).

Before moving to TGA, I also used my own custom format. The problem was that I had to make a converter. Then when I later wanted to take one of my images and modify it (and I didnt have the original format available), I had to write a reverse converter. Then you have to deal with conversion every time you make a change or make a new image. I find it much easier to be able to open the actual image itself in photoshop. Then it becomes more efficient to
1)make a change
2)save
3)run your app
4)see what (if anything) is still wrong with the image
5)repeat

Personally I find it more trouble than it is worth.

Originally posted by Warrior:
where can i find info on RLE compression/decompression?

Try a search engine (hotbot, google, etc…). There is PLENTY of info on the topic of RLE. If you are specifically interested int the TGA format:
ftp://ftp.truevision.com/pub/TGA.File.Format.Spec/PC.Version/TGA_FFS.EXE

run this and it extracts a rtf file.

If the TGA-format stores the components in reverse order, then why not use the GL_BGR_EXT-format (or whatever it’s called)? No need to do anything with the data.

Originally posted by Warrior:
where can i find info on RLE compression/decompression?

If you want to compress your textures for storage on disk, look into LZSS (an LZW derivative). It’s fast, efficient, and free to use

I’ve got the perfect solution to get rid of any performance hit when loading texture.

The fact is that that I don’t even have to load textures anymore . I just put the image data in my source code, then when it’s compiled, the data is in the exe file or in a dll and I don’t have to load image files.

I wrote a small program that converts a bmp file into an array definition in C code (ASCII text). I just paste that in a .cpp file. My program swaps the R and B components of every pixel so that I have RGB data.

Well of course I still have to create texture objects and I end up with huge .exe files.

It was the first image loading technique that I implemented. It might still be useful in some cases.

I did that because I thougth that coding an image loader was more difficult. Then when I wrote my first TGA loader I found out it was much simplier .

PS: bgl: for loading speed, I think I beat you on that one .

this is taken from NVidia’s opengl performace faq:


  1. How can I maximize texture downloading performance?

Best RGB/RGBA texture image formats/types in order of performance:

Image Format Image Type Texture Internal Format
GL_RGB GL_UNSIGNED_SHORT_5_6_5 GL_RGB
GL_BGRA GL_UNSIGNED_SHORT_1_5_5_5_REV GL_RGBA
GL_BGRA GL_UNSIGNED_SHORT_4_4_4_4_REV GL_RGBA
GL_BGRA GL_UNSIGNED_INT_8_8_8_8_REV GL_RGBA
GL_RGBA GL_UNSIGNED_INT_8_8_8_8 GL_RGBA

(hope this shows right)

Bear in mind that the NVIDIA GPUs store all 24-bit texels in 32-bit entries, so try using the
spare alpha channel for something worthwhile, or it will just be wasted space. Moreover, 32-bit
texels can be downloaded at twice the speed of 24-bit texels. Single or dual component texture
formats such as GL_LUMINANCE, GL_ALPHA and GL_LUMINANCE_ALPHA are also very
effective, as well as space efficient, particularly when they are blended with a constant color (e.g.
grass, sky, etc.). Most importantly, always use glTexSubImage2D instead of glTexImage2D
(and glCopyTexSubImage2D instead of glCopyTexImage2D) when updating texture images.
The former call avoids any memory freeing or allocation, while the latter call may be required to
reallocate its texture buffer for the newly defined texture.


as you see, its best to use GL_RGB for 16bit images, but for 24 or 32bit, you’d better use GL_BGRA_EXT with GL_UNSIGNED_INT_8_8_8_8_REV
When i load my textures, i convert 16 bit rgb images to GL_RGB/GL_UNSIGNED_SHORT_5_6_5, 16bit rgba to GL_BGRA/ GL_UNSIGNED_SHORT_1_5_5_5_REV and 24bit or 32bit rgba to GL_BGRA/ GL_UNSIGNED_INT_8_8_8_8_REV.
So for 16bit rgb, i put one pixel in 1 short (RRRRRGGGGGGBBBBB), and so on.
I have not tested if this actaully performes better, but i believe Nvidia

Is this a good idea ? or shouldn’t i bother the trouble ?

Sven

[This message has been edited by Sven Clauw (edited 02-28-2001).]

has anyone a function wich reads out of a tga-memblock?

like that:

unsigned char* myfile = GetFullFileData(“mytexture.tga”);
image* img = loadtga( myfile );

!?

(why?! cause i want to read out of some different zip/rar etc files (mpq, perhaps, too) )