Ah, I see cgif does this automatically:

// if frame matches previous frame, drop it completely and sum the frame delay

Could you explain why this doesn't work? Is the GIF viewer not respecting the duration attribute?

The use case here is that my bot does media manipulation, some of which randomly recolor each frame in different ways.

The main roadblock I found was that I added a command .fadein which uses ffmpeg's fade filter. By default I have it fadein the media in the first 0.5 seconds. I was trying to take single frame images and making a 0.5 second gif out of them with libvips before sending it to ffmpeg so it would have the duration to be able to fade in properly. Technically I can use ffmpeg to increase the duration but I'd rather use libvips as it's easier.

Other use cases is someone using a command like .seesaw which duplicates the frames, then they use something like .glitch which would randomly color each frame. The result of .seesaw becomes a 1 frame gif and confuses the users.

Its a compression setting that I'd like to be able to disable without having to drop down to a lower cgif, been using libvips for like 4 years now and just now realized this undocumented thing was happening (looks like since about November 2022 lol).

Ahhh I see. I agree, this would be useful for cases like that. Let's add (yet another) enhancement issue.

#4220