I wonder how it compares to lossy (but high-quality) compression codecs.
Free Lossless Image Format
231–240 of 374 posts
Re: Free Lossless Image Format
#232To 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.
And of course I'm planning to describe the algorithms and the exact file format in a detailed and public specification, which should be accurate enough to allow anyone to write their own FLIF implementation.
Re: Free Lossless Image Format
#233Between Brotli and FLIF, which is good enough?
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.
Re: Free Lossless Image Format
#234One 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.
Or at least LGPL, but that is still a hassle for embedded use. GPL may prevent some from trying to embrace/extend/extinguish, but you get around that by writing a spec and clean room code from the spec. Right?
Re: Free Lossless Image Format
#235Earlier quoted context omitted.
I think the suggestion is that the client could just stop downloading at a set threshold, maybe taking current bandwidth, cost, etc. into consideration. Judging from the video, something like that could work very well (and much better than with progressive jpegs).
It's an interesting concept. But I'm not sure how it could work. Resizing introduces artifacts so best quality is always going to be achieved by reencoding for different resolutions. Also, how would the client know when to stop downloading?
The client would download the first 1KB for an icon, 4K for a thumbnail and the whole image for the full size. The best part is that all of those are actually the same file, not separate embedded thumbnails inside the file.
The client could decide BY ITSELF to download only 2K for a thumbnail because it's currently on 3g.
Re: Free Lossless Image Format
#236Earlier quoted context omitted.
Interesting, just last week I had a use for lowsrc for the first time in years and tried to use it, only to find out it had been removed from all browsers a while back.
http://www.w3schools.com/jsref/prop_img_lowsrc.asp ?
Look at what the js ia actually doing, lowsrc has been obsoleted in html5: http://www.w3.org/TR/html5/obsolete.html
Re: Free Lossless Image Format
#237To 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
#238Earlier quoted context omitted.
I think the suggestion is that the client could just stop downloading at a set threshold, maybe taking current bandwidth, cost, etc. into consideration. Judging from the video, something like that could work very well (and much better than with progressive jpegs).
It's an interesting concept. But I'm not sure how it could work. Resizing introduces artifacts so best quality is always going to be achieved by reencoding for different resolutions. Also, how would the client know when to stop downloading?
You'd need to set the thresholds in the file manually, based on the artists judgement of quality.
It would take a few extra seconds when creating it, but could save both bandwidth and create a better user experience on mobile.
Re: Free Lossless Image Format
#239Earlier quoted context omitted.
The HN crowd tends to be a bit more money oriented than some of us older coders.
As a younger coder who has worked at the bigger firms that disallow use of GPL code in projects (Amazon, Google) - it is a huge disappointment to find a quality library that is GPL: There are plenty of projects at these companies that would be unreasonable to open source - and due to frequent reuse of code within a company, GPL is an unreasonable license due to its ripple effect. Contributing back to open source proj…
[deleted]
Re: Free Lossless Image Format
#240Earlier quoted context omitted.
It's an interesting concept. But I'm not sure how it could work. Resizing introduces artifacts so best quality is always going to be achieved by reencoding for different resolutions. Also, how would the client know when to stop downloading?
The client would download the first 1KB for an icon, 4K for a thumbnail and the whole image for the full size. The best part is that all of those are actually the same file, not separate embedded thumbnails inside the file. The client could decide BY ITSELF to download only 2K for a thumbnail because it's currently on 3g.
Where are you getting 1KB and 4KB from? The compression is highly dependent on the image so there's no way to know the quality of the thumbnail image.