public wiki contents of
git clone git://
Log | Files | Refs (4996B)

      1 FAQ
      2 ===
      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.
     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.
     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.
     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.
     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.
     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.
     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.
     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.
     57 Is metadata supported?
     58 ----------------------
     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.
     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.
     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.
     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.
     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.
     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.
     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.