Hello fellow hackers,
I'm pleased to announce version 1 of farbfeld[0]. Those of you subscribed
to hackers@ have already seen the ramped up activity in the last few
days and I'm glad to have had the time to finally bring the codebase
forward to something stable and consistent.
Farbfeld is a very simple image format created to make image processing
as easy as possible. Once you've had the chance to use libpng or
libjpeg in your projects, you know what I'm talking about.
It just can't be that when you want to get things done you first have
to fight your way through pages and pages of documentation for a given
image library. It took me quite a while to get this right for libpng,
especially in regard to 16-Bits-per-channel-data.
The farbfeld-format is so simple, I can post the entire spec right here:
+--------+-----------------------------------------------------------+
| Bytes | Description |
+--------+-----------------------------------------------------------+
| 8 | "farbfeld" magic value |
+--------+-----------------------------------------------------------+
| 4 | 32-Bit BE unsigned integer (width) |
+--------+-----------------------------------------------------------+
| 4 | 32-Bit BE unsigned integer (height) |
+--------+-----------------------------------------------------------+
| [2222] | 4*16-Bit BE unsigned integers [RGBA] / pixel, row-aligned |
+--------+-----------------------------------------------------------+
I am not going to change this format. This is a 0K.
So, go ahead, download the tarball, read the provided manpages
(at best start with farbfeld(5); you'll find a simple code-example for
a color-inverter there) and start hacking. Use lel(1) or "ff2png | feh
-" to view your results.
I'm sure you'll come up with something cool!
---
I want to use this chance to also discuss some points that I discussed
with fellow hackers while working on this project:
0) Why use 16-Bits-per-channel all the time? Isn't this a total waste?
Not when you take compression into account. To make this
clearer, assume a paletted image with 5 colors and no
transparency. So the data is only a set of regular chunks
(color1, ..., color5) in a certain order.
Compression algorithms have been designed to recognize those
chunks and can even look at how these chunks interact.
My testing has shown that farbfeld easily beats paletted
PNG-images. Try for yourself and look at the bzipped results!
There is no need for special Grayscale, Palette, RGB, 1-, 2-,
4-, 8-, 16-Bit subformats.
Just store 16-Bit RGBA all the time and let compression take
care of the rest.
1) Why is there no support for color spaces (Adobe RGB, ...)?
The most widely-used color space is sRGB. I know it has its
drawbacks, but there are excellent ressources[1][2] as to why
you probably won't need Adobe RGB and other color spaces anyway.
Additionally, AdobeRGB is very difficult to process and if you
make one tiny mistake in your pipeline, you'll end up with very
dull colors (which is because Adobe RGB just stretches the RGB
values non-linearily).
Most displays and printers are calibrated for sRGB. I have yet
to see an example of an image which looked any different in the
print depending on if it had been processed in a sRGB or Adobe RGB
pipeline. Also, for smoother gradients, sRGB actually is better
because for the same color depth the sRGB colors lie closer to
each other. However, this is minor due to the fact that you can
easily ramp up bit-depth. However, it helps you realize that
Adobe RGB is just a tool like any other and it has no magic
properties.
Given most people don't even know what this stuff is all about
anyway and unknowingly use sRGB, why not appease the 99%?
The 1% wanting to use AdobeRGB is not forbidden to use it in
farbfeld, nobody is stopping you. You just have to make it clear
in your data interchange, which is not problematic given that
you have to be very careful building your AdobeRGB-pipeline in
the first place.
There are exotic color spaces which try to fix some issues of the
sRGB color space, but it doesn't look like they'll catch on in
the near future.
2) Which compression should I use?
I recommend bzip2 in the manpages, which is widely available
and gives good results. As time will move forward and new
algorithms hit the market, this recommendation might be rethought.
---
I also want to thank Dimitris, Hiltjo, z3bra and all the other guys helping
me debugging and testing the software across distros, unixes and endianesses.
Have a nice evening and happy hacking!
Cheers
FRIGN
[0]: http://git.suckless.org/farbfeld
[1]: http://www.kenrockwell.com/tech/adobe-rgb.htm
[2]: http://www.kenrockwell.com/tech/color-management/is-for-wimps.htm
--
FRIGN <d...@frign.de>
