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.