Thursday, August 20, 2009

Performance comparison of TGA and PNG

I've been doing a little research into the TGA and PNG formats. Dagger currently supports both, something I'd like to change as it is completely unnecessary.

Both support RGBA and are lossless which are pretty much my only requirements.

TGA is simple to load, but the files are usually two to three times larger than the equivalent image saved as a PNG. PNG on the other hand is a compressed format so the files are pretty small, but loading is much more complex and I've resorted to using a PNG library that is several times larger than Dagger...

There is no reason to support two different formats with essentially the same feature set, therefore I would like to cut one of them out of Dagger. The problem so far has been deciding which one.

I can live with TGA's large file sizes, what I'm mainly concerned about is loading performance. I originally thought that loading compressed images would be faster because disk IO is slow. To test this I wrote a quick benchmark that loads a 512x512x24 image 100 (I also tried 1000 but the results were mostly the same) times and then takes the average load time for each format. It turns out that in all of my tests loading a TGA is 2.5-3.5 times faster than loading the equivalent PNG.

The code and the images can be found here. Make sure that you configure & compile Dagger with.
The test was performed several times on both 32bit and 64bit machines (Fedora 11).

TGA loading was performed by Dagger, PNG loading was performed by whatever version of libpng ships with Fedora.

Edit: After changing my loader to use GL_BGR(A) instead of manually swapping pixel components, TGA loading is now roughly 12 times faster than PNG loading. Wow.

Late edit: Not sure how scientific this was. Increasing the number of times I loaded a texture showed that eventually PNG beats TGA. Unsure what exactly this means, but I'm probably going to go with PNG afterall seeing as how for the time being some kind of image compression is still important.

No comments:

Post a Comment