uprootlabs/poly-flif

:camera: A poly-fill for the FLIF image format.

Poly FLIF

A browser poly fill for FLIF image format. Since this image format is not supported natively by browsers yet, this project makes it possible to decode FLIF images with Javascript and to then render them on HTML5 Canvas.

Try the interactive demo if you are new to FLIF. The demo allows you to truncate the bitstream and to compare FLIF with other image formats.

For an example of how to use the PolyFLIF API to render FLIF images, see this page.

Status

Mostly stable but needs more testing.

Currently, has been tested manually on latest versions of Chromium and Firefox. No regression tests / CI setup yet.

JS payload size

As of version 0.3, the gzipped and minified payload size is 77KB.

Roadmap

• Async processing (so as to not block the browser event loop during decode)
• Animation speed and loop control. #2
• Code size reduction and performance optimisation.

License

GNU Lesser General Public License (LGPLv3+) in accordance with the upstream license.

Contributing

How to Build

• Install emscripten
• Install Java (for the closure compiler)
• cd src/
• emmake make -f Makefile-emscript

CLA

When you send us a pull request, you acknowledge that

• You either hold the copyright to your contribution or you have the permission from the copyright holder to submit the contribution to this project.
• You grant the right to Uproot Labs to use your contribution in the project without any strings attached.

About FLIF

FLIF is a lossless image format based on MANIAC compression. MANIAC (Meta-Adaptive Near-zero Integer Arithmetic Coding) is a variant of CABAC (context-adaptive binary arithmetic coding), where the contexts are nodes of decision trees which are dynamically learned at encode time.

poly-flif's Issues

Load image data asynchronously

add some line-art to the list of images

Some references: https://commons.wikimedia.org/wiki/File:Bee_-_queen_(PSF).png

https://commons.wikimedia.org/wiki/File:Op-art-4-sided-spiral-tunnel-6.svg

http://duelistabbeyryou.deviantart.com/art/Brain-Spill-Uncolored-74995356

http://edelart.deviantart.com/art/Rooster-Peleador-175223593

Use Cloudinary to generate FLIF images

As discussed on gitter:

Cloudinary supports FLIF, so for the demo page, you could make a Cloudinary account and put the original PNGs there. E.g.

http://res.cloudinary.com/jon/kodim05.png

To produce a progressive lossless FLIF file from that, you simply have to change the URL:
http://res.cloudinary.com/jon/fl_progressive/kodim05.flif

For lossy, you can use e.g.:
http://res.cloudinary.com/jon/fl_progressive,fl_lossy,q_50/kodim05.flif

You can also produce JPEGs and Adam7 interlaced PNGs in a similar way.

You can also use the upload widget to let people upload their own images (in any format) and automatically convert it to the other formats.

Cloudinary accounts are free as long as you're not using too much space or bandwidth. Let me know if you start to run into limits; I can probably arrange something if needed.

Error when scaling

The final render of the following appears broken:

<canvas data-polyflif-src="clock.flif" data-polyflif-scale="true" style="width:100px;height:100px"></canvas>
<canvas data-polyflif-src="spinfox.flif" data-polyflif-scale="true" style="width:100px;height:100px"></canvas>

The preview renders are fine.

Implement upscale / downscale when decoded size doesn't match specified size

Carrying over the discussion from #28, it would be convenient if the decoded image is fitted into the specified size.

There's an interesting choice though:

• to decode to one size lower (which is the current behavior) and upscale (better speed), or
• to decode to one size bigger and downscale (better quality)

Maximum Image Size

Using the latest release with one 7.9MB and one 2.8MB flif, neither render and this is output to the console.

Cannot enlarge memory arrays. Either (1) compile with -s TOTAL_MEMORY=X with X higher than the current value 33554432, (2) compile with -s ALLOW_MEMORY_GROWTH=1 which adjusts the size at runtime but prevents some optimizations, (3) set Module.TOTAL_MEMORY to a higher value before the program runs, or if you want malloc to return NULL (0) instead of this abort, compile with -s ABORTING_MALLOC=0
flif-stillonly.js:44:383

Red channel weirdness when SUPPORT_HDR is disabled

This is something specific to the emscript port; it works fine on native.

Example : http://i.imgur.com/Oet69lD.png

Thoughts:

• The operand size in some write is probably bigger than expected, which is probably causing the red channel to be over-written. Try disabling / trapping some memory writes to track down the problem.
• Try with a new version of emscripten, when it comes out.

Methods to handle runtime-created elements

I read your docs and assumed that there is no API provided to handle lazy-loaded element.
It would be great to give a chance to handle it like below:

var c = document.getElementById("SOME_CANVAAS");
flifify_or_something (c);

Thanks.

When scaling, decode to a higher dimension and then downscale back to target dimension

Refer discussion here

Add credits, description to images

corrupted decoding latest version

https://www.dropbox.com/s/i9bqu0b6w8vps3n/test.zip?dl=0

This is using the attached setup, with python -m SimpleHTTPServer and localhost:8000/index2.html
There are no messages in console, and it happens every time over safari, firefox and chrome.
The test site here however, works fine on all three browsers
The flif file itself is also fine, or at least it displays properly in phew

animation stays when viewing still

If you first view an animation and then a still image, the animation remains visible.

Web worker enhancements

• Detect worker capability in browser, and only then install worker proxy
• Allow worker to be disabled via API
• Limit number of workers by having a worker pool. See this for techniques.
• Use current-script's text converted to a blob, as URL for worker, instead of the original URL. (Avoids network request).

Progressive Loading not working.

When loading a progressive image e.g

<canvas id="draw" data-polyflif-src="http://res.cloudinary.com/jon/fl_progressive,fl_lossy,q_25/kodim05.flif"></canvas>

The whole file is loaded before being displayed rather than progressively.

The ability to publish a version that does not contain animation decoding can reduce the size of JS

The ability to publish a version that does not contain animation decoding can reduce the size of JS

Improvements to Progressive decode

Ensure that progressive mode is disabled when web-workers are disabled.

---

Follow up tasks created:
#42 #43

Update poly-filf

I saw there wore some additional classes created to build it with emscripten.

How do i update the repo to the latest version of flif?

Thank you

Support animations

• Prelim support for animations
• Playback speed. flif encoder now has the -F option to specify frame delay.
• loop control
• immediate playback (play as soon as some frames are available).

error: unknown type name when compiling on macOS

$ emmake make                                                                                                                                                                                       [45/537]
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_D
ISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o maniac/chance.o maniac/chance.cpp
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_D
ISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o maniac/symbol.o maniac/symbol.cpp
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_D
ISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o image/crc32k.o image/crc32k.cpp
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_D
ISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o image/image.o image/image.cpp
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_D
ISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o image/image-png.o image/image-png.cpp
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_D
ISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o image/image-pnm.o image/image-pnm.cpp
image/image-pnm.cpp:134:17: warning: comparison of constant 65535 with expression of type 'ColorVal' (aka 'short') is always false [-Wtautological-constant-out-of-range-compare]
        if (max > 0xffff) {
            ~~~ ^ ~~~~~~
image/image-pnm.cpp:155:17: warning: comparison of constant 65535 with expression of type 'ColorVal' (aka 'short') is always false [-Wtautological-constant-out-of-range-compare]
        if (max > 0xffff) {
            ~~~ ^ ~~~~~~
2 warnings generated.
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_D
ISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o image/image-pam.o image/image-pam.cpp
image/image-pam.cpp:119:17: warning: comparison of constant 65535 with expression of type 'ColorVal' (aka 'short') is always false [-Wtautological-constant-out-of-range-compare]
        if (max > 0xffff) {
            ~~~ ^ ~~~~~~
1 warning generated.                                                                                                                                                                                [20/537]
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_D
ISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o image/image-rggb.o image/image-rggb.cpp
image/image-rggb.cpp:286:10: warning: comparison of constant 65535 with expression of type 'ColorVal' (aka 'short') is always false [-Wtautological-constant-out-of-range-compare]
        if (max > 0xffff) {
            ~~~ ^ ~~~~~~
1 warning generated.
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_D
ISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o image/image-metadata.o image/image-metadata.cpp
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_D
ISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o image/color_range.o image/color_range.cpp
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_D
ISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o transform/factory.o transform/factory.cpp
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_D
ISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o common.o common.cpp
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_D
ISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o flif-enc.o flif-enc.cpp
flif-enc.cpp:824:76: warning: comparison of constant 65535 with expression of type 'ColorVal' (aka 'short') is always true [-Wtautological-constant-out-of-range-compare]
    if (c=='2') {for (int p = 0; p < numPlanes; p++) {if (images[0].max(p) != 65535) c='0';}}
1 warning generated.
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_DISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o flif-dec.o flif-dec.cpp
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_DISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o io.o io.cpp
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_DISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o ../extern/lodepng.o ../extern/lodepng.cpp
/usr/local/Cellar/emscripten/1.37.18/libexec/em++ -c -std=gnu++11 -I/usr/local/Cellar/zlib/1.2.11/include -I/usr/local/Cellar/libpng/1.6.31/include/libpng16 -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_DISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o flif.o flif.cpp
flif.cpp:343:7: error: unknown type name 'FileIO'
      FileIO fio(file, (file == stdout? "to standard output" : argv[0]));
      ^
flif.cpp:346:7: error: unknown type name 'BlobIO'
      BlobIO bio; // will just contain some unneeded FLIF header stuff
      ^
flif.cpp:369:5: error: unknown type name 'FileIO'
    FileIO fio(file, (file==stdin ? "from standard input" : argv[0]));
    ^
3 errors generated.
ERROR:root:compiler frontend failed to generate LLVM bitcode, halting
make: *** [flif.o] Error 1

Emit events to indicate progress and status of decode

• Events to indicate progress during decode:

  • input fetched
  • decoding progress: 0% to 100%
  • decode finished
  • decode errored

• Use the events in the demo to indicate progress

poly-flif vs libflif

I am trying to understand how I can help with getting FLIF on the web.
But, I am not sure why there is two projects trying to do the same. What's the difference?
It looks like asm.js is being used here, and https://github.com/saschanaz/libflif.js uses WASM.

I've been tasked to make progress on this so I am trying to gauge which repo is further along so that I can focus my efforts there.

Another difference is here TOTAL_MEMORY is set at 100663296 , and in libflif ALLOW_MEMORY_GROWTH is turned on instead. This is just a performance trade off.

I've noticed some issues in libflif that seem to indicate partial functionality:
saschanaz/libflif.js#6 saschanaz/libflif.js#14
Are these not issues here as well?

Update to FLIF16

Now flif 0.2 has been released, and with it, the FLIF16 bitstream has been finalized, it seems to be a good time to update poly-flif as well.

Async loading

(start decoding while the bytes are still being fetched from the network)

Grayscale images are causing trouble

I think it's because your code assumes the image either has 3 channels (RGB) or 4 (RGBA), but there's also a possibility that it has just 1 channel (grayscale). When attempting to decode grayscale images, things go wrong because you're trying to access non-existent channels.

For grayscale images, you can just set R=G=B=[channel 0 value].

data-polyflif-scale does not resize correctly

Using data-polyflif-scale scales the image wrong (i think). The canvas get´s the right size but the image inside is smaller. Is there a known workaround for this? Tried to come up with a solution or a PR but im not firm with C++ and the tooling.

top: orginal png
bottom: sized flif in the canvas

Show file sizes

It would be nice to see the size of the FLIF file, the size of the truncated FLIF file, and the size of the original PNG file.

Allow progressive stages to be configured.

Simplest idea is to take two parameters: initialQuality and nextQualityFactor. The factor will be multiplied with current quality.

Design a proper API

Support encoding to FLIF format

It might be sometimes desirable to encode FLIF on the client side. Although it might consume a lot of CPU, it might be more bandwidth efficient and simplify design on the server-side.

Support rendering to CSS background image

Idea credit: @TheJaredWilcurt

If an element has data-polyflif-bg attribute, then its value should be taken as a source URL, fetched, decoded, and rendered to an offline canvas.

The offline canvas can then be converted to a blob URL and assigned to element.style.backgroundImage.

This is already possible with the current API; demo: https://jsfiddle.net/5v4t424f/12/

.. but would be nice to support out of the box.

Note: toBlob() is a new API (requires Chrome 50, IE10), but is easily poly-fillable as shown on the MDN page.

Fix memory leaks

Seg fault from upstream code when scaling animations

FLIF-hub/FLIF#345

(Creating an issue here, so that I am reminded to sync with upstream before making a release)

Partial loading?

Under “Controlling the image dimensions” here it talks about partially decoding the image to fit a canvas element’s actual size... is there any way to partially load the FLIF resource as well, with, say, HTTP range requests?

Progressive / Interlaced rendering of FLIF Image

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.

use cheerp ?

I just came across cheerp, which seems to have one big advantage over emscripten: No flat memory space; uses native JS objects.

I am not sure what the performance would be like.

The license is also a bit complex: http://www.leaningtech.com/cheerp/buy/index.html
I am not sure if the LGPL libraries would be allowed by their license.

Progressive mode for background images

This depends on #39

Doesn't seem to work on chromium based browsers on Android

Build Error

I ran emmake make, as suggested by the README, but I got an error. I guess it has to do with libpng. So, I installed libpng with: sudo apt-get install libpng-dev. But, I still got this error.

make: pkg-config: Command not found
make: pkg-config: Command not found
make: pkg-config: Command not found
.../emsdk/emscripten/1.37.37/em++.py -c -std=gnu++11  -DLODEPNG_NO_COMPILE_PNG -DLODEPNG_NO_COMPILE_DISK -DNDEBUG -O2 -ftree-vectorize -g0 -Wall -fPIC -o image/image-png.o image/image-png.cpp
image/image-png.cpp:18:10: fatal error: 'png.h' file not found
#include <png.h>
         ^~~~~~~
1 error generated.
ERROR:root:compiler frontend failed to generate LLVM bitcode, halting
Makefile:41: recipe for target 'image/image-png.o' failed
make: *** [image/image-png.o] Error 1

I ran emmake make -f Makefile-emscript, and it fails with this error:

Traceback (most recent call last):
  File ".../emsdk/emscripten/1.37.37/em++", line 15, in <module>
    python_selector.run(emcc, profile=True)
  File ".../emsdk/emscripten/1.37.37/tools/python_selector.py", line 38, in run
    sys.exit(run_by_import(filename, main) if on_allowed_version() else run_by_subprocess(filename))
  File ".../emsdk/emscripten/1.37.37/tools/python_selector.py", line 13, in run_by_import
    return getattr(importlib.import_module(os.path.basename(filename)), main)()
  File ".../emsdk/emscripten/1.37.37/emcc.py", line 1864, in run
    optimizer.flush()
  File ".../emsdk/emscripten/1.37.37/emcc.py", line 241, in flush
    self.run_passes(chunks[0], title, just_split=False, just_concat=False)
  File ".../emsdk/emscripten/1.37.37/emcc.py", line 276, in run_passes
    output_filename=self.in_temp(os.path.basename(final) + '.jsopted.js'))
  File ".../emsdk/emscripten/1.37.37/tools/shared.py", line 2079, in js_optimizer
    ret = js_optimizer.run(filename, passes, NODE_JS, debug, extra_info, just_split, just_concat)
  File ".../emsdk/emscripten/1.37.37/tools/js_optimizer.py", line 557, in run
    return temp_files.run_and_clean(lambda: run_on_js(filename, passes, js_engine, source_map, extra_info, just_split, just_concat))
  File ".../emsdk/emscripten/1.37.37/tools/tempfiles.py", line 93, in run_and_clean
    return func()
  File ".../emsdk/emscripten/1.37.37/tools/js_optimizer.py", line 557, in <lambda>
    return temp_files.run_and_clean(lambda: run_on_js(filename, passes, js_engine, source_map, extra_info, just_split, just_concat))
  File ".../emsdk/emscripten/1.37.37/tools/js_optimizer.py", line 492, in run_on_js
    cld = shared.Building.closure_compiler(cld, pretty='minifyWhitespace' not in passes)
  File ".../emsdk/emscripten/1.37.37/tools/shared.py", line 2211, in closure_compiler
    raise Exception('closure compiler error: ' + process.stdout + ' (rc: %d)' % process.returncode)
Exception: closure compiler error: .../emsdk/emscripten/1.37.37/third_party/closure-compiler/node-externs/domain.js:67: WARNING - Bad type annotation. type not recognized due to syntax error. See https://github.com/google/closure-compiler/wiki/Bad-Type-Annotation for more information.
 * @param {function(...[*])} callback
                       ^

.../emsdk/emscripten/1.37.37/third_party/closure-compiler/node-externs/domain.js:68: WARNING - Bad type annotation. type not recognized due to syntax error. See https://github.com/google/closure-compiler/wiki/Bad-Type-Annotation for more information.
 * @return {function(...[*])}
                        ^

.../emsdk/emscripten/1.37.37/third_party/closure-compiler/node-externs/domain.js:73: WARNING - Bad type annotation. type not recognized due to syntax error. See https://github.com/google/closure-compiler/wiki/Bad-Type-Annotation for more information.
 * @param {function(...[*])} callback
                       ^

.../emsdk/emscripten/1.37.37/third_party/closure-compiler/node-externs/domain.js:74: WARNING - Bad type annotation. type not recognized due to syntax error. See https://github.com/google/closure-compiler/wiki/Bad-Type-Annotation for more information.
 * @return {function(...[*])}
                        ^

/tmp/tmp_I1XS8.cl.js:4323: ERROR - variable PolyFlif is undeclared
            var pf = new PolyFlif({"buf": content, "canvas": elem});
                         ^^^^^^^^

1 error(s), 4 warning(s)
 (rc: 1)
Makefile-emscript:49: recipe for target 'em-out/flif.html' failed
make: *** [em-out/flif.html] Error 1

Async render

(render while the decoding is still in progress)

Strip gamma info in PNG

Make It Clear Which Browsers Are Supported

Hi, I'm curious which browsers this polyfill supports and can't seem to find much information? I feel like this would be a good addition to the README

Usable in a non-public production system?

This project is fantastic, but I see that the repo hasn't been updated in a while.

Just curious to get a status update. I'm interested in using this for archival storage of a few TB of aerial images which need to be both stored lossless, but also queried for low-fi versions (for preview / index)

I can have everything backed up in original TIFF offline, so no risk there. Would love to choose this as our softwares new internal standard.

compare with other animation formats

Animated GIF is lossy when there are >256 colors, but I guess it is a good reference point. Also several browsers support APNG (or have a plugin for APNG), so perhaps you could also compare with that.

Comparison with Adam7 PNG

A side-by-side comparison of FLIF and Adam7 interlaced PNG would be nice. It would be interesting to compare those two interactively, both in absolute performance (same file size of truncated files) and relative performance (same percentage of truncation). For fairness, the PNG file should be progressively decoded with bilinear interpolation.

API to modify the heap size

flif.js:147 Uncaught TypeError: Cannot convert "undefined" to int

flif.js:147 Uncaught TypeError: Cannot convert "undefined" to int
at Object.toWireType (flif.js:147)
at PolyFlif$startCount [as startCount] (eval at Va (flif.js:13), :11:26)
at self.onmessage (flif.js:177)
toWireType @ flif.js:147
PolyFlif$startCount @ VM46:11
self.onmessage @ flif.js:177
flif.js:147 Uncaught TypeError: Cannot convert "undefined" to int
at Object.toWireType (flif.js:147)
at PolyFlif$startCount [as startCount] (eval at Va (flif.js:13), :11:26)
at self.onmessage (flif.js:177)
toWireType @ flif.js:147
PolyFlif$startCount @ VM46:11
self.onmessage @ flif.js:177

Decode in web worker

Is it possible to decode a flif in a web worker? I'm using canvas-webworker with webpack in a web worker but keep running into this issue: Cannot set property 'PolyFlif' of undefined.

The referenced line is:

  }var ic = !1;c.noInitialRun && (ic = !1);c.noExitRuntime = !0;jb();window.PolyFlif = c.PolyFlif.extend("PolyFlif", { __construct: function __construct(b) {

at window.PolyFlif.

I've tried adding let window = self before importing the script but it seems to have no effect.

Disable browser interpolation of <canvas>

Currently the browser is doing some interpolation to the canvas that will affect the quality of the decoded image and will affect the perception of the flif image format. To disable this across browsers you would need to add:

canvas {
  image-rendering: optimizeSpeed;             /* Older versions of FF          */
  image-rendering: -moz-crisp-edges;          /* FF 6.0+                       */
  image-rendering: -webkit-optimize-contrast; /* Safari                        */
  image-rendering: -o-crisp-edges;            /* OS X & Windows Opera (12.02+) */
  image-rendering: pixelated;                 /* Awesome future-browsers       */
  -ms-interpolation-mode: nearest-neighbor;   /* IE                            */
}

via StackOverflow

Roadmap and crowd-funding

In order to evolve this demo into a production quality library, I am planning to spend some dedicated time on it.

Roadmap

• Async loading (start decoding while the bytes are still being fetched from the network)
• Async render (render while the decoding is still in progress)
• The above is with browsers that support WebWorkers. For older browsers, a work-around, such as decoding in a separate iframe can be considered. In the worst case, fall-back will be to synchronous versions.
• Stopping the decoding when sufficient resolution has been achieved. And resuming if requirement changes (user pinch-zooms on the image).
• Better support for animations including
  • Respecting the frame delay and looping constraints specified in the stream
  • Allowing playback control (pause, play, rewind, etc)
• Size and speed optimisations of the JS layer.
• Design a flexible API around all this functionality. There would be two APIs: a low level API which deals with just decoding a byte stream, and a higher level one which makes it convenient to render to a canvas or img element and to fetch data / decode asynchronously.
• Testing with different browsers that I have access to, which includes Chromium, Firefox on Linux, Android and Windows, and IE 8. Some testing could be done on cloud-hosted testing services as well.

License

This work is a derivative of the upstream C++ code, so the license of this library will follow the upstream license. The current license is GPLv3. The informal word I have heard is that the decoder will be available in a more permissive license as soon as the bytestream format is finalised.

Crowd-funding

To be able to spend dedicated time on this, I am considering the option of receiving crowd-funds. My estimated time for completing the above is 4 to 6 weeks, and I feel around 3000 USD should help cover the cost.

Any feedback on the above would be highly appreciated.

EOF is not properly reported by the buffer io

io.isEOF() should become true only when the EOF is reached while attempting a read operation.