Page MenuHomePhabricator

Resizing with -extent sometimes removes transparency from WebP files
Open, MediumPublic



I've gathered a few files at that are transparent in the thumbnail at the top but in the file history section they are opaque for some reason. I guess this is some kind of bug?

Reported upstream:

Event Timeline

Jonteemil renamed this task from Opacity errors with WebP Files to Transparency errors with WebP Files.Jun 1 2021, 2:47 AM
AntiCompositeNumber added a project: Upstream.

I'll use as a sample image.

  • 380x116px (original resolution): transparent
  • 370px: transparent
  • 360px: transparent
  • 355px: transparent
  • 354px: transparent
  • 353x108px: opaque
  • 350px: opaque

And for

  • 468x217px (original resolution): transparent
  • 400px: transparent
  • 300px: transparent
  • 250px: transparent
  • 225px: transparent
  • 220px: transparent
  • 210px: transparent
  • 205px: transparent
  • 203px: transparent
  • 202x94px: opaque
  • 200px: opaque

It's not limited to smaller files though, I also tried with

  • 5,824x4,141 px: transparent
  • 4000px: transparent
  • 3000px: transparent
  • 1000px: transparent
  • 700px: transparent
  • 601px: transparent
  • 600px: opaque
  • 550px: transparent
  • 501px: transparent
  • 500x356px: opaque
  • 499px: transparent
  • 495px: transparent
  • 490px: transparent
  • 475px: transparent
  • 450px: transparent
  • 400px: transparent
  • 300px: transparent

I don't know about you, but I can't find a correlation between those resolutions. Testing locally, I found that this is related to our use of -extent when resizing. On ImageMagick 6.9.7-4 it appears to only affect certain resolutions, but on ImageMagick 7.0.11-14 it affects every resolution as far as I can see.

Reported upstream

AntiCompositeNumber renamed this task from Transparency errors with WebP Files to Resizing with -extent sometimes removes transparency from WebP files.Jun 1 2021, 6:28 PM
AntiCompositeNumber moved this task from Backlog to Reported Upstream on the Upstream board.
AntiCompositeNumber updated the task description. (Show Details)

@AntiCompositeNumber Thanks for looking further into this and reporting upstream. I also found which possesses the same transparency error, but this file is a PNG, not WebP. seems to possess the inverse of the error - transparent in the file history but thumbnail is opaque. Intresting to say the least.

@AntiCompositeNumber You seem to have gotten a response over at GitHub. Do you know if it fixes the problem?