Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preserve delay when resizing animated images #3061

Closed
janicduplessis opened this issue Jan 27, 2022 · 5 comments
Closed

Preserve delay when resizing animated images #3061

janicduplessis opened this issue Jan 27, 2022 · 5 comments

Comments

@janicduplessis
Copy link

janicduplessis commented Jan 27, 2022

I've been testing the 0.30 version in the main branch for resizing animated images. The only issue I encountered is that delay seem to be lost when resizing / converting to webp.

Not sure exactly where the delay is lost, but I've been doing the following operations:

  • input gif
  • resize
  • output webp
const image = sharp(someGif, { animated: true });
const processed = image.rotate().resize(200, 200).webp();

The result animates, but a lot faster than the source.

As a workaround I used the metadata function to get the delay and pass that to .webp.

const image = sharp(someGif, { animated: true });
const meta = await image.metadata();
const processed = image.rotate().resize(200, 200).webp({ delay: meta.delay });
@kleisauke
Copy link
Contributor

Are you able to provide the test image that exhibits this behavior? I could not reproduce this with:

$ curl -LO https://storage.googleapis.com/downloads.webmproject.org/webp/images/dancing-banana.gif
$ vipsheader dancing-banana.gif -f delay
100 100 100 100 100 100 100 100
$ node -e "require('sharp')('dancing-banana.gif', { animated: true }).rotate().resize(200, 200).toFile('x.webp')"
$ vipsheader x.webp -f delay
100 100 100 100 100 100 100 100

The only bug that I'm aware of is libvips/libvips#2582, but that was fixed in libvips v8.12.2 and causes the animated image to be slower (not faster).

@janicduplessis
Copy link
Author

janicduplessis commented Jan 27, 2022

Hey @kleisauke! Thanks for having a look.

Here's the image I had the issue with: https://cdn.th3rdwave.coffee/merchants/24IRazCBNSlALF2blNYuCEKhkPX.gif

And I get the following webp: https://cdn.th3rdwave.coffee/merchants/24IS3XyZOKKkhQSoKUeLIoZCqhz.webp

kleisauke added a commit to kleisauke/sharp that referenced this issue Jan 28, 2022
By not initializing the delay vector, since we assume it's empty by default.

See: lovell#3061.
@kleisauke
Copy link
Contributor

Ah, the image I tested with had all delays set to 100ms, which is also the default duration for WebP images.
https://github.com/libvips/libvips/blob/0a7e96a4e2f97dc2b933ebeaa763ab573adb7f6d/libvips/foreign/vips2webp.c#L336-L341

I was able to reproduce this with the image you provided. PR #3062 should fix this. Thanks for reporting/testing!

lovell pushed a commit that referenced this issue Jan 28, 2022
By not initializing the delay vector, since we assume it's empty by default.

See: #3061.
@janicduplessis
Copy link
Author

Thanks for the quick fix, will test this today!

@janicduplessis
Copy link
Author

I can confirm this works

Y2zz pushed a commit to Y2zz/sharp that referenced this issue Feb 26, 2022
By not initializing the delay vector, since we assume it's empty by default.

See: lovell#3061.
martinj pushed a commit to aptoma/sharp that referenced this issue Mar 31, 2022
By not initializing the delay vector, since we assume it's empty by default.

See: lovell#3061.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants