Rotation and EXIF Orientation field

*** Please report new bugs here! ***

Moderator: Dreamer

User avatar
B.Douille
Posts: 182
Joined: Sat Sep 09, 2006 9:25 pm
Location: Hte Savoie - France

Re: Rotation and EXIF Orientation field

Post by B.Douille » Tue May 29, 2018 10:12 am

Yes
Daniel, promoting XnView since 2004 and now using MP only (Platform Windows 10 & Windows 7, both 64 bits)

CameronD
Posts: 295
Joined: Wed Aug 01, 2007 1:28 pm
Location: Australia

Re: Rotation and EXIF Orientation field

Post by CameronD » Wed Jun 06, 2018 2:58 pm

No wonder this is hard to get right. I have just spent two days (not full time) accumulating test cases and testing under various conditions.

I ended up with 26 test images, each tested under 4 different option conditions, under 3 different rotation operations. And that is by no means exhaustive, except what it did to me :( .

Let's start with what possible images configurations are possible, why they are a problem, and then what we think should happen - well, I'll tell you what I would like to happen and you can suggest otherwise.

When I say image is in normal orientation, I mean the image has been written to the file in such a way that it displays in the correct orientation when the orientation tag is ignored.

Possible image configurations:
  • No Orientation tag; Image in file is normal
  • No Orientation tag; Image in file is wrong This can happen for example with images from a scanner that does not write an orientation tag.
  • file has Orientation tag; Image in file is oriented correctly according to tag There are subsets to this, that sometimes lead to different responses from XnviewMP. A full set is provided by Karl02's test images:
    • mode 0: Orientation tag = 1 (normal); image is normal
    • mode 1: Orientation tag = 3, 6, 8 (pure rotate); image is correctly stored according to tag
    • Orientation tag = 2,4 (pure mirror); image is correctly stored
    • Orientation tag = 5,7 (mirror and rotate); image is correctly stored
  • file has Orientation tag; Image in file is not oriented according to tag This happens to me mainly when copying documents and the camera is pointing vertically down. Subsets are:
    • mode 2: Orientation tag = 1 (normal); image in file is rotated. Always displays wrongly
    • mode 3: Orientation tag is not 1 (normal); image in file is oriented normally. Displays wrongly if tag honoured
    • mode 4: Orientation tag is not 1 (normal); image in file is rotated but not as tags says Always displays wrongly
    My sample set included images with pixel dimensions being odd numbers and those with pixel dimensions at multiples of 16.
What are the problems?:
  • Some image viewers do not follow the Exif orientation tag and so display the image as it is stored in the file. (just about everything supplied with Windows 7 for a start). This is sometimes confounded by the built-in thumbnail stored in an orientation that does not match the full image. Even further confounded by many other programs caching their own copies of thumbnails.
  • Some image viewers (e.g. Picasa) do not understand all of the tags - pure rotate is OK, but any with a mirror flip is shown wrongly.
  • Image viewers that honour the Exif orientation tag will wrongly display the last set of images, and those that do not honour the tag might or might not display it correctly.
What is the solution?
The only way to avoid these problems is a follows:
Once I rotate an image, XnViewMP should assume I leave it in the correct orientation for viewing.
All images should be saved in the normal orientation, and the tag set to 1. This will display all images correctly with all viewers. The option to "Change EXIF orientation ONLY(if possible) can be used to disable this behaviour.
The only significant problem I can see is with images that cannot be rotated losslessly. (I do not regard automatic arbitrary cropping as "lossless" - in some cases that does more damage to the image than re-encoding.

What is the current behaviour?
In too many cases XnviewMP will write an image that is wrong with all viewers. In most conditions there will be at least one of the image types that will cause a problem with one viewer or another.

Unfortunately, it is getting late, and I will need to continue with posting my results and test images tomorrow.
Last edited by CameronD on Thu Jun 07, 2018 7:20 am, edited 2 times in total.

User avatar
B.Douille
Posts: 182
Joined: Sat Sep 09, 2006 9:25 pm
Location: Hte Savoie - France

Re: Rotation and EXIF Orientation field

Post by B.Douille » Thu Jun 07, 2018 5:44 am

Hi Cameron, I agree with tour recommendation, this is the way I use XnView for the reason you exposed. I wonder if you posted it in the wrong topic?
This one is about a bug where the application forget to reset the orientation tag to 1. I explain how to reproduce.

There is another topic about the options available and a proposal I made to simplify, make it easier to understand. To avoid confusion maybe your post can be moved there? viewtopic.php?f=60&t=30710&hilit=orientation

DBa
Daniel, promoting XnView since 2004 and now using MP only (Platform Windows 10 & Windows 7, both 64 bits)

CameronD
Posts: 295
Joined: Wed Aug 01, 2007 1:28 pm
Location: Australia

Re: Rotation and EXIF Orientation field

Post by CameronD » Thu Jun 07, 2018 5:57 am

B.Douille wrote:
Thu Jun 07, 2018 5:44 am
Hi Cameron, I agree with tour recommendation, this is the way I use XnView for the reason you exposed. I wonder if you posted it in the wrong topic?
This one is about a bug where the application forget to reset the orientation tag to 1. I explain how to reproduce.

There is another topic about the options available and a proposal I made to simplify, make it easier to understand. To avoid confusion maybe your post can be moved there? viewtopic.php?f=60&t=30710&hilit=orientation

DBa
I did deliberately post in this topic, because that is the main symptom that I see. I think the reason it can be hard to reproduce is that it only occurs in some combinations, which is why I am trying to investigate many combinations. I hope Pierre will be able to understand the problem - when I get around to listing my findings.

Edit:
While some of my comments fit well into your other post, this is eventually going to be mainly a bug report, so I think it belongs here.
On the other hand, instead of just fixing the immediate bugs, it might be a good time to examine your proposals to reconsider how rotation is treated overall.

CameronD
Posts: 295
Joined: Wed Aug 01, 2007 1:28 pm
Location: Australia

Re: Rotation and EXIF Orientation field

Post by CameronD » Thu Jun 07, 2018 8:58 am

Here is my set of test case images attached:
testcases-badorientation.zip
A set of test files, most with mismatch between orientation in file and the Exif orientation flag
(319.05 KiB) Downloaded 19 times
They are named mode-n_xxx where the mode number is defined in my post above.
  • Modes 0 and 1 will display correctly with a viewer that obeys the Exif orientation tag.
  • Modes 0 and 3 will display correctly with a viewer that ignores the Exif orientation tag.
  • Modes 2 and 4 always display incorrectly.
The Test Settings:
  1. I always update file modification date if I modify a file
  2. These tests were all done with Settings->General->General->"Rotate images according to EXIF orientation tag" set to enabled. I assume from other posts here that this is a display setting only.
  3. options in Settings->Browser->Misc are "Change EXIF Orientation ONLY (if possible)" and "Use lossless rotation (if possible)". Tests were done with each combination of these two enabled or disabled.
The Test Operations:
  1. Select all and batch convert all images to jpeg. This is good for removing the orientation tags that are not equal to 1. Images are automatically rotated and saved in normal orientation, so modes 0 and 1 always display correctly, whatever the viewer. All other modes are always wrong but this is not a bug - it is how I would expect when the orientation tag is wrong.
  2. In Browser mode: use the "rotate CW" or "rotate CCW" buttons to display the image correctly. then browse another folder and images are updated. Buttons are set to cmd_rotate90 and cmd_rotate270. For Karl02's test images I tried to trick it into saving updated copied by a rotate left then immediate rotate right.
  3. In single image Viewer mode, rotate each image as required using the "rotate CW" or "rotate CCW" buttons and then press ctrl-S to save the image and proceed to the next image. For Karl02's test images I did the same trick of a rotate left then immediate rotate right and save.
To keep track of everything I created 4 folders named with the 4 option possibilities: Exif_only-ON+lossless-ON, Exif_only-ON+lossless-OFF and so on.
Below them I created 3 more folders: Batch, Browser and Viewer. Then placed copies of the test images into each folder.

After processing all images, I examined them each with
  1. XvniewMP browser
  2. windows 7 file explorer
  3. Picasa previewer
  4. exiftool -Exif:Orientation -Exif:Orientation# *.jpg
Results:

The batch convert behaved almost as expected, and did not change with test conditions. I will not mention it further, except that all of Karl02's examples have a separate orientation tag for the embedded thumbnail in IFD1. I suppose this could be construed as correct operation, although the results might end up surprising in some cases where viewers do not honour the rotation tag. However, my format settings for jpeg write say enable for "Rebuild embedded thumbnail" :bug: ?

Images with no embedded orientation tag were always saved in the corrected orientation and no tag was added.

For Karl02's images in browser mode:
  • with the two Exif_only-ON conditions the images were not changed - not written at all.
  • For the Exif_only-OFF+lossless-OFF condition the images were rewritten, but the tag and image were the same
  • For the Exif_only-OFF+lossless-ON condition the images are cropped to a multiple of 16 pixels horizontally and sometimes vertically, and rewritten as mode-0 - tag is 1 and image orientation is normal. But, for the images that are tag 2 or 4 (flip only), the images display OK, but XnViewMP refuses to rebuild a proper thumbnail. I keep clicking on View->rebuild thumbnails and it ignores me. Make a new copy of the file, or touch the modified date and it still supplies an invalid thumbnail. The image is displayed properly in Viewer mode. So what seems to be happening is Option "Use embedded thumbnail" is enabled and "rebuild Thumbnail" seems to just copy the bad embedded thumbnail instead of actually rebuilding it as requested. :bug: Incidentally, the thumbnail in the transformed image is not the same as in the original image. The new thumbnail has one of the two rotations applied to it. :bug:
For Karl02's images in single image view mode following rotate 90, rotate back and save:
  • with all 4 conditions it invariably rewrites the image in the file to be viewed correctly if the tag is ignored.
  • However, in almost all cases, the orientation tag remains the same as in the original image - so XnviewMP now displays it the wrong way around :bug: .
    • This is independent of the value for the "use EXIF orientation tag".
    • If I set the option to not write lossless AND the orientation is 2 (flip horiz) or 5 (flip horiz and rotate 270) then the orientation tag is reset to 1 and the image is displayed correctly.
For my images in browser mode following rotating to look correct in XnViewMP:
  • with the Change_Exif_orientation_only-ON condition (either lossless setting) the images were not changed - but the tag is updated to correctly display the new orientation. Working as expected.
  • For the Change_Exif_orientation_only-OFF+lossless-ON condition: images are rewritten (if necessary) to be normal orientation in the file and the tag is always set to 1. So images always displays correctly.
  • For the Change_Exif_orientation_only-OFF+lossless-OFF condition: the images were rewritten to an orientation that matches the original tag. This means it now displays properly in XnViewMP, but not with viewers that do not use the orientation tag.
For my images in single image viewer mode following manual rotation to look correct in XnViewMP then (ctrl-S) save:
  • changing Change_Exif_orientation_only or Use_lossless-if-possible options did not affect the results.
  • The images are always written in the correct orientation to view ignoring the orientation tag;
  • The orientation tag remains unchanged, so the images look wrong in XnViewMP, except for mode-2 originals. :bug:

CameronD
Posts: 295
Joined: Wed Aug 01, 2007 1:28 pm
Location: Australia

Re: Rotation and EXIF Orientation field

Post by CameronD » Sun Jun 10, 2018 9:17 am

A short(er) summary:
There were not as many orientation bugs as I initially thought, but the important factor is to test all variations of tag and actual orientation.

Some were actual orientation bugs, and some were bugs in the way that XnViewMP generated or used the thumbnail. Because XnViewMP sometimes displayed a different orientation in the browser from what it showed in the single image view, what was actually a thumbnail bug looked like an orientation bug.

Thirdly, the program did not always behave in obvious ways - the clearest instance of this is between browser mode and single image view mode.
  • There seem to be very different rules applied when saving after rotation in the Browser compared to single image view. There are options for "write jpeg" but no equivalent options I can find for "write jpeg from browser". Options such as "rebuild embedded thumbnail" do not seem to apply.
  • Options "Rotation: Change EXIF Orientation only" and "Use lossless rotation": are only available in Browser view - there are no equivalents for single image view. Suggestion: on the option setting tab add the text: "Rotation: These options are only available in Browser view"
  • Lossless rotation. Suggestion:this should be tristate:
    • no lossless - use jpeg write compression options (I am guessing this is what happens)
    • use lossless - crop if necessary.
    • use lossless - only if cropping not needed (perfect lossless)
  • During JPEG format write there are no rules/options to control orientation. As far as I can see it always uses new encoding settings (as specified in the jpeg write options), so I cannot see any value in saving anything other than normal orientation. If users have good reasons for not wanting this then I suppose there are three option:
    1. Always convert image to normal orientation (tag 1)
    2. Save image oriented according to original orientation tag.
    3. Save image in original layout and adjust orientation tag to account for any rotation.

User avatar
xnview
Author of XnView
Posts: 29916
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Rotation and EXIF Orientation field

Post by xnview » Tue Jun 12, 2018 10:51 am

CameronD wrote:
Sun Jun 10, 2018 9:17 am
Some were actual orientation bugs, and some were bugs in the way that XnViewMP generated or used the thumbnail. Because XnViewMP sometimes displayed a different orientation in the browser from what it showed in the single image view, what was actually a thumbnail bug looked like an orientation bug.
do you have some sample files?
[*]There seem to be very different rules applied when saving after rotation in the Browser compared to single image view. There are options for "write jpeg" but no equivalent options I can find for "write jpeg from browser". Options such as "rebuild embedded thumbnail" do not seem to apply.
you have tools>Metadata>Rebuild thumbnail
[*]Options "Rotation: Change EXIF Orientation only" and "Use lossless rotation": are only available in Browser view - there are no equivalents for single image view. Suggestion: on the option setting tab add the text: "Rotation: These options are only available in Browser view"
In edit mode, the image is rotated, and orientation flag is cleared. And the settings are in Browser>Misc so not for edit mode
[*]Lossless rotation. Suggestion:this should be tristate:
  • no lossless - use jpeg write compression options (I am guessing this is what happens)
  • use lossless - crop if necessary.
  • use lossless - only if cropping not needed (perfect lossless)
??
[*]During JPEG format write there are no rules/options to control orientation. As far as I can see it always uses new encoding settings (as specified in the jpeg write options), so I cannot see any value in saving anything other than normal orientation. If users have good reasons for not wanting this then I suppose there are three option:
  1. Always convert image to normal orientation (tag 1)
  2. Save image oriented according to original orientation tag.
  3. Save image in original layout and adjust orientation tag to account for any rotation.
[/list]
Saving use always nomal orientation
Pierre.

CameronD
Posts: 295
Joined: Wed Aug 01, 2007 1:28 pm
Location: Australia

Re: Rotation and EXIF Orientation field

Post by CameronD » Tue Jun 12, 2018 3:31 pm

xnview wrote:
Tue Jun 12, 2018 10:51 am

do you have some sample files?
They are in the attached zip file two posts above: testcases-badorientation.zip. That longer post also describes conditions for reproducing.
[*]There seem to be very different rules applied when saving after rotation in the Browser compared to single image view. There are options for "write jpeg" but no equivalent options I can find for "write jpeg from browser". Options such as "rebuild embedded thumbnail" do not seem to apply.
you have tools>Metadata>Rebuild thumbnail
OK - I had not seen that, however it is a manual operation. I expected that if I have "rebuild embedded thumbnail" enabled then it should automatically rebuild the thumbnail when saving the modified jpeg.
[*]Options "Rotation: Change EXIF Orientation only" and "Use lossless rotation": are only available in Browser view - there are no equivalents for single image view. Suggestion: on the option setting tab add the text: "Rotation: These options are only available in Browser view"
In edit mode, the image is rotated, and orientation flag is cleared. And the settings are in Browser>Misc so not for edit mode
Yes, so I eventually worked out. But it does not seem obvious to me that it should be that way, which is why I suggest you simply add some clarifying words to the option tab. There is plenty of space.
[*]Lossless rotation. Suggestion:this should be tristate:
  • no lossless - use jpeg write compression options (I am guessing this is what happens)
  • use lossless - crop if necessary.
  • use lossless - only if cropping not needed (perfect lossless)
??
As I understand it, there are three possible situations. Images with dimensions that are multiples of 8 or 16 pixels can be truly rotated "losslessly" in the sense of "without more loss".
However If you need to crop the image to achieve this then there is some loss involved - several pixels along one side.
The third is don't do lossless.
Maybe I do not understand what the current option is supposed to select between, because "if possible" to me implies it will not use lossless if it needs to crop. But if is allowed to crop then "lossless rotate" will always be possible.
I am not too concerned about this in real situations because camera images tend to fit the required multiples and I would normally do rotating before cropping.
During JPEG format write there are no rules/options to control orientation. As far as I can see it always uses new encoding settings (as specified in the jpeg write options), so I cannot see any value in saving anything other than normal orientation. If users have good reasons for not wanting this then I suppose there are three option:
  1. Always convert image to normal orientation (tag 1)
  2. Save image oriented according to original orientation tag.
  3. Save image in original layout and adjust orientation tag to account for any rotation.
Saving use always nomal orientation
That is the main point of my post - I would be happy if it just did that but sometimes it gets it wrong.

tmack0
Posts: 1
Joined: Fri Jun 22, 2018 6:23 pm

Re: Rotation and EXIF Orientation field

Post by tmack0 » Fri Jun 22, 2018 6:36 pm

Posting a "me too" with details I have noticed:

This seems to happen mid-use. When I first look at photos from my camera, all the thumbnails are properly rotated, as are images. After some use, and possibly rotating some that were taken at angles that confuse the camera (ie: looking mostly up, and the image comes out sideways, so needs to be turned 90d) the thumb isn't updated. Sometimes revisiting an image I rotated once, it appears rotated twice (possibly my rotation + xnview reading the exif rotation tag and applying that again?).

Running a batch "rebuild tumbnails" results in mixed results, but uncovered another bug for me that really hurt: it reset the image rating on all images I rebuilt thumbs for... 200+ images I have to go back through again :(

Post Reply