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

Flickering padded webp images #1469

Closed
mt-krainski opened this issue Nov 15, 2019 · 4 comments
Closed

Flickering padded webp images #1469

mt-krainski opened this issue Nov 15, 2019 · 4 comments

Comments

@mt-krainski
Copy link

Hey,

I'm having quite a peculiar problem with webp images, which seems to happen at least on libvips 8.8.2 and 8.8.3 (built locally), but seems not to happen with 8.7.4 (from apt). We observed it for libwebp versioned 0.6.1 and 1.0.3.

The sequence of actions is as follows:

  • Resize a png image (sintel-in.png), and store the result as a vips image (t.v):
    vips thumbnail sintel-in.png t.v 1920 --height 1080 --size both
  • Pad the resulting vips image (t.v) to 2x the height, and store as a webp image (sintel-out.webp):
    vips gravity t.v sintel-out.webp centre 1920 2160

After this, when opened in a browser, the sintel-out.webp image will be... flickering (see output image below). If I open the image in e.g. gimp, it will show only the top half of the image...

This seems to happen only if the pad size is exactly 2x the image height (width doesn't matter), only for webp images, and only after the intermediate step of storing it as a vips image. If I was doing this from the command line, I could simply save the intermediate image to a different format, but I'm using pyvips, where the same result is achieved with:

import pyvips
test_image = pyvips.Image.new_from_file('sintel-in.png')
test_image.thumbnail_image(
    1920, 
    height=1080, 
    size='both',
).gravity(
    'centre', 
    1920, 
    2*1080,
).write_to_file('sintel-out.webp')

Without thumbnail_image it works properly.

It's also noteworthy that if the image is opened with access='sequential', the write operation will fail with:

~/.virtualenvs/image/lib/python3.7/site-packages/pyvips/vimage.py in write_to_file(self, vips_filename, **kwargs)
    499 
    500         return pyvips.Operation.call(name, self, filename,
--> 501                                      string_options=options, **kwargs)
    502 
    503     def write_to_buffer(self, format_string, **kwargs):

~/.virtualenvs/image/lib/python3.7/site-packages/pyvips/voperation.py in call(operation_name, *args, **kwargs)
    213         vop = vips_lib.vips_cache_operation_build(op.pointer)
    214         if vop == ffi.NULL:
--> 215             raise Error('unable to call {0}'.format(operation_name))
    216         op = Operation(vop)
    217 

Error: unable to call VipsForeignSaveWebpFile
  vipspng: out of order read at line 544

Input image:
sintel-in

Output image:
Well, not exactly the output image, because github does not allow me to upload a webp image, but this is a screen recording of how the output image looks like when opened in a browser.
sintel-out-recording

Please advise?

@jcupitt
Copy link
Member

jcupitt commented Nov 15, 2019

Huh how completely bizarre.

I'll have a look, thanks for reporting this.

jcupitt added a commit that referenced this issue Jan 6, 2020
We were always setting page-height in thumbnail, even on single-frame
images. This could cause problems if the image height was later
increased by a factor of the height -- non-animated images could
accidentally turn into animated images.

#1469
@jcupitt
Copy link
Member

jcupitt commented Jan 6, 2020

Sorry for having sat on this. It should be fixed in git master, and the fix should be in 8.9.

Thanks again for reporting the dumbness.

@mt-krainski
Copy link
Author

Thanks!

@jcupitt
Copy link
Member

jcupitt commented Jan 26, 2020

I'll close, I think it's all done.

@jcupitt jcupitt closed this as completed Jan 26, 2020
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