Progressive / Interlaced rendering of FLIF Image

[ayurmedia]

For using FILF in responsive, eg. mobile device over slow internet, one advantage of FLIF would be to render the partial Image while loading, eg. each 10 percent. so render if 10% of data is there, then 20% then 30% etc. until enough detail is loaded, because the original image is bigger than the width and height of the img in the webpage (or the canvas replacement). this means start lossy in 10% intervals until its lossless for the visible image/canvas size. eg. it does not make sense to load several dots of image for each pixel unless you have subpixel-rendering or retina-display which could take advantage of it, but then you would effectively render the image in 2 or 3 times of the visible resolution. Is it realistic to get it in a good speed, or is the pixel by pixel rendering to the canvas really slow. is it theoretically possible to render the data while downloading = streaming directly on the canvas and not all at once when all the data has arrived. now the demo only compares image quality and compression ratio, but not the streaming/interlacing effect which is possible by truncating the image.

[hrj]

Yes, this is something that I am currently planning to do. It's going to require a significant overhaul of the code though:

• The decoding needs to be moved to a separate thread (webworker or iframe).
• Partially decoded stills / animations should be rendered as the decoding progresses.
• Decode asynchronously while the response has not fully arrived yet.

[ayurmedia]

Nice to hear about this roadmap, might make it more realistic to use flif in browser in a real project in the future, as native support for flif in modern browsers will be far away as its not on their radar yet. even if they start a project to implement it today it would need time to develop it, improve performance and ship it to the new browsers. luckily modern browsers all have automatic update features so the deployment of the new format would be relatively quick as chrome etc. updates often. on mobile devices which are stuck with a version of a mobile android browser there will be very slow adoption as deployment of new versions of android is dependent on the carriers and not the os developer like google. so in mobile devices this canvas+javascript polyfill will be the only real path to try and use flif in the near future. And paradoxically on mobile devices with slow network flif has the best ROI for web development as it can improve the percived (lossy) rendering, download speed. On desktop browsers with fast DSL-Connection the old tech like good quality jpg will outperform flif in performance and subjective visual quality by size. eg. in web the image can be lossy and a jpg can compress much higher than a flif which is lossless, the partial loading and rendering of flif can try to outperform jpg but its a close race. and jpg will win this race for a while as tools and deployment of jpg is more mainstream in the moment, or is status quo, which flif tries to challange.

[benepo]

bounty incentive: https://freedomsponsors.org/issue/806/progressive-interlaced-rendering-of-flif-image

[hrj]

Given the current synchronous FLIF code and the (lack of) support available in emscripten for async execution, the only way to do progressive rendering is to use a webworker. Hence, I have started working on #27

[hrj]

A demo of progressive decode is here.

[benepo]

Very nice! I'll notify procurement for the bounty.