Skip to main content
johnrellis
Legend
May 13, 2021
In Development

P: Correct copying of crops and local adjustments

  • May 13, 2021
  • 31 replies
  • 5444 views

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

 

Problems

 

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. 

 

I've done extensive testing of copying between orientations and crops, and the most recent results for LR 11.0 are posted below:
https://community.adobe.com/t5/lightroom-classic-ideas/lightroom-correct-copying-of-crops-and-local-adjustments-of-virtual-copies/idc-p/12489948#M13017

 

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.

 

31 replies

Rikk Flohr_Photography
Community Manager
May 13, 2021

@John_R_Ellis 

Thanks for the detailed report - it shows a lot of work and thought on your part. 

A few of the items in this list are active bugs scheduled for upcoming releases. It might be better to revisit this list after those are fixed to see what remainder we have that qualify for behavior change requests. 

Also keep in mind that some recent behavior changes are being made in conjunction with yet-to-be-released features that can't be discussed yet.

Rikk Flohr: Adobe Photography Org