WebP EXIF data missing and images are not rotated in the same way JPEG images are rotated.

[mitogh]

When a WebP image is uploaded with the rotated exif this exif is ignored and the image is uploaded as it is instead of rotating the image when a JPEG version is uploaded the rotation happens as it should creating a -rotated.jpeg version of the original image.

Result when uploading a JPEG version

Result when uploading a WebP version

Steps to replicate the problem:

• Create a WebP version of the original JPEG image (you can use imagemagick to do this)
• Upload the WebP version of the image and observe the image is not rotated the same way it happens with the JPEG version.

Original JPEG image used to test this behavior can be found at (and attached as part of this report):

• ​https://www.flickr.com/photos/brevity/6221434141/in/photostream/

Related with the performance ticket:

• ​https://github.com/WordPress/performance/issues/146

Media handling information from the installation where this is happening:

Active editor WP_Image_Editor_Imagick
ImageMagick version number 1691
ImageMagick version string ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 ​https://imagemagick.org
Imagick version 3.7.0
File uploads Enabled
Max size of post data allowed 100M
Max size of an uploaded file 100M
Max effective file size 100 MB
Max number of files allowed 20
Imagick Resource Limits area: 122 MBdisk: 1073741824file: 786432map: 512 MBmemory: 256 MBthread: 1
ImageMagick supported file formats 3FR, 3G2, 3GP, AAI, AI, APNG, ART, ARW, AVI, AVIF, AVS, BGR, BGRA, BGRO, BIE, BMP, BMP2, BMP3, BRF, CAL, CALS, CANVAS, CAPTION, CIN, CIP, CLIP, CMYK, CMYKA, CR2, CR3, CRW, CUR, CUT, DATA, DCM, DCR, DCX, DDS, DFONT, DJVU, DNG, DOT, DPX, DXT1, DXT5, EPDF, EPI, EPS, EPS2, EPS3, EPSF, EPSI, EPT, EPT2, EPT3, ERF, EXR, FAX, FILE, FITS, FRACTAL, FTP, FTS, G3, G4, GIF, GIF87, GRADIENT, GRAY, GRAYA, GROUP4, GV, H, HALD, HDR, HEIC, HISTOGRAM, HRZ, HTM, HTML, HTTP, HTTPS, ICB, ICO, ICON, IIQ, INFO, INLINE, IPL, ISOBRL, ISOBRL6, J2C, J2K, JBG, JBIG, JNG, JNX, JP2, JPC, JPE, JPEG, JPG, JPM, JPS, JPT, JSON, K25, KDC, LABEL, M2V, M4V, MAC, MAGICK, MAP, MASK, MAT, MATTE, MEF, MIFF, MKV, MNG, MONO, MOV, MP4, MPC, MPG, MRW, MSL, MSVG, MTV, MVG, NEF, NRW, NULL, ORF, OTB, OTF, PAL, PALM, PAM, PANGO, PATTERN, PBM, PCD, PCDS, PCL, PCT, PCX, PDB, PDF, PDFA, PEF, PES, PFA, PFB, PFM, PGM, PGX, PICON, PICT, PIX, PJPEG, PLASMA, PNG, PNG00, PNG24, PNG32, PNG48, PNG64, PNG8, PNM, POCKETMOD, PPM, PREVIEW, PS, PS2, PS3, PSB, PSD, PTIF, PWP, RADIAL-GRADIENT, RAF, RAS, RAW, RGB, RGBA, RGBO, RGF, RLA, RLE, RMF, RW2, SCR, SCT, SFW, SGI, SHTML, SIX, SIXEL, SPARSE-COLOR, SR2, SRF, STEGANO, SUN, SVG, SVGZ, TEXT, TGA, THUMBNAIL, TIFF, TIFF64, TILE, TIM, TTC, TTF, TXT, UBRL, UBRL6, UIL, UYVY, VDA, VICAR, VID, VIDEO, VIFF, VIPS, VST, WBMP, WEBM, WEBP, WMF, WMV, WMZ, WPG, X, X3F, XBM, XC, XCF, XPM, XPS, XV, XWD, YCbCr, YCbCrA, YUV
GD version bundled (2.1.0 compatible)
GD supported file formats GIF, JPEG, PNG, WebP, BMP
Ghostscript version 9.53.3

[mitogh]

Arrow in JPEG version

[mitogh]

Arrow in WebP format

[adamsilverstein]

@mitogh thanks for opening this issue, I will take a look.

[adamsilverstein]

@mitogh Looking into this, so far I have discovered that PHP's exif_read_data( $this->file ); returns false for your image, although I verified the Exif data is in the file with several web based scanners. I've tried with both libgd and imagick and both return null.

I also tried using Imagick's getImageProperties function on the WebP and it only returned image dimensions.

I've been researching a bit and as far as I can tell exif_read_data in PHP ​https://www.php.net/manual/en/function.exif-read-data.php does not support extracting WebP EXIF data, even though the format supports it.

In order to fix this, WordPress would need to bundle our own exif parser (similar to the way we already parse image sizes) or bundle a 3p library to add the parsing.

Since exif data is usually embedded in jpegs by cameras (that is where the Orientation is important), we probably don't need to worry about this too much - users will upload a jpeg which we can read exif data from, and WordPress will generate the WebPs. In the future if cameras start saving WebP images, this functionality would become more important.

[mitogh]

Thanks for taking a look into this @adamsilverstein I tried to find some alternatives for exif_read_data that can be used for WebP but I was not lucky enough to find information.

Let me know in case I can help with anything else on this one.

[adamsilverstein]

We can probably get some help writing a php function to extract the EXIF data from WebP files since it doesn't seem to be supported by the underlying image libraries. Similar to the shim we added to read WebP image sizes, we can parse WebP Exif "manually".

We can also check to see if libwebp can extract the exif data, and if so, add that support to gd/imagick. Still, a php shim will be helpful regardless because new code in the image libraries will take a long time to make it to WordPress (see AVIF).

Marking as future release while we look for help from a WebP expert.

[adamsilverstein]

@mitogh - I updated the ticket title to reflect that all EXIF data is missing from core WebP handling. In addition to rotation data, this could include a copyright or photographic info like focal length.

I did some more research on this:

• WebP spec supports both EXIF and XMP data: ​https://developers.google.com/speed/webp/docs/riff_container#metadata - we should be able to extract this data manually the same way we extract WebP size data if needed ​code
• LibGD issue to to add EXIF support for WebP (and AVIF): ​https://github.com/libgd/libgd/issues/452
• LibGD relies on libexif, where there is an existing issue to add WebP support - ​https://github.com/libexif/libexif/issues/58
• I discovered Imagick should support WebP EXIF data, as long as it was built with libwebpmux ​code
• LibGD depends on libwebp, but not libwebpdemux currently (which handles exif data)

Long story short, the path for PHP to get EXIF support is going to be long, so for our use case the best solution will be to write PHP code to read the exif data directly (perhaps leveraging an exif library) to get the data core expects.

[codekraft]

Replying to mitogh:

Thanks for taking a look into this @adamsilverstein I tried to find some alternatives for exif_read_data that can be used for WebP but I was not lucky enough to find information.

Let me know in case I can help with anything else on this one.

@mitogh I found a way to get the exif metadata without any php module and I can retrieve some information such as the orientation of the images... The issue with webp is that the exif data are stored inside the image in RIFF format while the different php modules (which @adamsilverstein has listed) are not able to grab them (and I don't have much hope that users will update the module soon even if this gets fixed)

This is a poc of how exif icc xmp and animations could be extracted using php:
​https://gist.github.com/erikyo/c9365b0bc49d599f1be14b2f7feeed91

You will get (for the images that store the exif meta) an array with the information of the image and a field "orientation" like this:

[orientation] => 0008

1        2       3      4         5            6           7          8

888888  888888      88  88      8888888888  88                  88  8888888888
88          88      88  88      88  88      88  88          88  88      88  88
8888      8888    8888  8888    88          8888888888  8888888888          88
88          88      88  88
88          88  888888  888888

This is the way to get the orientation but I was wondering if it would be interesting to write a library that allows avoid the dependency of the EXIF php module. What do you think? it's worth of it?

(EDIT) the same behaviour happens with avif files

[codekraft]

test file arrow.avif (exif has orientation 8)

[flixos90]

Removing the performance focus here since this is unrelated to performance problems or improvements.