0.153.0 dropped PNG support?

support
1

Where 0.152.2 works as expected, 0.153.0 fails with image: unknown format in an attempt to resize a PNG image. Is this a bug or a feature?

2

Certainly not, we have lots of PNG tests and I have tested several sites with PNGs … But we have obviously gotten something wrong. To take WebP decoding in-house we needed to consolidate all decoding/encoding (Go’s setup gets initialised per format with a package import…

I will do a patch release later today increasing the WebP memory limit, and will try to pinpoint where I got it wrong re. PNG, but it would help a lot if you could provide some details as to what function that fails, or even better, point to a failing site on GitHub.

3

OK, I have checked and double checked + added some more PNG tests, and I suspect this is something very specific. Maybe it isn’t a PNG file you’re trying to process and it happened to work before because, I don’t know.

4

did the following test:

  • created four images types: PNG, JPG, JPEG, WEBP
  • copied each image by using all extensions
    • actual file format in CAPTIALS as filename
    • extension in lower case
    JPEG.jpg
JPG.jpg
PNG.jpg
WEBP.jpg

for each I did resize 100x and resize 100x webp

  • with 152.2 all images are resized without errors

  • with 153.0 it fails for both cases if

    • the extension is “webp” but the actual file format is not
Summary 
WARN  1==== RESIZE ONLY ====
WARN  2[ resize 100x ] OK   : /images/JPEG.jpg
WARN  3[ resize 100x ] OK   : /images/JPG.jpg
WARN  4[ resize 100x ] OK   : /images/PNG.jpg
WARN  5[ resize 100x ] OK   : /images/WEBP.jpg
WARN  6==== RESIZE and convert to WEBP ====
WARN  7[ resize 100x ] OK   : /images/JPEG.jpg
WARN  8[ resize 100x ] OK   : /images/JPG.jpg
WARN  9[ resize 100x ] OK   : /images/PNG.jpg
WARN  10[ resize 100x ] OK   : /images/WEBP.jpg
WARN  11----------------------
WARN  12==== RESIZE ONLY ====
WARN  13[ resize 100x ] OK   : /images/JPEG.jpg
WARN  14[ resize 100x ] OK   : /images/JPG.jpg
WARN  15[ resize 100x ] OK   : /images/PNG.jpg
WARN  16[ resize 100x ] OK   : /images/WEBP.jpg
WARN  17==== RESIZE and convert to WEBP ====
WARN  18[ resize 100x ] OK   : /images/JPEG.jpg
WARN  19[ resize 100x ] OK   : /images/JPG.jpg
WARN  20[ resize 100x ] OK   : /images/PNG.jpg
WARN  21[ resize 100x ] OK   : /images/WEBP.jpg
WARN  22----------------------
WARN  23==== RESIZE ONLY ====
WARN  24[ resize 100x ] OK   : /images/JPEG.png
WARN  25[ resize 100x ] OK   : /images/JPG.png
WARN  26[ resize 100x ] OK   : /images/PNG.png
WARN  27[ resize 100x ] OK   : /images/WEBP.png
WARN  28==== RESIZE and convert to WEBP ====
WARN  29[ resize 100x ] OK   : /images/JPEG.png
WARN  30[ resize 100x ] OK   : /images/JPG.png
WARN  31[ resize 100x ] OK   : /images/PNG.png
WARN  32[ resize 100x ] OK   : /images/WEBP.png
WARN  33----------------------
WARN  34==== RESIZE ONLY ====
WARN  35[ resize 100x ] FAIL : /images/JPEG.webp
WARN  36[ resize 100x ] FAIL : /images/JPG.webp
WARN  37[ resize 100x ] FAIL : /images/PNG.webp
WARN  38[ resize 100x ] OK   : /images/WEBP.webp
WARN  39==== RESIZE and convert to WEBP ====
WARN  40[ resize 100x ] FAIL : /images/JPEG.webp
WARN  41[ resize 100x ] FAIL : /images/JPG.webp
WARN  42[ resize 100x ] FAIL : /images/PNG.webp
WARN  43[ resize 100x ] OK   : /images/WEBP.webp
WARN  44----------------------
5

OK; that I understand, when decoding an image:

  • For WebP we currently only use the MediaType derived from the extension.
  • For PNG and JPEG we delegate to Go’s stdlib – which looks at the file header.
  • I originally did the first approach for both, but testing it on some sites I found that it’s very common to name JPEG files as PNG and vice versa …

OK, I can certainly adjust the logic to handle this. Thanks for the input.

6

would be really good to elaborate on that to see if that’s a known one:

  • full code of the resize call
  • full image file name
  • real image format
7

But then again, why do you name a PNG with webp extension …? I adjusted the PNG/JPEG to reduce noise in the release, but this sounds like something that should be fixed by renaming the file.You would get the same issue if you rename e.g. a JPEG file to *.bmp …

1 Like
8

Mishap? Or just someone who doesn’t give a damn about file extensions, hoping that software will inspect the contents? There’s (IMO, of course) nothing wrong with naming a file my-lovely-webp.img or even that-other-png without any extension.

File extensions are largely an inheritance from DOS, where there were no mechanisms to figure out the content. Since then, we’ve got the files command, MIME types, and UTIs. And even (Open)VMS didn’t force a meaning on the extension: File extension - VSI OpenVMS Wiki

1 Like
9

Indeed, the image itself, upon close inspection, turned out to be WebP (I have no idea how it came to be this way with the wrong extension).

10

If it fails to be understood by the receiving software, would you still claim the above?

Sniffing the content to resolve the MediaType is a gazillion times slower than just using the extension.

2 Likes
11

Yes. OTOH, software might not want to rely solely on the extension. Checking it and then verifying if the extension matches the content might be an acceptable slowdown given that the content must be read anyway. And if the two do not match, the software can raise an informative error.

12

To be clear, that’s also what we do in Hugo’s WebP decoder. But we use Go stdlib’s for the others (PNG, JPEG etc.) and the way they wire that up (global state, package initialisers) made it hard to create an elegant Decode method that had a fallback to e.g. PNG for foo.webp. I assumed this was an OK trade off to get WebP animation support and fix the dull color/low contrast issue … But I guess some prefer to name their files in confusing ways …

OK, well, in Hugo v0.153.1 I added a fallback in the decoder to hopefully make everyone happy.

Happy holidays all!

4 Likes
13

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.