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

71–80 of 153 posts

Re: FLIF – Free Lossless Image Format

#71

Post by Veedrac »

teh_klev wrote: post #46

Do any of these newer/experimental schemes, such as this one, take into account other factors such as CPU load before declaring themselves as "better". For example this project seems pretty cool, but there's no data on how CPU bound, memory bound, I/O bound its decompression algorithm is. I guess what I'm asking is, if I hit a web page with 20 images @ 100k per image is it going to nail one or more cores at 100% and…

From the page,

> Encoding and decoding speeds are acceptable, but should be improved

From elsewhere:

https://news.ycombinator.com/item?id=10318161

though the above is quite old.

Re: FLIF – Free Lossless Image Format

#73

Post by vanderZwan »

Zardoz84 wrote: post #67
vanderZwan wrote: post #47

Earlier quoted context omitted.

> (so, waste of storage space) To be fair, given the speed at which storage space has grown over the years, it's not really something to worry about in the context of archiving material for future generations (which is very different than being able to quickly download something on the internet now , for example)

Well, when you do service archiving material to the web, the storage cost isn't irrelevant Also, big files means more network traffic between our webservers and the storage servers. Plus this format have other interesting features, like tiled rendering or the progressive download. Sadly, we must handle huge TIFFs and generate jpeg miniatures and tilesets from it, if not serving it online would be very painful. Note:…

Ah ok, cool! But then you're talking about trying to meet both goals I mentioned at the same time ;)

But I guess you handle it similar to how Archive.org does it, with a large TIFF as a poorly compressed but lossless "base case" and other compression formats for the web?

Re: FLIF – Free Lossless Image Format

#74

Post by teh_klev »

dave2000 wrote: post #68
teh_klev wrote: post #46

Do any of these newer/experimental schemes, such as this one, take into account other factors such as CPU load before declaring themselves as "better". For example this project seems pretty cool, but there's no data on how CPU bound, memory bound, I/O bound its decompression algorithm is. I guess what I'm asking is, if I hit a web page with 20 images @ 100k per image is it going to nail one or more cores at 100% and…

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.

Re: FLIF – Free Lossless Image Format

#76

Post by teh_klev »

Veedrac wrote: post #71
teh_klev wrote: post #46

Do any of these newer/experimental schemes, such as this one, take into account other factors such as CPU load before declaring themselves as "better". For example this project seems pretty cool, but there's no data on how CPU bound, memory bound, I/O bound its decompression algorithm is. I guess what I'm asking is, if I hit a web page with 20 images @ 100k per image is it going to nail one or more cores at 100% and…

From the page, > Encoding and decoding speeds are acceptable, but should be improved From elsewhere: https://news.ycombinator.com/item?id=10318161 though the above is quite old.

Not trying to be obtuse, but that's just a subjective measure of how quick or not their algo is. It doesn't address (nor in the linked HN discussion) how efficient it is in terms of burning up CPU and battery.

Re: FLIF – Free Lossless Image Format

#78

Post by formula1 »

dave2000 wrote: post #68
teh_klev wrote: post #46

Do any of these newer/experimental schemes, such as this one, take into account other factors such as CPU load before declaring themselves as "better". For example this project seems pretty cool, but there's no data on how CPU bound, memory bound, I/O bound its decompression algorithm is. I guess what I'm asking is, if I hit a web page with 20 images @ 100k per image is it going to nail one or more cores at 100% and…

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 calculations seem small, and likely are more often than not. But you add enough of these things up and all of a sudden the cpu must hit 100% for the time of 30+ images

Re: FLIF – Free Lossless Image Format

#79

Post by formula1 »

teh_klev wrote: post #76
Veedrac wrote: post #71

Earlier quoted context omitted.

From the page, > Encoding and decoding speeds are acceptable, but should be improved From elsewhere: https://news.ycombinator.com/item?id=10318161 though the above is quite old.

Not trying to be obtuse, but that's just a subjective measure of how quick or not their algo is. It doesn't address (nor in the linked HN discussion) how efficient it is in terms of burning up CPU and battery.

If it takes a long time, it probably means that there is a lot to calculate. If theres a lot to calculate, probably means the cpu is running full speed to get through it

Re: FLIF – Free Lossless Image Format

#80

Post by pornel »

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

Note that it's generally not desirable to have FLIF used on the Web. A decent-quality JPEG will load at full resolution quicker than it takes FLIF to show a half-resolution preview.

FLIF is a lossless format, and lossless is a very hard and costly constraint. Images that aren't technically lossless, but look lossless to the naked eye can be half the size.

e.g. Monkey image from https://uprootlabs.github.io/poly-flif/ is 700KB in FLIF, but 300KB in high-quality JPEG at q=90 without chroma subsampling (i.e. settings good even for text/line-art), and this photo looks fine even at 140KB JPEG (80% smaller than FLIF).

So you want FLIF for archival, editing and interchange of image originals, but even the best lossless format is a waste of bytes when used for distribution to end users.

Post reply on HN