frign

Yeah right... http://www.codeproject.com/KB/graphics/TargaImage/TargaImage...

Ah yeah, excuse me please. I've used errno too often today :P It's corrected now.

The bzip2 choice is not set in stone. The reason why PNG is built on top of deflate is because back then there was nothing better around for the computing power available. If you talk about speeds, the more or less only revelant measure is _decompression_ speed, and bzip2 is just fine for that. How long it takes to compress an image is relevant only once. Decompression is another story.

Additionally, in pipelines, you would only decompress your image once and compress it once. Usually, when people build pipelines based on individual tools passing png's to each other, these steps are repeated n times for n elements of the pipeline.

I also noticed that in my tests, thus I stressed this point in the FAQ. If you try LZMA, you'll see that it sometimes is actually worse than bzip2, even though the latter is regarded to be quite aged compared to the former.

Keep in mind not all machines are Little Endian. This assumption is wrong.

If you just want to read in the header data, it should be sufficient if you just piped the decompressed data to your "header-checker" like this

bzip2 < giantimage.ff.bz2 | header-checker

Inside the header checker, you just read in the first 16 Bytes ("farbfeld" + width + height), do whatever you like with the data and exit. bzip2 would then receive an SIGPIPE. Up until this point, it would have probably filled the pipe buffer (~16K) with data and then blocked.

Receiving SIGPIPE, I'm certain bzip2(1) will cancel any further decompression attempts.

You see, you could even carry on with your image-processing in case you like the header data and want to proceed. The nice pipe-system already handles that for you. :)

It is specified (BE = Big Endian)

Hey krasin,

how come people assume there are only Little Endian machines. This mmap-technique wouldn't work on Big Endian like this, this is inaccetable!

However, you can still mmap and properly call ntohs() on each color channel value (if you access it). These functions won't hurt performance too much anyway, if at all. If you show me a measurable difference between using LE and BE, I owe you a beer, okay? :)

thing is, bzip2 is widespread, unlike lzma not everybody has.

on a technical side, lzma is a better choice. I might add a lzma recommendation, however, in soma cases lzma performs worse than bzip2.

also, decompression speeds matter, not compression speeds.

in the end, use what you prefer. the compression is not mandated by the spec. the main use for farbfeld is also rather thought to be as a piping format. it could also be used for storage, but that's not the main point.

Actually, you can have images with up to (2^32-1)(2^32-1) pixels. Given each pixel stores 64 Bits of data, there are 2^64 combinations for each pixel, yielding in the total number of possible images as:

(2^64)^((2^32-1)(2^32-1)) ~ 10^(10^21)