Rotate images using linked viewer

[joer]

Hi, I'm currently facing the following situation and would like to know if there's anything in the process I am doing that could be improved, or if it is actually a bug that needs fixing. Here's the situation: I set this command Show LISTERLINK USEEXISTING=yes,avoid on the image file types and it opens a linked viewer window.

By default, there were some buttons on the viewer for rotating the images. However, I realized that this only worked in the viewer and not on the actual file Show VIEWERCMD=rotate,-90. Therefore, I took the command used for rotating images and integrated it into the viewer's buttons:

Show VIEWERCMD=rotate,-90
Image ROTATE=-90 HERE REPLACE PRESERVEDATE

This way, the rotation is displayed as well as applied to the file itself. What I've noticed is that if I rotate an image, select another, and then return to the one I previously edited, it does some weird things displaying a rotation that is wrong. I tried to refresh using the command within the viewer Show VIEWERCMD=refresh but it did nothing.

If I close this viewer and reopen it, then it displays correctly. However, this isn't practical when you need to rotate multiple images and view them in large format. Thanks in advance.

Here's some recorded example and commands of the other buttons.

Show VIEWERCMD=rotate,+90
Image ROTATE=90 HERE REPLACE PRESERVEDATE

Show VIEWERCMD=rotate,-180
Image ROTATE=-180 HERE REPLACE PRESERVEDATE

[lxp]

Try

Image ROTATE=-90 HERE REPLACE PRESERVEDATE
Show VIEWERCMD=refresh

[joer]

Ah, of course, telling the viewer to rotate becomes unnecessary by refreshing after rotating the file. TY

[Kris]

Image ROTATE=-90 HERE REPLACE PRESERVEDATE

@joer be wary as this command :
a/ It is Not rotating .jpg image in a good way: it is using pixel rotation (slower process, and can be lossy) instead of just modifying the .jpg Orientation metada (which is the recommended method. Even Windows File Explorer in Windows 11 is rotating .jpg image with the Orienation metadata )
b/ AND it is erasing all your .jpg metada ! (not even just the Orientation metadata, all your .jpg metadata)

The concrete consequence is that for each .jpg where this command is applied, all the .jpg metadata is lost forever

[Leo]

That's not (usually) true. The image command will do a lossless JPEG rotation where possible.

Please also link your account, as requested already a few days ago.

[Kris]

I will do. Lossless in terms of pixels maybe, but in terms of .jpg file it is Not Lossless: all the .jpg metadatas are lost.
Metadata are as important as pixels, so using the term "Lossless" for "Image ROTATE=-90 HERE REPLACE PRESERVEDATE" is misleading.

[PassThePeas]

@Kris

all the .jpg metadatas are lost

I do not have this behavior.

Before

After

[Guido]

@Kris

all the .jpg metadatas are lost

Lossless rotation of JPEG data is based on the implementation in the jpegtran utility of the Independent JPEG Group (IJG) software.

jpegtran has an option -copy all so that metadata is not lost.

Applications using the IJG code usually have the -copy all option as default setting, see the screenshot of Preferences (section Marker Copy Option) of my Jpegcrop utility in my post in the Labels Under Thumbnails - More Options Please thread.

I would assume that Opus uses similar default, and posted statements and examples confirm this.

Regards
Guido
JPEG developer
Organizer Independent JPEG Group
Original author of the lossless rotation features

[Kris]

@PassThePeas
Thanks for your feedback. You are correct; it works sometimes, but it frequently does not work and you lose all .jpg metadata: in the standalone separate viewer, I had a hotkey assigned to :

Image ROTATE=-90 HERE REPLACE PRESERVEDATE
Show VIEWERCMD=refresh

The issue is more frequent when you have the .jpg stored on OneDrive. I think the issue is due to the closing of the separate standalone viewer (DO window is still open, though) just after rotating the image. Maybe the separate standalone viewer close action is killing the rotation in the middle of the process.

@Leo @Guido
You are saying that rotation in Directory Opus with Image ROTATE=-90 HERE REPLACE PRESERVEDATE is lossless. This is not correct, it is lossy. Please try for yourself. Even the screenshots of @PassThePeas prove Directory Opus rotation is lossy with Image ROTATE=-90 HERE REPLACE PRESERVEDATE

I observe the same behavior. And contrary to the metadata issue, this behavior happens for all .jpg files rotated in Directory Opus.

[Leo]

Kris, link your account to continue using the forum.

[Guido]

@Kris
OK, I have now done the stated procedure on an own example, and I can confirm:
The JPEG rotation in DOpus is LOSSLESS and works correctly!

Please post an example which you think would not work so that we can analyze what is wrong there.

There are some flaws in your statements:

1. JPEG lossless rotation is not done on pixel data.
   That's why I carefully wrote "Lossless rotation of JPEG data" above, which is internally represented as DCT (Discrete Cosine Transform) coefficients.
   See also my post in the Force lossless rotation of JPEGs thread.

2. Just modifying the Orientation metadata is not the preferred method.
   This is a dumb method, and Windows is a dumb OS regarding JPEG support, as I have explained in other places.
   Other than many other compressed image formats, JPEG can adjust the orientation losslessly by rearranging DCT coefficients, so decoders need not be burdened with the task.
   See also my posts in above given thread.

Regards
Guido
JPEG developer

[Kris]

@Guido

OK, I have now done the stated procedure on an own example, and I can confirm:
The JPEG rotation in DOpus is LOSSLESS and works correctly!

Please post an example which you think would not work so that we can analyze what is wrong there.

Have you looked at the screenshots I took the time to annotate Rotate images using linked viewer - #9 by Kris ?
It speaks for itself. They are not even from me, proving we are not the only people observing this. Let us know how you can say this was lossless?

@Guido

• JPEG lossless rotation is not done on pixel data.
  That's why I carefully wrote "Lossless rotation of JPEG data" above, which is internally represented as DCT (Discrete Cosine Transform) coefficients.
  See also my post in the Force lossless rotation of JPEGs thread.
• Just modifying the Orientation metadata is not the preferred method.
  Other than many other compressed image formats, JPEG can adjust the orientation losslessly by rearranging DCT coefficients, so decoders need not be burdened with the task.
  See also my posts in above given thread

Rotating the .jpg image physically is no longer the recommended way to do it in 2025, as it can be lossless, true but only when the .jpg happens to meet certain criteria. So not all .jpg by far.
Rotating the .jpg image using the Orientation metadata is lossless for all .jpg files, not just a subset like the physical image rotation. Furthermore, this process requires little CPU and is almost instant (whereas physically rotating the image requires a lot more CPU and takes more time to process).

It is true that you can have small issues like the metadata orientation under "IFD0" is "Horizontal - normal" and under "IFD1" it is "Rotate 180". But physically rotating the image does not even solve this situation, since if you rotate the .jpg physically, your .jpg will still have in its metadata the orientation item. So if this orientation item is messy, your physically rotated image will be as well.

In 2025, do you know a software that is up to date and does not manage the .jpg metadata properly? Even the current Windows 11 built-in Windows file explorer rotates .jpg with metadata.

[Guido]

@Kris

Have you looked at the screenshots I took the time to annotate Rotate images using linked viewer - #9 by Kris ?

Sorry, this is useless.
I have more than 30 years experience in JPEG development, I have introduced the JPEG lossless rotation features more than 25 years ago, and I am responsible for general JPEG advancement since 20 years.

You come in this forum only moaning and expressing flawed statements, without any evidence by giving an actual example which would allow us to investigate your pretended issue.

There can be many reasons for the observed phenomenon, I don't have the time to describe them all here.

So PLEASE POST AN ACTUAL EXAMPLE which can be investigated, maybe ask the other member to post his example which you have "annotated" if you don't have an own one.

@Kris

Rotating the .jpg image physically is no longer the recommended way to do it in 2025

I have edited my previous post for more clarity:
The metadata way is a dumb method, and Windows is a dumb OS regarding JPEG support. See reference given in previous post.

The proper fix for the dimension issue is not metadata, but fixing it in another way as described in my other post in the Force lossless rotation of JPEGs thread, which couldn't be realized for other reasons.

Metadata is not the right place for information which is essential for proper image reconstruction.

Other compressed image formats may have such kind of information in essential markers by design, but JPEG does not.

JPEG has other options to handle this issue as described.

The advantage of the JPEG approach is, as mentioned, that the decoder is not burdened with orientation adjustment at all for proper image reconstruction.

Regards
Guido
JPEG developer