-
Notifications
You must be signed in to change notification settings - Fork 10
/
index.html
197 lines (158 loc) · 14.1 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
---
title: FLIF - Free Lossless Image Format
group: home
---
{% include header.html %}
<div id="container">
<img src="img/flif.png" alt="FLIF logo" class="logo" />
</div>
<h2 id="update">UPDATE</h2>
<p>FLIF development has stopped since FLIF is superseded by FUIF and then again by <a href="https://jpeg.org/jpegxl">JPEG XL</a>,
which is based on a combination of <a href="https://github.com/google/pik">Pik</a> and <a href="https://github.com/cloudinary/fuif">FUIF</a>.
For more information, see <a href="https://sneyers.info/jxl">Jon's JXL info page</a> or visit the
<a href="https://discord.gg/DqkQgDRTFu">JPEG XL Discord server</a>.</p>
<h2 id="flif-free-lossless-image-format">FLIF - Free Lossless Image Format</h2>
<p>FLIF is a novel lossless image format which outperforms PNG, lossless WebP, lossless BPG, lossless JPEG2000, and lossless JPEG XR
in terms of compression ratio.</p>
<p>According to the
<a href="https://docs.google.com/spreadsheets/d/1LxY78fbm47VmrYGTXkBXXitGjhGl32NsuHPH2QXufgA/edit?usp=sharing">compression experiments we have performed</a>
<a href="https://docs.google.com/spreadsheets/d/16ghJEjf_T7TDTOg2WlelnG1SYCsHng6V-1rxdo78YL8/edit?usp=sharing">[older results here]</a>,
FLIF files are on average:</p>
<ul>
<li>14% smaller than lossless <a href="https://developers.google.com/speed/webp/">WebP</a>,</li>
<li>22% smaller than lossless <a href="http://bellard.org/bpg/">BPG</a>,</li>
<li>33% smaller than brute-force crushed PNG files (using ZopfliPNG),</li>
<li>43% smaller than typical PNG files,</li>
<li>46% smaller than optimized Adam7-interlaced PNG files,</li>
<li>53% smaller than lossless JPEG 2000 compression,</li>
<li>74% smaller than lossless JPEG XR compression.</li>
</ul>
<p>Even if the best image format was picked out of PNG, JPEG 2000, WebP or BPG for a given image corpus,
depending on the type of images (photograph, line art, 8 bit or higher bit depth, etc),
<strong>then FLIF still beats that by 12%</strong> on a <i>median</i> corpus
(or 19% on average, including 16-bit images which are not supported by WebP and BPG).</p>
<h2>Status</h2>
<p>The file format has been standardised and versioned. The latest stable version is <strong>FLIF16</strong> and
is documented <a href="spec.html">here</a>.</p>
<h2 id="advantages">Advantages</h2>
<div>
<p>Here are some of the key advantages of FLIF:</p>
<dl>
<dt id="best-compression">Best compression</dt>
<dd>
<p>The results of a compression test similar to the <a href="https://developers.google.com/speed/webp/docs/webp_lossless_alpha_study#results">WebP study</a> are shown below. FLIF clearly beats other image compression algorithms.
(Note: the graph below is for an early version of FLIF. It has slightly improved since then.)</p>
<a href="img/comparison.png" class="img"><img src="img/comparison.png" alt="Chart comparing FLIF to alternatives."></a>
</dd>
<dt id="works-on-any-kind-of-image">Works on any kind of image</dt>
<dd>
<p>FLIF does away with knowing what image format performs the best at any given task.</p>
<p>You are supposed to know that PNG works well for line art, but not for photographs. For regular photographs where some quality loss is acceptable, JPEG can be used, but for medical images you may want to use lossless JPEG 2000. And so on. It can be tricky for non-technical end-users.</p>
<p>More recent formats like <a href="https://developers.google.com/speed/webp/">WebP</a> and <a href="http://bellard.org/bpg/">BPG</a> do not solve this problem, since they still have their strengths and weaknesses.</p>
<p><strong>FLIF works well on any kind of image, so the end-user does not need to try different algorithms and parameters.</strong> <a href="https://docs.google.com/spreadsheets/d/16ghJEjf_T7TDTOg2WlelnG1SYCsHng6V-1rxdo78YL8/edit?usp=sharing">Here is a selection of different kinds of images and how each image format performs with them</a>. The conclusion? FLIF beats anything else <strong>in all categories</strong>.</p>
<p>Here is an example to illustrate the point. On photographs, PNG performs poorly while WebP, BPG and JPEG 2000 compress well (see plot on the left). On medical images, PNG and WebP perform relatively poorly (note: it looks like the most recent development version of WebP performs a lot better!) while BPG and JPEG 2000 work well (see middle plot). On geographical maps, BPG and JPEG 2000 perform (extremely) poorly while while PNG and WebP work well (see plot on the right). In each of these three examples, FLIF performs well — even better than any of the others.</p>
</dd>
</dl>
</div>
<div class="small_images">
<a href="img/compression-kodak.png" class="img"><img src="img/compression-kodak.png" alt="Chart showing a comparison of FLIF to alternatives against the Kodak Suite" /></a>
<a href="img/compression-lukas_medical.png" class="img"><img src="img/compression-lukas_medical.png" alt="Chart showing a comparison of FLIF to alternatives against the Lukas 2D Medical Images Suite"></a>
<a href="img/compression-maps.png" class="img"><img src="img/compression-maps.png" alt="Chart showing a comparison of FLIF to alternatives against a set of geographical maps" /></a>
</div>
<dl>
<dt id="progressive-and-lossless">Progressive and lossless</dt>
<dd>
<p>FLIF is lossless, but can still be used in low-bandwidth situations, since only the first part of a file is needed for a reasonable preview of the image.</p>
<p>Other lossless formats also support progressive decoding (e.g. PNG with Adam7 interlacing), but FLIF is better at it. Here is a simple demonstration video, which shows an image as it is slowly being downloaded:</p>
<iframe width="640" height="360" src="https://www.youtube-nocookie.com/embed/ByH7RMsMxBY?rel=0" frameborder="0" allowfullscreen style="max-width:100%">
<a href="https://www.youtube.com/watch?v=ByH7RMsMxBY">PNG Adam7 vs FLIF</a>
</iframe>
<p>Lossy compression is useful when network bandwidth or diskspace are limited, and you still want to get a visually OK image. The disadvantages of lossy compression are obvious: information is lost forever, compression artifacts can be noticeable, and transcoding or editing can cause <a href="https://en.wikipedia.org/wiki/Generation_loss">generation loss</a>. With better compression, the need to go there is lessened.</p>
<p><a href="example.html">Here is an example</a> to illustrate the progressive decoding of FLIF, compared to other methods.</p>
</dd>
<dt id="responsive-by-design">Responsive by design</dt>
<dd>
<p>A FLIF image can be loaded in different ‘variations’ from the same source file, by loading the file only partially. This makes it a very appropriate file format for responsive web design.</p>
<p><a href="responsive.html">Read more about FLIF and Responsive Web Design</a></p>
<p>Try the <a href="https://uprootlabs.github.io/poly-flif/">Poly-FLIF interactive demo</a> by <a href="https://github.com/hrj">hrj</a>!</p>
</dd>
<dt id="no-patents-free">No patents, Free</dt>
<dd>
<p>Unlike some other image formats (e.g. BPG and JPEG 2000), FLIF is completely royalty-free and it is not known to be encumbered by software patents.
At least as far as we know.
FLIF uses <a href="https://en.wikipedia.org/wiki/Arithmetic_coding">arithmetic coding</a>,
just like <a href="https://en.wikipedia.org/wiki/FFV1">FFV1</a> (which inspired FLIF), but as far as we know,
all patents related to arithmetic coding <a href="https://en.wikipedia.org/wiki/Arithmetic_coding#US_patents">are expired</a>.
Other than that, we do not think FLIF uses any techniques on which patents are claimed.
However, we are not lawyers. There are a stunning number of software patents, some of which are very broad and vague;
it is impossible to read them all, let alone guarantee that nobody will ever claim part of FLIF to be covered by some patent.
All we know is that we did not knowingly use any technique which is (still) patented, and we did not patent FLIF ourselves either.
</p>
<p>
<a href="http://www.gnu.org/licenses/lgpl.html" class="no-highlight"><img src="img/lgplv3.png"></a>
</p>
<p>The reference implementation of FLIF is <a href="http://fsfe.org/about/basics/freesoftware.en.html">Free Software</a>.
It is released under the terms of the <a href="http://www.gnu.org/licenses/gpl.html">GNU Lesser General Public License (LGPL)</a>,
version 3 or any later version.
That means you get the “four freedoms”:</p>
<ol>
<li>The freedom to run the program, for any purpose.</li>
<li>The freedom to study how the program works, and adapt it to your needs.</li>
<li>The freedom to redistribute copies.</li>
<li>The freedom to improve the program, and release your improvements to the public, so that the whole community benefits.</li>
</ol>
<p>The reference FLIF decoder is also available as a shared library, released under the more permissive
(non-copyleft) terms of the <a href="http://www.apache.org/licenses/LICENSE-2.0">Apache 2.0 license</a>.
Public domain example code is available to illustrate how to use the decoder library.</p>
<p>Moreover, the reference implementation is available free of charge (gratis) under these terms.</p>
</dd>
</dl>
<h2 id="download">Download</h2>
<p><a href="https://github.com/FLIF-hub/FLIF">FLIF source code</a></p>
<p><a href="http://flif.info/UGUI_FLIF">UGUI: FLIF</a> - A GUI for FLIF</p>
<p><a href="https://filemill.net/#flif-gui">FLIF-GUI</a> - Drag & drop, parallel batch processing, size statistics. (Windows).</p>
<p><a href="https://github.com/sveinbjornt/Phew">Phew</a> - FLIF Viewer for OSX</p>
<h2 id="features">Features</h2>
<p>FLIF currently has the following features:</p>
<ul>
<li>Lossless compression</li>
<li><a href="lossy.html">Lossy compression</a> (encoder preprocessing option, format itself is lossless so no generation loss)</li>
<li>Greyscale, RGB, RGBA (also palette and color-bucket modes)</li>
<li>Color depth: up to 16 bits per channel (high bit depth)</li>
<li>Interlaced (default) or non-interlaced</li>
<li>Interlaced files can be decoded quickly at lower quality/resolution (<a href="responsive.html">“Responsive By Design”</a>)</li>
<li><a href="example.html">Progressive decoding</a> of partially downloaded files</li>
<li><a href="animation.html">Animation support</a></li>
<li>Support for embedded ICC color profiles, Exif and XMP metadata</li>
<li>Rudimentary support to compress camera raw files (RGGB)</li>
<li>Encoding and decoding speeds are acceptable, but should be improved</li>
<li>Fallback web browser support via a JavaScript polyfill decoder (<a href="https://uprootlabs.github.io/poly-flif">poly-flif</a>)</li>
</ul>
<h2 id="todo-list">TODO list</h2>
<p>FLIF does not yet support the following features:</p>
<ul>
<li>Other color spaces (CMYK, YCbCr, ...)</li>
<li>Tiles (to store huge images with fast cropped viewing)</li>
<li>Better lossy compression</li>
<li>Native web browser support</li>
<li>Support in popular image tools and viewers</li>
<li>A highly optimized implementation</li>
</ul>
<h2 id="technical-information">Technical information</h2>
<p>FLIF is based on MANIAC compression. MANIAC (Meta-Adaptive Near-zero Integer Arithmetic Coding) is an algorithm for entropy coding developed by Jon Sneyers and Pieter Wuille. It is a variant of <a href="https://en.wikipedia.org/wiki/Context-adaptive_binary_arithmetic_coding">CABAC (context-adaptive binary arithmetic coding)</a>, where instead of using a multi-dimensional array of quantized local image information, the contexts are nodes of decision trees which are dynamically learned at encode time. This means a much more image-specific context model can be used, resulting in better compression.</p>
<p>Moreover, FLIF supports a form of progressive interlacing (essentially a generalization/improvement of PNG's <a href="https://en.wikipedia.org/wiki/Adam7_algorithm">Adam7 interlacing</a>) which means that any prefix (e.g. partial download) of a compressed file can be used as a reasonable lossy encoding of the entire image. In contrast to other interlacing image formats (e.g. PNG or GIF), interlaced FLIF encoding takes the interlacing into account in the pixel estimation and in the MANIAC context model. As a result, the overhead of interlacing is small, and in some cases (e.g. photographs) interlaced FLIF files are even smaller than non-interlaced ones.</p>
<p>Many more technical details can be found in the <a href="publications.html">publications</a> section of this website.
<h2 id="sponsors">FLIF sponsors</h2>
<p>
<a href="http://cloudinary.com" class="no-highlight"><img src="http://res.cloudinary.com/cloudinary/image/upload/c_scale,w_150/v1/logo/for_white_bg/cloudinary_logo_for_white_bg.png" align="left" style="padding-right: 1em; padding-bottom: 2em;"></a>
FLIF development is currently sponsored by <a href="http://cloudinary.com">Cloudinary</a>, the image back-end for web and mobile developers.
Obviously Cloudinary fully supports the FLIF format, both as an input format and an output format.
</p>
<script>
((window.gitter = {}).chat = {}).options = {
room: 'FLIF-hub/FLIF'
};
</script>
<script src="https://sidecar.gitter.im/dist/sidecar.v1.js" async defer></script>
</body>
</html>