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

221–230 of 254 posts

Re: FLIF – Free Lossless Image Format

#221

Post by thaumasiotes »

jstummbillig wrote: post #130
thaumasiotes wrote: post #123

Earlier quoted context omitted.

Why would the lack of a progressive mode matter? How is a progressive mode better than a "loading..." spinner?

Progressive mode is better than a loading spinner in the same way that PWAs are better than a loading spinner: By getting mostly usable content in as little time as possible to the user you decrease perceived wait, you decrease time to interactive and you increase perceived loading speed (even though time to full load might be the same or slightly increased).

> By getting mostly usable content in as little time as possible to the user you decrease perceived wait

See, this is the issue. Progressive images aren't "mostly usable content"; they're vague, ugly blobs.

Re: FLIF – Free Lossless Image Format

#222

Post by mrob »

thaumasiotes wrote: post #220
mrob wrote: post #145

Earlier quoted context omitted.

In the common case that you don't actually care about the picture, you decrease actual wait, not just perceived. Progressive mode lets you ignore it before it's fully loaded.

> Progressive mode lets you ignore it before it's fully loaded. Huh? It's obviously easier to ignore the spinner than to ignore a low-res image. You've seen the spinner before.

Progressive mode doesn't need JavaScript.

Re: FLIF – Free Lossless Image Format

#223

Post by spider-mario »

bscphil wrote: post #194
jhabdas wrote: post #178

Earlier quoted context omitted.

Browsers don't need the codecs anyway. They just need Wasm and a decoder. Clients can do the work[1] until the hardware supports the goods. [1] https://git.habd.as/comfusion/fractal-forest/src/branch/mast...

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.

Re: FLIF – Free Lossless Image Format

#224

Post by spider-mario »

thaumasiotes wrote: post #221
jstummbillig wrote: post #130

Earlier quoted context omitted.

Progressive mode is better than a loading spinner in the same way that PWAs are better than a loading spinner: By getting mostly usable content in as little time as possible to the user you decrease perceived wait, you decrease time to interactive and you increase perceived loading speed (even though time to full load might be the same or slightly increased).

> By getting mostly usable content in as little time as possible to the user you decrease perceived wait See, this is the issue. Progressive images aren't "mostly usable content"; they're vague, ugly blobs.

It entirely depends on what progressive steps you define / where you stop loading.

Re: FLIF – Free Lossless Image Format

#225

Post by ksec »

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…

>I think only one good format is enough and JPEG XR might be it.

I think you meant JPEG XL here? JPEG XR [1] is a completely different thing.

[1] https://en.wikipedia.org/wiki/JPEG_XR

Re: FLIF – Free Lossless Image Format

#226

Post by spider-mario »

pmarreck wrote: post #83
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…

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 least, that’s my experience with the reference encoder. I haven’t had a chance to experiment with Apple’s implementation.

In contrast, with JPEG XL, I can simply use the high quality setting once per image and be done with it, trusting that I will get a faithful image at a reasonable size.

Re: FLIF – Free Lossless Image Format

#227

Post by ksec »

supportlocal4h wrote: post #190
jstummbillig wrote: post #130

Earlier quoted context omitted.

Progressive mode is better than a loading spinner in the same way that PWAs are better than a loading spinner: By getting mostly usable content in as little time as possible to the user you decrease perceived wait, you decrease time to interactive and you increase perceived loading speed (even though time to full load might be the same or slightly increased).

Progressive photos always irritate me. The photo comes on my screen all blurry and out of focus and I'm disappointed that the moment I thought I had captured didn't turn out. Then, 3 seconds later, the picture changes and gets slightly better. Then I'm hopeful, but disappointed again. Then i think, "maybe it's not loaded yet", so i wait and hope. Then 2 seconds later it changes again. Is it done? Is it loaded now? Wi…

The progressive mode in Jpeg and JPEG XL is quite different, because the quality is so much better your perception of it changes. Where Progressive Jpeg are literally useless before it finish loading, JPEG XL provides decent quality.

Re: FLIF – Free Lossless Image Format

#228

Post by spider-mario »

GoblinSlayer wrote: post #172
jillesvangurp wrote: post #142

Earlier quoted context omitted.

The reason we have jpeg is because png is not good enough for photos and people prefer the lossy compression of jpeg over using png. The reason other lossy formats are struggling is because they are still lossy. This promises to basically be good enough for just about anything. That sounds like a big promise but if true, there's very little stopping major browser implementing support for this. I'd say progressive dec…

File size matters for networks, not compression. Compressors have an interface where you specify desired file size and the program tries to produce a file of that size. With better compression algorithm the image will be just of a better quality, time to download and cost per GB will be the same.

> Compressors have an interface where you specify desired file size and the program tries to produce a file of that size.

That’s not really the case for JPEG XL, where the main parameter of the reference encoder is in fact a target quality. There is a setting to target a certain file size, but it just runs a search on the quality setting to use.

Re: FLIF – Free Lossless Image Format

#229

Post by loeg »

terrelln wrote: post #207
loeg wrote: post #116

Earlier quoted context omitted.

Agreed. I think I'd take zstd over xz for WORN backups anyway, just because it's pretty reliable at detecting stream corruption. (Then again, I suggest generating par2 or other FEC against your compressed backups so that's not a problem.)

Zstd has a 32-bit checksum over the uncompressed data, which is enabled by default on the CLI.

(I know you know this, as one of the principals; this is for other readers.)

And importantly, that 32-bit checksum is a pretty good checksum; a truncated XXH64(): https://tools.ietf.org/html/rfc8478#section-3 That's about as high-quality as you can expect from 32 bits. It's not, say, Fletcher-32.

Re: FLIF – Free Lossless Image Format

#230

Post by spider-mario »

eclipseo76 wrote: post #40
tangm wrote: post #15

It looks like the the creator (Jon Sneyers) has since (2019) made another image format more focused on the lossy compression, FUIF[0], which itself has been subsumed by the JPEG XL format[1]. I hope the "JPEG" branding doesn't make folks think that JPEG XL isn't also a lossless format! [0] https://github.com/cloudinary/fuif [1] https://jpeg.org/jpegxl/index.html

Last time I heard they were teaming with Google Pik for the JPEG XL format. Don't know where they are at.

Still there. Collaboration is ongoing.
Post reply on HN