Hacker News Reader

Comment by sysadm1n | Hacker News Reader

Anecdotally, the first time I heard of TGA was in Tomb Raider. The Tomb Raider games of old had a screenshot feature that outputted TGA files of gameplay and were useful for making walk-throughs for other people (you would typically convert them to JPG when sharing on the web).

And I still see BMP files being used even in modern games. Yeah: PNG is better, but BMP has its uses.

View on HN

BMP and TGA have the advantage that they're uncompressed, so it's mostly trivial to dump the contents of your framebuffer to a file without any major dependencies.

You can write an uncompressed PNG IIRC.

Sort of but not really.

You can write out PNG files with deflate blocks that aren't compressed, so in that sense they are uncompressed PNG files, but all of the complexity of supporting compression is still there in the data format in a way that is not fully avoidable even if you don't actually compress the data.

BMPs on the other hand are simple to write, only a very small portion of the header data is required and then you can dump the image out as its raw pixel data in a way that they are probably already being stored in memory, making it a very easy format to support the writing of and a pretty easy format to support the reading of.

BMP is quite complex and poorly documented (it's a bunch of random Microsoft structs and #defines), more so than PNG.

BMP has compression too (RLE and Huffman). PNG is simpler here since you can just drop a DEFLATE library straight in.

Images are usually stored in memory as RGBA in scanline order. You can dump this representation straight to a PNG file (edit: this is wrong, you can't). BMPs are typically written with pixels in packed BGR order, rows going bottom to top. But not always. I think they go top to bottom if you give a negative height, and you can supply masks defining which bits the RGBA come from.

If you're going to drop a library in, sure use PNG or whatever else, but the premise of this subthread was about ease of dumping an in-memory representation of the pixels into a valid file, and BMP makes that way easier than PNG does.

In a couple lines of code with no external library you can create a valid BMP file with just enough header bits to tell the BMP reader how your pixels are arranged and let it deal with the conversion.

Virtually all of the complexity of BMP files is optional and can be ignored by a BMP writer and just let the BMP reader worry about it. This is not true for PNGs where you have to have a significant understanding of the file format to write a PNG file.

Libraries make that not matter so much but are kind of outside of the scope of where this discussion was at the time this came up.

I'm certainly not advocating for BMP over PNG and most people should just include a flexible image handling library that's relevant for their given language and be done with it, but I also understand why even today programmers working in languages like C/C++ will use BMPs just to get a simple and functional export working without dealing with the complexity of using a third party library when their needs for the file format are minimal and internal to their own use and not being exposed to users.

Well, you're right. I had thought you could write an uncompressed PNG, but I was wrong, it has to be DEFLATED. You can write a series of uncompressed DEFLATE blocks like you said (not so bad), but the Adler32 and CRC32 checksums kill you.

Agree about TGA, it is trivially easy to write. Example in C# for grayscale version, a single page of code: https://github.com/Const-me/Vrmac/blob/1.2/VrmacInterop/Util...

BMP is more complicated, unfortunately. The header structure is more complex. And then there’s a requirement for rows to be 4-bytes aligned, might need to insert padding bytes between the rows.

The code for BMP isn't very complicated, the hard part is knowing all the rules and corner cases. Like the 4-byte alignment you mentioned, or the fact that the rows are in reverse order of what you'd expect (bottom up).

I think the row order in BMP is OS/2 related. Windows, X, etc. all put 0,0 in the top-left corner, but OS/2 puts it in the bottom-left instead.

Just to chime in, my 3D engine uses TGA to import textures too because the code is dead simple.

Sometimes when you are going to use your own format for saving data you could pick the simplest format for your import to accelerate productivity at the cost of diskspace.

In a similar way I use collada for character animations, it gets alot of slack from AAA studios (who all use FBX) but for indie development it's simple enough to be able to implement in a reasonable time (XML so you can see what's what)...

In the same line of thinking, I import static meshes from .obj, sound from .wav and last but not least font from .ttf!

The limiting factor usually is the editor you use to create/manipulate the assets in the first place, always look to the simplest export format they have, for Photoshop TGA is the simplest!

I export everything to my own custom binary formats to be loaded by the engine by customers, and there lz4 is a pretty good/simple RLE compression (RLE is also used by TGA BTW) and then .zip (also very simple!) to wrap it all up...

Keep it simple!

TGA is a great format for tinkering because it is very simple to code yourself to generate images and it is still widely supported.

Yes, IIRC it's about an 18 byte binary header and then BGRABGRABGRA... or BGRBGRBGR... bytes for uncompressed (there's also an RLE mode, but I never use it). The only real gotchas are the channel ordering and that the image might be flipped top-to-bottom if you're not careful.

These days though, I use tend to use the even simpler PPM format. It uses normal RGB byte ordering from top to bottom, and it's simple enough that I can code a basic writer for it from memory:

    fprintf(stream, "P6 %d %d 255\n", width, height);
    fwrite(image, 1, height * width * 3, stream);

(Often, I won't even bother opening a file to write to. I'll just emit the image to stdout and then pipe it to Image Magick for display or to convert to a compressed image format for storage.)

PPM P6 is also what I use all the time - I usually have to convert from paletted format to RGB first.

A PPM paletted format would save me a lot of space.

The built-in support for PPM in Preview on Mac OS X makes it extremely useful.

For my use, alpha is what I tend to miss in PPM. There's the PAM extension [0] but it's not nearly as widely supported as basic PPM. Usually at that point, I reach for PNG via stb_image_write [1].

[0] https://en.wikipedia.org/wiki/Netpbm#PAM_graphics_format

[1] https://github.com/nothings/stb/blob/master/stb_image_write....

TGA was very popular in 3d games for a time, I do recall seeing lots and lots of textures and the like encoded as TGA.

Reply on news.ycombinator.com