P: 32bit TIFFs are no longer treated as raw files

[JtheNinja]

Broken: LrC 12.1

Working: LrC 12.0.1

OS: Win11 22H2

GPU driver: Nvidia gameready 527.56 (disabling GPU acceleration does not resolve the issue)

32bit TIFF files (such as 3D renders, astro stacks, HDRs from third party tools, etc) are not being rendered correctly in Lightroom Classic 12.1. The bug is new in 12.1, 12.0.1 handles them correctly/as previous versions did.

Here's how 12.0.1 handles this file:

Here's the same file, with the same develop settings and export settings, from 12.1:

The highlights and shadows adjustments simply flatten the contrast of the image. Additionally, in 12.1 the white balance slider is now relative(-100 to +100) instead of absolute (showing a kelvin temp). As if 32bit TIFFs are being treated as non-raw/non-linear files or something like that?

Here's a sample TIFF: https://drive.google.com/file/d/1WvqO09WhL3QtTVw4SEaCost6ChcwKJYX/view?usp=share_link

Steps to reproduce:

1. Load any 32bit tiff, the sample file linked above will do
2. Attempt to make some adjustments, particularly the highlights/shadows sliders
3. Note that the result is not at all as expected. (also note the white balance slider is curiously not displaying a temp, but rather a relative value)

[JtheNinja]

Additional detail I found with some more testing: if you convert a 32bit TIFF to DNG using LrC 12.0.1, the resulting DNG will no longer exhibit the issue, even once it is opened in 12.1, However, if you convert 32bit TIFF to DNG using LrC 12.1, the resulting DNG remains broken even once opened in LrC 12.0.1.

[Rikk Flohr: Photography]

The team was able to reproduce with your files - thank you.  We've logged a bug. 

[Rikk Flohr: Photography]

Greetings all,

Updates for Adobe Photography products have been released.  The February 2023  updates contain a fix for this issue. 

If you do not see the update in your Creative Cloud Application, you can refresh it by hitting [Ctrl/Cmd]+[Alt/Opt]+[ R ].

Note: It may take up to 24 hours for your update to be available in your Creative Cloud app.

Thank you for your patience.

[JtheNinja]

Hi Rick! While I can confirm the issue is now fixed in Lightroom Classic, I wanted to make sure you and the team are aware there are other cases where the same file handling bug happens. The Camera Raw plugin in Photoshop still exhibits the same issue when parsing 32bit TIFFs, and the issue is also present when using Camera Raw to convert 32bit Photoshop documents to 8/16bit (as far as I can tell, this issue effectively breaks that feature. But admitedly I don't ever use that feature either😬)

If you open the test file in the original post, you'll find that LrC 12.2 and ACR 15.2 produce different results from it because LrC 12.2 correctly parses it as a linear/raw file, while ACR 15.2 does not.

[Rikk Flohr: Photography]

Make sure you've updated both Photoshop and Camera Raw (15.2).  The Camera Raw team is listing this as fixed. 

[Ronan Mahon]

This issue was fixed, and is now once again broken in the latest version of Lightroom Classic 12.3.
On opening/importing a TIFF the exposure/tone mapping is different to how the file is displayed and saved in every other program such as Photoshop etc.

[JtheNinja]

I'm not seeing the issue here atm? ACR has its own output transform for 32bit TIFFs, so LR/ACR will never render them the way opening them in, say, the regular editor in PS will. Or your OS' image viewer.

When you open a 32bit TIFF in LrC 12.3, does the white balance slider show a relative value or an absolute temp? It should be treated as a scene-referred/HDR file and get the absolute slider, which is what I'm seeing in 12.3 here. The telltale for the bug I initially reported was that it showed a relative temp like it does with 8/16bit TIFFs or JPEGs (that, and several of the sliders like highlights/shadows had obviously messed up results, which I'm also not seeing in 12.3)

[Ronan Mahon]

I'm in the middle of a project so dont have the time to uninstall and reinstall LRC and show images sorry.
My workflow:
1. Unreal Engine rendered EXR image opened in Photoshop and saved as 32bit TIFF (LRC doesnt support EXR...) 
2. This TIFF then imported to LRC for developing

The issue - On import LRC automatically applies some sort of adjustment which means the images are really overexposed and look different to the EXR and the TIFF when viewed in Photoshop or any other image viewer. There is no way to remove that adjustment, I presume it's some different tonemapping applied to the image or it's interpreting it wrong somehow. 

I had to roll back to LRC 12.1 to temporarily solve my issue.

[JtheNinja]

Yes, like I said, LR/ACR applies its own output transform/tonemap to 32bit TIFFs. If it's going to develop them as raw files, it has to do this. The fact that 12.1 doesn't is a bug of 12.1 interpreting tiff32 as an output-referred file, which it shouldn't. Your EXR didn't come from Unreal with a tonemap or any sort of clamping, nor does the tiff32 copy. So Lightroom itself needs to apply that, and so it does. The behavior is 12.3 is the same as 12.0 and earlier, and is the correct behavior for scene-referred files.

Why the tonemap has different saturation from "gamma 2.2 and clip" that you see in Photoshop or the ACES RRT in Unreal, I don't know. I've assumed it was to match behavior of this when doing HDR photography workflows: https://photographylife.com/adobes-silent-exposure-compensation But really, I have no idea. Maybe someone from the Lightroom team could explain their reasoning, but as far as I know it's been there for years and there's probably some guy who has been importing 32bit TIFFs of his exposure stacks for the better part of a decade who would be really angry if they changed it now.

The output transforms used in most games and 3D DCCs (ACES RRT, Tcam, Filmic Blender, etc) are usually designed to behave similar to a simple gamma 2.2 function for input values below 1.0 or so, then just add a gradual rolloff for values higher than that. If you want LR to produce images a little more consistent with that, you can reduce exposure and saturation a bit. I made a profile that applies those as a look, and also throws in the Adobe Portrait looktable because it helps avoid hue skews and gamut clipping in my experience, you can grab it here: https://shared-assets.adobe.com/link/c477c3eb-02b8-436e-7dce-c031f64de2ad

Alternately, if you want the LR 12.1 behavior, that's just loading the image as an output-referred file. So you can get that behavior by saving a tonemapped image from Unreal (ex, PNG or 16bit TIFF)

[Ronan Mahon]

Unreal "burns" the viewport tonemapping into the EXR output file by default. You can optionally disable all tonemapping in the output.
Regardless of which way I do it, the image always looks different in Lightroom once it's converted to a 32bit TIFF. This same TIFF looks consistant with the EXR in any other app I open it in - be it Premiere, Photoshop or non Adobe apps like Windows photo viewer or Image glass. 

That seems like a bug to me, perhaps it's not the same one reported here but your's was the closest I could find.  

[JtheNinja]

First of all, EXRs with baked-in tonemaps, gamma curves, and other non-linear things is extremely verboten. The OpenEXR file specification states you should never do this, and most tools that properly support EXR will be expecting that you didn't do this and the data is 1) linear and 2) unclipped. Lightroom assumes the same for tiff32

To your main point, exr and tiff32 files are scene-referred. They are more like raw files than they are like finished images the way a jpg or tiff16 would be. In fact, the "linear DNG" raw files you get from Lightroom's various enhance and photo merge tools are also scene-referred floating point RGB images, so Lightroom is handling your TIFFs the same way it would those files. Because they're basically the same thing, or at least supposed to be. The data in an EXR isn't bound to display ranges and it does not have a display curve, it's a raw record of the incoming radiance that struck a sensor or film back, or at least a virtual one in this case. You have to interpret this data to actually show it on a display, and there isn't one canonical right way to do this.

Photoshop, Premiere, ImageGlass, and Windows Photo Viewer do it by simply applying the display gamma (2.2) and clamping any pixel values above 1.0, Here's what that looks like with a sample test chart of values you'd expect to get from a modern 3D engine (game engine or offline renderer): https://shared-assets.adobe.com/link/f80acf11-7741-43c4-5a05-29b81a0a8eb3

This is what it looks like passed through the ACES sRGB output device transform, which is the closest you'll get to a standardized handler for this situation. (Unreal's tonemapper is derived from the ACES sRGB ODT, but I believe it has some exposure adjustments to raise the mid-gray point a bit): https://shared-assets.adobe.com/link/dea2eb63-64dd-4d3e-4036-06ee4340d0c6

That's the view you're looking through while doing your lighting, so your raw file (the EXR) will contain values that need to be passed through an output transform like this. Something that captures floating point values up to ~16.0 or so and applies a film-like roll off to them

Lightroom does something similar, here's it's default rendering of the same test chart: https://shared-assets.adobe.com/link/e5552baf-fc98-481a-4154-458705450d81

And for reference, here's how it changes with the profile I posted in my previous comment: https://shared-assets.adobe.com/link/41628e42-5db4-4775-7414-1e34638bc4fe

Are any of these "wrong" per se? Probably not. The basic Photoshop/Premiere "gamma 2.2 and clip" method looks really bad because we're using an input image designed for the "film rolloff" style output transform. But in other situations you may actually want that behavior, because it preserves input colors for pixel values below 1.0. For a stylized motion graphics project where you need to preserve brand colors and don't have any HDR overbrights, it's great!

As for Lightroom's output transform vs the ACES sRGB ODT, that's all subjective. I wouldn't point to any of them being wrong necessarily, just different ways to interpret the same input scene. If you had an HDR monitor and wanted to output the data for those, that would need yet another interpretation. Lightroom's behavior isn't broken though, saying it is broken is akin to saying there's a bug with bayer raw images because it doesn't draw them like this: https://s3.amazonaws.com/red_3/uploads/asset_image/image/5075bb6217ef0277ee00b9ad/bayer-simulation2.... Of course it doesn't draw them like that. It's arguably the most simple and faithful interpretation of the file, but the file is unfinished data and wasn't designed to be drawn like that. OpenEXRs of photorealistic renders are the same way. And in any case, Lightroom doesn't know or care whether a 32bit TIFF is the result of an HDR stack of real photos, a 3D render, an astrophotography stack, or something else.

For further reading:

https://www.xdcam-user.com/2013/10/understanding-the-difference-between-display-referenced-and-scene...

https://hg2dc.com/2019/05/28/question-6/

https://prolost.com/blog/aces

https://chrisbrejon.com/articles/ocio-display-transforms-and-misconceptions/ (Warning: super dense)

tl:dr: What you're seeing in Lightroom is intended behavior, and should work well with an untonemapped input file

[Ronan Mahon]

Firstly thanks for taking the time to write that up. I loosely knew already about what you explained but it helped my understanding further.
I tried to impliment a full ACES workflow to combat this issue about 6 months ago, so that I would get consistant visual results at the various authoring stages and maintain the expanded data to give me more to work with in post. The Unreal implimentation was full of caveats and bugs at the time. I still think it's too cumbersome right now for me to impliment ACES in all the apps in my pipeline at the moment.
Instead what I think I'll do is what I put off before and make a profile for Lightroom to visually match the Unreal viewport. The one you linked should be a good test.  At the time I wasn't just seeing exposure but color changes also, and worried it would be too messy to match - since I couldnt find some easy profiles for what the Unreal tonemapper is doing. 
Sigh.. every time I look at color management I know it's a complex subject, and every time it gives me a headache. 
I just want to play with cool sliders and make pretty pictures and videos and not worry about banding and crappy depth. 

[JtheNinja]

@Rikk Flohr: PhotographyThis issue appears to have returned in 13.0 😞

[Rikk Flohr: Photography]

I will have the team take another look. 

[SvenFlock]

Hi all,

as of version 13.0 (macOS Sonoma) external created 32bit HDR files (e.g. TIFF/PSD by PTGui Pro) are not rendered and imported properly. The following issues occur:

• Real color temperature is not given (instead it shows the slider with offsets only like on LDR images)
• Images renders flat (like log based)

Already 32bit TIFF files are still working and show the correct color temperature and image rendering, however, newly imported images have that issue.

Please find attached three screenshots from the sliders from previously imported 32bit TIFF files (showing 5001/0 as color temperature and the reimported one (0/0 offsets). Funny thing, though, the faulty rendered image has the extended exposure range of -10EV to +10EV (third screenshot).

As this is by design: is there any workaround to get new imported images back to the old style? If not, this version is a no go as it breaks my HDR workflows.

Thanks!

[SvenFlock]

Why is this moved to discussions? It's not behaving as it was before v13.

[SvenFlock]

Thanks for the upvotes. Can I assume that everyone who upvotes share the same issue?

[Rikk Flohr: Photography]

You cannot assume that. It has been documented in other posts that there are Phantom Upvotes as a result of bot traffic. The forum team is working on that. As no one else has posted - I think it is safe to assume that the value is much lower than the 6 votes (at the time of this writing). 

Regarding your issues - the screenshots do not appear to represent anything supporting your assertions, as they are missing critical parts of the screen. 

Tiff files have a WB baked into the file. It is expected that a Tiff shows an offset value instead of a Kelvin temperature on the Temp slider. 

[SvenFlock]

What screenshot would you need? I can provide you with a sample 32bit HDR TIFF file generated by PTGui Pro. This kind of files got a Kelvin scale in the previous Lightroom Classic versions. As it is 32bit, color temperature information is available in contrast to 16bit TIFF files.

In Lightroom 5, it is already available. Please look at that YouTube video: https://youtu.be/YsuyUx3Wrr8?t=484

I think it is a bug. 

Happy to help with examples.

[Rikk Flohr: Photography]

"I can provide you with a sample 32bit HDR TIFF file generated by PTGui Pro. "
Please do.

[JtheNinja]

I believe this is the same issue I reported here? It seems to have returned in LrC 13.x https://community.adobe.com/t5/lightroom-classic-bugs/p-32bit-tiffs-broken-in-lightroom-classic-12-1...

It's basically impossible to use the new HDR tools with files from external editing apps due to the 32bit TIFF importer being broken. Linear DNGs still import correctly, but almost nothing can write linear DNGs, not even Photoshop. 32bit TIFFs are supposed to be handled the same way linear DNGs are, but they currently are not. It's like some wires got crossed and 32bit TIFFs are being treated like 8/16bit TIFFs instead of as scene-linear files.

Alternately, if anyone knows a way to convert TIFF-32 (or OpenEXR) files to Linear DNG that doesn't involve Lightroom/ACR, that could workaround this issue. But I've never seen any software that can do it.

[Rikk Flohr: Photography]

@JtheNinja  After reading your previous post - (which is still under evaluation btw),  I agree this is in the same family of issue. As the Camera Raw team is tracking that post, I am going to merge these two together. 

[SvenFlock]

Hi,

there is indeed a workaround to get functional Kelvin color temperature and color settings back to work. The new version of Photomatix Pro (v7) supports linear DNG export. So, I tested the workflow to safe my HDR content to Radiance files (TIFF don't work) and then skip the tonemapping and choose direct export to DNG. Please find a screenshot attached, color temperature is back. Though, there are extra steps involved, it's better than the currently broken ACR version. Hope that helps!

[Tijolo3075623940hb]

I'm experiencing the same issue and I can ensure you that neither me or the issue are phantoms.

[SvenFlock]

LoL, so let's hope Adobe takes it serious and fixes it in an upcoming minor .x update 🙂