linuxmint / xviewer

A generic Image viewer
GNU General Public License v2.0
75 stars 37 forks source link

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

Open Evarin opened 2 years ago

Evarin commented 2 years ago
 * 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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 :sweat_smile:

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 commented 2 years ago

@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.