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

51–60 of 254 posts

Re: FLIF – Free Lossless Image Format

#51

Post by sjwright »

floatingatoll wrote: post #31
yellowapple wrote: post #21

Earlier quoted context omitted.

The decoder-only version of the reference implementation (libflif_dec) uses the Apache 2.0 license (specifically for this reason, I'd assume). Browsers shouldn't need to encode FLIF images very often, so decoder-only would be fine for that use case.

Evaluating the efficacy of the new image codec is not possible using only a decoder. I was unable to find an APL2 JS polyfill decoder. Does one exist?

How would the evaluation of any codec be hampered by any open source license?

Re: FLIF – Free Lossless Image Format

#53

Post by Polylactic_acid »

gtirloni wrote: post #11
RcouF1uZ4gsC wrote: post #4

Seems really cool. It seems that the biggest gatekeepers for image formats are Apple and Google because of iPhone/Safari and Android/Chrome. Basically, if you want to be able to easily view the image on a mobile device or on the web, the format needs their blessing.

Well, Chromium is open source so it's open to anyone to implement it.

Its about as useful as sending a politician an email. Technically the option exists but its not of much use.

Re: FLIF – Free Lossless Image Format

#54

Post by Polylactic_acid »

sjwright wrote: post #51
floatingatoll wrote: post #31

Earlier quoted context omitted.

Evaluating the efficacy of the new image codec is not possible using only a decoder. I was unable to find an APL2 JS polyfill decoder. Does one exist?

How would the evaluation of any codec be hampered by any open source license?

Not even the most restrictive copyleft license hampers evaluation. You are literally free to do whatever you want with the program on your own hardware. Its only when you start redistributing that the license kicks in.

Re: FLIF – Free Lossless Image Format

#55

Post by BurningCycles »

jjcm wrote: post #47

Always cool to see new visual compression libraries hit the scene. That said I think the hardest part isn't the math of it, but the adoption of it. Likely the format with the best chance of overthrowing the jpg/gif/png incumbents is AVIF. Since it's based on AV1, you'd get hardware acceleration for decoding/encoding once it starts becoming a standard, and browser support will be trivial to add once AV1 has wide suppo…

>Likely the format with the best chance of overthrowing the jpg/gif/png incumbents is AVIF

I used to think the same as well, however I now think Jpeg XL is poised to be the 'winner' among next gen image codecs. It's royalty free, great lossy and lossless compression which is said to beat the competition, as well as providing a perfect upgrade path for existing jpeg's as it can losslessly recompress them into the jpeg XL format with a ~20% size decrease (courtesy of the PIK project).

It's slated for standardisation within a couple of weeks, it will be very interesting to see large-scale comparisons of this codec against the likes of AVIF and HEIF.

Re: FLIF – Free Lossless Image Format

#56

Post by Polylactic_acid »

SethTro wrote: post #2

The progressive loading video is great!

This is something I wish was used on the web. Imagine instead of creating a high compression image for use on a web page and then having a link for the full res one, you could just say "Load this image at 60%" and if users right click and save it would download the entire image.

Re: FLIF – Free Lossless Image Format

#57

Post by pier25 »

hug wrote: post #45
andrewzah wrote: post #33

Earlier quoted context omitted.

Good thing we’re discussing JavaScript library sizes and not cars in random contexts, then. 77kb gzipped is massive considering it’s only doing one thing. If I want my website to load in ~100 milliseconds or less (or even 1 second or less!), I absolutely do need to pay attention to all the libraries I add. I can and do criticize software developers for making hideously bloated websites because they don’t pay attentio…

So it turns out that the use-case for a polyfill of a 77KB image decoder isn't particular suited to a site you want to load in sub 100ms. Oddly, though, that's not the only usecase in the world, and there are circumstances where saving ~30% on every image load turns out to be significantly more efficient than not loading a 77KB JS library. In other news, I also chose to forgo adding a 15 lb. fuel pump to my go-kart,…

You are missing the point. It's not only about the transferred bytes. You have to actually execute 77kB to display an image. Every image.

Re: FLIF – Free Lossless Image Format

#58

Post by hug »

pier25 wrote: post #57
hug wrote: post #45

Earlier quoted context omitted.

So it turns out that the use-case for a polyfill of a 77KB image decoder isn't particular suited to a site you want to load in sub 100ms. Oddly, though, that's not the only usecase in the world, and there are circumstances where saving ~30% on every image load turns out to be significantly more efficient than not loading a 77KB JS library. In other news, I also chose to forgo adding a 15 lb. fuel pump to my go-kart,…

You are missing the point. It's not only about the transferred bytes. You have to actually execute 77kB to display an image. Every image.

I am most assuredly not missing the point. Your use-case is not my use-case.

I sometimes render 50mb PNGs. The execution of decoder is insignificant compared to everything else.

Also, my go-kart also gets more miles to the gallon than NASCAR team cars.

Re: FLIF – Free Lossless Image Format

#59

Post by userbinator »

I wonder how it compares with simply LZMA'ing (i.e. 7zip) a BMP. In my experience that has always been significantly smaller than PNG (which is itself a low bar --- deflate/zlib is a simple LZ+Huffman variant which is nowhere near the top of general-purpose lossless compression algorithms.)

Along the same lines, I suspect BMP+LZMA would likely be beaten by BMP+PPM or BMP+PAQ, the current extreme in general-purpose compression.

Re: FLIF – Free Lossless Image Format

#60

Post by pier25 »

hug wrote: post #58
pier25 wrote: post #57

Earlier quoted context omitted.

You are missing the point. It's not only about the transferred bytes. You have to actually execute 77kB to display an image. Every image.

I am most assuredly not missing the point. Your use-case is not my use-case. I sometimes render 50mb PNGs. The execution of decoder is insignificant compared to everything else. Also, my go-kart also gets more miles to the gallon than NASCAR team cars.

> I sometimes render 50mb PNGs. The execution of decoder is insignificant compared to everything else.

Fair point but you have to admit that is a very niche use case.

Have you compared the execution to native performance? Even decoding a 50MB JPEG in Chrome with turbojpeg is going to be a hard pill to swallow.

Post reply on HN