Page MenuHomePhabricator

PHP7 exif_read_data doesn't read all the EXIF key/values that HHVM version did
Closed, ResolvedPublic


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
Image uploaded before 12 September 209 and likely parsed by HHVM

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 ?

Event Timeline

It's actually the opposite.. HHVM never had 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?

@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...

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.

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

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

Some possibly related tickets

@Molgreen Its fixed in PHP, but not in the version of PHP that the WMF currently runs.

@TheDJ Thank you for the feedback. Is there anything I can do to somehow speed up the implementation by WMF?

There is not much to "implement" here but updated PHP packages to ship in the Debian Linux distribution, as WMF servers run on Debian. (Basically.)

@Aklapper How do WMF administrators find out about the new version? (Is there a communication channel?)

I'm not sure what "WMF administrators" are, sorry. The operating system/distribution on WMF servers receives new updates via updating or upgrading.

@Aklapper okay, thank you very much for the feedback. Can you tell approximately when the update could be effective.

I don't know Debian's update policies, sorry.

@Aklapper thank you, not so bad. The thing interests me because I think the location data is very important.
@Krinkle Thanks also to you

Just to let you know, this now seems to work again.

TheDJ closed this task as Resolved.EditedJun 27 2023, 8:41 AM
TheDJ claimed this task.

Fixed for new uploads because Wikimedia now runs PHP 7.4.33