XnView Software

XnViewMP v0.93.1 64bits for Windows

With all of the "Keep original date/time" options disabled (shown here: https://imgur.com/6IsvcJ1) and "Change EXIF orientation only" enabled (shown here: https://imgur.com/3KscmRm)...

...In Browse Mode, the buttons "Rotate Clockwise" and "Rotate Counter Clockwise" (shown here: https://imgur.com/4jtyZv1) do NOT update the timestamp of the file when used (bug #1).

In View Mode, if you customize the toolbar to add those two commands - "Rotate Clockwise" and "Rotate Counter Clockwise" (shown here: https://imgur.com/g8efh2l), it DOES update the timestamp of the file, as expected. However, you'll notice that the buttons are missing their icons (bug #2)

Thanks to your detailed description I can reproduce the problem.

Addendum: in the case of the view mode, as mentioned, it is updating the timestamp. However, on closer examination, it's not actually always rotating by just setting the exif flag - sometimes it's still transposing the x,y pixels, contrary to the setting (verified by using BeyondCompare to diff the before/after image files). This doesn't occur for all photos - just some.

So:

1) In Browse, rotate doesn't update the timestamp (despite settings)
2) In View, rotate buttons are missing icons
3) In View, rotate is not doing so via exif flag for some photos (despite settings)

See issue for current status and some details.

This problem is supposed to be fixed in XnView MP 0.94. Please check and confirm the bug fix here.

Oops, I guess I missed the notification that you replied here. To respond very late:

>1) In Browse, rotate doesn't update the timestamp (despite settings)

Fixed.

>2) In View, rotate buttons are missing icons

Not fixed.

>3) In View, rotate is not doing so via exif flag for some photos (despite settings)

Not fixed. To make this easier to see, here's an example photo before & after doing "exif" (lossless) rotation:

https://www.dropbox.com/scl/fi/klkweo27 ... yufukbq8xj
https://www.dropbox.com/scl/fi/qlkhhykt ... gjmjx4qt5z

You'll notice that after, the image height is reduced from 2268 to 2256 (8 pixels were chopped off), the filesize is *smaller*, and the exif orientation is unchanged. Also, if I again rotate it 2 more times so it's back to its original orientation, it remains at the smaller resolution and smaller filesize, so it could not have been lossless. If it was lossless, it should've just changed the exif rotation flag, and then changed it back, yielding the same original photo.

metal450 wrote: Fri Jun 09, 2023 1:28 am >2) In View, rotate buttons are missing icons

Not fixed.

Could you explain the issue?

>3) In View, rotate is not doing so via exif flag for some photos (despite settings)

Not fixed. To make this easier to see, here's an example photo before & after doing "exif" (lossless) rotation:

you use 'rotate base on EXIF orientation field', right? the exif orientation is 1 so nothing to change...

> Could you explain the issue?

In Browse mode, the toolbar buttons for lossless rotate have icons. In View mode, they have no icons - only text:
https://imgur.com/k5dqJdG
https://imgur.com/JYRvHBC

> you use 'rotate base on EXIF orientation field', right? the exif orientation is 1 so nothing to change...

No, I used Tools->Lossless jpeg transformations->rotate clockwise/rotate counter clockwise

metal450 wrote: Mon Jun 12, 2023 1:57 pm > you use 'rotate base on EXIF orientation field', right? the exif orientation is 1 so nothing to change...

No, I used Tools->Lossless jpeg transformations->rotate clockwise/rotate counter clockwise

Ok, but where is the problem. When using 'JPEG lossless transformation' EXIF rotation is not changed

My assumption was that lossless rotation would work by flipping the EXIF rotation value - perhaps that was a misunderstanding. However, in any event, from above:

"You'll notice that after, the image height is reduced from 2268 to 2256 (8 pixels were chopped off), the filesize is *smaller*, and the exif orientation is unchanged. Also, if I again rotate it 2 more times so it's back to its original orientation, it remains at the smaller resolution and smaller filesize, so it could not have been lossless.

metal450 wrote: Tue Jun 13, 2023 11:26 pm My assumption was that lossless rotation would work by flipping the EXIF rotation value - perhaps that was a misunderstanding. However, in any event, from above:

"You'll notice that after, the image height is reduced from 2268 to 2256 (8 pixels were chopped off), the filesize is *smaller*, and the exif orientation is unchanged. Also, if I again rotate it 2 more times so it's back to its original orientation, it remains at the smaller resolution and smaller filesize, so it could not have been lossless.

Using lossless rotation can remove some image data, when width/height are not a multiple of 4

> can remove some image data

...If it's losing image data...then it can't really be "lossless"

Is there any way to rotate by simply having it alternate the exif orientation value? I always assumed that's what it had been doing, as that's truly lossless ( = "no loss").

metal450 wrote: Wed Jun 14, 2023 3:37 pm Is there any way to rotate by simply having it alternate the exif orientation value? I always assumed that's what it had been doing, as that's truly lossless ( = "no loss").

You can in browser, Settings>Browser>Misc

I did have that setting enabled.

So the behavior of the same commands, i.e. "Rotate clockwise", is not consistent? It behaves one way in view mode, and a different way in browse mode...?

And if viewing images in view mode (which is the most common), it's necessary to remember to switch back & forth between modes each time - so you need to stop when you get to an image to rotate, change to browser mode, rotate it, change back to view mode, continue through images?

Seems like it'd be far better / clearer / more intuitive to just have the behavior of "Rotate clockwise" be consistent, regardless of where it happens to be triggered from.

'Rotate' in viewer works only on image data, in browser it works on file