Page MenuHomePhabricator

PHP7 exif_read_data doesn't read all the EXIF key/values that HHVM version did
Open, Needs TriagePublic

Description

It seems that when we transitioned from HHVM to PHP7, we lost the ability to read all of the EXIF information that some JPEG files contain.

Image uploaded on 21 September 2019 and likely parsed by PHP7 https://commons.wikimedia.org/wiki/File:Argenvors%C3%A4%C3%9F_von_S%C3%BCden_2.jpg
Image uploaded before 12 September 209 and likely parsed by HHVM https://commons.wikimedia.org/wiki/File:Wiesbadener_H%C3%BCtte_von_Nordwesten.jpg

These files, uploaded by @Reinhard_Mueller contain MakerNote data, which IS parsed by exif_read_data, but either not fully, or they contain an error. The next EXIF key value pairs at least are missing and when you enable php warnings, I see on the console:

PHP Warning: exif_read_data(Argenvorsäß_von_Süden_2.jpg): corrupt EXIF header: maximum directory nesting level reached in /Users/hartman/Development/wikimedia-git/mediawiki-core/includes/media/Exif.php on line 296

Maybe this relates to https://bugs.php.net/bug.php?id=75424 ?

Event Timeline

TheDJ created this task.Dec 11 2019, 9:50 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 11 2019, 9:50 PM
TheDJ added a comment.EditedDec 11 2019, 10:00 PM

Possibly fixed in PHP 7.4 support ??
https://github.com/php/php-src/commit/fbb169019842996db693e021c46dac9b68698f15

ah no, that's already in 7.2 which i'm also running

TheDJ added a comment.EditedDec 11 2019, 10:20 PM

It's actually the opposite.. HHVM never had https://github.com/php/php-src/commit/fbb169019842996db693e021c46dac9b68698f15 which was a very late php5.6 change and added support for the Panasonic MakerNote format. Because of the support, it hits more than 150 exif key/value pairs in php7 which is the limit, even though in hhvm the limit with just 100 (without Panasonic MakerNote support) we didn't hit it.

So do I understand correctly that we're actually hitting a hard-coded limit in PHP which cannot easily be changed? I guess patching PHP to set the limit to 200 or 250 is not an option, right? Is there anything we can do about this at all?

TheDJ added a comment.Dec 12 2019, 8:45 AM

@Reinhard_Mueller correct. We can file a ticket upstream with PHP (and we probably should), but it will take a long time to fix.

Maybe we can do a wikimedia patch...

TheDJ added a comment.EditedDec 27 2019, 8:15 PM

I compiled my own php and have been able to confirm that we are indeed running into the maximum number of exif tags. This is less visible than ud think, because unknown tags get skipped in the parser results, but are counted when doing the actual parsing. Will see if the limit can be safely raised.

Dzahn removed a project: HHVM.Jan 17 2020, 7:05 PM

I recently bought a NIKON CORPORATION: COOLPIX P1000. It works with version ID: 2.3.0.0. Just like my Panasonic: DMC-TZ61. Amazing for me: the UploadWizard processes the images of the NIKON CORPORATION: COOLPIX P1000 without any problems: see:

https://commons.wikimedia.org/wiki/File:20200806_xl_0033-solarpark-an-der-b1-bei-Ruedersdorf-ortsteil-tasdorf.jpg

but still no pictures of the Panasonic: DMC-TZ61:

https://commons.wikimedia.org/wiki/File:20170910_xl_P1150222-windkraftanlagen--wka--im-windpark--werder-zinndorf--rehfelde-amt-maerkische-schweiz.jpg

Some possibly related tickets