Lossless Movie/Image Recompression

[ecc521]

The TIFF image format supports compression, but may not always use it. Adding compression results in HUGE gains (though converting the TIFF image to another lossless format is even bigger gains).

GIF images use LZW compression. A non-greedy LZW compressor could reduce GIF file sizes

[ecc521]

TIFF can likely be ignored. It is very old and rarely used. There are JavaScript implementations though such as UTIF.js (https://github.com/photopea/UTIF.js) that may work.

[ecc521]

Some stuff I found on LZW: https://stackoverflow.com/questions/51859631/creating-a-non-greedy-lzw-algorithm (Stack Overflow question) https://www.semanticscholar.org/paper/The-Effect-of-Non-Greedy-Parsing-in-Ziv-Lempel-Horspool/4e8659917a0cbc2ac033aced4a48948943c42246 (Look at the figures - unless of course you can view the whole thing) http://theory.stanford.edu/~matias/papers/wae98.pdf (Charts look somewhat promising) https://www.computer.org/csdl/proceedings/dcc/1991/9202/00/00213347.pdf (I had already though of most/all of this already. Doesn't look useful for this purpose)

[ecc521]

It looks like there are already tools that take advantage of the GIF clear code (dictionary entry 257) to save some file size. They appeared to save ~2% on average and take WAY WAY WAY too much time.

I'll need to build a MUCH MUCH MUCH faster (though less effective) version of this for it to be useful.

My flexible parsing designs often generated larger outputs (in fact, on everything but continually repeated patterns, with extremely few holes in the pattern, my compressor did worse. And without including numerous overrides of the flexible parsing design, performance was absolutely terrible on repeated patterns)

[ecc521]

LZW flexible parsing is unreasonable to implement for the space savings - in fact, to be compatible with current day decoders, space savings would be significantly less than they would be otherwise.