P: Rotated and flipped raw opens upside down in Photoshop

[johnrellis]

When a raw that's been rotated 270 degrees CW in the camera and flipped horizontal in LR is opened in Photoshop from LR, it opens upside down. To reproduce:

1. Turn off the option Catalog Settings > Metadata > Automatically Write Changes Into XMP.

2. Import a raw that's been rotated in the camera 270 degrees CW (90 degrees CCW). Make sure no .xmp file for the raw is present before you import. (The raw should have EXIF:Orientation = Rotate 270 CW.)

3. Do Photo > Flip Horizontal.

4. Do Photo > Edit In > Edit In Adobe Photoshop 2020. 

5. Observe the photo is upside down in Photoshop.

Tested in LR 9.2 / PS 21.1 / Mac OS 10.14.6.

[johnrellis]

Original report of the problem:
https://www.lightroomqueen.com/community/threads/cropped-image-in-lightroom-arrives-in-photoshop-ups...

[Rikk Flohr: Photography]

To be certain I understand:

The scene is:  A B C D clockwise from the top.
After rotating in camera:  it is B C D A clockwise from the top.
After flipping in Lightroom: it is B A D C clockwise from the top.
Open in Photoshop and it is: D A B C?

[johnrellis]

The Flip Horizontal produces C B A D, not B A D C (clockwise from top).  Here's more detail:

Before in-camera rotation, the raw photo is A B C D;



The in-camera rotation (EXIF:Orientation = Rotate 270 CW) produces B C D A, which is how the raw appears in LR after importing:



After LR Photo > Flip Horizontal, the photo is C B A D:



Doing Photo > Edit In > Edit In Adobe Photoshop 2020, the photo in PS is A D C B:

[Lumigraphics]

Do you see an XMP tag like this:

<tiff:Orientation>6</tiff:Orientation>

Bridge and probably other software use this to denote lossless rotation, the number shows which way its turned. I wonder if there is a conflict between an EXIF and a TIFF rotation tag?

You can test using Bridge with the Edit->Rotate commands.

[johnrellis]

Exiftool shows EXIF:Orientation for the raw:

[EXIF]  Orientation : Rotate 270 CW

Exiftool shows no XMP metadata in the raw (-xmp:all).  Further, in the bug recipe above, LR does not write a .xmp sidecar when it passes the raw to PS. 

[Rikk Flohr: Photography]

I labeled sides not corners. A = Top Side -  Is that the difference?

[johnrellis]

Yup, your labeling of the sides corresponds with my labeling of the corners. (I assumed you were labeling corners, because that's what LR does internally for representing orientation.)

[Lumigraphics]

I bet this is the problem.

[Rikk Flohr: Photography]

I am digging way back in my memory here John, but as I recall, Horizontal and Vertical flips are stored in the LRCAT file and not in the XMP metadata file. 

[johnrellis]

In LR 9.2, photo:getRawMetadata ("orientation") and photo:getDevelopSettings ("orientation") return from the catalog the current rotation and mirroring as applied within LR .  It is represented as a two-letter string, where the corners of the photo as read from the file are labeled A B C D counter-clockwise, starting in the lower-left.  An image with no rotation or mirroring applied within LR is represented as "AB".  After rotating 270 CW (90 CCW), it is "DA".  After flipping horizontal (mirroring), it is "AD".

When LR does Save Metadata To File, it writes the current rotation and mirroring of the image to EXIF:Orientation in a non-raw or XMP:Orientation in a raw's sidecar.

So for my example in the previous post above, before reading into LR, the raw file has this (coming from the camera):

[EXIF]  Orientation : Rotate 270 CW

After flipping horizontal and doing Save Metadata To File in LR, the .xmp sidecar contains:

[XMP] Orientation : Mirror horizontal and rotate 90 CW

[Lumigraphics]

This is different than how Bridge does rotations (which was added a couple of version back. Bridge uses a tag in the TIFF namespace.

[johnrellis]

This bug isn't caused by the absence of a .xmp sidecar.

When editing a raw in PS, LR doesn't write any of the develop settings (e.g. Exposure, Contrast) into a .xmp sidecar before invoking PS (unless the sidecar already exists).  LR uses some other mechanism for passing the develop settings from LR to PS.  

This mechanism includes the current orientation (rotation and mirroring).  You can demonstrate that by rotating a raw in LR, editing it in PS, and observing it appears correctly in PS. Alternatively, flip a photo in LR, edit it in PS, and observe it appears correctly.  No .xmp sidecar is created, but PS still gets the orientation information from LR.

It's only when you rotate and flip together that LR/PS get it wrong. 

[johnrellis]

LR and Bridge use the same industry standards for representing orientation in file metadata.

The Orientation tag can be stored in EXIF metadata (which appears in non-raws and most TIFF-based raws), and it can be stored in XMP metadata (e.g. in a .xmp sidecar) in the namespace http://ns.adobe.com/tiff/1.0/ (commonly named "tiff").   By default, Exiftool's output labels these two locations EXIF:Orientation and XMP:Orientation.

For non-raws, LR and Bridge read and write EXIF:Orientation in the file itself.

For raws they read XMP:Orientation from the .xmp sidecar if it exists, otherwise they read EXIF:Orientation from the raw itself. They always write the orientation to XMP:Orientation in the sidecar, creating it if necessary.

[Rikk Flohr: Photography]

Version 9.3, an update to Lightroom Classic, went live on June 15, 2020 and contains a fix for this issue. Please install the update and respond back if it does not cure the issue for you. Thank you for your patience!

[johnrellis]

The bug recipe in the first post no longer shows the bug. Tested in LR 9.3 / Mac OS 10.15.5. Thanks.