[This version of the post from the old feedback forum was updated 11/1/21.]
Lightroom has long incorrectly copied crops and local adjustments between photos with different orientations. This post provides consistent principles of how copying should behave, test results of the current broken behavior, and a guide to implementing correct behavior.
How Copying Crops and Adjustments Should Behave
Users almost always place crops and local adjustments relative to the photo's content. A Spot Removal is placed over a blemish on a face; an Adjustment Brush lightens the shadows under eyes; a crop is placed tightly around a face; a Graduated Filter darkens the sky.
So if a user copies a crop or local adjustment from a raw to a TIFF produced from that raw by Photoshop, the user expects the adjustment to appear in the exact same visual position and have the same effect. A Graduated Filter aligned with the horizon in the raw should also be aligned with the horizon in the TIFF; a Spot Removal applied to a face blemish in the raw should be located on that blemish in the TIFF.
When a user edits a portrait raw in Photoshop, the saved TIFF will appear portrait. But internally, the orientations of the two photos are different – the raw pixels are stored in landscape with an orientation tag indicating a 90-degree rotation, while the TIFF pixels are stored in portrait with an orientation tag indicating no rotation.
When a user copies a crop or local adjustment between photos with different orientations or crops, LR usually copies the crop or adjustment incorrectly, placing it in the wrong location and with the wrong size. The precise behavior of LR has varied across versions, but it's never come close to being completely correct.
There hasn't been much change from LR 10.3, though LR 11 did fix one important use-case, copying adjustments between masters and their virtual copies.
Implementing the Desired Behavior
Implementing the desired behavior is straightforward, requiring elementary coordinate transformations from the source to destination photos. I've implemented these transformations for my Copy Settings, Any Crop, and Any Filter plugins, and I've posted the source code for Copy Settings plugin.
Internally, LR represents a photo as an underlying image (an array of pixels) and an "orientation" tag, which specifies how much the underlying image should be rotated (0, 90, 180, 270 degrees) and whether it should be mirrored to display it visually. Rotating or flipping an image in LR changes just the orientation tag. But when you edit a photo in Photoshop, it actually rotates and mirrors the pixels in the underlying image as specified by the orientation, and the saved TIFF will then have an orientation tag with no rotation or mirroring.
LR represents the coordinates of crops and local adjustments with values in [0..1], where (0, 0) represents the upper-left corner of the underlying image before any orientation (rotation and mirroring) has been applied. Call this coordinate system the underlying-pixels coordinates. Call the coordinate system after the orientation has been applied the visible-pixels coordinates.
When copying, LR should translate the underlying-pixel coordinates of the adjustments in the source image to visible coordinates. Then it should translate those visible coordinates to the underlying pixel coordinates of the target photo.
Updates to the Adobe Photography Products were released today and contain improvements to this issue. Please install the update via your Creative Cloud Desktop App or your respective App Store. Note: You may need to refresh the Creative Cloud App for desktop software to show an update available. ([Ctrl/Cmd]+[Alt/Opt]+ [ R ]) For Mobile downloads, it may take several days for the update to appear in your respective App Stores. Thank you for your patience.