I think it's nice to have a simple format for storing images for the sake of being able to build a pipeline of filters that are very lightweight and simple to implement.
But I was really distracted by how the author kept going on borderline nonsensical tangents about compression. There's a reason we usually build compression into the file format, instead of just zipping a lossless bitmap. It turns out that there's a ton of stuff you can do to exploit redundancy in two dimensions - if you can apply a transformation before the compression stage.
And yeah, you can make up some of your losses by using bzip2. But again, there's a reason formats like PNG don't do that: it's slow.
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.
Well, you can compare it to compressed RAW files, which are probably the closest we've come in terms of lossless compression. Then again, from a photography point of view, I do really like metadata, and I see no reason to omit them.
If I understand correctly farbenfeld is designed for processing images, not storing them. And if you bzip a farbenfeld image you might as well do it with a separate json file for metadata.
No and no.
If you discard metadata (e.g. EXIF from a camera) upon conversion, they don't come back after "processing". And bzip compresses a single file, not two; it is commonly used along with tar to make compressed multi-file archives.
Why would you discard metadata? What I'm saying is you should be able to extract it to a separate file when converting to ff. You're right about bzip and tar, but that just adds one extra step.
But I was really distracted by how the author kept going on borderline nonsensical tangents about compression. There's a reason we usually build compression into the file format, instead of just zipping a lossless bitmap. It turns out that there's a ton of stuff you can do to exploit redundancy in two dimensions - if you can apply a transformation before the compression stage.
And yeah, you can make up some of your losses by using bzip2. But again, there's a reason formats like PNG don't do that: it's slow.