Live data from Hacker News

Free Lossless Image Format

flif.info

241–250 of 374 posts

Re: Free Lossless Image Format

#242

Earlier quoted context omitted.

There's also progressive PNGs. Progressive JPEGs have the advantage that they increase compression ratio (though they're more expensive to decode, as you need multiple passes and refresh)

They increase compression ratio? That's counter-intuitive. You're effectively imposing an ordering requiring certain information to be available first, so you'd expect the compression be at most as good as non-progressive. I guess the changed ordering makes the statistics simpler and easier to compress, or something like that.

The downside is memory usage during compression. A non-progressive jpeg can be compressed locally but a progressive encoding requires the whole image. But this is only a small downside.

(Converting JPEG images to progressive format is one of the optimizations mod_pagespeed makes.)

Re: Free Lossless Image Format

#243
post #74

Earlier quoted context omitted.

you don't have to use the code, you can (and probably want to) implement the code yourself.

Why do you really want to duplicate work and write, test, debug, maintain... a FLIF decoder yourself? Also, I'm not sure how far do you have to deviate from the original code to not be covered by its license.

> Why do you really want to duplicate work and write, test, debug, maintain... a FLIF decoder yourself?

Because multiple implementations are useful.

Re: Free Lossless Image Format

#244
They claim this is good for responsive images:

    The download or file read operations can be stopped
    as soon as sufficient detail is available, and if
    needed, it can be resumed when for whatever reason
    more detail is needed.
     -- http://flif.info/responsive.php
Unfortunately that's not how HTTP works. Your browser opens several connections to a website, and makes requests for resources. Each connection is in use until that resource is fully loaded, at which point you can send a request for another resource up that connection. Yes, the browser could close the connection after it has received enough of the image for the desired quality, but there's a lot of overhead in setting up a new connection, including some round trips, and so that is probably a net loss.

The JPEG image format also supports progressive images, in browsers today, and no one has figured out how to use that for single-file responsive images yet.

(You might be able to do something in HTTP/2 where you set the priority of the stream to 0 after you have enough of it for your needs, but I don't think anyone has gotten this working yet.)

Re: Free Lossless Image Format

#245

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…

BSD/MIT, or ASL2 are pretty much the standard if you want to see something as widely used as possible, which this sounds like might be the case.

Cool work in any case!

One thing the page could use is "how much processing power does this use, compared to other things?"

Re: Free Lossless Image Format

#246

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…

Very neat stuff. Would be nice to support 16/32bit floating point for true HDR as well if can be easily accommodated.

Can be done. Basically just change the type of ColorVal and implement a float variant of writer() and reader() in maniac/symbol.h.

Re: Free Lossless Image Format

#247
post #192

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.

No kidding. If you want an image format to become widely adopted and standardized, GPLing the code is a pretty bad idea.

He intends to make the spec public as well as to switch to a more permissive license once the format has stabilized, so I wouldn't be too concerned yet.

Re: Free Lossless Image Format

#248
post #98

Earlier quoted context omitted.

In fact, it makes it impossible to use in practice. None of the major browsers are GPLv3.

The GPL is compatible with BSD, MPL, and MIT licenses that Firefox / Chromium use. The problem is more that Firefox / Chrome ship proprietary bits like the DRM modules that would violate the linking GPL coverage of flif. And that Chrome is proprietary. Its going to need to be relicensed LGPL to be included.

Firefox doesn't actually ship anything proprietary. DRM module is an optional plugin from Adobe.

Re: Free Lossless Image Format

#249

Earlier quoted context omitted.

It's not about being apologetic or anti-freedom, it's all about the reality of software. If it gets reimplemented with a more libral license, then the more liberal version will dominate. If there is any incompatibility whatsoever, the more liberally licensed version will win. Look at gcc for an example: it has gcc-specific extensions and there are other compilers with more open license. These compilers are gaining th…

GCC has been around for 30 years. Only in the past 5 years has LLVM been around, and LLVM really is the only compiler to ever have matched GCC. The value GCC has provided to the software community in large is immense. Do you think it would have survived this far if it had been MIT-licensed all along? To support this argument, I'd like you to think about all the other compilers that never had a 10th of the traction of…

I'm a big fan of GCC, but this just isn't true that nothing matched it. It may be true that nothing "free" matched it.'

Where performance mattered we always used the commercial, proprietary, Intel compilers and/or the Microsoft compilers.

Re: Free Lossless Image Format

#250
post #192

Earlier quoted context omitted.

No kidding. If you want an image format to become widely adopted and standardized, GPLing the code is a pretty bad idea.

I think it's great to have a free software solution which wholly eclipses the competition. It's an incentive to use free software (use free software and get the best image codec in the world).

Yes, but the technology of "storing images" is never going to become the domain of free software. It's a little late for that.

If you're trying to drive widespread adoption of a competing file format, then don't GPL the only code that implements it. Make a brain-dead reference implementation with a license as unencumbered as you can stand. (Then code up an elegant implementation and GPL that.)

Post reply on HN