Exif tag "Orientation"

[ottogal]

Uploading image files to the image field of a page, I get a problem if the original file has the Exif tag "Orientation" set to "Right top":

The auto-created admin-thumbnail obviously doesn't get the Exif information. So while the image itself is auto-rotated to be displayed "upright" (in backend and frontend), the thumbnail is not.
To get this "repaired", do I have to use an external image processing software to rotate these images manually?

[horst]

The Imagesizer detects the settings of the Exif orientation tag and autocorrects this where needed, if it is enabled.

The setting to enable / disable this for all variations can be set in $config->imageSizerOptions "autoRotation". The default is true:

$config->imageSizerOptions = array(
	'upscaling' => true,     // upscale if necessary to reach target size?
	'cropping' => true,      // crop if necessary to reach target size?
   'autoRotation' => true,  // automatically correct orientation?
	'sharpening' => 'soft',  // sharpening: none | soft | medium | strong
	'quality' => 90,         // quality: 1-100 where higher is better but bigger
	'hidpiQuality' => 60,    // Same as above quality setting, but specific to hidpi images
	'defaultGamma' => 2.0,   // defaultGamma: 0.5 to 4.0 or -1 to disable gamma correction (default=2.0)
	);

There is an extra setting for this for AdminThumbs, default is true, too:

$config->adminThumbOptions = array(
        'width' => 0,            // max width of admin thumbnail or 0 for proportional to height
        'height' => 100,         // max height of admin thumbnail or 0 for proportional to width
        'scale' => 1,            // admin thumb scale (1=auto detect, 0.5=always hidpi, 1.0=force non-hidpi)
        'upscaling' => false,
        'cropping' => true,
    'autoRotation' => true,      // automatically correct orientation?
        'sharpening' => 'soft',  // sharpening: none | soft | medium | strong
        'quality' => 90,
        'suffix' => '',
    );

Please ensure that you have autoRotation set to true for both use cases.

[ottogal]

Thank you, Horst. But it seems that the auto-created admin-thumbnail doesn't receive the Exif information from the original image: Using IrfanView and its plugin METADATA.DLL, I open the thumbnail and look into Image>Information - I don't even see the button "Exif info" (which is there on the original image).

[LostKobrakai]

I'm not sure, but probably the image resizer just reads the exif data before resizing, turns the image if needed and discards them afterwards. 

[ottogal]

But obviously the image resizer rotates just the large version, not the thumbnail. Shouldn't it do this too, before it discards the Exif info?

[mr-fan]

Had the same Problem on some Installations - what camera produce the images - happen this with all images only with client's images?

[HannaP]

Have noticed this too, with a friend's site. He uses a Canon Camera. Large versions are fine, but thumbnails are not.

[ottogal]

I encountered the issue after having imported a bunch of images from a folder in the file system. (They have been used before on a website made with Modx Evo, where it never happened.) These images have been shot by various cameras; the issue occurs f.e. with the Canon IXUS 750.

But I don't understand why the camera model is of interest: The thumbnails created by ProcessWire are using the original image, containing the Exif data. Hence something is wrong with this thumbnail creation, isn't it? (Or I'm doing something stupid.)

[BitPoet]

Hence something is wrong with this thumbnail creation, isn't it?

GD doesn't really deal with Exif (it can read the information, but that's it), so any image created through GD is going to end up without Exif information. From what I saw in the code of ImageResizer, IPTC (semantic information) is copied over to the new image but not Exif. All freeware PHP projects with Exif write support I know of are either dead or gone.

[adrian]

All freeware PHP projects with Exif write support I know of are either dead or gone.

More of an FYI than anything - this is the one I have always used: http://www.ozhiker.com/electronics/pjmt/

It doesn't seem to be actively maintained anymore, but it has always worked for me as needed.

[BitPoet]

So now things are getting really wierd, as I'm sure when I tested it at work, I could reproduce the problem. Now at home and on a different server, I can't. The thumbnail comes out rotated correctly (without Exif information, of course).

[horst]

But I don't understand why the camera model is of interest: The thumbnails created by ProcessWire are using the original image, containing the Exif data. Hence something is wrong with this thumbnail creation, isn't it? (Or I'm doing something stupid.)

I fully agree. From a logical point of view, it is simply not possible, that the imagesizer does handle variation creations different. The imagesizer doesn't know about the disered target. It must have to do with something other.

As I have posted above, the ONLY difference between admin-thumbnails and other rezised variations is the default configuration. Therefore it is important that you doublecheck that all settings mentioned above ($config->imageSizerOptions => 'autoRotation' AND $config->adminThumbOptions=> 'autoRotation') are set identical. (and without typos!)

It would be really helpful if you can do a test as follows

• Copy both of these config settings into the site/config.php, if not already there.
• Set both autoRotation settings to false
• Somewhere in a template file get you one of the problematic images, $page->images->get("name=problematic.jpg")
• and run an image call like this:

$image = $page->images->get("name=problematic.jpg");
if($image) {
    $image->removeVariations();   // remove all variations, including AdminThumb
    $image = $image->width(intval($image->width / 2));  // create a new, halfsized variation
    echo "<img src='{$image->url}' />";
}

You now should see a halfsized image, not corrected in rotation.

Now go into the backend edit page, where PW will create a new adminthumb. The adminthumb also should be displayed without autocorrection. If you click onto it to view the original image, this also isn't autocorrected. All three images should have the identical orientation.

Ok, step 2:

• set autoRotation for both settings to true
• call the page with the code from above with the same problematic image
• and report back which image variation has what orientation:

  frontend, halfsized is in right orientation: yes [ ] - no [ ]

  backend Original    is in right orientation: yes [ ] - no [ ]

  backend Thumbnal    is in right orientation: yes [ ] - no [ ]

And please doublecheck the config settings before testing.

If this will not show matching results, we have to look into Pageimage, what is the instance just before imagesizer. But before that, I want to be sure that there is no misconfiguration.

[HannaP]

Even with AutoRotate set to true I have some photos that won't be rotated . They are ok in large version, but not in admin thumb.

I noticed that they have something like this in their exif-tag:

Camera Model Name  : Canon EOS 450D
Orientation    : Rotate 270 CW

whereas those that work fine have something like Orientation: bottom-left.

Maybe that helps ..
 

[horst]

@HannaP: Hi, this is not logical to me. I need to clarify what you mean with "They are ok in large version": Do you mean the original image or a resized variation?

---

Regarding exif-tag values: the PHP function exif_read_data() can extract the IFD0 marker from Exif where it looks for the value in key 'Orientation'. Orientation only holds an integer in the range of 1 - 8, what not only represents the orientation but also if it is flipped vertical or horizontal.

But neither 'bottom-left' nor 'Rotate 270 CW' will be stored there I assume. This sounds like the interpreted integer by two different softwares. Can you confirm this?

If you want to check the direct return from the function, use this to test, and if it is not an integer in the range 1-8, please report back and sent me such an image.

function checkOrientation($filename) {
    if(!function_exists('exif_read_data')) return false;
    $exif = @exif_read_data($filename, 'IFD0');
    if(!is_array($exif) || !isset($exif['Orientation'])) return false;
    return $exif['Orientation'];
}

var_dump(checkOrientation($page->images->get('name=problematic.jpg')->filename));

Edited January 27, 2016 by horst
corrected the function!

[ottogal]

@horst:

Strange things are going on.

As you proposed I set autoRotation to false in both the config settings imageSizerOptions and adminThumbOptions, and put your image call in a template, used by a newly created test page.

Result: Already with the upload of the test-image to the images field of the test page the created thumbnail was autorotated (i.e. displayed upright). Viewing the page, the half-sized image is oriented correctly, too.

Inserting the original, full sized image into the body field (textarea/CKEditor) resulted in an autorotated output (backend and frontend).

In the folder /site/assets/8765/ (where 8765 is the id of the test page) there is the file image test_1.jpg (width 600), not rotated like the original, and the half-sized image test_1.300x0.jpg, rotated to the correct orientation.  (*)

To crosscheck I reset the autoRotation settings in the config both back to true.

Now both the admin-thumbnail in the backend and the half-sized image in the frontend are displayed not rotated (the latter one, inserted by the template, of course doesn't show in the frontend). But the full sized image inserted via the CKEditor ist autorotated correctly, both in backend and frontend...

Thanks a lot, Horst, for your help!

(*)

Another strangeness: The original file I uploaded was test_1_.jpg, i.e. the name had a trailing underscore. This obviously is removed by PW processing the image.

(But I don't think that has any influence on the problem in discussion.)

EDIT:

I also called your function checkOrientation(), it returned nothing.

[horst]

Strange things are going on.

Indeed!

As you proposed I set autoRotation to false in both the config settings imageSizerOptions and adminThumbOptions, and put your image call in a template, used by a newly created test page.

Result: Already with the upload of the test-image to the images field of the test page the created thumbnail was autorotated (i.e. displayed upright). Viewing the page, the half-sized image is oriented correctly, too.

Inserting the original, full sized image into the body field (textarea/CKEditor) resulted in an autorotated output (backend and frontend).

In the folder /site/assets/8765/ (where 8765 is the id of the test page) there is the file image test_1.jpg (width 600), not rotated like the original, and the half-sized image test_1.300x0.jpg, rotated to the correct orientation. (*)

To crosscheck I reset the autoRotation settings in the config both back to true.

Now both the admin-thumbnail in the backend and the half-sized image in the frontend are displayed not rotated (the latter one, inserted by the template, of course doesn't show in the frontend). But the full sized image inserted via the CKEditor ist autorotated correctly, both in backend and frontend...

What you describe here is, that in the upload process the settings seems to be used toggled to its opposite.

I will check this by myself in the next days and report back here. Thank you for your help.

[horst]

 I also called your function checkOrientation(), it returned nothing.

Oh, sorry there was a bug in the function. I have corrected it above. But maybe we should use a more thouroughful checking function:

function checkOrientation($filename) {
    $out = array('file_exists' => file_exists($filename));
    $out['exif_read_data'] = function_exists('exif_read_data') ? 'TRUE' : 'FALSE';
    $exif = function_exists('exif_read_data') ? @exif_read_data($filename, 'IFD0') : null;
    $out['exif'] = (is_array($exif) ? 'TRUE' : 'FALSE');
    $out['exif["Orientation"]'] = (isset($exif['Orientation']) ? 'TRUE' : 'FALSE');
    $out['Orientation'] = htmlentities(strval($exif['Orientation']));
    $ret = '';
    foreach($out as $k => $v) $ret .= "<li>$k = $v</li>";
    return "<ul>$ret</ul>";
}
$image = $page->images->get('name=problematic.jpg');
$result = checkOrientation($image->filename);
// flush the $result to the browser, e.g. with echo,
// or add it to your delayed output buffer, if you uses one

[ottogal]

Applying your modified function on my test image I got this output:

file_exists = 1
exif_read_data = TRUE
exif = TRUE
exif["Orientation"] = TRUE
Orientation = 6

Searching the web for information on the Exif tag Orientation you find dozens of sites and forum posts which show the subject is really a complex one, given that various hardware and software is treating it differently. So asking for the camera model was not as far-fetched as it seemed...

Here's one link I found quite instructive:

http://www.impulseadventure.com/photo/exif-orientation.html

Edit: Two more links:

http://www.daveperrett.com/articles/2012/07/28/exif-orientation-handling-is-a-ghetto/

http://keyj.emphy.de/exif-orientation-rant/

[HannaP]

@horst

I refererred to the original image when talking about 'large' image. it's the one I see when clicking on a thumbnail in the backend.

I have two of those candidates that behave differently.

Thanks for clarifying about the orientation stuff of exif-tags. I didn't know that.  I used exiftool to output the CW 270 and gThumb for the other one.

I would like to send you a link via PM, so you can inspect those images further, if that helps.

[horst]

Applying your modified function on my test image I got this output:

It output is 6. Thats fine and indicates that the image should be rotated by 270 degrees. The imagesizer does handle this correct. WHat needs to be inspected is the way along through config settings merging by other modules / classes / instances that read / modify and merge those settings before they finally reach the imagesizer.

(e.g. Pageimage, ProcessPageEditImageSelect, etc)

@horst

I refererred to the original image when talking about 'large' image. it's the one I see when clicking on a thumbnail in the backend.

I have two of those candidates that behave differently.

Thanks for clarifying about the orientation stuff of exif-tags. I didn't know that.  I used exiftool to output the CW 270 and gThumb for the other one.

I would like to send you a link via PM, so you can inspect those images further, if that helps.

Thanks, i will look into this, maybe tomorrow, and report back.

[horst]

@HannaP: already done.

You sent me two images, whereas the original dog.jpg is displayed correct, and the original tree.jpg is displayed 90 degrees rotated.

Checking the settings in exif-Orientation outputs for both files 8, what indicates that they both need to be rotated by 90 degrees, what the imagesizer does. As result, you afterwards has one image displayed correct (the tree.jpg) and the dog.jpg is displayed wrong. But this depends on the wrong stored value in the file.

This image looks like it was manipulated after it came from the camera, because it contains a logo. I assume the software that merged the logo into it has corrected the orientation but hasn't updated the exif settings. That's simply it.

There is nothing that imagesizer can do here.

[LostKobrakai]

There is nothing that imagesizer can do here.

Except maybe a way to correct the issue in the admin.

[horst]

Except maybe a way to correct the issue in the admin.

Is this a bit nitpicking ?

I meant what imagesizer can do when completly acting automated.

Having a way to correct those wrong original images would be good. I'm not in this RTE usage, but I saw in imagesizer that there is already a setting for rotate that has nothing to do with autoRotation. Also, when I remember correct, wasn't there within the 2.6-dev branch already the ability to rotate images? Will this come back?

[LostKobrakai]

It might actually be I'm really not sure if there is a option to rotate images already. Haven't had the need for by now.

[horst]

 Strange things are going on.

@ottogal: I have found out that I have tricked me myself when changing settings for imageSizerOptions in site/config.php for testing.  I also have installed Pia, Pageimage Assistant module, what overrides some settings of site/config.php. So, those settings should be applied in the modules config page in that case.

As a result, I decided to removed this config settings from the module. I will upload a new version to github after I can reach there servers again. (currently unreachable from here).

Maybe you have installed Pia too?