Issue 547 in webp: webpmux cannot perform exif metadata write operation

[roman… via monorail]

Status: New
Owner: ----
Labels: Type-Defect Priority-Medium

New issue 547 by roman...@gmail.com: webpmux cannot perform exif metadata write operation
https://bugs.chromium.org/p/webp/issues/detail?id=547

I am using webpmux to write exif metadata to an image. The sequence of actions that I follow:

1) I am generating an exif file with the data I need
```
~$ exiftool -ver
12.00
~$ exiftool -m -EXIF:UserComment='{"foo":bar}' default.exif
```

2) I am using webpmux to write exif metadata but I get the error
```
~$ webpmux -set exif default.exif input.webp -o output.webp
Failed to create mux object from file input.webp.
```

Information about my software:
```
~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.3 LTS
Release: 20.04
Codename: focal

~$ webpmux -version
1.2.1

~$ cwebp -version
1.2.1

~$ webpinfo -version
WebP Decoder version: 1.2.1
```

webpinfo confirms that I am processing a webp image
```
~$ webpinfo input.webp
File: input.webp
RIFF HEADER:
File size: 49324
Chunk VP8X at offset 12, length 18
ICCP: 0
Alpha: 1
EXIF: 0
XMP: 0
Animation: 0
Canvas size 2000 x 2000
Chunk ALPH at offset 30, length 12434
Chunk VP8 at offset 12464, length 36860
Width: 2000
Height: 2000
Alpha: 0
Animation: 0
Format: Lossy (1)
No error detected.
```

I noticed that if you convert a picture using cwebp, then the problem disappears
```
~$ cwebp input.webp -o input.webp
Saving file 'input.webp'
File: input.webp
Dimension: 2000 x 2000 (with alpha)
Output: 45444 bytes Y-U-V-All-PSNR 50.02 59.69 61.51 51.59 dB
(0.09 bpp)
block count: intra4: 2112 (13.52%)
intra16: 13513 (86.48%)
skipped: 12600 (80.64%)
bytes used: header: 179 (0.4%)
mode-partition: 14289 (31.4%)
transparency: 13372 (99.0 dB)
Residuals bytes |segment 1|segment 2|segment 3|segment 4| total
macroblocks: | 2%| 6%| 7%| 85%| 15625
quantizer: | 36 | 36 | 31 | 24 |
filter level: | 11 | 23 | 54 | 21 |
Lossless-alpha compressed size: 13371 bytes
* Header size: 228 bytes, image data size: 13143
* Lossless features used: PALETTE
* Precision Bits: histogram=6 transform=5 cache=0
* Palette size: 248

~$ webpinfo input.webp
File: input.webp
RIFF HEADER:
File size: 45444
Chunk VP8X at offset 12, length 18
ICCP: 0
Alpha: 1
EXIF: 0
XMP: 0
Animation: 0
Canvas size 2000 x 2000
Chunk ALPH at offset 30, length 13380
Chunk VP8 at offset 13410, length 32034
Width: 2000
Height: 2000
Alpha: 0
Animation: 0
Format: Lossy (1)
No error detected.

~$ webpmux -set exif default.exif input.webp -o output.webp
Saved file output.webp (45666 bytes)
```

The same issue occurs when running OS X Big Sur 11.6.1 using the current version of webpmux

Ubuntu 18.04 and webpmux downloaded from the repository are causing this issue as well.
```
~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.5 LTS
Release: 18.04
Codename: bionic

~$ webpmux -version
0.4.1

~$ cwebp -version
0.6.1

~$ webpinfo -version
WebP Decoder version: 0.6.1

~$ webpmux -set exif default.exif input.webp -o output.webp
Failed to create mux object from file input.webp.

~$ webpinfo input.webp
File: input.webp
RIFF HEADER:
File size: 49324
Chunk VP8X at offset 12, length 18
ICCP: 0
Alpha: 1
EXIF: 0
XMP: 0
Animation: 0
Canvas size 2000 x 2000
Chunk ALPH at offset 30, length 12434
Chunk VP8 at offset 12464, length 36860
Width: 2000
Height: 2000
Alpha: 0
Animation: 0
Format: Lossy (1)
No error detected.


~$ cwebp input.webp -o input.webp
Saving file 'input.webp'
File: input.webp
Dimension: 2000 x 2000 (with alpha)
Output: 46002 bytes Y-U-V-All-PSNR 49.97 50.95 56.61 50.75 dB
block count: intra4: 6524
intra16: 9101 (-> 58.25%)
skipped block: 11997 (76.78%)
bytes used: header: 184 (0.4%)
mode-partition: 14726 (32.0%)
transparency: 13392 (99.0 dB)
Residuals bytes |segment 1|segment 2|segment 3|segment 4| total
macroblocks: | 2%| 5%| 6%| 85%| 15625
quantizer: | 36 | 36 | 31 | 24 |
filter level: | 11 | 23 | 40 | 21 |
Lossless-alpha compressed size: 13391 bytes
* Header size: 248 bytes, image data size: 13143
* Lossless features used: PALETTE
* Precision Bits: histogram=6 transform=5 cache=0
* Palette size: 248

~$ webpmux -set exif default.exif input.webp -o output.webp
Saved file output.webp (46224 bytes)
```

I got curious and decided to check out Ubuntu 16.04. The result was interesting
```
~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04 LTS
Release: 16.04
Codename: xenial

~$ webpmux -version
0.2.2

~$ cwebp -version
0.4.4

~$ webpmux -set exif default.exif input.webp -o out.webp
Saved file out.webp (49546 bytes)
```
Older version of webpmux writes exif metadata successfully and throws no errors. Please tell me why this is happening?

Attachments:
default.exif 184 bytes
input.webp 504 KB

--
You received this message because:
1. The project was configured to send all issue notifications to this address

You may adjust your notification preferences at:
https://bugs.chromium.org/hosting/settings

[jz… via monorail]

Updates:
Labels: Needs-Feedback

Comment #1 on issue 547 by jz...@google.com: webpmux cannot perform exif metadata write operation
https://bugs.chromium.org/p/webp/issues/detail?id=547#c1

Thanks for the report. The input.webp file that you attached is a PNG, do you have the original failing file around? What was used to create it?

[roman… via monorail]

Comment #2 on issue 547 by roman...@gmail.com: webpmux cannot perform exif metadata write operation
https://bugs.chromium.org/p/webp/issues/detail?id=547#c2

Wow, I couldn't think that PNG could use a RIFF container.
Unfortunately, I do not have the original file, but I will try to find out exactly how it was created. It will take some time

[jz… via monorail]

Comment #3 on issue 547 by jz...@google.com: webpmux cannot perform exif metadata write operation
https://bugs.chromium.org/p/webp/issues/detail?id=547#c3

Thanks for checking on the generation. I'm wondering if something might have been off with the riff or file size for instance.
In this case the attachment is a standard png, so dwebp fails with it. webpmux would fail in the same way as the report, so another possibility is that the images got mixed up while you were testing this.

[roman… via monorail]

Comment #4 on issue 547 by roman...@gmail.com: webpmux cannot perform exif metadata write operation
https://bugs.chromium.org/p/webp/issues/detail?id=547#c4

I got some feedback on a question about image creation. Indeed, the image was rendered as png in SolidWorks, but then the extension was changed. Here is the original picture. I tested this picture following the steps outlined above and the result is exactly the same.

I think it was wrong for me to determine if an image is in webp format using the `webpinfo` command. I tried using `webpmux -info` to check this image and got the error as you suggested. For me, the question remains - why `webpinfo` did not reveal any errors when checking png. It seems that imagemagick also determines whether an image belongs to the webp format by using a RIFF container.

```
~$ identify kormushka_medved_vid_sverhu_2_2.png
kormushka_medved_vid_sverhu_2_2.png WEBP 2000x2000 2000x2000+0+0 8-bit sRGB 32321B 0.060u 0:00.064

~$ identify -version
Version: ImageMagick 7.1.0-18 Q16-HDRI x86_64 2021-12-04 https://imagemagick.org
Copyright: (C) 1999-2021 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI OpenMP(4.5)
Delegates (built-in): bzlib djvu fontconfig freetype jbig jng jpeg lcms lqr lzma openexr png tiff webp x xml zlib
Compiler: gcc (9.3)
```

Are you planning to add additional checks for image identification?

Attachments:
kormushka_medved_vid_sverhu_2.png 31.6 KB

[pasca… via monorail]

Comment #5 on issue 547 by pasca...@gmail.com: webpmux cannot perform exif metadata write operation
https://bugs.chromium.org/p/webp/issues/detail?id=547#c5

One current difference between 'webpinfo' and 'webpmux' is that the former is more lenient about the bitstream having extra data at the end.
webpmux, on the contrary, will verify that there is no extra data after the expected chunks and fail otherwise.

Maybe that's what's happening here?
It's not uncommon that some editor append a \n at the end of bitstreams, e.g.

[jz… via monorail]

Comment #6 on issue 547 by jz...@google.com: webpmux cannot perform exif metadata write operation
https://bugs.chromium.org/p/webp/issues/detail?id=547#c6

That looks to be the case:
$ od -tx1 -a kormushka_medved_vid_sverhu_2.png |tail
0076720 e2 63 a0 fb 6f dc eb f9 c6 cf 1a f0 6d a8 90 00
b c sp { o \ k y F O sub p m ( dle nul
0076740 00 00 0a 3d c2 10 7b 40 14 34 00 00 00 00 00 00
nul nul nl = B dle { @ dc4 4 nul nul nul nul nul nul
0076760 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
*
0077100 0a
nl

webpinfo treats it as a warning (chrome is tolerant of this too), but in practice no webp file should be an odd size:

$ webpinfo -diag kormushka_medved_vid_sverhu_2.png
File: kormushka_medved_vid_sverhu_2.png
RIFF HEADER:
File size: 32320
Warning: RIFF size is smaller than the file size.
^^^^^^^^^^

Chunk VP8X at offset 12, length 18
ICCP: 0
Alpha: 1
EXIF: 0
XMP: 0
Animation: 0
Canvas size 2000 x 2000

Chunk ALPH at offset 30, length 12462
Chunk VP8 at offset 12492, length 19828

Width: 2000
Height: 2000
Alpha: 0
Animation: 0
Format: Lossy (1)
No error detected.

There were 1 warning(s).

[jz… via monorail]

Updates:
Status: Invalid

Comment #7 on issue 547 by jz...@google.com: webpmux cannot perform exif metadata write operation
https://bugs.chromium.org/p/webp/issues/detail?id=547#c7

The root cause seems to be an odd sized webp file, possibly due to open/saving the file in a text editor. webpmux is more strict about format correctness than demuxers because it wants to avoid perpetuating bad data. I don't think we plan on changing that, though a possible feature request might be a '-fix' option to the tool.