[dev] [farbfeld] version 1 release

From: FRIGN <dev_AT_frign.de>
Date: Wed, 6 Jan 2016 19:45:37 +0100

Hello fellow hackers,

I'm pleased to announce version 1 of farbfeld[0]. Those of you subscribed
to hackers_AT_ 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 <dev_AT_frign.de>

Received on Wed Jan 06 2016 - 19:45:37 CET