Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The batch "save" action is messing with rotated images (with Exif?) #168

Open
Evarin opened this issue Jul 4, 2022 · 5 comments
Open

The batch "save" action is messing with rotated images (with Exif?) #168

Evarin opened this issue Jul 4, 2022 · 5 comments

Comments

@Evarin
Copy link

Evarin commented Jul 4, 2022

 * Xviewer version : 3.2.4
 * Distribution : Mint 20.3

Issue

The "Save" action after rotating several images in a row gets random results.
It seems to be only the case when images are pictures (with exif).

(It is related to #30, but not the same, as it seems to only happen when several images were modified; and it does not look to be "action is replicated")

Steps to reproduce
1- Open xviewer in a folder with several pictures (having exif metadata)
2- Rotate a few images through xviewer
3- Close xviewer. A dialog opens, asking if you want to save.
4- Click save
5- Reopen xviewer on the same images.

I'd be happy to provide additional information on this matter :)

@programmer-ceds
Copy link
Contributor

I have just saved an image that has an EXIF orientation tag 9 times. The images are distinguished by each having a single digit in the range from 1 to 9 draw on them.

I rotated image 1 by 90 degrees clockwise, image 2 by 90 deg CCW, image 4 by 180 degrees and image 6 by 90 degrees CW. I then clicked the close button. The expected images appeared in the list of changed images. I then clicked the Save button. All of the changes appeared in the nemo thumbnails and the images were rotated as expected when I re-opened them with xviewer.

Do you have a set of compact (small in size) images that you could zip and give idiot-proof details of the exact procedure you are using and what it is that you see that is not as expected. (I'm not doubting that it doesn't work as expected for you - just that I don't know how to reproduce it)

@Evarin
Copy link
Author

Evarin commented Jul 5, 2022

Hello,

Thanks for looking at the issue! Here is a test folder with a few compressed images, taken with various camera orientations, and rotated (according to the arrows I drew on the images) : rotate-test.zip

Here is what it should look like in the end:

expected-small

And here is the actual result:

results-small

The problem seems to happen only when the Exif orientation value is different to "1" -- as the last row (with exif value 1) is correctly rotated, but not the others (with exif values 3 or 6)

@programmer-ceds
Copy link
Contributor

Firstly I can reproduce exactly the issues that you show above - always a good start. I will look at the code and see if I can fix this but I'm not sure how much time I will have in the next day or so.

Do you realise that the rotation performed by xviewer is destructive? It actually rotates all of the pixels and, in the case of your images at least, seems to use a higher level of JPEG compression afterwards (your images go from around 80kB to around 28kB). Some years ago I wrote a program called ExifRotate that added right-click context entries for JPEG files in Windows explorer - one click would rotate one or more selected images by altering the value held by the EXIF orientation tag. I have recently ported this for Linux to work in the same way with nemo. It does require the presence of MonoDevelop runtime. As yet I haven't got around to adding the Linux version to my website but I can let you have a copy of the program and the nemo action file if you are interested.

@Evarin
Copy link
Author

Evarin commented Jul 6, 2022

Thanks! Honestly I use it to rotate photos of texts taken with my phone, that get a random orientation based on how I was holding the phone, I don't care much about the quality as long as I can read it 😅

Plus, the images I sent you were downscaled and compressed with ImageMagick (convert), which for an unknown reason wouldn't make an image smaller than 80kB, even with very strong compression factor. That might be why the rotated image is smaller.

@programmer-ceds
Copy link
Contributor

@Evarin - I have updated my system to Mint 21.0 and this includes xviewer v3.2.10

I have checked that this issue does not occur in the 3.2.10 so this issue can now be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants