Best image format for uncompressed textures?

Question

I am in the process of selecting an image format that will be used as the storage format for all in-house textures. The format will be used as a source format from which compressed textures for different platforms and configurations will be generated, and so needs to cover all possible texture types (2D, cube, volymetric, varying number of mip-maps, floating point pixel formats, etc.) and be completely lossless. In addition the format has to be able to keep a bit of metadata.

Currently a custom format is used for this, but a commonly available format will be easier to work with for the artists since its viewable in most image editors.

I have thought of using DDS, but this format does not support metadata as far as I can see.

All suggestions appreciated!

Answer 1

Have you tried PNG? http://java.sun.com/javase/6/docs/api/javax/imageio/metadata/doc-files/png_metadata.html

Answer 2

When peeking inside various games' resources I found out that most of them store textures (I don't know whether they're compressed or not) in TGA

Answer 3

With your requirements you should stay with your selfmade format. I don't know about any image-format besides DDS that supports volumetric and cube-textures. Unfortunately DDS does not support meta-data.

The closest thing you can find is TIFF. It does not directly support cube-maps or volumetric textures, but it supports any number of sub-images. That way you could re-use the sub-images as slices or cube-sides.

TIFF also has a very good support for custom meta-data. The libtiff image reading/writing library works pretty good. It looks a bit archaic if you come from a OO side, but it gets it's job done.

Nils

Answer 4

TIFF would probably be your closest bet for a format which supports arbitrary meta-data and multiple frames, but I think you are better off keeping the assets (in this case, images) separate from how they are converted and utilized in your engine.

Keep images in 32 bit PNG format, and put type- and meta information in XML. That keeps your data human viewable, readable and editable. Obscure custom formats are for engines, not people.

Answer 5

Stick with whatever your artists work with.

• If you are a windows/mac shop and use photoshop stick with .psd
• If you are a unix shop and use gimp stick with .xcf

These formats will store layers and all the stuff your artists need and are used to. Since your artists will be creating loads of assets make their life as easy as possible, even if it means to write some extra code.

Put the meta data (whatever it may be) somewhere "along" the images if the native format (psd/xcf) doesn't support it.

For stuff like cube maps, mipmaps (if not generated by the converter) stick to naming guidlines or guidlines on how to put them into one file.

Depending on what tool you use to create the volumetric stuff, just stick with that tools native format.

While writing custom formats for the target is usually a good idea, writing custom formats for artists results in mayhem...

Answer 6

My experience with DDS is that it is a poorly documented and difficult format to work with and offers few advantages. It is generally simpler to just store a master file for each image class that has references to the source images that make it up ( i.e. 6 faces for a cube map, an arbitrary number of slices for a volume texture ) as well as any other useful meta-data. It's always going to be a good idea to keep the meta-data in a seperate file ( or in a database ) as you do not want to be loading large numbers of images when carryong out searches, populating browsers, etc. It also makes sense to seperate your source image format ( tiff, tga, jpeg, dds ... ) from your "meta-format" ( cube, volume ... ) since you may well find that you need to use lossy compression to support HDR formats or very large source volume data.

Answer 7

As an alternative solution, maybe spend some time writing a plugin for a Free Image Editor for your file format? I've never done it before, so I don't know the work involved, but there is boatloads of example code out there for you.