For https://commons.wikimedia.org/wiki/File:Sarcophagus_of_Louise_of_Great_Brittain,_Roskilde_Cathedral,_Denmark,_2015-03-31-4813.jpg (and presumably the others although I haven't investigated them), it appears to be a bug in the php exif library. But we should probably narrow it down and get a minimal test case before reporting upstream.

I spent some time debugging this.

I believe the issue occurs when the pointers in the Exif IFD point to locations earlier in the file in the IFD. When that happens, php's exif library seeks directly to that pointer instead of seeking relative to the start of the APP1 segment in the jpeg file. Thus everything is off by the difference between the two starting points (In Sarcophagus_of_Louise_of_Great_Brittain,_Roskilde_Cathedral,_Denmark,_2015-03-31-4813.jpg that's about 12 bytes, so you get tags mismatching with their values)

See exif_process_IFD_TAG in ext/exif/exif.c (in zend php)

And what's the upstream bug report?

I think every "upstream" issue should have an upstream bug report, and mention it here, too.

Perhaps https://bugs.php.net/bug.php?id=50845 opened in 2010?

In T97253#1260717, @Lupo wrote:

I think every "upstream" issue should have an upstream bug report, and mention it here, too.

+1

Perhaps https://bugs.php.net/bug.php?id=50845 opened in 2010?

Why took it 5 years for the bug to reach us? Was there an update of our php to an affected version in the last 30 to 60 days?

Why took it 5 years for the bug to reach us? Was there an update of our php to an affected version in the last 30 to 60 days?

@McZusatz, another option is that files with this format have become more common, because some device or application that produces these files has become more popular.

If the images are exported from Lightroom 6, the EXIF-Data are not correct readable in PHP. This is a LR / PHP - Problem. See: https://forums.adobe.com/thread/1835290 and http://feedback.photoshop.com/photoshop_family/topics/lightroom-cc-jpeg-format-tripping-up-other-programs

Possibly related PHP bug report ? https://bugs.php.net/bug.php?id=50660

New, here, so sorry in advance for not knowing the circuitry :-)

Any idea when this bug will be fixed and deployed on Commons?

Could the priority be escalated?

Currently as more and more people are uploading photos generated using the extremely popular Lightroom 6.x the problem is escalating and new users are affected.
https://commons.wikimedia.org/wiki/Commons:Featured_picture_candidates/File:141227_Berliner_Dom.jpg
I have tried to summarize some methods I have found for mitigating the issue here:
https://commons.wikimedia.org/wiki/User:Slaunger/Mitigating_Mediawiki_Metadata_Viewer_Bug

A question:

When the bug is fixed, will the metadata shown on the file pages of those files, which currently display corrupted data automatically be fixed?

I'd like to add my voice to those requesting this fix ASAP. We've had yet another post to the Village Pump from users wondering why their EXIF data is displayed incorrectly. This wastes people's time investigating if there is a problem with their own image software.

I'd also like to know, if the problem is fixed, whether existing images would have their EXIF reported correctly. Or do you have to refresh the data held by MediaWiki? If the latter, then some search on images created by Lightroom 6 (and possibly Photoshop CC 2015) would target those in need of refresh.

In T97253#1505774, @Colin wrote:

I'd like to add my voice to those requesting this fix ASAP.

Well, as this seems to be a problem in PHP, anybody can and should provide a patch to PHP. https://bugs.php.net/bug.php?id=50660 and https://bugs.php.net/bug.php?id=50845 have been mentioned in this task and that's where this problem can and should get solved.

Adding @Smalyshev for PHP issues...

https://github.com/php/php-src/pull/1943

HHVM probably needs the same patch somewhere around here:

https://github.com/facebook/hhvm/blob/master/hphp/runtime/ext/gd/ext_gd.cpp#L6584

@Smalyshev merged the PHP patch (http://git.php.net/?p=php-src.git;a=commit;h=1ab5a1b432a4b4c62171864bd1b545616e1b07db). This fixes the most common problem mentioned here, bogus values being read when the data is before the IFD structure (https://bugs.php.net/bug.php?id=50845). It will be a part of PHP 5.6.24.

I have no idea what it would take to have it deployed in Wikimedia production today, especially since we actually use HHVM. Porting it should be straightforward, @Smalyshev pointed to https://github.com/facebook/hhvm/blob/ea6ff01f6c31f1615a935ef96622d623a6277d37/hphp/runtime/ext/gd/ext_gd.cpp#L6584.

https://github.com/facebook/hhvm/pull/7208

HHVM patch is also merged (https://reviews.facebook.net/rHHVM255373a80a9b9c8b1b452f902e394cd9773729cd). Now, I wonder what I need to do to get it to our servers.

(The patch was also backported to HHVM 3.12.8.)