Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FLIF – Free Lossless Image Format

flif.info

Post reply on HN
Print view View original

121–130 of 153 posts

Re: FLIF – Free Lossless Image Format

#121

Post by vram22 »

panic wrote: post #23
AshleysBrain wrote: post #5

If browsers supported APIs to allow "native" image/video/audio codecs to be written in JS, we could support new formats like this without needing any co-operation from the (very conservative) browser vendors. I wrote a proposal for this here: https://discourse.wicg.io/t/custom-image-audio-video-codec-a...

Please, no! The web already makes my phone heat up enough as it is.

Just had a wild thought:

I wonder how different the web would be [1] if all data was sent in binary instead of some (text, HTML, JS) being sent in text format. Or do some servers and clients gzip the text automatically before sending it. I've heard of stuff like that (and seen HTTP headers related to it), but haven't looked deeply into it.

[1] I mean in terms of speed. But there could be tradeoffs, because, though sending (smaller) binary data would be faster, the parts of it that represented text would have to converted to/from text at either end.

Re: FLIF – Free Lossless Image Format

#122

Post by gfody »

jonsneyers wrote: post #104
pornel wrote: post #80

Everyone loves the "responsive loading" feature, but that's not even the novel thing about the format (JPEG 2000 did it even better — 16 years ago)! The novel feature of this format is better entropy coding. FLIF decoder adds interpolation to make incomplete scans look nicer than in PNG, but that's a feature of the decoder, not the file format, so there's nothing stopping existing PNG decoders from copying that featu…

I agree with all of your comments. Some remarks though: (Disclaimer: I'm the author of FLIF) - interpolation is not the only difference between PNG and FLIF in terms of progressive decoding. Another difference is that instead of doing the interlacing on RGB pixels, it does it on YCoCg pixels with priority given to Y, so intermediate steps are effectively chroma subsampled (or in other words you get luma faster at hig…

> However, you can still have a lossy encoder that uses a lossless format as a target

I wish "lossy-ness" was always an encoder parameter and never an intrinsic property of the container. The world would be a better place if we made this distinction early on. Instead every time a jpeg is edited and resaved the world gets a little more potatoey.

Re: FLIF – Free Lossless Image Format

#123

Post by AshleysBrain »

panic wrote: post #23
AshleysBrain wrote: post #5

If browsers supported APIs to allow "native" image/video/audio codecs to be written in JS, we could support new formats like this without needing any co-operation from the (very conservative) browser vendors. I wrote a proposal for this here: https://discourse.wicg.io/t/custom-image-audio-video-codec-a...

Please, no! The web already makes my phone heat up enough as it is.

The proposal I linked to suggests writing decoders using WebAssembly, so they should heat up your phone no more than the native image decoders in the browser itself.

Re: FLIF – Free Lossless Image Format

#124

Post by ericfrederich »

matheweis wrote: post #94
mistercow wrote: post #87

Earlier quoted context omitted.

It's lgpl3, which is less restrictive than gpl3.

... but still too restrictive for many (most?) commercial applications. However (link got changed?) I now see that the decoder is also available under the Apache 2.0 license, so that is useful.

If you're just using it, it isn't restrictive at all is it? You just have to say that you used it.

If you modify it, you must provide source code for the version that was distributed. Not the source code for anything else.

... unless I totally misunderstand LGPL

Re: FLIF – Free Lossless Image Format

#125

Post by gpvos »

pornel wrote: post #80

Everyone loves the "responsive loading" feature, but that's not even the novel thing about the format (JPEG 2000 did it even better — 16 years ago)! The novel feature of this format is better entropy coding. FLIF decoder adds interpolation to make incomplete scans look nicer than in PNG, but that's a feature of the decoder, not the file format, so there's nothing stopping existing PNG decoders from copying that featu…

Thanks for the note about chroma subsampling. I was already sometimes wondering why some line-art JPEGs had artifacts and others (almost) not. Is there an easy command-line argument to, say, cjpeg to do this? (The manual page doesn't seem to be clear on this?)

Re: FLIF – Free Lossless Image Format

#126

Post by Daiz »

gpvos wrote: post #125
pornel wrote: post #80

Everyone loves the "responsive loading" feature, but that's not even the novel thing about the format (JPEG 2000 did it even better — 16 years ago)! The novel feature of this format is better entropy coding. FLIF decoder adds interpolation to make incomplete scans look nicer than in PNG, but that's a feature of the decoder, not the file format, so there's nothing stopping existing PNG decoders from copying that featu…

Thanks for the note about chroma subsampling. I was already sometimes wondering why some line-art JPEGs had artifacts and others (almost) not. Is there an easy command-line argument to, say, cjpeg to do this? (The manual page doesn't seem to be clear on this?)

cjpeg -sample 1x1 does the trick. Also, I recommend using mozjpeg if you already aren't.

Re: FLIF – Free Lossless Image Format

#127

Post by r0m4n0 »

Seems cool. Slightly off topic but I hate when someone names a file format with "format" or "file" in the name. Isn't it a bit redundant to include format in the format? Something that has always bothered me about PDF.

Re: FLIF – Free Lossless Image Format

#128

Post by ktRolster »

acdha wrote: post #112
ktRolster wrote: post #91

Earlier quoted context omitted.

>Everyone loves the "responsive loading" feature, but > that's not even the novel thing about the format >(JPEG 2000 did it even better — 16 years ago)! Interlaced GIFs did it ~30 years ago.

That's not quite the same: an interlaced GIF loads with gaps and still requires a fair amount of data to be loaded before it can start displaying. JPEG 2000's approach provides successively finer detail so the entire image can be rendered after only a small percentage of the total data has been received and then it just becomes sharper as data continues to stream in. If the rollout hadn't been so unsuccessful, this w…

JPEG 2000's approach provides successively finer detail so the entire image can be rendered after only a small percentage of the total data has been received and then it just becomes sharper as data continues to stream in.

If you'd ever watched an interlaced GIF arrive over a slow connection, that's exactly how it looks.

Re: FLIF – Free Lossless Image Format

#129

Post by krick »

gfody wrote: post #122
jonsneyers wrote: post #104

Earlier quoted context omitted.

I agree with all of your comments. Some remarks though: (Disclaimer: I'm the author of FLIF) - interpolation is not the only difference between PNG and FLIF in terms of progressive decoding. Another difference is that instead of doing the interlacing on RGB pixels, it does it on YCoCg pixels with priority given to Y, so intermediate steps are effectively chroma subsampled (or in other words you get luma faster at hig…

> However, you can still have a lossy encoder that uses a lossless format as a target I wish "lossy-ness" was always an encoder parameter and never an intrinsic property of the container. The world would be a better place if we made this distinction early on. Instead every time a jpeg is edited and resaved the world gets a little more potatoey.

Maybe I am mistaken, but there's no real solution here: either you open a lossy image, edit it and save as lossless (which you easily can do), gaining in size but keeping the quality as is at this point, or (if you want to get smaller image still even after editing lossy image) you must re-encode it as lossy and make image a little more potatoey.

However, as silly as it might seem, I find having a clear distinction between media formats and unique file extension for each a huge usability improvement. A must, basically. I absolutely hate currently existing convention of distributing animated pictures as a webm or mp4 video container w/o audio track. It might seem insignificant: after all, that's what they are — audio-less video files. But because of that I can no longer mv *.gif pictures/animated/. What's even worse, I cannot make my file manager open these "moving pictures" with some other program, because there's no way it could know that it's just looped animation, and not a "real movie".

For the same reason I dislike (even though not that much) formats that can be (and are widely used as) both lossy and loseless while having the same container and file extension.

Re: FLIF – Free Lossless Image Format

#130

Post by matheweis »

ericfrederich wrote: post #124
matheweis wrote: post #94

Earlier quoted context omitted.

... but still too restrictive for many (most?) commercial applications. However (link got changed?) I now see that the decoder is also available under the Apache 2.0 license, so that is useful.

If you're just using it, it isn't restrictive at all is it? You just have to say that you used it. If you modify it, you must provide source code for the version that was distributed. Not the source code for anything else. ... unless I totally misunderstand LGPL

I am not a lawyer, but, yes, the LGPLv3 in particular is in fact quite restrictive relative to what is believed (LGPLv2 much less so).

The driving force behind the GPL-series of licenses is to maintain the GNU/Stallman freedoms [1], including "freedom to run the program as you wish, for any purpose" (0) and "to study how the program works, and change it so it does your computing as you wish" (1)

It is widely believed that any software implementing DRM on it's runtime code is incompatible with the (L)GPLv3, in particular signed firmware distributions or software distribution systems such as the Mac/iOS App Stores or Steam. The (L)GPLv3 was actually written with this in mind, with some of the authors calling it Tivoization [2] in reference to Tivo's locked down firmware.

The relevant legal jargon is in section 6 of the GPL [3], which the LGPL is built on top of, and states:

“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source.

Again I am not a lawyer, but in other words, you must cough up your signing keys (which for Mac/iOS devs is incidentally a breach of your Apple Developer contract) in order to legally distribute signed software that uses LGPL libraries (-).

[-] It seems it should be OK to distribute non-DRM protected software, but for general consumer software this kind of distribution seems to be on it's way out in a hurry.

[1] http://www.gnu.org/philosophy/free-sw.html

[2] https://en.wikipedia.org/wiki/Tivoization#GPLv3

[3] http://www.gnu.org/licenses/gpl-3.0.en.html

Post reply on HN