P: Pano merge of iPhone HDR images result in uneven exposure

[Russ Wright]

Hi, using latest Lightroom Classic on MacOS 26. I have found that sometimes LRC gets confused about the exposure. I have a two image example where the images are exposed exactly the same but the resulting pano is messed up. One half of the resulting pano is exposed correctly, the other half is light. I've only seen this in iPhone RAW HDR images. The one I kept was from Apple Camera but I've also seen it using Project Indigo camera.

On the Indigo forum, another person was complaining about pano issues (black bars ending up in panos). I've also seen this issue and have example RAW images.

https://community.adobe.com/t5/lightroom-ecosystem-cloud-based-discussions/p-introducing-the-project...

I tried attaching example files but that failed. How can I get images to the Lightroom team?

[moved from bugs to discussions according to the community rules - Mod.]

[johnrellis]

Upload the pics to Wetransfer, Dropbox, Google Drive or similar free service and post the sharing link here.

[Russ Wright]

Here you go. There are two folders-

1) Exposure contains two images that when LRC tries to create a pano from them fails to get the exposure correct.

2) black border - contains two images with messed up borders due to iOS or Project Indigo bug. Even when you crop out the right sides of the image, when you try to create a pano with LRC it still uses the black border and gets confused.

https://www.dropbox.com/scl/fo/aa2qr4ls17ovyxfandg3y/AAdsvTLGd4_DTdejeuimp_0?rlkey=kmxhbc8uzom032daz...

I'll be deleting the dropbox files in a few weeks so copy them please.

[johnrellis]

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

Re the Exposure example with the two iPhone 16 Pro Max Apple ProRaw DNGs:

Photo Merge > Panorama gets both the exposure and the colors completely wrong:

A workaround is to export the two DNGs back to the catalog as TIFFs in the Proraw color space, and then merge those:

There won't be any visually noticeable difference in quality.

You're also stumbling over another bug with merging Apple ProRaw DNGs, where Photo Merge is not setting the profile correctly:

However, the symptoms in that bug report did not include getting the merged exposure wrong or the colors so wrong, so this bug report should not be merged with that one.

But given that bug report is two years old and hasn't been fixed, I wouldn't expect that this bug would be fixed any time soon (if ever) either.

[johnrellis]

@Rikk Flohr: Photography: Please consider moving to Bugs.

[johnrellis]

I've copied the sample photos to here:

https://www.dropbox.com/scl/fi/fhlvnra8cdvkbirpdqwvb/bad-panos-apple-proraw.2025-08-02.zip?rlkey=vs5... 

[johnrellis]

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

"black border - contains two images with messed up borders due to iOS or Project Indigo bug. Even when you crop out the right sides of the image, when you try to create a pano with LRC it still uses the black border and gets confused."

Photo Merge > Panorama always operates on the uncropped originals. But I don't think the black bar is causing bad results.  I get pretty good results with the Perspective projection but not as good with Spherical or Cylindrical:

I get similar results if I export the cropped DNGs to TIFFs and then merge the TIFFs, demonstrating the black bars aren't affecting the merges appreciably.

[Russ Wright]

Thanks John,

For this example I agree, you just crop out the black right border and that's fine but I think I've seen odd results where an image in the middle of the pano with black border messes up the pano in a way where you can't just crop. I don't think I have an example, though. I can see ways to work around this but I'd rather the sticher just respect cropping, optionally. Oh well, not the most important issue to fix, I can see.

[Russ Wright]

With respect to the exposure bug, thanks for confirming. I wonder what is causing this problem. Most of the time my panos work. I didn't try exporting to TIFFs. A bit ugly since you no longer have an HDR tagged image, right? I'm very new to editing HDR images so need to do more reading, clearly. Maybe 16 bit TIFFs give you the equivilent.

I also noticed the profile missing message and just set the profile to adaptive color and that worked well for most of my panos. Would be nice to fix that profile bug but I'm not sure exactly what the negative result would be if you manually change the profile to something else. I've only noticed this for iPhone DNGs.

[Rikk Flohr: Photography]

Has anyone on this thread observed if Camera Raw exhibits the same issue with the Pano Merge?

[Russ Wright]

@Rikk Flohr: Photography  The example panos I provided have same issue in Camera Raw.

[Rikk Flohr: Photography]

@Russ Wright  Thanks, I will direct this to the Camera Raw team for review. 

[johnrellis]

"I didn't try exporting to TIFFs. A bit ugly since you no longer have an HDR tagged image, right? I'm very new to editing HDR images so need to do more reading, clearly. Maybe 16 bit TIFFs give you the equivilent."

I'm not expert in LR HDR editing. But with your example, the panorama merged from the 16-bit Prophoto TIFFs seemed to preserve the entire dynamic range when edited in HDR and viewed on my Macbook Pro 16" 2023. On Mac OS, you'll need to view it in Chrome or in LR:

https://www.dropbox.com/scl/fi/9tk4gudqh7tt6rdhpj1gd/tiff-hdr-pano.IMG_0945-Pano.2025-08-04.avif?rlk...

[Rikk Flohr: Photography]

Thanks for the sample files. I've logged a bug with the Camera Raw team to investigate the issue. 

[Russ Wright]

Ok, hopefully a fix in Camera Raw will also fix this behavior in Lightroom Classic? I never use Camera Raw directly.

[johnrellis]

"hopefully a fix in Camera Raw will also fix this behavior in Lightroom Classic?"

LR includes an embedded copy of Camera Raw. The entire LR / CR ecosystem releases about every 8 weeks, and it will include the latest version of CR. We might expect to see LR 14.5 next week or the one thereafter (8 weeks after LR 14.4). Given this bug was just filed, I think it's more likely that 14.6 would include a fix rather than 14.5.

[Russ Wright]

No worries, thanks in advance for fixing this issue 🙂