Oh very cool, I hadn't thought of using the palette as an image source. @DarthSim, do you have an opinion on the best way to initialise the quantisation result from an existing palette?

On new switches to control behaviour:

1. We could add an argument to not use the global palette from the metadata (perhaps reoptimise?), or alternatively users could delete gif-palette before saving. I suppose having a switch would be more convenient.
2. We could add a switch to enable dynamic palette generation (perhaps local_palette?). Or I suppose we could just delete all that code and only support a single global palette.

I hadn't thought of using the palette as an image source. @DarthSim, do you have an opinion on the best way to initialise the quantisation result from an existing palette?

That's exactly want I'd do :)

I think we should reuse by default. The most common case must be GIF -> GIF resize, and that should reuse with no extra parameters.

How about something like reoptimise (or maybe optimise_palette?) to generate a new global palette.

@jcupitt Good point. I'll introduce a reoptimise parameter.

generate a new global palette

For now, I would prefer to keep the current method of determining palettes (in case no palette has been attached or reoptimise == TRUE), because that keeps the possibility to output chunks of GIF-data to the target (streaming) in gifsave. Maybe quantizing to a single global palette is something for a different PR?

Maybe quantizing to a single global palette is something for a different PR?

OK, sounds reasonable.

Ready for review from my side.
One additional improvement we could do, is to attach local palettes on gifload as well. This should both improve file sizes and processing time for the affected GIFs again. @jcupitt Do you think that would make sense for a follow-up PR?

Additional notes:
I noticed artifacts with certain GIFs depending on the quantizr / libimagequant version:
original image
Command: $ vipsthumbnail --size 200x input.gif[n=-1] -o out.gif

quantizr v1.2.0	imagequant v2.17	imagequant v4.0

The issue is gone with the latest libimagequant version (v4.0), but I just wanted to mention this.

Hi again, could you explain the motivation behind the use_lct feature? Does this help with a significant percentage of images? It looks like a rather niche thing at first glance.

While testing this change with a dataset of GIFs, I noticed that about 25% of the animated GIFs we process have at least one local colour table (might be because some of the GIFs come from libvips originally).
Therefore I would like to extend this improvement to GIFs with local colour tables. But I guess that's something for a follow-up PR - I'll remove the use_lct feature for now :-)

25% is higher than I expected! Sure, let's do that in another PR.

Sounds good 👍
All done. I also updated the documentation/changelog.

Great! It seems to work well, this is a nice improvement. Good job!

With reoptimise (more or less the old behaviour) I see:

$ time vips copy 3198.gif[n=-1] x.gif[reoptimise]
real	0m1.076s
user	0m1.386s
sys	0m0.013s
$ ls -l x.gif
-rw-r--r-- 1 john john 4153849 May 23 13:05 x.gif

And with this patch:

$ time vips copy 3198.gif[n=-1] x.gif
real	0m0.886s
user	0m1.206s
sys	0m0.039s
$ ls -l x.gif
-rw-r--r-- 1 john john 4041446 May 23 13:05 x.gif

So in many cases: smaller GIFs, lower CPU load, same memory use.