One more nice feature they didn't mention: unambiguous pronunciation.
So, is it eff-leef or fleef ?
Free Lossless Image Format
241–250 of 374 posts
Re: Free Lossless Image Format
#242Earlier 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.
(Converting JPEG images to progressive format is one of the optimizations mod_pagespeed makes.)
Re: Free Lossless Image Format
#243Earlier 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.
Because multiple implementations are useful.
Re: Free Lossless Image Format
#244 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
#245To 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…
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
#246To 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.
Re: Free Lossless Image Format
#247One 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.
Re: Free Lossless Image Format
#248Earlier 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.
Re: Free Lossless Image Format
#249Earlier 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…
Where performance mattered we always used the commercial, proprietary, Intel compilers and/or the Microsoft compilers.
Re: Free Lossless Image Format
#250Earlier 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).
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.)