Happy Koalaween! We just released a new version of Koa11y. It's an easy to use program to detect accessibility issues on webpages and output a report in different formats (HTML, JSON, CSV, Markdown, XML). It's designed to be usable by less technical folks.
What about NW.js, It's the real hero here. They spent 5 years building up the platform, being used by thousands of companies and apps, basically inventing this technology; just to have GitHub buy up their intern and pay him to make a shitty knockoff called "atom-shell". You're excited because someone tossed a marketing department at a shitty knockoff?
NW.js uses less resources (less ram, smaller distribution sizes).
It is updated more often (within 24 hours of every Chromium and Node.js release, ensuring access to latest technology).
It supports about twice as many OS's (XP+, OSX 10.6+, Debian 8, Ubuntu 10+). Electron doesn't even care enough about Linux to merge in simple bug fixes.
It's much easier to get started with and takes a no-nonsense approach to everything. (thejaredwilcurt.github.io/website/quickstart.html)
Allows for HTML or JS entry for apps.
It offers actual source code protection, and even recently updated this so that there is no longer a performance hit when using it. Which is a pretty serious technical achievement.
The only thing wrong with it is that it's got a shitty name/logo, and has a smaller ecosystem. If you can get passed that you will have a much nicer experience.
You won't ever fully replace GIF, at least not in the next decade. There are too many devices and apps/software that ONLY have GIF support due to the low computational footprint (designed for 1989 hardware). There's a reason why all these sites that have replaced GIF with HTML5 video still have a GIF fallback available. The file size is usually much larger, but it is supported everywhere. 100% of devices will be able to support GIFs. It's hard to argue with universal support.
Also, FLIF is much better than APNG, animated WebP, MNG, etc. If we are going to adopt a new universal standard as a replacement, that's the smarter route.
The truncated version is basically a lower resolution. So if you have a 5000x5000px image and you display it on your page as 100x100px, it only needs to download a small amount of data to show it at that lower resolution. Obviously being a lower resolution it won't match pixel-for-pixel identically to the original, but if you downloaded the whole file it would.
FLIF does support a "lossy" encoding method too. The compression FLIF uses (MANIAC Trees) predict what the next pixels will be. If you modify your pixels a small amount so they will be closer to what FLIF expects it will compress much better but still look very similar to the original image. The stored version with the modified pixels would be losslessly stored, in the sense that it perfectly reproduces your image with the modified pixels. But it's lossy in the sense that you had to change the pixels in the first place to better benefit from the way FLIF analyzes and compresses images. The major benefit to this type of lossy compression is that the image doesn't degrade with multiple saves, unlike JPG, where each save compounds the artifacts, causing the "Xerox effect". Here's a video of how FLIF benefits from it's style of lossy encoding:
The encoder option -Q<quality> (that's a capital Q, lowercase -q is used to decode a lower quality preview by only reading part of the file) can be used to do lossy encoding, where -Q100 is lossless and -Q0 is usually the most lossy you would want to go. But you can go lower if you want, using a negative number (e.g. -Q-50); there is not really any lower bound.
On September 19, 2016 Jon Sneyers wrote "I'm going to drop the "rc" and tag what we have now as v0.2. This will be FLIF16 and all bitstream-breaking changes will have to be in a new branch, which will become FLIF17 or FLIF18 or whatever. " (https://gitter.im/FLIF-hub/FLIF?at=57df798133c63ba01a135f0d)
For clarification, on the FLIF GitHub "Issues page", there is a ticket indicating an intention to build FLIF into FireFox's rendering engine Gecko, and also Servo (which will eventually replace Gecko). This ticket is a placeholder declaring Servo's interest in FLIF once it is finalized.
FLIF does not have an problem preventing it from pointing to a common Rust image library. (which is how I originally read it).
The FLIF format isn't finished yet. There are optimizations still being made both in compression ratio and decoding performance. Encoding performance is a lower priority.
Also it wouldn't really be a fair comparison to show this slowly maturing format's decoding time versus that of formats that have had decades of time for people to research and find the best ways for decoding (even hardware tailored). You're comparing the heavy weight champ against the up and comer with a lot of promise. FLIF would get pretty beat up in that comparison, but perhaps only because it isn't even finished yet, and thus hasn't had the time to reach that level of efficiency. From having used it, and played around with it, it seems to be pretty fast. Fast enough that people wouldn't notice a perceptible difference between it and other common formats. I think the current decode time is about 20 MegaBytes per second. Which is faster than most people's internet, and considerably larger than most people's images (on the web).
Once it's bitstream has been finalized and it starts to get some use, we'll see decoders improve their performance. The initial plan was to lock the bitstream for a 2016 release, and then in a year or two release a new bitstream with further improvements. Similar to GIFv87a (1987 version) and GIFv89a (1989 version with improvements and new features). However this may have changed as the FLIF 2016 release was set for late December, then February, and has been pushed back again.
In due time we'll see more accurately how the format compares to the existing champs in terms of performance.
Current plan is to keep lossless and lossy versions of the format in the same bitstream for encoders/decoders and to differentiate the output files encoded to be lossy as ".flyf" (Free LossY image Format), and those that are encoded as lossless as ".flif" (Free Lossless Image Format).
However renaming the files from flif to flyf or vice versa would have no effect, they would still be opened and decoded the same. It's merely meant to convey to humans the intention of the person who created the image.
From my understanding, not much focus has been given to lossy endcoding as of yet.
FLIF allows for animation, and it is very possible to interpret each frame of the animation as it's own layer. This would year the same lossless quality as a TIFF at a much smaller file size. Though FLIF isn't intended to be used for this purpose, neither was PNG, and that didn't stop Fireworks from abusing that format and adding layering. The same could be done by someone who wants to add a little meta data to the file to let layered flif opening applications know that the frame are to be interpreted in that manner.
This format isn't complete yet, if layering is important to you, you should join the gitter.im/FLIF-hub/FLIF chat room.
A bigger question here is why not build FLIF as a document format using an established container? Why not use something established, mainstream and non controversial like TIFF as the container and FLIF as the codec. I'm kind of sick of this "new file format and file extension for no good reason" crap. MKV as a container and I dont care about codec because FFMPEG/VLC/etc support all the codecs is great, it hides all the complexity and enables codec experimentation without hassle. FLIF is an image encoding/decoding scheme that would be completely compatible inside a TIFF image if implemented correctly.
Why do I care about having a "dot flif" file when the new codec is the important improvement?
Is '*.flif' actually a good thing?
Personally I don't think so, mainly because without a mechanism to drive adoption in browsers, the format offers very little value to anyone over existing formats. TIFF would be a decent solution to that problem. ... And the fact that FireFox has marked TIFF support as WONTFIX is actually pretty indicative of how unlikely they are to support a new format such as FLIF. Sad but true. From what I already see of the FireFox support thread for FLIF, its not going to happen any time soon.
Well TIFF has very poor compression leading to large file sizes compared even to PNG. And thus no one uses it on the web.
FLIF has very good compression, it will only download the minimum amount of data required to display the image at it's current resolution. It supports 32-Bit images/animations/transparency. It does animation playback in realtime while it's downloading the file. So as it plays the resolution just increases, you aren't waiting for the next frame to load, only improve. FLIF can also handle the incredibly high resolution images that TIFF is usually used for, and can even do tiled rendering, where it only loads the chunks of the image you are zoomed in at into memory at that resolution. Meaning it takes less time to render those chunks on gigantic images and it uses less memory to do so.
FLIF is an incredibly powerful format that offers a lot. It has archival, scientific, and web purposes. It likely won't be useful to those in 3D or Gaming as files like TGA are better suited for faster reading/loading where as FLIF is a little slower to decompress than PNG. But then again, game devs have been optimizing resource usage for a long time giving models that are further away lower poly counts and lower quality bitmaps/textures. So having one flif image to work at any distant may be of use for them, where they truncate the file at different lengths depending on distance from the camera.
There is a lot to be explored with this format, and it isn't even finalized yet.
