jaredcheeda

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:

https://www.youtube.com/watch?v=IheZzcYUV9w

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.

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.

The first official version of FLIF has not been released yet, and currently they are discussing releasing it under Apache 2 or MPL (Mozilla Public License).

The current decode time (on a lower end ARM CPU) is approx 1 megabyte per second. This of course will increase as the format is finalized and better/more optimized decoders are written for it. As well as with CPU speeds increasing. Though even at the current rate it should be fast enough in almost any real world scenario. A 1080p video on youtube is about 260-320 kilobytes per second. So as long as video quality doesn't demand 3-4 times what we are currently getting from HD video online, it should decode faster than it matters. Plus the whole video is available as it downloads in a lower resolution. It just gets clearer the longer it plays. Which is a much better experience than GIF/APNG/BPG/WebP and even MP4 in use as a GIF replacement. Though the MP4 will almost certainly be visually as good of quality at a consistently much smaller filesize due to H.264's fantastic lossy compression.

The first official version of FLIF has not been released yet, and currently they are discussing releasing it under Apache 2 or MPL (Mozilla Public License).

In the part where it says "Spot the difference" and everyone says "The BPG one looks worse". That's because BPG, even in "lossless" mode... is lossy. So you're taking a video with H.264 compression artifacts and recompressing it with HEVC artifacts. The quality can only go down.

FLIF on the other hand is lossless, so the image would be truly identical (pixel for pixel). However the filesize will likely be much larger, as MP4 is a very good at lossy compression. What BPG is doing is better performed by HTML5 video formats that already exist due to hardware acceleration support for H.264 and better memory management for video. Also there are patent issues with BPG due to it being based on HEVC.

FLIF is patent free, making it the more likely candidate for mass adoption. It's animation, like APNG is lossless and supports full 24-bit transparency (versus GIF's 8-bit). However the filesize for FLIF is considerably smaller than APNG, even when crushing it with algorithms like Zopfli. Still though, for full frame video, you'll have a better time with MP4, though FLIF will be better quality, it will only be marginal and not likely noticeable in most cases.

What is interesting is the responsive aspect of FLIF. If you encoded an HD video, but only display it on a page at a lower resolution, it will only download the minimum amount of data required to display the image up to that resolution. So it could technically require a lot less bandwidth from a server compared to MP4 if the user doesn't fullscreen the video. But this is more to do with implementation than with formats. YouTube does this same idea, though with a completely different style of execution, in which they only give the the quality for the resolution you are playing it at.