index.md - sites - public wiki contents of suckless.org
(HTM) git clone git://git.suckless.org/sites
(DIR) Log
(DIR) Files
(DIR) Refs
---
index.md (4996B)
---
1 FAQ
2 ===
3
4 Why yet another image format?
5 -----------------------------
6 Current image formats have integrated compression, making it complicated to
7 read the image data. One is forced to use complex libraries like libpng,
8 libjpeg, libjpeg-turbo, giflib and others, read the documentation and write a
9 lot of boilerplate in order to get started.
10
11 Farbfeld leaves this behind and is designed to be as simple as possible,
12 leaving the task of compression to external tools. The simple design, which was
13 the primary objective, implicitly leads to the very good compression
14 characteristics, as it often happens when you go with the UNIX philosophy.
15 Reading farbfeld images doesn't require any special libraries. The tools are
16 just a toolbox to make it easy to convert between common image formats and
17 farbfeld.
18
19 How does it work?
20 -----------------
21 In Farbfeld, pattern resolution is not done while converting, but while
22 compressing the image. For example, farbfeld always stores the alpha-channel,
23 even if the image doesn't have alpha-variation. This may sound like a big waste
24 at first, but as soon as you compress an image of this kind, the
25 compression-algorithm (e.g. bz2) recognizes the pattern that every 48 bits the
26 16 bits store the same information. And the compression-algorithms get better
27 and better at this.
28
29 Same applies to the idea of having 16 bits per channel. It sounds excessive,
30 but if you for instance only have a greyscale image, the R, G and B channels
31 will store the same value, which is recognized by the compression algorithm
32 easily.
33
34 This effectively leads to filesizes you'd normally only reach with paletted
35 images, and in some cases bz2 even beats png's compression, for instance when
36 you're dealing with grayscale data, line drawings, decals and even photographs.
37
38 Why use 16-Bits-per-channel all the time? Isn't this a total waste?
39 -------------------------------------------------------------------
40 Not when you take compression into account. To make this clearer, assume a
41 paletted image with 5 colors and no transparency. So the data is only a set of
42 regular chunks (color1, ..., color5) in a certain order. Compression algorithms
43 have been designed to recognize those chunks and can even look at how these
44 chunks interact.
45
46 Local tests have shown that farbfeld easily beats paletted PNG-images. Try for
47 yourself and look at the bzipped results! There is no need for special
48 grayscale, palette, RGB, 1-, 2-, 4-, 8-, 16-Bit subformats. Just use 16-Bit
49 RGBA all the time and let compression take care of the rest.
50
51 Which compression should I use?
52 -------------------------------
53 bzip2 is recommended, which is widely available (anybody has it) and gives good
54 results. As time will move forward and new algorithms hit the market, this
55 recommendation might be rethought.
56
57 Is metadata supported?
58 ----------------------
59
60 Almost every image format out there has special offsets or locations
61 where metadata is stored. In itself, there are several different metadata
62 formats (Exif, XMP, etc.). For farbfeld, to keep it simple, there are
63 no provisions within the file format for metadata. Instead, one can
64 use so-called sidecar files (also known as buddy files or connected
65 files). As an example, to provide metadata for an image.ff.bz2, one can
66 add a file called image.xmp that contains XMP metadata for said image.
67
68 An added advantage of this approach is that the metadata is independent
69 of the image compression. As argued above, compression is vital for
70 farbfeld to be used efficiently, but when thinking of an application
71 that lists farbfeld-images in a folder, it might want to access
72 metadata as fast as possible.
73
74 The use of multiple files for one entity is a downside, but it wouldn't
75 be a problem at all if modern file systems supported forks.
76
77 What about NetPBM?
78 ------------------
79 NetPBM is considered to be the most simple format around, however, there's much
80 room for improvement. In fact, it doesn't help that the format is subdivided
81 into Portable BitMaps, Portable GrayMaps and Portable PixMaps. It's not helpful
82 when a manpage can't give a simple overview of a format in a few sentences.
83
84 NetPBM's big vice is that it has originally been developed to be hand-written
85 and passed around as plain text. A binary format exists, but still handling
86 optional comments in the header, base 10 ASCII width and height values,
87 arbitrary whitespace inside the data and out-of-band image size and color depth
88 is too painful for the sane user.
89
90 Judging from the usage of the format considering how long it's been around,
91 it's no surprise it never really took off. Additionally, functionality like
92 alpha channels and 16-Bit color depth can only be achieved via extensions. Due
93 to it being a textual format it also lacks the desired compression
94 characteristics.
95
96 The question you have to ask yourself is: Can I read in a format without
97 consulting the manpages? If your answer is yes, then the format is simple
98 enough. In this regard, NetPBM can be considered to be a failed format.