Speed

[MarcusJohnson91]

I just compared a 3840x2160 8 bit full color image in FLIF (quality 100) to x264 placebo lossless, and FLIF was 20.475 times slower... oh, and the FLIF was 7.5MB and the x264 was 7.7MB.

Have there been optimizations to the code yet? any idea when there will be?

[jonsneyers]

There have been some optimizations, but only to the decode part, not the encode part.

Notice that x264 "lossless" is most likely not lossless, because it works in a lossy color space (YCbCr is effectively roughly 22-bit per pixel, not 24-bit, and maybe x264 is additionally also doing chroma subsampling, which means you might be losing 75% of the information in the two chroma channels).

I'm considering to make a kind of "baseline" FLIF, which uses only a fragment of the format features (in particular, it would use MANIAC trees with a restricted subset of properties). This would speed up both encoding and decoding, at the cost of some compression potential.

[MarcusJohnson91]

Nope. it was lossless. I used the YCgCo color space and I disabled chroma subsampling. Granted the conversion may be lossy, but I inspected the resulting file by eye (and zooming in 8x) and didn't see any difference, so it was at least effectively lossless.

If you want, I can upload the original and the .264 decoded back to png?

Any idea when the encoding speedups will be implemented? jw

[jonsneyers]

You can already try e.g. flif -E10 if you want faster/worse compression now.

The reduced maniac properties thing is an orthogonal speedup idea, but experiments/implementation of that still has to start. On Jun 10, 2016 21:49, "Marcus" notifications@github.com wrote:

Nope. it was lossless. I used the YCgCo color space and I disabled chroma subsampling. Granted the conversion may be lossless, but I inspected the resulting file by eye (and zooming in 8x) and didn't see any difference, so it was at least effectively lossless.

Any idea when the encoding speedups will be implemented? jw

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/FLIF-hub/FLIF/issues/272#issuecomment-225278715, or mute the thread https://github.com/notifications/unsubscribe/AOUJFC0Ssw4Nz4DoeH8IVpToe7abjJbBks5qKb_EgaJpZM4Iycmr .

[jonsneyers]

Reduced maniac properties is an optimization that can be done within the current bitstream (just need to encode to a restricted subset of the format, and detect this at decode time). As such, I'm postponing this until a later Milestone so we can proceed with the FLIF16 release.

[matthiaskrgr]

For some low level optimizations it might be interesting to poke around with llvms opt-report tool: compile file with -fsave-optimization-record -O3 run llvm/utils/opt-viewer/opt-viewer.py file.yml html then view code annotations of done/not done optimizations via (html/index.html)