Rotating JPEGs sometimes drops images from selection & shuffles files

When rotating JPEGs using the toolbar buttons, one or more JPEGs (almost always just one) is sometimes deselected. The more files are rotated at once, the higher the chance seems of be of this happening. You can always tell when this will happen, because one of the images is renamed to .jpg.bak during the process; when the rotated image reappears, it's at the end of the file list and no longer selected.
This is bothersome for two reasons. First, I usually rotate images 180 degrees, so I select, say 50 images, and press the rotate button twice. If one of the images is deselected on the first rotate, it gets missed out of the second. Second, the change in the file order can really catch me out. If I don't realise what's happened and refresh, I can open an image viewer and decide to delete, say, the first 10 images. I select the first 10 in DOpus and delete. But one of the images I saw in the viewer is now at the bottom of the lister - I've just deleted image number 11.
Also, if I do realise what's happened before I do rotation number two, I can't refresh because I'll lose my selection - I need to scroll all the way down to reselect the lost image. If I'm trawling through hundreds of holiday photos, refreshing and scrolling are generally a bit of a nuisance.
I started using the DOpus rotate function because the shell extension I used to use, JPEG lossless Rotate, doesn't play well at all with DOpus. I don't know whether the two problems are related.

I'm using 12.20, BTW.

Wouldn't Image ROTATE=180 be smarter anyway?

And associate that with a button? Yes, you're right. The bug still stands though.

When I go through my pictures I rarely have the need to rotate more than a few, but if I had to do many, I'd assign them to a collection and rotate them all at once when I am done browsing.

OK, that's good for you, but every case is different. I rotate a lot of images, frequently.

What's the command you're using to rotate the files?

How large are the images (file size and dimensions), approximately?

I've tried using this command:

@nodeselect
image rotate=90 here replace

On these images:

So far I haven't run into a problem with any being de-selected.

I'm using the standard rotate right, rotate left buttons. In my tests, it doesn't seem to happen in list mode. Or, I guess, detail mode. Only in thumbnail mode, which is, unsurprisingly, the mode I use for photo organising. I just did 6 rotations of 50 images in list mode, and you do see the .bak file appear at the end of the file list, but no files are deselected or moved to the end. I tried just once in thumbnail mode, and the deselection/shuffling happened immediately.

I did most of my tests in thumbnails mode. (The screenshot is Details since that shows the sizes and dimensions I was asking about.)

Try larger images. For some reason, it seems not to happen as much with smaller ones. The ones from my camera are between 4MB and 6MB each.

What about the dimensions (width and height)?

3456x4608, although it also happens with smaller ones, 1920x1080

Thanks! We've made a change for the next beta which should help with this and keep the files selected.

2 Likes

Excellent! Thanks Leo

The change for this is in 12.20.8, please let us know if it solves it for you.

1 Like

Using 12.21.2 (Beta) and this issue appears to continue to be present.
Selecting multiple (e.g. 3) images (in thumbnails view) and attempting to rotate them right or left results in:
a. Some of the images get deselected upon completion
b. The images consistently over-rotate (if I request rotate = -90) then the image rotates -180
Commands I am using are:

@nodeselect
Image ROTATE=-90 HERE REPLACE QUALITY=100
Show VIEWERCMD=refresh

Even specifying Rotate = 270 gives the same result.

  • More peculiar is that this behavior only seems to occur when I freshly attempt to rotate an image that was not previously rotated by DO.
  • After the images have been initially and improperly rotated by DO, then subsequent rotations behave as expected!

I don't know if it's involved, but Show VIEWERCMD=refresh shouldn't be in the command if it's being used in the lister. That line should only be used in the viewer.

Turn on the Rotation column and see if the EXIF data is rotating the images in question before Opus modifies them (it should be cleared after Opus rotates them). That can complicate things, depending on your config.

Leo,
Enabled Rotation column.

  • Value before rotation: 270. After rotation: 0 (results in the image being over-rotated).

  • When the before rotation is 0, the expected correct behavior of the image rotation occurs.

  • Disabling Show VIEWERCMD=refresh makes no difference.

Assuming you're looking at how the images are before and after via their thumbnails, is Preferences / File Display Modes / Thumbnails / Use EXIF information (if present) to auto-rotate images on or off?

This option is on. I will continue to experiment this setting off.