P: SDK: Restore ability of Copy Settings plugin to work around longstanding LR bugs
LR 15.4 changed the representation of brush masks returned by photo:getDevelopSettings(), making it impossible for the Copy Settings plugin to provide a workaround for the numerous, longstanding bugs copying local adjustments between photos with different orientations.
A relatively simple change to the implementations of SDK methods photo:getDevelopSettings() and photo:applyDevelopSettings() would restore the ability of Copy Settings to copy local adjustments correctly, lessening the need for Adobe to fix all the bugs in Copy/Sync Settings.
Details
Prior to LR 15.4, the strokes of a brush mask were represented by a "Dabs" array of points:
Dabs = {
[1] = "d 0.038236 0.022757",
[2] = "d 0.037902 0.025261",
[3] = "d 0.037802 0.027775",
[4] = "d 0.037799 0.030289",
[5] = "d 0.037798 0.032803",
When copying a brush mask, the Copy Settings plugin would translate these points to match the orientation of the target photo, so that the mask would appear in the correct position.
But as part of significantly improving the performance of brush masks, LR 15.4 changed the representation of strokes. When there are fewer than 250 points, it uses the original Dabs representation. But when there are more, it encodes them as an opaque BrushTable:
BrushTable_31A27BD834AA19BF4C899DCF07AE14C1 = "4000010000}`800Xs0009am20U$F(tIU-d(SvmV(-cF+p]zwB]K-h@@arV7O@Lyjh1N1=qxwU[ocAW!(`m.{jnT52Ju9rgiQt9%`Ug3nOv2FNnwDs#MzBM0AAVyJM][D(
This prevents the plugin from translating the points of the strokes to match the target photo's orientation.
Proposal
photo:getDevelopSettings() should always return the Dabs representation of brush masks, converting from the internal BrushTable representation to the Dabs format.
photo:applyDevelopSettings() should accept the Dabs representation and convert it to the internal BrushRepresentation. This code already exists to handle the transition from the LR 15.3 representation to that of LR 15.4.
This would have zero impact on built-in features, which would continue to use the current BrushTable representation. It would have very minimal performance impact on plugins invoking getDevelopSettings() and applyDevelopSettings().
