Opened 3 years ago
Last modified 2 years ago
#55057 assigned defect (bug)
WebP EXIF data missing and images are not rotated in the same way JPEG images are rotated.
Reported by: | mitogh | Owned by: | adamsilverstein |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 5.8 |
Component: | Media | Keywords: | needs-patch |
Focuses: | Cc: |
Description
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):
Related with the performance ticket:
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
Attachments (3)
Change History (12)
#1
@
3 years ago
- Keywords needs-patch added
- Milestone changed from Awaiting Review to 6.0
- Owner set to adamsilverstein
- Status changed from new to assigned
- Version changed from 5.9 to 5.8
@mitogh thanks for opening this issue, I will take a look.
#2
@
3 years ago
@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.
#3
follow-up:
↓ 8
@
3 years ago
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.
#4
@
3 years ago
- Milestone changed from 6.0 to Future Release
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.
#5
@
3 years ago
- Summary changed from WebP images are not rotated in the same way JPEG images are rotated. to Uploaded WebP images are not rotated in the same way JPEG images are rotated.
#6
@
3 years ago
- Summary changed from Uploaded WebP images are not rotated in the same way JPEG images are rotated. to WebP EXIF data missing and images are not rotated in the same way JPEG images are rotated.
#7
@
3 years ago
@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.
#8
in reply to:
↑ 3
@
3 years ago
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?
Arrow in JPEG version