Rotation and EXIF Orientation field
Moderators: XnTriq, helmut, xnview, Dreamer
Re: Rotation and EXIF Orientation field
Yes
Daniel, promoting XnView since 2004, moved to MP (exclusively) years ago (Platform Windows and Linux Ubuntu)
Re: Rotation and EXIF Orientation field
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:
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.
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
- 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.
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.
Re: Rotation and EXIF Orientation field
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
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, moved to MP (exclusively) years ago (Platform Windows and Linux Ubuntu)
Re: Rotation and EXIF Orientation field
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.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
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.
Re: Rotation and EXIF Orientation field
Here is my set of test case images attached:
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
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" ?
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:
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.
- I always update file modification date if I modify a file
- 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.
- 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.
- 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.
- 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.
- 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.
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
- XvniewMP browser
- windows 7 file explorer
- Picasa previewer
- exiftool -Exif:Orientation -Exif:Orientation# *.jpg
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" ?
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. 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.
- 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 .
- 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.
- 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.
- 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.
Re: Rotation and EXIF Orientation field
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 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:
- Always convert image to normal orientation (tag 1)
- Save image oriented according to original orientation tag.
- Save image in original layout and adjust orientation tag to account for any rotation.
Re: Rotation and EXIF Orientation field
do you have some sample files?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.
you have tools>Metadata>Rebuild thumbnail[*]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.
In edit mode, the image is rotated, and orientation flag is cleared. And the settings are in Browser>Misc so not for edit mode[*]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)
Saving use always nomal orientation[*]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:[/list]
- Always convert image to normal orientation (tag 1)
- Save image oriented according to original orientation tag.
- Save image in original layout and adjust orientation tag to account for any rotation.
Pierre.
Re: Rotation and EXIF Orientation field
They are in the attached zip file two posts above: testcases-badorientation.zip. That longer post also describes conditions for reproducing.
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.you have tools>Metadata>Rebuild thumbnail[*]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.
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.In edit mode, the image is rotated, and orientation flag is cleared. And the settings are in Browser>Misc so not for edit mode[*]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"
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".??[*]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)
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.
That is the main point of my post - I would be happy if it just did that but sometimes it gets it wrong.Saving use always nomal orientationDuring 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:
- Always convert image to normal orientation (tag 1)
- Save image oriented according to original orientation tag.
- Save image in original layout and adjust orientation tag to account for any rotation.
Re: Rotation and EXIF Orientation field
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
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
Re: Rotation and EXIF Orientation field
Hi guys,
Sorry but this one is still not fixed: Opening a JPEG image in View mode, make a Rotation left or right and close/save the image change the picture orientation but leaves the original value unchanged in the EXIF Orientation field (text from the original post).
I just checked on my 2 machines (Desktop/Win7 and Tablet/Win 10) and both replicate, whatever the source of the image.
To replicate: Options General>General>"Rotation based on EXIF" & Browser>Various>Change only the EXIF orientation tag Both should be unchecked. It's not mandatory but it make it easier to understand.
Sorry but this one is still not fixed: Opening a JPEG image in View mode, make a Rotation left or right and close/save the image change the picture orientation but leaves the original value unchanged in the EXIF Orientation field (text from the original post).
I just checked on my 2 machines (Desktop/Win7 and Tablet/Win 10) and both replicate, whatever the source of the image.
To replicate: Options General>General>"Rotation based on EXIF" & Browser>Various>Change only the EXIF orientation tag Both should be unchecked. It's not mandatory but it make it easier to understand.
Daniel, promoting XnView since 2004, moved to MP (exclusively) years ago (Platform Windows and Linux Ubuntu)
Re: Rotation and EXIF Orientation field
FYI the issue still exist in MP and I noticed it can be replicated with XnView Classic as well (latest version 2.49.2)
To replicate in Classic, apply the same settings as described for MP. Use whatever picture taken in portrait mode (EXIF:Orientation should be different than 1)
To replicate in Classic, apply the same settings as described for MP. Use whatever picture taken in portrait mode (EXIF:Orientation should be different than 1)
Daniel, promoting XnView since 2004, moved to MP (exclusively) years ago (Platform Windows and Linux Ubuntu)
Re: Rotation and EXIF Orientation field
Please send me a file to reproduce?B.Douille wrote: ↑Mon May 11, 2020 9:00 pm FYI the issue still exist in MP and I noticed it can be replicated with XnView Classic as well (latest version 2.49.2)
To replicate in Classic, apply the same settings as described for MP. Use whatever picture taken in portrait mode (EXIF:Orientation should be different than 1)
Pierre.
Re: Rotation and EXIF Orientation field
Here are 2 samples you can use:
Pict 1 Original (6 is right orientation)
https://drive.google.com/file/d/1V3-pdk ... sp=sharing
Pict 2 Original (6 is wrong orientation)
https://drive.google.com/file/d/1i01czz ... sp=sharing
Pict 1 Original (6 is right orientation)
https://drive.google.com/file/d/1V3-pdk ... sp=sharing
Pict 2 Original (6 is wrong orientation)
https://drive.google.com/file/d/1i01czz ... sp=sharing
Daniel, promoting XnView since 2004, moved to MP (exclusively) years ago (Platform Windows and Linux Ubuntu)
Re: Rotation and EXIF Orientation field
could you describe how to reproduce with these files?B.Douille wrote: ↑Thu May 14, 2020 12:26 pm Here are 2 samples you can use:
Pict 1 Original (6 is right orientation)
https://drive.google.com/file/d/1V3-pdk ... sp=sharing
Pict 2 Original (6 is wrong orientation)
https://drive.google.com/file/d/1i01czz ... sp=sharing
Pierre.
Re: Rotation and EXIF Orientation field
Hello Pierre, I created a video showing how to reproduce. All samples (original files), output files and the video are available here:could you describe how to reproduce with these files?
https://drive.google.com/open?id=1PGOfe ... JurQe65lN7
Daniel, promoting XnView since 2004, moved to MP (exclusively) years ago (Platform Windows and Linux Ubuntu)