FLIF – Free Lossless Image Format • Hacker News Board

Re: FLIF – Free Lossless Image Format

#91

Post by ktRolster » Mon, Mar 07, 2016, 4:03 PM UTC

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…

  >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.

Re: FLIF – Free Lossless Image Format

#92

Post by dave2000 » Mon, Mar 07, 2016, 4:03 PM UTC

formula1 wrote: post #78

dave2000 wrote: post #68

Earlier quoted context omitted.

It says very clearly a number of times that it's better in terms of compression ratio.

Reason why your downvoted is because compression can often add to computation. An exanple would be - I have a pallet of bytes, this will cause colors to be stored in a 8 bit integer instead of a 32 bit one (8 for r,b,g,a) - every color now adds alook up to that memory address - I turn every color sequence possible into a numerator + denominator pair than 4 bytes) is reached get the value of that digit. These types of…

I don't care about my score. I could have guessed why though. People not reading things properly. I was taking point with the observation that the site said it was better. I pointed out that it didn't say that, just that the compression ratio was better.

Re: FLIF – Free Lossless Image Format

#93

Post by ktRolster » Mon, Mar 07, 2016, 4:06 PM UTC

ipunchghosts wrote: post #89

This is probably the 3rd "replacement" for JPEG I have seen on HN in the last few years. None of these formats have been supported by common browsers. When will this stuff start making its way to the desktop?

It's good that browsers aren't too quick to add support for new image formats, otherwise we'd have a lot of bloatware for non-optimal image formats that few people use.

Re: FLIF – Free Lossless Image Format

#94

Post by matheweis » Mon, Mar 07, 2016, 4:13 PM UTC

mistercow wrote: post #87

matheweis wrote: post #86

I'm curious about patent/ licensing restrictions. From what I gather it is patent free and the implementation is GPLv3? Does this mean someone else could make a compatible encoder/decoder with a less restrictive license?

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.

Re: FLIF – Free Lossless Image Format

#95

Post by mrob » Mon, Mar 07, 2016, 4:13 PM UTC

I'd like to see some comparisons with palettized PNGs. All the demo images for poly-flif use more than 256 colors, but diagrams and line art sometimes use 256 colors or less, which means they can be stored in an 8-bit palettized PNG losslessly. People often forget about this when optimizing PNG sizes, and most graphics software saves as RGB by default even when the image will fit in 8-bit palettized.

Re: FLIF – Free Lossless Image Format

#96

Post by pmontra » Mon, Mar 07, 2016, 4:22 PM UTC

matzipan wrote: post #13

chris_wot wrote: post #2

I wonder if IE will adopt it? Firefox and Chrome are very responsive, Microsoft not so much.

How often do you need lossless images on the web? Almost never.

All those animated GIFs around the web, plus the images were JPEG artefacts would be noticed. Examples:

The Y logo in the top left of this page is a GIF.

All the logos at http://www.ycombinator.com/ plus the six images below More Quotes are PNGs.

Re: FLIF – Free Lossless Image Format

#97

Post by techdragon » Mon, Mar 07, 2016, 4:25 PM UTC

jaredcheeda wrote: post #49

colejohnson66 wrote: post #43

Earlier quoted context omitted.

Not to mention TIFF supports layers. From a skim of the homepage, this doesn't.

FLIF allows for animation, and it is very possible to interpret each frame of the animation as it's own layer. This would year the same lossless quality as a TIFF at a much smaller file size. Though FLIF isn't intended to be used for this purpose, neither was PNG, and that didn't stop Fireworks from abusing that format and adding layering. The same could be done by someone who wants to add a little meta data to the f…

A bigger question here is why not build FLIF as a document format using an established container? Why not use something established, mainstream and non controversial like TIFF as the container and FLIF as the codec. I'm kind of sick of this "new file format and file extension for no good reason" crap. MKV as a container and I dont care about codec because FFMPEG/VLC/etc support all the codecs is great, it hides all the complexity and enables codec experimentation without hassle. FLIF is an image encoding/decoding scheme that would be completely compatible inside a TIFF image if implemented correctly.

Why do I care about having a "dot flif" file when the new codec is the important improvement?

Is '*.flif' actually a good thing?

Personally I don't think so, mainly because without a mechanism to drive adoption in browsers, the format offers very little value to anyone over existing formats. TIFF would be a decent solution to that problem. ... And the fact that FireFox has marked TIFF support as WONTFIX is actually pretty indicative of how unlikely they are to support a new format such as FLIF. Sad but true. From what I already see of the FireFox support thread for FLIF, its not going to happen any time soon.

Re: FLIF – Free Lossless Image Format

#98

Post by teh_klev » Mon, Mar 07, 2016, 4:33 PM UTC

dave2000 wrote: post #92

formula1 wrote: post #78

Earlier quoted context omitted.

Reason why your downvoted is because compression can often add to computation. An exanple would be - I have a pallet of bytes, this will cause colors to be stored in a 8 bit integer instead of a 32 bit one (8 for r,b,g,a) - every color now adds alook up to that memory address - I turn every color sequence possible into a numerator + denominator pair than 4 bytes) is reached get the value of that digit. These types of…

I don't care about my score. I could have guessed why though. People not reading things properly. I was taking point with the observation that the site said it was better. I pointed out that it didn't say that, just that the compression ratio was better.

> People not reading things properly

I did read the article twice and thoroughly, all I sawmentioned was "Encoding and decoding speeds are acceptable, but should be improved" . That doesn't address the points I raised in my original post if you were to read it properly.

Re: FLIF – Free Lossless Image Format

#99

Post by tomtheguvnor » Mon, Mar 07, 2016, 4:40 PM UTC

monkmartinez wrote: post #77

tomtheguvnor wrote: post #75

Apparently it relies on a novel new "middle out" compression algorithm.

Here is the paper[1] regarding the "middle out" or "tip to tip efficiency" algorithm. [1] http://www.scribd.com/doc/228831637/Optimal-Tip-to-Tip-Effic...

Some people have WAY too much time on their hands...

Re: FLIF – Free Lossless Image Format

#100

Post by dalke » Mon, Mar 07, 2016, 4:44 PM UTC

teh_klev wrote: post #74

dave2000 wrote: post #68

Earlier quoted context omitted.

It says very clearly a number of times that it's better in terms of compression ratio.

It says: "Encoding and decoding speeds are acceptable, but should be improved" But that doesn't address resource usage such as CPU, battery.

It's hard for a single author/developer to fully explore solution space.

For example, it could be that Javascript acquires special primitives to decode these images, or that they be a common Javascript engine extension, with a polyfill fallback.

It could be that these extensions make effective use of CPU-specific instructions, or that the underlying hardware contains special silicon to decode these images, similar to how there are H.264 decoder chips.

It's therefore possible to do the power consumption analysis, but the results would not really indicate something fundamental about the algorithm but only its current implementation. People are willing to work on improved implementations if there are other factors, like smaller size, which suggest it's worthwhile to investigate.