commit 79a704c473a99541ed4cd8a9350a9f995fdaf9d0
parent 5e8074ac3fcedc95f72b869a184a5b6336e31608
Author: FRIGN <dev@frign.de>
Date: Mon, 11 Jan 2016 16:25:20 +0100
Add farbfeld-FAQ
Diffstat:
1 file changed, 94 insertions(+), 0 deletions(-)
diff --git a/tools.suckless.org/farbfeld/index.md b/tools.suckless.org/farbfeld/index.md
@@ -12,6 +12,100 @@ It has the following format:
The RGB-data should be sRGB for best interoperability.
+FAQ
+---
+
+Why yet another image format?
+ : Current image formats have integrated compression,
+ making it complicated to read the image data.
+ One is forced to use complex libraries like libpng,
+ libjpeg, libjpeg-turbo, giflib and others, read the
+ documentation and write a lot of boilerplate in order
+ to get started.
+ Farbfeld leaves this behind and is designed to be as
+ simple as possible, leaving the task of compression
+ to external tools.
+ The simple design, which was the primary objective,
+ implicitly leads to the very good compression
+ characteristics, as it often happens when you go with
+ the UNIX philosophy.
+ Reading farbfeld images doesn't require any special
+ libraries. The tools are just a toolbox
+ to make it easy to convert between common image formats
+ and farbfeld.
+
+How does it work?
+ : In Farbfeld, pattern resolution is not done while
+ converting, but while compressing the image.
+ For example, farbfeld always stores the alpha-channel,
+ even if the image doesn't have alpha-variation.
+ This may sound like a big waste at first, but as
+ soon as you compress an image of this kind, the
+ compression-algorithm (e.g. bz2) recognizes the
+ pattern that every 48 bits the 16 bits store the
+ same information.
+ And the compression-algorithms get better and better
+ at this.
+ Same applies to the idea of having 16 bits per channel.
+ It sounds excessive, but if you for instance only have
+ a greyscale image, the R, G and B channels will store
+ the same value, which is recognized by the compression
+ algorithm easily.
+ This effectively leads to filesizes you'd normally only
+ reach with paletted images, and in some cases bz2 even
+ beats png's compression, for instance when you're dealing
+ with grayscale data, line drawings, decals and even
+ photographs.
+
+Which compression should I use?
+ : bzip2 is recommended, which is widely available (anybody has it)
+ and gives good results. As time will move forward and new
+ algorithms hit the market, this recommendation might be rethought.
+
+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.
+ Local tests 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.
+
+Why is there no support for color spaces (Adobe RGB, ...)?
+ : The most widely-used color space is sRGB. It has its
+ drawbacks, but there are
+ [excellent](http://www.kenrockwell.com/tech/adobe-rgb.htm)
+ [ressources](http://www.kenrockwell.com/tech/color-management/is-for-wimps.htm)
+ explaining 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. The author has 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 anyway.
+ There are exotic color spaces which try to fix some limitations of the
+ sRGB color space, but it doesn't look like they'll catch on in
+ the near future.
+
Dependencies
------------
