P: Inconsistent results when copying white balance between raws & JPEGs via Sync, preset, & the SDK

[John R Ellis]

LR gives inconsistent results when copying white-balance settings between JPEGs and raws, depending on whether Copy/Sync, presets, or the SDK is used -- each method gives different results. They should either give the same results, or the white balance shouldn't be allowed to be copied between raws and non-raws.

1. Download this catalog folder:

https://www.dropbox.com/scl/fi/e30gieo2wdokek42uam07/white-balance-bug.2023.11.07.zip?rlkey=ss8dm5wm...

2. Install the two scripts in the folder, "set-temp-tint.lua" and "set-incremental-temp-tint.lua" in the Lightroom Scripts folder.

3. Open the catalog.

4. Select wb.jpg in Develop and set Temp = 24, Tint = 29.

5. Make a preset JPEG Temp/Tint with just White Balance selected.

6. Select both photos with wb.jpg most selected and do Sync Settings with White Balance selected.

7. Open wb.arw in Develop and observe Temp = 5000, Tint = 21.

8. Reset wb.arw and apply the preset JPEG Temp/Tint. Observe that Temp = 5450, Tint = 50, different than the result of Sync Settings.

9. Reset wb.arw and run the script "set-incremental-temp-tint.lua" (containing the same Develop settings as the preset JPEG Temp/Tint) and observe that Temp = 3850, Tint = 21 (unchanged), though WB has been changed to Custom.

Thus: three different values for the raw's Temp/Tint, depending on whether white balance is Synced from a JPEG, applied with a preset, or set by the SDK.  Copying Temp/Tint the other direction:

10. Select wb.raw in Develop and set Temp = 5000, Tint = 21.

11. Make a preset Raw Temp/Tint with just White Balance selected.

12. Select both photos with wb.arw most selected and do Sync Settings with White Balance selected.

13. Open wb.jpg in Develop and observe Temp = 24, Tint = 30.

14. Reset wb.jpg and apply the preset Raw Temp/Tint. Observe that Temp = 19, Tint = 0, different than the result of Sync Settings.

15. Reset wb.jpg and run the script "set-temp-tint.lua" (containing the same Develop settings as the preset Raw Temp/Tint) and observe that Temp = 0, Tint = 14.

Thus: three different values for the JPEG's Temp/Tint, depending on whether white balance is Synced from a raw, applied with a preset, or set by the SDK. 

[Rikk Flohr: Photography]

I've logged the issue with the team @John R Ellis 

[sb-x]

hm, so, is there actually a official "correct" translation between jpg<>raw? So far, I had the impression they are just pretty much independant and it is not so easily possible to translate between the values.

[John R Ellis]

I don't understand enough about the math of color science to know how hard it might be to get a good translation from Temp/Tint on a raw to Temp/Ting on a JPEG, or vice versa. But regardless of the quality of the translation, LR should give the same results regardless of how Temp/Tint is copied (Copy/Sync, presets, or the plugin SDK).

[D Fosse]

Thranslating temp and tint between raw and jpeg makes no sense. They are two different things.

[John R Ellis]

[This post contains formatting and embedded images that don't appear in email. View the post in your Web browser.]

"Translating temp and tint between raw and jpeg makes no sense. They are two different things."

By design, when LR copies Temp/Tint from a raw to a non-raw or vice versa, it picks Temp/Tint settings for the destination that approximate the visual appearance of the source photo.

Here's an example. The first row contains a raw and a JPEG exported from the raw. In the second row, the raw Temp was adjusted and its white balance synced to the JPEG.  In the third row, the raw Tint was adjusted and its white balance synced to the JPEG:

LR sets the JPEG's Temp and Tint to approximate the visual appearance from the raw:

Given that LR is designed to approximate the visual appearance when copying Temp and Tint between formats, the copying should (but doesn't) produce the same JPEG Temp/Tint settings (different than the raw settings) whether one is using Copy/Paste, Sync Settings, presets, or the plugin SDK. The current behavior was surely not intended by the product manager.

Note that copying the image-adaptive Basic sliders (Exposure, Contrast, Highlights, Shadows, White, Blacks) from raws to JPEGs and vice versa work analogously -- they approximate the visual appearance of the source image, even though internally they are using different computations for the two formats. Usually the differences between the raw and the JPEG are small but sometimes they are quite noticeable. (I warn users of my Export LUT plugin to use it with non-raws rather than raws for that reason.)

[Rikk Flohr: Photography]

The team has kicked this back as "as designed" with the following explanation:

"The difference in behavior is because, in some workflows, the full negative is available; in others, only the metadata negative or no negative is present. In this case, when WB is being applied across Raw and non-Raw images, the full negative is needed to get the correct result. So when preset is applied to a single image in Develop, it works fine because it will use the current full negative from the controller. But suppose the preset were to be applied in Library using QD or even from Develop but on multiple images. In that case, it will use metadata negative only, which will give different results. The same is true for Copy-Paste workflow. For SDK API, settings are pasted verbatim but since JPEG's WB values are not valid on Raw image, it doesn't change anything. Changing this behavior would incur a significant performance hit of loading full negatives for all the operations."

[John R Ellis]

Thanks much for the technical explanation of the current behavior. Of the four possible designs:

1. Faster but incorrect results.

2. Slower but consistent results.

3. Prohibit copying Tint/Temp between raw and non-raw.

4. Ask the user whether they want the fast/wrong or slow/correct results.

I think the current design (1) is least useful. How many users would find faster-but-incorrect results even useful?

[D Fosse]

No numerical adjustment makes any sense copied from raw to RGB or vice versa. This is one of many things that are possible to do, they just shouldn't be done because the result is inherently unpredictable and doesn't really apply. 

Even an adjustment copied from an Adobe RGB file to a ProPhoto file may produce a very different and "unexpected" result. The Lightroom sliders operate in a custom color space with sRGB tone curve and ProPhoto primaries (and, I presume, a D65 white point). This does not match any standard RGB color space.