XnView Software

Subject: 0.99.7 x64 Portrait pictures orientation

XnView: MP, Version 0.99.7 64bits (Jan 13 2022)
OS: Win 10 Pro 21H2 64bit

Hi, I hope this is not a duplicity of another bug report, but I have found problem with portrait-oriented pictures and I was able to reproduce with for example 5 copies of the same image from my camera. I cannot reproduce it with random image downloaded from google, probably because of missing EXIF data. Hope this is not caused by wrong program settings

Effect: wrong orientation from third edited photo.

To reproduce:
1) open the first picture, adjust levels / crop / rotate by ie. 2°(does not matter, this is just what I actually do)
2) go to next image (I do it with PgDn key), confirm saving of first image. Everything is OK.
3) do the same (similar) picture adjustments on 2nd picture
4) go to next image, save. Everything is OK.
3) do the same (similar) picture adjustments on 3rd picture
4) go to next image, save. This and all following portrait pictures have broken orientation information, that means all originally portrait images are now saved as landscape. Does not matter, if the previous 2 editted pictures was landscape or portrait

Actual behaviour (bug): When I want to edit whole photos folder, I edit one photo by one and weird behaviour starts at photo no.3

If I close XnVeiw after each picture adjustment, it is OK (but I do not want to close it every time).
If I uncheck the option "Keep EXIF" in Tools/Settings...Formats/Write/JPEG it does not produce this error, bud I would like to preserve EXIF files.
The older SW XnView for Windows XnView v1.98.2 19/07/2011 works fine.
Manualy rotated photo after wrongly rotated is also OK.
Once the photo is manipulated, it does not produce the error next time.

Expected behaviour: Image orientation should be correct

The EXIF data are added as an attachment, file with photos are here (if you don't want to open that zip let me know where can i upload photos with option to download it again with original EXIF):
https://ulozto.cz/tam/a6a8b993-03bd-4e7 ... 618dc57547

Thank you for the great SW and for the answer

Thank you for your detailed and good problem report, oneshot. I'd like to reproduce the problem using your original files but downloading the ZIP archive fails: "Error 451! The page is blocked due to the decision of the authorities in your area.".
Could you, oneshot, please upload your ZIP archive to a different file hosting service?

Hello, thanks for the reply, you can try this download site https://easyupload.io/2zlx3h

I was now able to reproduce the behaviour on another computer with same SW version with the files from easyupload.io

It has to do with the EXIF rotation metadata.

I believe XnViewMP conserves the EXIF orientation info, and thus re-saving it with a slight adjustment to the rotation will cause it to display incorrectly.

I noticed that with GIMP, when I make a slight adjustment to its rotation, then export it as a JPEG, it will remove/reset the orientation info on the new image; whereas XnViewMP does not.

Your JPEGs appear to have two different orientation fields? One is "orientation" and the other is "camera orientation".

It could be any operation (for example automatic contrast - Ctrl+Alt+O).

I don't know if there is something special with EXIF info from my camera Panasonic Lumix DMC-TZ200, but it is very annoying to work with that and I have no other option where could i complain

i'm not able to reproduce, 'Settings>View>Read ahead' is enabled?

Hi, thank you for the answer, the option "Settings > View > Misc. > Cache > Read one image ahead is checked". Should it be inactive? Or do you mean another option?

oneshot wrote: Fri Apr 22, 2022 12:48 pm Hi, thank you for the answer, the option "Settings > View > Misc. > Cache > Read one image ahead is checked". Should it be inactive? Or do you mean another option?

could you try without?

Hi, with this option disabled my problem is gone
Thank you! But i am not sure what does it exactly do, will the pictures now load slower?

it seems that this bug is fixed in beta 1

xnview wrote: Mon May 02, 2022 9:29 am it seems that this bug is fixed in beta 1

It seems to be still broken in Version 1.0 64bits (Apr 28 2022)
I did not test it in other beta versions with the "Read one image ahead" option checked. The only thing I can confirm is when this option os disabled, the "wrong orientation" bug is not active

So i have to continue working with the option unchecked

oneshot wrote: Tue May 17, 2022 12:34 pm

xnview wrote: Mon May 02, 2022 9:29 am it seems that this bug is fixed in beta 1

It seems to be still broken in Version 1.0 64bits (Apr 28 2022)
I did not test it in other beta versions with the "Read one image ahead" option checked. The only thing I can confirm is when this option os disabled, the "wrong orientation" bug is not active

you can always reproduce in 1.0?

Yes, I can unfortunately reproduce it on two different computers. Option off, no problem. Option on, the same behaviour as described before.

oneshot wrote: Thu May 26, 2022 7:02 am Yes, I can unfortunately reproduce it on two different computers. Option off, no problem. Option on, the same behaviour as described before.

could you send me the files again , please?