ApeironTsuka
commented
1 month ago It was my understanding (probably incorrect) that a frame of an animation was compressed based on the previous frame and so on going back to the last keyframe.
Yes and no - it can be done that way but it will depend entirely on how the animation was created. Most (maybe all?) image editing software that can export animations will have some sort of way of doing this (with GIMP, for instance, you can use 'Optimize for GIF'), with WebP having the potential for slightly more complicated approaches.
I've checked the WebPReader read method and the demux/_demuxFrame methods and I can't see how it's doing anything like this.
For better or worse, I considered implementing actual frame re-assembly as outside the scope of the project, and is better done using libraries written by people who have vastly more knowledge and experience with doing image manipulation fast and efficiently. The implementation I do here simply dumps the raw frame to an individual .webp file with no modifications made to it.
For re-assembling individual frames, you can run the animation while ignoring the frame delays. Create an image of the animation's width/height using whatever library you're most comfortable with, and draw the frames from 0 onward, respecting their individual x/y position and the blend/dispose flags (see 'Options for saving' section of readme).
Apologies for not making this clear in the documentation.
Hi, this isn't an issue, it's just a quick question.
I'm using demux to extract a range of frames from a webp image. It was my understanding (probably incorrect) that a frame of an animation was compressed based on the previous frame and so on going back to the last keyframe.
I've checked the WebPReader read method and the demux/_demuxFrame methods and I can't see how it's doing anything like this.
Have I misunderstood the encoding of WebP animations and the frames are actually standalone and don't need previous frames to be decoded?
Cheers.