Ok, following up on this after some more careful testing. For files exported by LrC 14:   Plain HDR AVIF (no gainmap): works the same as it has since iOS 17. Tonemapping/display adaption is imperfect, but it displays in HDR on my iPhone and iPad. Displays in HDR on Win 11 (24H2) Photos app as well   Gainmap AVIF: Displays in HDR on the iPad, but not the iPhone - regardless of which device it was imported on! But also, has weird crushed shadows that is not present on the gainmap-less version or the gainmap JPG. Win 11 Photos sees it as SDR.   Gainmap JPG: Works perfectly on the iPad (although with almost triple the file size of gainmap AVIF + noticeably worse quality for the same image and same compression strength slider setting). Does NOT display in HDR on the iPhone 16 Pro, regardless of which device imported it. Win 11 Photos also sees it as SDR.   However, this behavior is not consistent for all gainmap JPG files! I have some files on my iCloud Photos that were taken with a friend's Pixel 8 Pro, these display in HDR on both iPhone and iPad just fine. Why does the iPhone show these in HDR but not the ones from Lightroom? Absolutely no idea!   Should also note: my 12.9 M1 iPad Pro's handling of bright HDR highlights on regular (no gainmap) HDR AVIF/JXL files is wildly different from both iOS 17, and on the iPhone 16 Pro despite also running iOS 18. ... View more

Hmm, perhaps I was mistaken. I'll do some more testing this evening ... View more

I imported some gainmap AVIF files to my iPad (via a USB drive) to test it. They work fine in the photos app there, but the copies my iPhone got via iCloud sync do not display in HDR. Which is annoying, because they seem to be working fantastic directly on the iPad. Zero tonemapping glitches, small file size, all the benefits you'd expect.   And of course, AVIF and JXL are both still broken in iMessage, even in iOS 18. Back to JPG, I guess. Gainmap JPGs seem pretty flawless on iOS 18. The show in HDR across the Photos apps on multiple devices, they post to Instagram in HDR, they send via iMessage in HDR, they seamlessly fall back in unsupported apps...the file size is just so big compared to the newer options though. ... View more

This has nothing to do with my post, I'm talking about the EXPORTED .jxl files, the size of the DNG is not what this discussion is about. Since the buffer is always RGB prior to compression, the fact that the enhanced DNGs are demosaiced is irrelevant. ... View more

Do you have HDR editing enabled for those last 400 photos? ... View more

While point releases are often a Tuesday around the middle of even-numbered months, Adobe never publicly promised that cadence. LR updates happen when they happen. It might be next week, it might be a few weeks from now. Also, when 13.3 does happen there's no guarantees it has anything besides bug fixes and camera/lens updates. Sometimes single point releases have new features, sometimes they do not.   Major releases are annual and coincide with Adobe MAX, or at least that's been the trend for a number of years now. ... View more

Did you do the entire survey? Quite a few of the AI features they asked about were asset management related (ex, an AI that locates and sorts all your HDR/pano sets, or auto detection of images with shake or missed focus)   AI is a big buzzword in the tech world right now, I wouldn't be surprised if the LR team is under orders from on high to implement more features that Adobe can point to their shareholders as them "leveraging AI". Honestly, some of the suggestions they had in that survey were a lot more useful than I was fearing we'd get from the LR team being pressured to do more AI stuff. I think my favorite proposal the survey threw out there was a neural net that would analyze how you cropped an image and apply a similar crop to a bunch of selected images. That would be a huge time saver for me on quite a few things if it worked well. ... View more

If you export as 32bit TIFF with HDR edits enabled, you should get a linear fp32 file. (Use the "Adobe Neutral" profile to stop LR from applying its own curve). Nuke/Fusion can ingest this directly, and it's fairly simple to convert to a half-float zip EXR from there if that's what you need. It's extra steps, but not complicated and can be done with software you probably have around anyway.   I'd rather have OpenEXR IMPORT in LR, tbh. LrC 13.x changed how 32bit TIFFs are handled on import and now they have much more limited tonemapping compared to linear DNGs. I wish there was another file format that's more widely support that had the same handling that linear DNGs get, and depth map support in LR would be nice too. ... View more

All of that information is still used and just compressed into SDR range when in SDR mode. The exact compression method in the traditional SDR mode is slightly different from the SDR downconversion when in HDR mode, so you might find one is subtly different from the other. Also, the tone curve module (specifically the point curve) works a bit differently in HDR mode which might be useful to you. Outside of those two things, there is no difference when delivering for SDR monitors or print. HDR mode mainly exists for delivering images for HDR screens. ... View more

@Tijolo3075623940hb Yeah, I'm seeing the same. I've got a number of things that I just can't export in their original form anymore. Only exceptions are the things I converted to DNG prior to updating to LrC 13 ... View more

Ok, follow up on this comment. After @Rikk Flohr: Photography stated this was an intentional change, I got curious about how editing in PS works for images with HDR enabled. It does indeed return them as...32bit TIFF! So it appears that the TIFF-32 importer has been repurposed from being a scene-referred loader (old behavior) to a display-referred HDR loader? That...at least kinda makes sense. It ensures PS edits return to LR exactly as they looked in PS (bringing the edited TIFF in as a scene-referred file and simply re-applying the same develop settings might produce signficantly different results)   Except this leaves LR 13.x with only Linear DNG for scene-referred input, and almost nothing supports writing that. Not even PS can write 32bit files to Linear DNG. If you have a scene-referred file from another application such as 3rd party HDR tools, astro stacking, 3D renders, etc, you're apparently out of luck unless you have an app that can convert TIFF-32/OpenEXR/Radiance to Linear DNG. Which btw, is not a functionality that exists in any Adobe product that I'm aware of. (it did in LrC 12.x, hillairiously enough, by importing a 32bit TIFF and converting it to DNG!)   tl:dr: Adobe, can we have OpenEXR import support now? ... View more

Why was the decision made to treat TIFF-32 differently from Linear DNG, when they contain essentially the same data? Is there plans for an alternative file type to Linear DNG (such as OpenEXR) since so few tools support exporting Linear DNG? Lightroom has an excellent pipeline for handling scene-linear RGB images, but it's near unuseable if it only accepts Linear DNG as inputs for that pipeline. ... View more

Do you have GPU accelerated exports enabled? Generally, you won't see fully saturated CPU use in that case, since the CPU spends some time waiting on the GPU. ... View more

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/idc-p/14146298#M47004   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. ... View more

For question 1, as you found later in the thread, that's a known limitation atm. Adobe hasn't given a timeline for supporting HDR in the full screen preview   For question 2: AVIF and JXL will work if you're on Sonoma for the Photos app, and I believe Preview? Ventura does not support HDR still images from the built-in apps, although Chrome will still work with AVIFs. ... View more

The Windows HDR Calibration app is for testing how bright of HDR signals your display will handle without clipping. Displays are supposed to specify this to Windows automatically, but often do not do so correctly. The calibration app is just to find the true max point. Since this is unrelated to your brightness and SDR content appearance settings, it won't break the calibration. Those settings just alter how far up the scale the SDR "paper white" level sits. Since calibration is only for locating the top of the scale, they don't conflict.   The reason the available stops in the LR histogram moves, is because that is based on the difference between your current SDR paper white setting, and the max HDR white signal your display has. The latter is fixed and a physical property of your monitor. So raising the SDR paper white level eats into your HDR headroom above that, which is why the HDR capability bar in LR decreases. ... View more

There are all manner of common color space issues that can cause that. Are you exporting in sRGB? Are you opening them in a color managed viewer? Does opening the image in Photoshop or reimporting it to Lightroom have the correct colors? ... View more

I have also noticed that library/loupe photos seem to have colors slightly off (I noticed it as purplish skies). I'm also on Windows 11 and using an HDR monitor. It's definitely new in 13.x. Develop and exported photos are still fine, which is where perfect color really matters, so it's not a huge deal most of the time. I believe everything except for develop mode view and exports uses a cached preview, so perhaps something is wrong with the creation or display of those previews? ... View more

Does the software that you're using for the final video support AVIF or JPEG XL sequences as HDR input footage? That would be the simplest way if it does. Just export the entire timelapse sequence, point your video software at it, set frame rate, and you're good to go. ... View more

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

The tonemap applied by the "amount" slider for ProRaw profiles is derived from a layer stored in the ProRaw file that the iPhone uses to record what edits it would've done to finish the image. Amount=100 and all the other basic panel sliders at 0 is supposed to give a result that more or less resembles the processed HEIC output you get from using the iPhone camera normally. You had some pretty extreme develop adjustments that you selected to make the shot look good without the tonemap, so stacking the iPhone tonemap on top of them procedures weird results.   When editing a ProRaw from scratch, you can use that amount slider to adjust how much of the built-in tonemap you want and how much adjustment you want to apply with the regular Lightroom tools. ... View more

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.png 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-referenced/   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   ... View more

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) ... View more

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) ... View more