Page MenuHomePhabricator

Exif orientation problem (no metadata extracted due to empty JPEG segment)
Closed, ResolvedPublic

Details

Related Gerrit Patches:

Event Timeline

Restricted Application added projects: Multimedia, Commons. · View Herald TranscriptSep 29 2016, 6:40 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

MediaWiki is unable to extract any metadata from this file (notice that there's no "Metadata" section on the file page), including the orientation, so the thumbnail doesn't get rotated correctly.

Restricted Application added subscribers: Poyekhali, Matanya. · View Herald TranscriptSep 29 2016, 9:49 PM

The file has an empty APP5 (FFE5) segment, and apparently we don't like empty segments. I think it's just an off-by-one error.

Change 313514 had a related patch set uploaded (by Bartosz Dziewoński):
JpegMetadataExtractor: Allow empty segments

https://gerrit.wikimedia.org/r/313514

matmarex renamed this task from Exif orientation problem to Exif orientation problem (no metadata extracted due to empty JPEG segment).Sep 29 2016, 10:18 PM

Change 313514 merged by jenkins-bot:
JpegMetadataExtractor: Allow empty segments

https://gerrit.wikimedia.org/r/313514

matmarex closed this task as Resolved.Sep 29 2016, 11:44 PM
matmarex claimed this task.
matmarex removed a project: Patch-For-Review.

The change will be deployed to Commons next week, on Thursday, 5 October 2016, per the schedule: https://www.mediawiki.org/wiki/MediaWiki_1.28/Roadmap.

I'm not sure if it's possible for users to clear the metadata for existing files… try purging the file page, and if that doesn't help, re-upload the file.

To manually purge the cached bad metadata for this file:

update image set img_metadata='' where img_name = "20160927_St_George's_Church_(The_Winery)_Mohegan_Lake_2.jpg";
Stashbot added a subscriber: Stashbot.

Mentioned in SAL (#wikimedia-operations) [2016-10-07T16:53:31Z] <jynus> testing img_metadata nuking for T145953 and T147015 (backups on neodymium)

MariaDB MARIADB s4-master commonswiki > UPDATE image SET img_metadata='' WHERE img_name = 'Jena_-_Hummelsberg_05.jpg';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

MariaDB MARIADB s4-master commonswiki > UPDATE image SET img_metadata='' WHERE img_name = '20160927_St_George''s_Church_(The_Winery)_Mohegan_Lake_2.jpg';
Query OK, 1 row affected (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 0

The metadata got re-generated as expected (and with correct data) after @jcrespo purged it and I viewed the file pages.

Note that the old thumbnails still look wrong, because we didn't purge metadata for the old files. It's not really worth it.

Note that the old thumbnails still look wrong, because we didn't purge metadata for the old files. It's not really worth it.

Can we purge old ones? Otherwise users are requesting rotation where no rotation is needed (https://commons.wikimedia.org/wiki/File:Wikipedia_Photowalk_Puthia,_September_2016_57.jpg)

Of course the same version could be re-uploaded, but not sure if that is a good idea.

&action=purge won't solve the problem as far i can see.

If you mean for old versions of this file, not really. There is no built-in way to do this (not even a maintenance script) and I'm not sure whether the manual way we used here works for old versions of files.

If you mean the latest versions of any other affected files, yes, we have to run a maintenance script to do it (T32961: Run refreshImageMetadata.php --force). I'm working to make it happen, see that task for details.