Maybe add a (probably best as optional) step to improve webp compression?

[xdy]

Or use a heuristic like 'if greater than 4mb try to reduce size'. I did it using cwebp and a command like:

for img in $( find . -type f -iname "*.webp" ); do cwebp.exe $img -q 95 -o ${img}.webp; done;
for img in $( find . -type f -iname "*.webp.webp" ); do mv ${img} ${img%.*}; done;

I did it as a two-parter so I could check it the results, but it could probably be done in place. I couldn't see any difference in image appearance, but the webp files were reduced by 25-75% in size so it seemed well worth it. (Though, it could be that I ran with -q 75 rather than 95 for the above size reduction. Try both and see what seems best.)

[jegasus]

Hi there! Awesome, I like the idea. I need to make sure this syntax also works with FFMPEG. If it does, it probably won't be very difficult to update. I'll take a look at this soon!

[Merudo]

Is the current compression to webp 100% lossless?

[jegasus]

The current conversion process uses the defaults set by ffmpeg. Here is the text from the original ffmpeg documentation:

-compression_level integer For lossy, this is a quality/speed tradeoff. Higher values give better quality for a given size at the cost of increased encoding time. >For lossless, this is a size/speed tradeoff. Higher values give smaller size at the cost of increased encoding time. More specifically, it controls the number of extra algorithms and compression tools used, and varies the combination of these tools. This maps to the method option in libwebp. The valid range is 0 to 6. Default is 4.