2011-04-20 23:15:13 +00:00
|
|
|
<?php
|
|
|
|
|
/**
|
2012-05-03 20:13:10 +00:00
|
|
|
* Handler for bitmap images with exif metadata.
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU General Public License along
|
|
|
|
|
* with this program; if not, write to the Free Software Foundation, Inc.,
|
|
|
|
|
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
|
* http://www.gnu.org/copyleft/gpl.html
|
|
|
|
|
*
|
2011-04-20 23:15:13 +00:00
|
|
|
* @file
|
|
|
|
|
* @ingroup Media
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Stuff specific to JPEG and (built-in) TIFF handler.
|
|
|
|
|
* All metadata related, since both JPEG and TIFF support Exif.
|
|
|
|
|
*
|
|
|
|
|
* @ingroup Media
|
|
|
|
|
*/
|
2011-06-17 03:37:59 +00:00
|
|
|
class ExifBitmapHandler extends BitmapHandler {
|
2011-04-20 23:15:13 +00:00
|
|
|
const BROKEN_FILE = '-1'; // error extracting metadata
|
|
|
|
|
const OLD_BROKEN_FILE = '0'; // outdated error extracting metadata.
|
|
|
|
|
|
|
|
|
|
function convertMetadataVersion( $metadata, $version = 1 ) {
|
|
|
|
|
// basically flattens arrays.
|
2016-02-17 19:54:59 +00:00
|
|
|
$version = intval( explode( ';', $version, 2 )[0] );
|
2011-04-20 23:15:13 +00:00
|
|
|
if ( $version < 1 || $version >= 2 ) {
|
|
|
|
|
return $metadata;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$avoidHtml = true;
|
|
|
|
|
|
|
|
|
|
if ( !is_array( $metadata ) ) {
|
|
|
|
|
$metadata = unserialize( $metadata );
|
|
|
|
|
}
|
|
|
|
|
if ( !isset( $metadata['MEDIAWIKI_EXIF_VERSION'] ) || $metadata['MEDIAWIKI_EXIF_VERSION'] != 2 ) {
|
|
|
|
|
return $metadata;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Treat Software as a special case because in can contain
|
|
|
|
|
// an array of (SoftwareName, Version).
|
2013-03-24 10:01:51 +00:00
|
|
|
if ( isset( $metadata['Software'] )
|
2011-12-27 00:28:23 +00:00
|
|
|
&& is_array( $metadata['Software'] )
|
2013-03-24 10:01:51 +00:00
|
|
|
&& is_array( $metadata['Software'][0] )
|
2011-04-20 23:15:13 +00:00
|
|
|
&& isset( $metadata['Software'][0][0] )
|
2013-03-24 10:01:51 +00:00
|
|
|
&& isset( $metadata['Software'][0][1] )
|
2013-02-03 19:42:08 +00:00
|
|
|
) {
|
2011-04-20 23:15:13 +00:00
|
|
|
$metadata['Software'] = $metadata['Software'][0][0] . ' (Version '
|
|
|
|
|
. $metadata['Software'][0][1] . ')';
|
|
|
|
|
}
|
|
|
|
|
|
2013-08-07 23:03:34 +00:00
|
|
|
$formatter = new FormatMetadata;
|
|
|
|
|
|
2011-04-20 23:15:13 +00:00
|
|
|
// ContactInfo also has to be dealt with specially
|
|
|
|
|
if ( isset( $metadata['Contact'] ) ) {
|
|
|
|
|
$metadata['Contact'] =
|
2013-08-07 23:03:34 +00:00
|
|
|
$formatter->collapseContactInfo(
|
2011-04-20 23:15:13 +00:00
|
|
|
$metadata['Contact'] );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
foreach ( $metadata as &$val ) {
|
|
|
|
|
if ( is_array( $val ) ) {
|
2013-08-07 23:03:34 +00:00
|
|
|
$val = $formatter->flattenArrayReal( $val, 'ul', $avoidHtml );
|
2011-04-20 23:15:13 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
$metadata['MEDIAWIKI_EXIF_VERSION'] = 1;
|
2013-12-05 10:05:05 +00:00
|
|
|
|
2011-04-20 23:15:13 +00:00
|
|
|
return $metadata;
|
|
|
|
|
}
|
|
|
|
|
|
2013-12-05 19:27:27 +00:00
|
|
|
/**
|
2014-04-20 19:16:57 +00:00
|
|
|
* @param File $image
|
2013-12-05 19:27:27 +00:00
|
|
|
* @param array $metadata
|
|
|
|
|
* @return bool|int
|
|
|
|
|
*/
|
2011-04-20 23:15:13 +00:00
|
|
|
function isMetadataValid( $image, $metadata ) {
|
|
|
|
|
global $wgShowEXIF;
|
|
|
|
|
if ( !$wgShowEXIF ) {
|
|
|
|
|
# Metadata disabled and so an empty field is expected
|
|
|
|
|
return self::METADATA_GOOD;
|
|
|
|
|
}
|
|
|
|
|
if ( $metadata === self::OLD_BROKEN_FILE ) {
|
2013-05-10 11:51:06 +00:00
|
|
|
# Old special value indicating that there is no Exif data in the file.
|
2011-04-20 23:15:13 +00:00
|
|
|
# or that there was an error well extracting the metadata.
|
2013-02-09 22:03:53 +00:00
|
|
|
wfDebug( __METHOD__ . ": back-compat version\n" );
|
2013-12-05 10:05:05 +00:00
|
|
|
|
2011-04-20 23:15:13 +00:00
|
|
|
return self::METADATA_COMPATIBLE;
|
|
|
|
|
}
|
|
|
|
|
if ( $metadata === self::BROKEN_FILE ) {
|
|
|
|
|
return self::METADATA_GOOD;
|
|
|
|
|
}
|
2015-06-10 18:29:05 +00:00
|
|
|
MediaWiki\suppressWarnings();
|
2011-04-20 23:15:13 +00:00
|
|
|
$exif = unserialize( $metadata );
|
2015-06-10 18:29:05 +00:00
|
|
|
MediaWiki\restoreWarnings();
|
2013-12-01 20:39:00 +00:00
|
|
|
if ( !isset( $exif['MEDIAWIKI_EXIF_VERSION'] )
|
|
|
|
|
|| $exif['MEDIAWIKI_EXIF_VERSION'] != Exif::version()
|
|
|
|
|
) {
|
|
|
|
|
if ( isset( $exif['MEDIAWIKI_EXIF_VERSION'] )
|
|
|
|
|
&& $exif['MEDIAWIKI_EXIF_VERSION'] == 1
|
|
|
|
|
) {
|
2015-09-11 13:44:59 +00:00
|
|
|
// back-compatible but old
|
2013-02-03 19:42:08 +00:00
|
|
|
wfDebug( __METHOD__ . ": back-compat version\n" );
|
2013-12-05 10:05:05 +00:00
|
|
|
|
2011-04-20 23:15:13 +00:00
|
|
|
return self::METADATA_COMPATIBLE;
|
|
|
|
|
}
|
|
|
|
|
# Wrong (non-compatible) version
|
2013-02-03 19:42:08 +00:00
|
|
|
wfDebug( __METHOD__ . ": wrong version\n" );
|
2013-12-05 10:05:05 +00:00
|
|
|
|
2011-04-20 23:15:13 +00:00
|
|
|
return self::METADATA_BAD;
|
|
|
|
|
}
|
2013-12-05 10:05:05 +00:00
|
|
|
|
2011-04-20 23:15:13 +00:00
|
|
|
return self::METADATA_GOOD;
|
|
|
|
|
}
|
|
|
|
|
|
2011-05-28 16:31:00 +00:00
|
|
|
/**
|
2013-12-05 19:27:27 +00:00
|
|
|
* @param File $image
|
2014-12-28 20:31:34 +00:00
|
|
|
* @param bool|IContextSource $context Context to use (optional)
|
2011-05-28 16:31:00 +00:00
|
|
|
* @return array|bool
|
|
|
|
|
*/
|
2014-12-28 20:31:34 +00:00
|
|
|
function formatMetadata( $image, $context = false ) {
|
2013-08-28 23:09:07 +00:00
|
|
|
$meta = $this->getCommonMetaArray( $image );
|
|
|
|
|
if ( count( $meta ) === 0 ) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
|
2014-12-28 20:31:34 +00:00
|
|
|
return $this->formatMetadataHelper( $meta, $context );
|
2013-08-28 23:09:07 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function getCommonMetaArray( File $file ) {
|
|
|
|
|
$metadata = $file->getMetadata();
|
2013-12-01 20:39:00 +00:00
|
|
|
if ( $metadata === self::OLD_BROKEN_FILE
|
|
|
|
|
|| $metadata === self::BROKEN_FILE
|
|
|
|
|
|| $this->isMetadataValid( $file, $metadata ) === self::METADATA_BAD
|
|
|
|
|
) {
|
2011-04-20 23:15:13 +00:00
|
|
|
// So we don't try and display metadata from PagedTiffHandler
|
|
|
|
|
// for example when using InstantCommons.
|
2016-02-17 09:09:32 +00:00
|
|
|
return [];
|
2011-04-20 23:15:13 +00:00
|
|
|
}
|
|
|
|
|
|
2011-07-06 18:47:35 +00:00
|
|
|
$exif = unserialize( $metadata );
|
2011-04-20 23:15:13 +00:00
|
|
|
if ( !$exif ) {
|
2016-02-17 09:09:32 +00:00
|
|
|
return [];
|
2011-04-20 23:15:13 +00:00
|
|
|
}
|
|
|
|
|
unset( $exif['MEDIAWIKI_EXIF_VERSION'] );
|
2013-08-28 23:09:07 +00:00
|
|
|
|
|
|
|
|
return $exif;
|
2011-04-20 23:15:13 +00:00
|
|
|
}
|
|
|
|
|
|
2011-05-28 16:31:00 +00:00
|
|
|
function getMetadataType( $image ) {
|
|
|
|
|
return 'exif';
|
|
|
|
|
}
|
* (bug 6672, 31024) Fixes for handling of images with an EXIF orientation
- sets an image's reported width/height to the logical form (portait image reports itself as portait)
- everything works in logical coordinates when sizing -- we don't touch the physical pre-rotation dimensions again until it's actual low-level resize time. This fixes several problems with incorrect thumb sizing (eg getting a 600x800 image when we asked for something that fits in 800x600 box)
- fixes unit test cases in ExifRotationTest that were reporting that the width/height were coming back with the physical form which we don't want
- removes some test cases on ExifRotationTest that tested dimension swapping in a place where we don't want it
- ensures that only logical width/height need be exposed to API etc, making exif-rotated images work via ForeignAPIRepo
Note that this may actually cause file metadata to get loaded twice during File::getPropsFromPath, as the $image parameter it passes in to the handler's getImageSize function is bogus and can't be used to fetch an already-loaded metadata blob. This should not generally be too expensive though; it's not a fast path.
Rotated files that were uploaded under previous versions may still have their width/height reversed; an action=purge on the file page will refresh it and cause thumbs to be regenerated.
Follows up on r79845, r90016, r92246, r92279, r96687, r97651, r97656, r97659.
Needs merge to 1.18.
2011-09-20 22:13:34 +00:00
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Wrapper for base classes ImageHandler::getImageSize() that checks for
|
|
|
|
|
* rotation reported from metadata and swaps the sizes to match.
|
|
|
|
|
*
|
2016-09-19 01:39:59 +00:00
|
|
|
* @param File|FSFile $image
|
* (bug 6672, 31024) Fixes for handling of images with an EXIF orientation
- sets an image's reported width/height to the logical form (portait image reports itself as portait)
- everything works in logical coordinates when sizing -- we don't touch the physical pre-rotation dimensions again until it's actual low-level resize time. This fixes several problems with incorrect thumb sizing (eg getting a 600x800 image when we asked for something that fits in 800x600 box)
- fixes unit test cases in ExifRotationTest that were reporting that the width/height were coming back with the physical form which we don't want
- removes some test cases on ExifRotationTest that tested dimension swapping in a place where we don't want it
- ensures that only logical width/height need be exposed to API etc, making exif-rotated images work via ForeignAPIRepo
Note that this may actually cause file metadata to get loaded twice during File::getPropsFromPath, as the $image parameter it passes in to the handler's getImageSize function is bogus and can't be used to fetch an already-loaded metadata blob. This should not generally be too expensive though; it's not a fast path.
Rotated files that were uploaded under previous versions may still have their width/height reversed; an action=purge on the file page will refresh it and cause thumbs to be regenerated.
Follows up on r79845, r90016, r92246, r92279, r96687, r97651, r97656, r97659.
Needs merge to 1.18.
2011-09-20 22:13:34 +00:00
|
|
|
* @param string $path
|
|
|
|
|
* @return array
|
|
|
|
|
*/
|
|
|
|
|
function getImageSize( $image, $path ) {
|
|
|
|
|
$gis = parent::getImageSize( $image, $path );
|
2011-12-27 00:28:23 +00:00
|
|
|
|
2011-12-20 03:52:06 +00:00
|
|
|
// Don't just call $image->getMetadata(); FSFile::getPropsFromPath() calls us with a bogus object.
|
* (bug 6672, 31024) Fixes for handling of images with an EXIF orientation
- sets an image's reported width/height to the logical form (portait image reports itself as portait)
- everything works in logical coordinates when sizing -- we don't touch the physical pre-rotation dimensions again until it's actual low-level resize time. This fixes several problems with incorrect thumb sizing (eg getting a 600x800 image when we asked for something that fits in 800x600 box)
- fixes unit test cases in ExifRotationTest that were reporting that the width/height were coming back with the physical form which we don't want
- removes some test cases on ExifRotationTest that tested dimension swapping in a place where we don't want it
- ensures that only logical width/height need be exposed to API etc, making exif-rotated images work via ForeignAPIRepo
Note that this may actually cause file metadata to get loaded twice during File::getPropsFromPath, as the $image parameter it passes in to the handler's getImageSize function is bogus and can't be used to fetch an already-loaded metadata blob. This should not generally be too expensive though; it's not a fast path.
Rotated files that were uploaded under previous versions may still have their width/height reversed; an action=purge on the file page will refresh it and cause thumbs to be regenerated.
Follows up on r79845, r90016, r92246, r92279, r96687, r97651, r97656, r97659.
Needs merge to 1.18.
2011-09-20 22:13:34 +00:00
|
|
|
// This may mean we read EXIF data twice on initial upload.
|
2014-07-09 20:03:31 +00:00
|
|
|
if ( $this->autoRotateEnabled() ) {
|
2011-11-11 04:09:05 +00:00
|
|
|
$meta = $this->getMetadata( $image, $path );
|
|
|
|
|
$rotation = $this->getRotationForExif( $meta );
|
|
|
|
|
} else {
|
|
|
|
|
$rotation = 0;
|
|
|
|
|
}
|
* (bug 6672, 31024) Fixes for handling of images with an EXIF orientation
- sets an image's reported width/height to the logical form (portait image reports itself as portait)
- everything works in logical coordinates when sizing -- we don't touch the physical pre-rotation dimensions again until it's actual low-level resize time. This fixes several problems with incorrect thumb sizing (eg getting a 600x800 image when we asked for something that fits in 800x600 box)
- fixes unit test cases in ExifRotationTest that were reporting that the width/height were coming back with the physical form which we don't want
- removes some test cases on ExifRotationTest that tested dimension swapping in a place where we don't want it
- ensures that only logical width/height need be exposed to API etc, making exif-rotated images work via ForeignAPIRepo
Note that this may actually cause file metadata to get loaded twice during File::getPropsFromPath, as the $image parameter it passes in to the handler's getImageSize function is bogus and can't be used to fetch an already-loaded metadata blob. This should not generally be too expensive though; it's not a fast path.
Rotated files that were uploaded under previous versions may still have their width/height reversed; an action=purge on the file page will refresh it and cause thumbs to be regenerated.
Follows up on r79845, r90016, r92246, r92279, r96687, r97651, r97656, r97659.
Needs merge to 1.18.
2011-09-20 22:13:34 +00:00
|
|
|
|
2013-02-03 19:42:08 +00:00
|
|
|
if ( $rotation == 90 || $rotation == 270 ) {
|
* (bug 6672, 31024) Fixes for handling of images with an EXIF orientation
- sets an image's reported width/height to the logical form (portait image reports itself as portait)
- everything works in logical coordinates when sizing -- we don't touch the physical pre-rotation dimensions again until it's actual low-level resize time. This fixes several problems with incorrect thumb sizing (eg getting a 600x800 image when we asked for something that fits in 800x600 box)
- fixes unit test cases in ExifRotationTest that were reporting that the width/height were coming back with the physical form which we don't want
- removes some test cases on ExifRotationTest that tested dimension swapping in a place where we don't want it
- ensures that only logical width/height need be exposed to API etc, making exif-rotated images work via ForeignAPIRepo
Note that this may actually cause file metadata to get loaded twice during File::getPropsFromPath, as the $image parameter it passes in to the handler's getImageSize function is bogus and can't be used to fetch an already-loaded metadata blob. This should not generally be too expensive though; it's not a fast path.
Rotated files that were uploaded under previous versions may still have their width/height reversed; an action=purge on the file page will refresh it and cause thumbs to be regenerated.
Follows up on r79845, r90016, r92246, r92279, r96687, r97651, r97656, r97659.
Needs merge to 1.18.
2011-09-20 22:13:34 +00:00
|
|
|
$width = $gis[0];
|
|
|
|
|
$gis[0] = $gis[1];
|
|
|
|
|
$gis[1] = $width;
|
|
|
|
|
}
|
2013-12-05 10:05:05 +00:00
|
|
|
|
* (bug 6672, 31024) Fixes for handling of images with an EXIF orientation
- sets an image's reported width/height to the logical form (portait image reports itself as portait)
- everything works in logical coordinates when sizing -- we don't touch the physical pre-rotation dimensions again until it's actual low-level resize time. This fixes several problems with incorrect thumb sizing (eg getting a 600x800 image when we asked for something that fits in 800x600 box)
- fixes unit test cases in ExifRotationTest that were reporting that the width/height were coming back with the physical form which we don't want
- removes some test cases on ExifRotationTest that tested dimension swapping in a place where we don't want it
- ensures that only logical width/height need be exposed to API etc, making exif-rotated images work via ForeignAPIRepo
Note that this may actually cause file metadata to get loaded twice during File::getPropsFromPath, as the $image parameter it passes in to the handler's getImageSize function is bogus and can't be used to fetch an already-loaded metadata blob. This should not generally be too expensive though; it's not a fast path.
Rotated files that were uploaded under previous versions may still have their width/height reversed; an action=purge on the file page will refresh it and cause thumbs to be regenerated.
Follows up on r79845, r90016, r92246, r92279, r96687, r97651, r97656, r97659.
Needs merge to 1.18.
2011-09-20 22:13:34 +00:00
|
|
|
return $gis;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* On supporting image formats, try to read out the low-level orientation
|
|
|
|
|
* of the file and return the angle that the file needs to be rotated to
|
|
|
|
|
* be viewed.
|
|
|
|
|
*
|
|
|
|
|
* This information is only useful when manipulating the original file;
|
|
|
|
|
* the width and height we normally work with is logical, and will match
|
|
|
|
|
* any produced output views.
|
|
|
|
|
*
|
2014-04-20 19:16:57 +00:00
|
|
|
* @param File $file
|
* (bug 6672, 31024) Fixes for handling of images with an EXIF orientation
- sets an image's reported width/height to the logical form (portait image reports itself as portait)
- everything works in logical coordinates when sizing -- we don't touch the physical pre-rotation dimensions again until it's actual low-level resize time. This fixes several problems with incorrect thumb sizing (eg getting a 600x800 image when we asked for something that fits in 800x600 box)
- fixes unit test cases in ExifRotationTest that were reporting that the width/height were coming back with the physical form which we don't want
- removes some test cases on ExifRotationTest that tested dimension swapping in a place where we don't want it
- ensures that only logical width/height need be exposed to API etc, making exif-rotated images work via ForeignAPIRepo
Note that this may actually cause file metadata to get loaded twice during File::getPropsFromPath, as the $image parameter it passes in to the handler's getImageSize function is bogus and can't be used to fetch an already-loaded metadata blob. This should not generally be too expensive though; it's not a fast path.
Rotated files that were uploaded under previous versions may still have their width/height reversed; an action=purge on the file page will refresh it and cause thumbs to be regenerated.
Follows up on r79845, r90016, r92246, r92279, r96687, r97651, r97656, r97659.
Needs merge to 1.18.
2011-09-20 22:13:34 +00:00
|
|
|
* @return int 0, 90, 180 or 270
|
|
|
|
|
*/
|
|
|
|
|
public function getRotation( $file ) {
|
2014-07-09 20:03:31 +00:00
|
|
|
if ( !$this->autoRotateEnabled() ) {
|
2011-10-15 20:30:37 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
2011-12-27 00:28:23 +00:00
|
|
|
|
* (bug 6672, 31024) Fixes for handling of images with an EXIF orientation
- sets an image's reported width/height to the logical form (portait image reports itself as portait)
- everything works in logical coordinates when sizing -- we don't touch the physical pre-rotation dimensions again until it's actual low-level resize time. This fixes several problems with incorrect thumb sizing (eg getting a 600x800 image when we asked for something that fits in 800x600 box)
- fixes unit test cases in ExifRotationTest that were reporting that the width/height were coming back with the physical form which we don't want
- removes some test cases on ExifRotationTest that tested dimension swapping in a place where we don't want it
- ensures that only logical width/height need be exposed to API etc, making exif-rotated images work via ForeignAPIRepo
Note that this may actually cause file metadata to get loaded twice during File::getPropsFromPath, as the $image parameter it passes in to the handler's getImageSize function is bogus and can't be used to fetch an already-loaded metadata blob. This should not generally be too expensive though; it's not a fast path.
Rotated files that were uploaded under previous versions may still have their width/height reversed; an action=purge on the file page will refresh it and cause thumbs to be regenerated.
Follows up on r79845, r90016, r92246, r92279, r96687, r97651, r97656, r97659.
Needs merge to 1.18.
2011-09-20 22:13:34 +00:00
|
|
|
$data = $file->getMetadata();
|
2013-12-05 10:05:05 +00:00
|
|
|
|
2013-03-08 12:07:32 +00:00
|
|
|
return $this->getRotationForExif( $data );
|
* (bug 6672, 31024) Fixes for handling of images with an EXIF orientation
- sets an image's reported width/height to the logical form (portait image reports itself as portait)
- everything works in logical coordinates when sizing -- we don't touch the physical pre-rotation dimensions again until it's actual low-level resize time. This fixes several problems with incorrect thumb sizing (eg getting a 600x800 image when we asked for something that fits in 800x600 box)
- fixes unit test cases in ExifRotationTest that were reporting that the width/height were coming back with the physical form which we don't want
- removes some test cases on ExifRotationTest that tested dimension swapping in a place where we don't want it
- ensures that only logical width/height need be exposed to API etc, making exif-rotated images work via ForeignAPIRepo
Note that this may actually cause file metadata to get loaded twice during File::getPropsFromPath, as the $image parameter it passes in to the handler's getImageSize function is bogus and can't be used to fetch an already-loaded metadata blob. This should not generally be too expensive though; it's not a fast path.
Rotated files that were uploaded under previous versions may still have their width/height reversed; an action=purge on the file page will refresh it and cause thumbs to be regenerated.
Follows up on r79845, r90016, r92246, r92279, r96687, r97651, r97656, r97659.
Needs merge to 1.18.
2011-09-20 22:13:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Given a chunk of serialized Exif metadata, return the orientation as
|
|
|
|
|
* degrees of rotation.
|
|
|
|
|
*
|
|
|
|
|
* @param string $data
|
|
|
|
|
* @return int 0, 90, 180 or 270
|
2013-12-05 19:27:27 +00:00
|
|
|
* @todo FIXME: Orientation can include flipping as well; see if this is an issue!
|
* (bug 6672, 31024) Fixes for handling of images with an EXIF orientation
- sets an image's reported width/height to the logical form (portait image reports itself as portait)
- everything works in logical coordinates when sizing -- we don't touch the physical pre-rotation dimensions again until it's actual low-level resize time. This fixes several problems with incorrect thumb sizing (eg getting a 600x800 image when we asked for something that fits in 800x600 box)
- fixes unit test cases in ExifRotationTest that were reporting that the width/height were coming back with the physical form which we don't want
- removes some test cases on ExifRotationTest that tested dimension swapping in a place where we don't want it
- ensures that only logical width/height need be exposed to API etc, making exif-rotated images work via ForeignAPIRepo
Note that this may actually cause file metadata to get loaded twice during File::getPropsFromPath, as the $image parameter it passes in to the handler's getImageSize function is bogus and can't be used to fetch an already-loaded metadata blob. This should not generally be too expensive though; it's not a fast path.
Rotated files that were uploaded under previous versions may still have their width/height reversed; an action=purge on the file page will refresh it and cause thumbs to be regenerated.
Follows up on r79845, r90016, r92246, r92279, r96687, r97651, r97656, r97659.
Needs merge to 1.18.
2011-09-20 22:13:34 +00:00
|
|
|
*/
|
|
|
|
|
protected function getRotationForExif( $data ) {
|
|
|
|
|
if ( !$data ) {
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
2015-06-10 18:29:05 +00:00
|
|
|
MediaWiki\suppressWarnings();
|
* (bug 6672, 31024) Fixes for handling of images with an EXIF orientation
- sets an image's reported width/height to the logical form (portait image reports itself as portait)
- everything works in logical coordinates when sizing -- we don't touch the physical pre-rotation dimensions again until it's actual low-level resize time. This fixes several problems with incorrect thumb sizing (eg getting a 600x800 image when we asked for something that fits in 800x600 box)
- fixes unit test cases in ExifRotationTest that were reporting that the width/height were coming back with the physical form which we don't want
- removes some test cases on ExifRotationTest that tested dimension swapping in a place where we don't want it
- ensures that only logical width/height need be exposed to API etc, making exif-rotated images work via ForeignAPIRepo
Note that this may actually cause file metadata to get loaded twice during File::getPropsFromPath, as the $image parameter it passes in to the handler's getImageSize function is bogus and can't be used to fetch an already-loaded metadata blob. This should not generally be too expensive though; it's not a fast path.
Rotated files that were uploaded under previous versions may still have their width/height reversed; an action=purge on the file page will refresh it and cause thumbs to be regenerated.
Follows up on r79845, r90016, r92246, r92279, r96687, r97651, r97656, r97659.
Needs merge to 1.18.
2011-09-20 22:13:34 +00:00
|
|
|
$data = unserialize( $data );
|
2015-06-10 18:29:05 +00:00
|
|
|
MediaWiki\restoreWarnings();
|
* (bug 6672, 31024) Fixes for handling of images with an EXIF orientation
- sets an image's reported width/height to the logical form (portait image reports itself as portait)
- everything works in logical coordinates when sizing -- we don't touch the physical pre-rotation dimensions again until it's actual low-level resize time. This fixes several problems with incorrect thumb sizing (eg getting a 600x800 image when we asked for something that fits in 800x600 box)
- fixes unit test cases in ExifRotationTest that were reporting that the width/height were coming back with the physical form which we don't want
- removes some test cases on ExifRotationTest that tested dimension swapping in a place where we don't want it
- ensures that only logical width/height need be exposed to API etc, making exif-rotated images work via ForeignAPIRepo
Note that this may actually cause file metadata to get loaded twice during File::getPropsFromPath, as the $image parameter it passes in to the handler's getImageSize function is bogus and can't be used to fetch an already-loaded metadata blob. This should not generally be too expensive though; it's not a fast path.
Rotated files that were uploaded under previous versions may still have their width/height reversed; an action=purge on the file page will refresh it and cause thumbs to be regenerated.
Follows up on r79845, r90016, r92246, r92279, r96687, r97651, r97656, r97659.
Needs merge to 1.18.
2011-09-20 22:13:34 +00:00
|
|
|
if ( isset( $data['Orientation'] ) ) {
|
|
|
|
|
# See http://sylvana.net/jpegcrop/exif_orientation.html
|
|
|
|
|
switch ( $data['Orientation'] ) {
|
|
|
|
|
case 8:
|
|
|
|
|
return 90;
|
|
|
|
|
case 3:
|
|
|
|
|
return 180;
|
|
|
|
|
case 6:
|
|
|
|
|
return 270;
|
|
|
|
|
default:
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
2013-12-05 10:05:05 +00:00
|
|
|
|
* (bug 6672, 31024) Fixes for handling of images with an EXIF orientation
- sets an image's reported width/height to the logical form (portait image reports itself as portait)
- everything works in logical coordinates when sizing -- we don't touch the physical pre-rotation dimensions again until it's actual low-level resize time. This fixes several problems with incorrect thumb sizing (eg getting a 600x800 image when we asked for something that fits in 800x600 box)
- fixes unit test cases in ExifRotationTest that were reporting that the width/height were coming back with the physical form which we don't want
- removes some test cases on ExifRotationTest that tested dimension swapping in a place where we don't want it
- ensures that only logical width/height need be exposed to API etc, making exif-rotated images work via ForeignAPIRepo
Note that this may actually cause file metadata to get loaded twice during File::getPropsFromPath, as the $image parameter it passes in to the handler's getImageSize function is bogus and can't be used to fetch an already-loaded metadata blob. This should not generally be too expensive though; it's not a fast path.
Rotated files that were uploaded under previous versions may still have their width/height reversed; an action=purge on the file page will refresh it and cause thumbs to be regenerated.
Follows up on r79845, r90016, r92246, r92279, r96687, r97651, r97656, r97659.
Needs merge to 1.18.
2011-09-20 22:13:34 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
2011-04-20 23:15:13 +00:00
|
|
|
}
|