commit 078578d04b4059e9e1d1d76be4933ea2fb4af488
parent 79a704c473a99541ed4cd8a9350a9f995fdaf9d0
Author: FRIGN <dev@frign.de>
Date: Mon, 11 Jan 2016 16:29:16 +0100
Fix FAQ-markdown
Diffstat:
1 file changed, 99 insertions(+), 90 deletions(-)
diff --git a/tools.suckless.org/farbfeld/index.md b/tools.suckless.org/farbfeld/index.md
@@ -15,96 +15,105 @@ 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.
+### 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 use 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
------------
