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

191–200 of 254 posts

Re: FLIF – Free Lossless Image Format

#191

Post by dspillett »

DagAgren wrote: post #188
theon144 wrote: post #159

Earlier quoted context omitted.

Uh, LGPL explicitly doesn't prevent even proprietary software from using the encoder?

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.

Re: FLIF – Free Lossless Image Format

#192

Post by nine_k »

theon144 wrote: post #159
DagAgren wrote: post #156

Earlier quoted context omitted.

Is it better that no tools will actually be able to export the format? Also, a GPL-licensed encoder will in no way stop incompatible extensions.

Uh, LGPL explicitly doesn't prevent even proprietary software from using the encoder?

Proprietary software can include the encoder. This is fine.

But any changes to the encoder itself remain under LGPL and get published. This is the point.

Re: FLIF – Free Lossless Image Format

#193

Post by dspillett »

0xff00ffee wrote: post #70

Isn't making it LGPL a problem? That means anything that touches it becomes LGPL, right?

> That means anything that touches it becomes LGPL, right?

Wrong, mostly.

Any changes you make to the encoder library itself would be LGPL, but if all you are doing is calling the library from other code then that is not an issue.

If you make a change to the library, even as part of a larger project, nothing else but that change is forced to be LGPL licensed. If your update is a bit of code you use elsewhere, as long as you own that code it does not force the elsewhere to be LGPL - while you are forced to LGPL the change to the library there is no stipulation that you can't dual license and use the same code under completely different terms outside the library.

Re: FLIF – Free Lossless Image Format

#194

Post by bscphil »

jhabdas wrote: post #178
gardaani wrote: post #177

Earlier quoted context omitted.

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…

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.

Re: FLIF – Free Lossless Image Format

#195

Post by adev_ »

sd314 wrote: post #115
nine_k wrote: post #39

Earlier quoted context omitted.

One can use C++ in radically different ways. I would appreciate a reference implementation in Rust. Or, if not intended for immediate linking, in something like OCaml or ATS. Clarity and correctness are important in a reference implementation, and they are harder to achieve using C.

Best practices and rules in C++ are changing on a daily basis as the language is still evolving. On the other hand, C is much more readable for many programmers and researchers even with a little programming experience. Moreover, C is more portable and helps the reference implementation be quickly adapted for production or being used by the other compatible languages.

> Best practices and rules in C++ are changing on a daily basis as the language is still evolving.

Yeah "daily", C++ standard evolves every 3 years minimum and most API are still C++11 meaning 9 years old. "Daily" right ?

This is FUD. Without even mentioning that any C++lib can expose a C API.

Re: FLIF – Free Lossless Image Format

#196

Post by TheRealPomax »

thaumasiotes wrote: post #123
Scaevolus wrote: post #79

Earlier quoted context omitted.

This presentation covers why AVIF isn't a great replacement for JPEG-- mostly that it's slow, complicated, and lacks a progressive mode. https://www.slideshare.net/cloudinarymarketing/imagecon-2019...

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

I'd by far rather see several full article-appropriately sized sideline image at only progression step 1 or 2 out of 5 or 6, than several empty boxes all showing spinners while the images load in.

Plus I'd love the ability to say "I'm on a low bandwidth, $$$ per megabyte network, stop loading any image after the first iteration until I indicate I want to see the full one" because you almost never need full-progression-loaded images. They just make things pretty. Having rudimentary images is often good enough to get the experience of the full article.

(whether that's news, or a tutorial, or even an educational resource. Load the text and images, and as someone who understands the text I'm reading, I can decide whether or not I need the rest of that image data after everything's already typeset and presentable, instead of having a DOM constantly reflow because it's loading in more and more images)

Re: FLIF – Free Lossless Image Format

#197

Post by kragen »

lisper wrote: post #108
kragen wrote: post #105

Earlier quoted context omitted.

Yes, of course it's impossible to losslessly compress all possible images by even a single bit. But how predictable is the content of typical images? How much structure do they have? They certainly have a lot more structure than PNG or even JPEG exploits. Some of the “loss” of lossy JPEG is just random sensor noise, which places a lower bound on the size of a losslessly compressed image, but we have no idea how much.

Doesn't matter. Whatever you do to compress losslessly you can always do better if you're allowed to discard information. And the structure is part of the reason. For lossless compression you have to keep all the noise, all the invisible details. With lossy compression you're allowed to discard all that.

Yes, that's what I said.

Re: FLIF – Free Lossless Image Format

#198

Post by TheRealPomax »

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…

On the other hand, it also doesn't constantly change the DOM, moving you across the page because images above what you're reading are getting swapped in and now you're looking at the paragraph above the one you were reading.

and again.

oh, and again.

and-

Re: FLIF – Free Lossless Image Format

#199

Post by TheRealPomax »

mrob wrote: post #145
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).

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.

true progressive mode actually gives you something usable before it's fully loaded, to the point where "not fully loading" can be entirely acceptable. If all images load "first iteration" first, you have a stable DOM that won't need to reflow in any way as each image goes through the rest of its progressive layers. And having a nice setting that says "only load up to X on slow networks" and "require image click to load past first iteration" would be godsend, even on gigabit connections. If I could bring the size and load time for modern webpages back down to "maybe a few 10s of kb" and "immediate" rather than "2.9MB and a second or two", I'd happily turn those options on.

Re: FLIF – Free Lossless Image Format

#200

Post by TheRealPomax »

Pretty cool, but where are the links to the issues on mozilla, chromium, webkit, and edge's bug trackers to add native support for it?

As an unencumbered open source technology, it should breeze through legal's OK pretty quickly, and getting it integrated could certainly take a bit of time, but should just be part of the FLIF roadmap itself, if the idea is to actually get this adopted.

You don't set out to come up with "one format to rule them all" and then not also go "by implementing libflif and sending patches upstream to all the open source browsers that we want to see it used in" =)

Post reply on HN