161–170 of 374 posts
"WARNING: FLIF is a work in progress. The format is not finalized yet. Any small or large change in the algorithm will most likely mean that FLIF files encoded with an older version will no longer be correctly decoded by a newer version. Keep this in mind. "
Earlier quoted context omitted.
The author has expressed interest in dual-licensing, so there will probably still be options. GPLv3+ or LGPLv3+ sounds reasonable.
LGPLv3 will still prevent use of Windows Phone, iOS and Android.
Earlier quoted context omitted.
It is interesting! I agree but I guess I am getting to old. I keep hearing awesome new formats and than they just waste away. The few success stories are few and in between. FLAC and OGG are a good example. OGG is a decent format and I prefer it to MP3 but it really just withered. FLAC is awesome but it is far from main stream. Heck even SVG is far from where it SHOULD be.
And then there is Opus which took the world in storm.
> Devices based on Google's Android platform, as of version 5.0 "Lollipop", support the Opus codecs. Chromecast supports Opus decoding. Grandstream GXV3240 and GXV3275 video IP phones support Opus audio both for encoding and decoding.
Developers were Mozilla and Skype (MS after the purchase)
>Its main developers are Jean-Marc Valin (Xiph.Org, Octasic, Mozilla Corporation), Koen Vos (Skype), and Timothy B. Terriberry (Xiph.Org, Mozilla Corporation). Among others, Juin-Hwey (Raymond) Chen (Broadcom), Gregory Maxwell (Xiph.Org, Wikimedia), and Christopher Montgomery (Xiph.Org) were also involved.
Standardized
> https://tools.ietf.org/html/rfc6716
Still I think most people have no idea about Opus as a codex and only thing OGG (Container which Opus uses) and Vorbis codec format (Which Opus was to replace).
Earlier quoted context omitted.
In the context of this project which is yet to have a finalized specification I think the GPL is an ideal format. As a project it is important to have access to all of the pieces and avoiding incompatible forks of different kinds in the early stages. So for the purpose of developing a 'golden standard' prototype for FLIF, I don't think a non-GPL license would have served them better. The author seems to have the same…
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…
I do agree that the LGPL is a reasonable choice for prototype implementation of a specification. I don't think using the GPL is a huge loss compared to LGPL for a prototype.
I'd like to ask a non-rhetorical question; On an individual basis is it not better if all software was available as sourcecode?
And if so, does that not mean the choice of not-publishing sourcecode is done for other reasons than what's best for the individual(s)?
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.
Awesome! I have been toying with custom png 'container' ideas in the past offering similar 'responsive' features (i.e various resolutions, lossy-lossless versions)
I would like to see the ASM.js version of the decoder and see how that one performs.
Earlier quoted context omitted.
JPEG has something cooler, you can first load a black-white smaller picture, then load more color and more detail.
Thinking back to the old days, are you sure the black and white image you have in mind didn't come from the "lowsrc" attribute of an img tag? Progressive jpeg is typically full colour from the start, and it does offer the progressive enhancement of resolution that you mention.
I don't see any comparison here on the impact of decompressing? Is this going to hit a processor harder than JPG/PNG/BPG/et al will, and thus be a hit to people on mobile devices?