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

Free Lossless Image Format

flif.info

Post reply on HN
Print view View original

271–280 of 374 posts

Re: Free Lossless Image Format

#271

Post by matheweis »

joelthelion wrote: post #186

How cpu-intensive is it? Decompression speed can be an issue, especially on mobile.

Here is what he says about that: https://boards.openpandora.org/topic/18485-free-lossless-ima...

Decode speed to restore the full lossless image and write it as a png is not so good: about 0.75s for a median file, 0.25s for a p25 file, 1.5s for a p75 file. That's roughly 3 to 5 times slower than the other algorithms. However, decoding a partial (lossy) file is much faster than decoding everything, so in a progressive decoding scenario, the difference would not be huge.

There's still room for optimizing the encode/decode speed, but it's not very useful to do that before the bitstream is somewhat finalized. The prototype implementation I have now is not extremely fast, but at least it's in the right ballpark. Most likely even an optimized decoder will still be slower than an optimized PNG decoder, but the difference will be small enough to not matter much (certainly compared to the time won by downloading less bytes). comradekingu likes this

Re: Free Lossless Image Format

#272

Post by magicalist »

DiThi wrote: post #269
magicalist wrote: post #256

Earlier quoted context omitted.

To be fair, that's not the same thing either. A thumbnail is resampled in a way to resemble the original at a smaller size. This will be resampled with (more or less) nearest neighbor, which means lots of aliasing and possibly looking nothing like the original, depending on the subject.

I haven't checked, but I suspect that a better down scaling method can be used while still being compatible with the same decoding algorithm.

hmm, how could it be? The pixels values have to fit into the eventual reconstructed image. If the values were different than any pixels found in the final image, it wouldn't be progressively loading, it would have several different size images embedded in it.

Re: Free Lossless Image Format

#273

Post by CamperBob2 »

spullara wrote: post #188

One of the least interesting parts of this is that it is GPL. Someone should reimplement it with a BSD license so it can be used more widely. AFAIK & IANAL, but I don't think you could integrate this with FF, Chrome, Safari or IE.

Seems like the mistake the author is making is announcing something as a "product" when it's really still a "project."

In principle, using the GPL license for the reference code is OK if his intent is to encourage other people to build more refined, practical, and performant implementations. But the real problem with his choice of license is that a lot of people can't even look at the code for fear of tainting themselves legally. Given that there is no desperate market demand for a better-PNG-than-PNG, it wasn't a good idea to handicap the proposed format by saddling it with various restrictions and legal minefields.

If the reference code is strictly of proof-of-concept quality, which it sounds like it is, then there was no reason not to use a more permissive license.

Re: Free Lossless Image Format

#274

Post by jonsneyers »

magicalist wrote: post #256
jo909 wrote: post #155

Earlier quoted context omitted.

But that is not the same. That is a small, but fixed size, second version of the image, embedded into the same file. With FLIF you simply read the first N bytes of the full image and have a resonable preview. You choose how big or small N has to be, depending on the size of the thumbnail you want to show. Maybe first read N bytes for each image to get a quick but rough preview, then repeatedly read a few bytes more t…

To be fair, that's not the same thing either. A thumbnail is resampled in a way to resemble the original at a smaller size. This will be resampled with (more or less) nearest neighbor, which means lots of aliasing and possibly looking nothing like the original, depending on the subject.

That's true. I tried a variant where the resampling would be better, but while it is possible, it hurts the compression rate significantly. At the level of a single step: if you have two pixels A and B that are both 8-bit numbers, then if you want some lossless way to store both (A+B)/2 (an 8-bit number) and enough information to restore both A and B, it will take at least one extra bit (9 bits, e.g. to store B and the least significant bit of A+B). So a 24-bit RGB image would become a 27-bit images when interlaced with better resampling (except for the very first pixel, which would need only 24 bits).

In practice, the simplistic resampling is not likely to be an issue -- of course you can create a malicious image which is white on the even rows and black on the odd rows, and then all previews would be black while they should be grey. But most of the actual images are not like that -- e.g. photographs. You can just decode at somewhat higher resolution and scale down from that. (You have to start from a power-of-two scaled image anyway.) Also note that Y is emitted at more detail earlier than chroma, so most of the error will be in those less important chroma channels. Other than that it's just Adam7 interlacing, but with no upper bound on the number of passes (so you could call it Adam-infinity interlacing).

Re: Free Lossless Image Format

#275

Post by zyxley »

acdha wrote: post #176
rplnt wrote: post #75

Earlier quoted context omitted.

This would be great. A lot of "responsive" sites nowadays use only one image as well, the highest resolution available. So you are downloading that 4K jpeg whether you are on mobile or on a desktop.

Your example also shows why it needs to be left up to the browser: downloading a large JPEG makes more sense on an iPhone 6S+ with a 1080p display and LTE than the 1024x768 computers at the local school sharing a basic cable modem. The part which would really make sense for this would be something like an extension to or which would allow you to provide the byte ranges for each resolution so the client could issue a…

I wonder if it would be feasible to have browser functionality that starts the download, then stops it once it has enough data to make an image the width of the element on the page. (Maybe then continuing the download later if it's resized larger?)

Re: Free Lossless Image Format

#276

Post by acdha »

zyxley wrote: post #275
acdha wrote: post #176

Earlier quoted context omitted.

Your example also shows why it needs to be left up to the browser: downloading a large JPEG makes more sense on an iPhone 6S+ with a 1080p display and LTE than the 1024x768 computers at the local school sharing a basic cable modem. The part which would really make sense for this would be something like an extension to or which would allow you to provide the byte ranges for each resolution so the client could issue a…

I wonder if it would be feasible to have browser functionality that starts the download, then stops it once it has enough data to make an image the width of the element on the page. (Maybe then continuing the download later if it's resized larger?)

You could certainly build that in as a heuristic similar to how many browsers implement : issue Range requests for a certain chunk size and stop once you have enough data. It's not as efficient as being able to get it all in one go but if you have a progressive image format that might be a better experience if it can start rendering quickly and fill details later.

Re: Free Lossless Image Format

#277

Post by URSpider94 »

I don't see how the author can claim that FLIF is "unencumbered by software patents," only that he/she hasn't obtained patents on the work already. This has traditionally been one of the problem with so-called "free" image formats -- it's not that the standards body or creator asserts patent rights, it's that other inventors claim that their pre-existing patents cover the new format.

Re: Free Lossless Image Format

#278

Post by jonsneyers »

colanderman wrote: post #185
mthoms wrote: post #172

Earlier quoted context omitted.

If compared to the original yes, but that's apples to oranges. They are different resolutions. It'd be more accurate to compare it to a pre-generated resizing of the original image (at the same effective resolution as the "half downloaded" FLIF).

A compressed image which does not reconstitute to the original image is by definition lossy. You can't scale a PNG down by 25% and call that "lossless compression". Though I'll gladly take your logic and call the first 1/64th of a progressive JPEG lossess (which it is, since at that point you only have the DC offsets of basic blocks, which undergo no lossy compression).

I think JPEG's color transform is lossy, so even those basic blocks are somewhat lossy. A better approximation of the entire 8x8 block than the exact pixel at the top-left position of the block, which is what FLIF and PNG with Adam7 interlacing do, but still lossy. If you would take an image, magnify it by a factor of 8 in both directions so each pixel gets blown up to an 8x8 block, then convert it to JPEG, there is still some information lost.

Re: Free Lossless Image Format

#279

Post by zyxley »

andruby wrote: post #251
jonsneyers wrote: post #232

To clarify: at the moment FLIF is licensed under the GPL v3+. Once the format is finalized, the next logical step would be to make a library version of it, which will be most probably get licensed under the LGPL v3+, or maybe something even more permissive. There is not much point in doing that when the format is not yet stable. It's not because FLIF is GPL v3+ now, that we can't add more permissive licenses later. A…

It would be useful if the metadata would include hints for responsive downloads. Eg: For 1/4 resolution download the first 10,000 bytes, for 1/2 resolution download the first 25,000 bytes.

This is a really good idea.

Re: Free Lossless Image Format

#280

Post by grumblestumble »

a_t48 wrote: post #211
mixmastamyk wrote: post #203

Earlier quoted context omitted.

Interesting, just last week I had a use for lowsrc for the first time in years and tried to use it, only to find out it had been removed from all browsers a while back.

http://www.w3schools.com/jsref/prop_img_lowsrc.asp ?

please be aware that w3schools is a terrible resource loaded with inaccuracies and misinformation. It's the National Enquirer of web development. I'd recommend using MDN instead: https://developer.mozilla.org/en-US/.
Post reply on HN