301–310 of 374 posts
Not a single mention of "signal to noise ratio" (SNR). If you are going to list compression rates you have to give the associated quality -- SNR is used in the literature.
I was suckered into "fractal image compression" by those selling the snake oil back in the 90's -- I am far more skeptical about these things now.
Earlier quoted context omitted.
Very, very hard. I don't see why they didn't use LGPL, as GPL will greatly increase the barrier to adoption. You see how unsupported WebP is at the moment. Simply having a better compression ratio isn't gonna cut it.
The real barrier to adoption is, for the time being, older browsers, anyway. Want to lose 20% of your potential market via IE in favor of some improved image compression? =\
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 th…
Why all the hate for GPLv3?
Sharing code is no longer cool if people have to share back. Or at least so it seems. The GPL-hate in here really is quite immense, even though time and time again, RMS has been shown to be right about his stance on freedom. Should we attribute it to people's desire for a quick ("free") fix over long term considerations? It's hard to tell, but I suspect the silicon valley influence here doesn't help. There everyone w…
I'm fine with GPL for a LOT of things... For others I feel that MIT/BSD/ISC/Apache2, etc are better choices.
A software application that's GPL3, great... A library you want to see make it into diverse, embedded platforms, not so much.
This is an exciting development. I think the concerns about the licensing are a bit premature - honestly, this is currently a research project, not a practical replacement for existing image formats. The licensing is only one of several impediments to adoption. - The format has no spec - The format may change, rendering all previous images unreadable - The format has no javascript implementation, and no way of runnin…
> - No peer-reviewed paper published yet? While there's no paper there's a full Github repo which I'd actually say is quite impressive.
BE SKEPTICAL! Not a single mention of "signal to noise ratio" (SNR). If you are going to list compression rates you have to give the associated quality -- SNR is used in the literature. I was suckered into "fractal image compression" by those selling the snake oil back in the 90's -- I am far more skeptical about these things now.
These are lossless compression algorithms that are being compared here. The only other pertinent details regarding a lossless compression algorithm are the Compression Ratio, CPU usage, and Memory usage.
This is really interesting. One of the most interesting parts is the progressive decoding/responsive images. http://flif.info/example.php (go to the bottom of the page). Basically, the last example shows that, if you want a scaled version of the image, you can simply stop decompressing. No need for multiple image files. Just create one with very high quality and decompress until you get the quality you want and scale…
This would be great. A lot of "responsive" sites nowadays use only one image as well, the highest resolution available. So you are downloading that 4K jpeg whether you are on mobile or on a desktop.
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?"
Earlier quoted context omitted.
Brotli is excellent at text and does a great job at compressing overall, but FLIF is written directly to excel at lossless image compression, hence FLIF will be much better unless it's a really poor solution (which results show it's certainly not). Likewise Brotli will not beat FLAC at compressing audio, since FLAC is specifically written to do that.
Actually, FLAC doesn't have a very good compression ratio (e.g. see [1]). It does have features that are very important for audio streams: it can be quickly resynced and AFAIK decompression proceeds at nearly-constant speed. [1] https://news.ycombinator.com/item?id=7893171
edit: went and did a test on a couple of tracks, using brotli: bro --quality 11 --window 24 against flac -8 (best settings in both cases)
satie - gymnopedie no 1:
wav: 41.6mb
brotli: 28.1mb
flac: 14.7mb
ram jam - black betty:
wav: 41.8
brotli: 35.8
flac: 26.5
vangelis - tao of love:
wav: 29.4
brotli: 23.0
flac: 13.4
meat load - paradise by the dashboard light:
wav: 89.3
brotli: 78.3
flac: 58.5