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

241–250 of 254 posts

Re: FLIF – Free Lossless Image Format

#241

Post by sk65535 »

gardaani wrote: post #177
BurningCycles wrote: post #55

Earlier quoted context omitted.

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

I hope that JPEG XL will be simpler than the competitors. If it's compression ratio is similar to AVIF and it can do HDR, then I'll all for it! AVIF (and its image sequences) seems to be fairly complicated. Here's few comments [1] about it: "Given all that I'm also beginning to understand why some folks want something simpler like webp2 :)" "Despite authoring libavif (library, not the standard) and being a big fan of…

WebP version 2 is in the work at AOM: https://www.youtube.com/watch?v=zogxpP2lm-o

It is complementary to AVIF (which targets photo capture more than delivery over the web).

WebP2 is like WebP: keep it simple, with only useful and efficient features, no fancy stuff. And aim at very low bitrate, it's the current trend, favoring image size over pristine quality.

Progressive rendering uses ~3x more resources on client side. So, instead, better have efficient 300-bytes thumbnails in the header.

Re: FLIF – Free Lossless Image Format

#242

Post by DagAgren »

dspillett wrote: post #191
DagAgren wrote: post #188

Earlier quoted context omitted.

Not explicitly, but in practice, it does. It is often not viable to jump through the hoops required to do it. That is, if your lawyers will even let you try.

> It is often not viable to jump through the hoops required to do it. Having it as a dynamic library isn't that problematic a hoop is it? > That is, if your lawyers will even let you try. This may be a genuine issue. Many have a strict "nothing related to GPL" policy driven at least partly by misunderstanding or paranoia.

Having it as a dynamic library is not enough. It has to be a dynamic library tgat you can replace. This doesn’t work when, for instance, distributing through many app stores.

Re: FLIF – Free Lossless Image Format

#243

Post by stingraycharles »

jonsneyers wrote: post #214
marton78 wrote: post #148

Earlier quoted context omitted.

JPEG XL is a terrible name for something that claims to produce extra small results.

It may not be the best name, but it sure is better than the names of the projects it was based on: PIK and FUIF. At least if you speak Dutch. A "pik" is a penis and a "fuif" is a party, so the combination would be the "penis party" image codec. I prefer "JPEG XL". The etymology of the name "XL" is as follows: JPEG has called all its new standards since j2k something that starts with an X: XR, XT, XS (S for speed, sin…

There might be an explanation around it, but I find it not much better than Apple with their iPhone XS. I agree that XL is a bad name, and I don’t think that “pik fuif” would matter a lot (I’m also Dutch).

Could have been e.g. JPEG PF or JPEG LTS.

Re: FLIF – Free Lossless Image Format

#244

Post by JyrkiAlakuijala »

spider-mario wrote: post #226
pmarreck wrote: post #83

Earlier quoted context omitted.

Is this superior to HEIF and H.265 other than licensing being freer?

It’s faster (especially to encode), and in my opinion, better tuned for high quality. H.265 can give a “usable” image in a relatively small file size, but it sometimes takes a surprising amount of additional bytes to get rid of the somewhat oversmoothed aspect, and that additional amount can vary a lot from one image to the next, so with the current implementations, you have little choice but to verify visually. At l…

This is an insightful comment.

Re: FLIF – Free Lossless Image Format

#245

Post by JyrkiAlakuijala »

yjftsjthsd-h wrote: post #92
kccqzy wrote: post #89

Earlier quoted context omitted.

That's exactly what I thought. About ten years everyone is rushing to distribute large downloads in xz format. These days some have started to move away from it just because how slow it is to compress and decompress.

That's part of the benefit of zstd, as I understand it; near-xz compression ratios but much faster.

Two good options here: Brotli gets within 0.6 % of the density of lzma, zstd within 5 %. Brotli is 5x faster than lzma and zstd 9x. I'm somewhat surprised that some people migrated from lzma to zstd, without considering brotli.

Re: FLIF – Free Lossless Image Format

#246

Post by JyrkiAlakuijala »

janwas wrote: post #206
andrius4669 wrote: post #175

Earlier quoted context omitted.

yeah. it's partially based on https://github.com/cloudinary/fuif so if you use that part of JPEG XL you'll get something similar out of it.

Yes indeed, for the lossless mode (based on tech by the same author) we're seeing about 45-82% of GIF size, and 60-80% of (A)PNG depending on content.

Also other famous compression gurus, including Alex Rhatushnyak and Lode Vandevenne contributed to the lossless side of JPEG XL.

Re: FLIF – Free Lossless Image Format

#247

Post by rurban »

dTal wrote: post #173
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…

Worth noting that it's not really "new" as such, being over 4 years old. It still doesn't seem to have hugely caught on... That said, lossless codecs have it easier because you can freely transcode between them as the mood takes you, with no generation loss, so there's less lock-in. For example, FLAC is dominant in audio, but there are a variety of other smaller lossless formats which still see use. Nobody much minds…

Because it was replaced by FUIF as a successor, then Google's PIK, then JPEG XL.

Re: FLIF – Free Lossless Image Format

#248

Post by floatingatoll »

adev_ wrote: post #209
floatingatoll wrote: post #202

Earlier quoted context omitted.

Do you have a source for that? Could you please provide supporting evidence for your view that is a consensus? Where is the documentation explaining your “static link” proposal and why it’s been endorsed by lawyers as a permitted approach? What was the response from the GPL team when they were asked to comment on this circumvention of their license? Will they be patching GPLv3 to correct it?

> Could you please provide supporting evidence for your view that is a consensus? Consensus is what is admitted by most actors, specially including the main interested actor : The FSF and the GNU project. And I do not remember reading any communication of the FSF or the GNU project saying it is forbidden. Currently the license text is very explicit about what you can do and not do if you link statically. > 0) Convey…

So, for macOS — where static executables aren't viable — you would need to ship all pre-linking components and then let the user assemble them.

You could ship those elements in a signed DMG, but it would be up to the user to assemble them, and so the user would not be able to codesign them under your developer ID.

Since they would not be able to compile and run the app as your developer ID — it would have to be theirs, since they're the ones linking it — the app won't have access to any ID-linked features such as iCloud syncing, Apple push notifications services, and so forth.

So that would imply that it's outright impossible to use this "static linking" bypass on MacOS when code signing is enabled, since you can't falsify the original signature's private key in order to sign the executable and gain access to signature-enforced platform capabilities.

I guess it would probably work fine for Linux folks, and you could always sign it with your own ID, but this certainly is not "compatible with signed executables" — to answer the original question asked upthread.

Re: FLIF – Free Lossless Image Format

#249

Post by eru »

janwas wrote: post #204
eru wrote: post #161

Earlier quoted context omitted.

If you can get all the pixels back exactly, getting the original jpeg back would only require a very small amount of extra data. But it might be more hassle than it's worth it to create the code and algorithms to do so.

Hi, we indeed support byte for byte reconstruction of the original JPEG codestream.

Interesting!

Btw, if memory serves right, Google Photos deliberately gives you back the same pixels but not the same JPEG codestream bits under some circumstances. That's too make it harder to exploit vulnerabilities with carefully crafted files.

Re: FLIF – Free Lossless Image Format

#250

Post by bscphil »

spider-mario wrote: post #223
bscphil wrote: post #194

Earlier quoted context omitted.

The example you linked to is pretty telling, because not only do the BPG images decode more slowly than natively supported images, the javascript decoding approach apparently breaks the browser's (Firefox's) color management. I think native support is needed for newer codecs to be viable for more than simple demos.

Chrome appears to interpret the canvas as sRGB and to convert from that, but that means that images decoded that way are effectively limited to sRGB until the canvas API allows specifying other colorspaces.

In Firefox, these canvas images appear stretched into the full gamut of the monitor (oversaturated), even though I have a color profile and have full color management enabled in about:config.
Post reply on HN