View Issue Details

IDProjectCategoryView StatusLast Update
0000646fileGeneralpublic2025-05-28 19:39
Reporterexpeedo Assigned Tochristos  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionfixed 
Platformx86_64OSopenSUSE LeapOS Version15.6
Product Version5.46 
Fixed in VersionHEAD 
Summary0000646: WEBP image dimensions reported as additions on some images
DescriptionThe attached WEBP image has a width of 1920 and a height of 200 pixels.

Beginning with file 5.46, a dimension is reported on this image file. Earlier versions did not report any dimension info.

The dimension reported isn't following the syntax convention of "[width]x[height]" though, but instead outputs both width & height as additions: "1919+1x199+1"

As file / libmagic is the fastest tool to exctract image type & dimensions, this is tried first by our systems. Decoding the dimension output then leads to the system assuming a dimension has been detected, but extracting wrong values for width & height.
Steps To Reproduce> file bugtest.webp
bugtest.webp: RIFF (little-endian) data, Web/P image, EXIF metadata, 1919+1x199+1
Additional Information> identify bugtest.webp
bugtest.webp WEBP 1920x200 1920x200+0+0 8-bit sRGB 79934B 0.000u 0:00.000

> exiftool bugtest.webp
Image Width : 1920
Image Height : 200
Image Size : 1920x200

> exiv2 bugtest.webp
Image size : 1920 x 200
Tagsdimension, webp

Activities

expeedo

2025-04-24 08:31

reporter  

bugtest.webp (79,934 bytes)   
bugtest.webp (79,934 bytes)   

expeedo

2025-04-24 08:48

reporter   ~0004211

Another image with the same issue:

> file bugtest2.webp
bugtest2.webp: RIFF (little-endian) data, Web/P image, with alpha, 299+1x299+1
bugtest2.webp (5,042 bytes)   
bugtest2.webp (5,042 bytes)   

jsummers

2025-04-28 14:14

reporter   ~0004215

'file' doesn't have a reasonable way to calculate WebP-style dimensions, so something's got to give, or it would need a major new feature.

The technical problem is the need to truncate a 32-bit integer to a 24-bit integer, and add 1 to the result. 'file' can do one of those things, or the other, but not both.

Another option would be to only print the dimensions if they fit into 16-bit integers. Like this:

[magic/Magdir/riff, "VP8X" section] Change this:

>>>12 lelong&0xffffff x \b, %d+1
>>>15 lelong&0xffffff x \bx%d+1

To this:

# This only prints the dimensions if both are 65535 or less.
>>>12 ulelong&0xffffff <65535
>>>>15 ulelong&0xffffff <65535
>>>>>12 uleshort+1 x \b, %u
>>>>>15 uleshort+1 x \bx%u

expeedo

2025-04-29 07:21

reporter   ~0004217

Thanks for the explanation and the patch, tested & works.

IMO, for practical reasons it's better to restrict the dimension decoding to WebP images < 65535x65535 for now, than to introduce the "+1" syntax. There are probably very few applications needing to work with images exceeding these limits, and those will normally use other methods to determine the dimensions.

christos

2025-05-28 19:39

manager   ~0004244

Applied patch.

Issue History

Date Modified Username Field Change
2025-04-24 08:31 expeedo New Issue
2025-04-24 08:31 expeedo Tag Attached: dimension
2025-04-24 08:31 expeedo Tag Attached: webp
2025-04-24 08:31 expeedo File Added: bugtest.webp
2025-04-24 08:48 expeedo Note Added: 0004211
2025-04-24 08:48 expeedo File Added: bugtest2.webp
2025-04-28 14:14 jsummers Note Added: 0004215
2025-04-29 07:21 expeedo Note Added: 0004217
2025-05-28 19:39 christos Assigned To => christos
2025-05-28 19:39 christos Status new => assigned
2025-05-28 19:39 christos Status assigned => resolved
2025-05-28 19:39 christos Resolution open => fixed
2025-05-28 19:39 christos Fixed in Version => HEAD
2025-05-28 19:39 christos Note Added: 0004244