Initial impressions of pano in Lr 6

[Rory]

I have a pano (2 rows of 7 portrait images from D800) that I have run through almost every pano application known to man.



Lightroom is the first pano program I have used that successfully integrated the area shown in the red square.  For some reason other applications cannot line up the curb and concrete in this area.  

I am running a Win 7 64 i7 with 8 cores and 16GB RAM.  It took 12 minutes to create the pano, which is 22549 x 10155 pixels and the dng file is 1GB in size.  While it is running everything else slows right down as Lr utilizes most of the resources. I'm not sure why the dng file is so large as the 14 NEF files used to generate the pano add up to 645 MB and there is a lot of overlap.  It also took a very long time, around a minute of "loading" when I zoomed to 100%.  Not very good performance.



So it is not quick, but for my test case, it is the best pano composite I have seen and you are still working with raw data afterwards.

I had set the pano generation to automatically crop.  I then ran auto upright, which worked, but removed the crop.  I don't think it should have done that.  Edit: I had constrain crop turned off in the basic tab of Lens corrections.

However, kudos to the Lr engineers for the quality of the composite.

[Schewe]

Actually, the kudos should go to the Camera Raw team as that's who did the engineering :~)
Lightroom just came along for the ride!

[Wolf Eilers]

Does this mean that the pano algorithms in Camera Raw are different than those in Photoshop? In other words, can we possibly expect different results when using Camera Raw pano versus Photoshop?

[Rory]

Does this mean that the pano algorithms in Camera Raw are different than those in Photoshop? In other words, can we possibly expect different results when using Camera Raw pano versus Photoshop?

I think it is, however I will try this in the latest version of photoshop cc and get back to you on whether the results are different.

[Wayne Fox]

Does this mean that the pano algorithms in Camera Raw are different than those in Photoshop? In other words, can we possibly expect different results when using Camera Raw pano versus Photoshop?

I’ve also seen similar results, panos that I had to use PTGui to stitch because of errors in Photoshop do not show those errors when stitched with LR 6/CC.  From a  workflow perspective this feature is really helpful. The ability to stitch the raw files first, and then process the image so visually you are seeing the entire image is so much better than before where it required adjusting one image, syncing the adjustments then merging in photoshop.

[Rory]

I think it is, however I will try this in the latest version of photoshop cc and get back to you on whether the results are different.

Well I just ran the same files through photoshop cc 2014.2 and got the same result, so is appears Lr and PS are very similar.  PTGUI and ICE both ran into difficulties in the same place as before.

[Stephane Desnault]

Hi Rory, just curious: Have you also tried Autopano on your example ?

[Cayman]

I tried a pano that had some lightly clouded sky in some of the tiles with no ground elements.   AutoPano Giga 4 correctly did it, but Lightroom made a complete mess of it.    I also had one where I had mistakenly taken two exposures at the same angle.   Lightroom spent about an hour churning away before coming back and saying it could not figure how to stitch it.    Once I removed the duplicate tile it finished fairly quickly.

When Lightroom succeeds though it does seem to do an exceptional job with balancing varied exposures to get a consistent sky.    It also seems excellent on providing a straight horizon line.

[Rory]

Yes.  It worked great except for this one.  It might has something to do with how the two rows line up.  It's no big deal, just impressed with the Lr/Ps latest implementation.

[Deardorff]

Sure hope it is vastly improved over Photoshop 6 which gives wierd results from time to time. Auto Pano Pro has been much better for me. Have not tried Lightroom yet but will when I can get the CD version of this latest update.

[Kirk Gittings]

I just ran a side-by-side comparison of a panorama in PSCC2014 and LRCC2015 and LR took 3X as long and had two major errors in the sky where as the PS one was perfect. I cannot explain this by anything I did any differently. I'm very disappointed so far with this feature in the new LR.

[Alistair]

I just ran a side-by-side comparison of a panorama in PSCC2014 and LRCC2015 and LR took 3X as long and had two major errors in the sky where as the PS one was perfect. I cannot explain this by anything I did any differently. I'm very disappointed so far with this feature in the new LR.

It seems very intensive on memory in LR. I have 32Gb and a 10x36mp pano used 88% of memory at one stage.

[ihv]

This is a good sign that available resources are used, no?

It seems very intensive on memory in LR. I have 32Gb and a 10x36mp pano used 88% of memory at one stage.

[Bart_van_der_Wolf]

I just ran a side-by-side comparison of a panorama in PSCC2014 and LRCC2015 and LR took 3X as long and had two major errors in the sky where as the PS one was perfect. I cannot explain this by anything I did any differently. I'm very disappointed so far with this feature in the new LR.

Hi Kirk,

The problem with these automatic Pano-stitchers is that; if it works, it works, but if it doesn't work, there's no cure because manual intervention is not possible. In your example, there may have been cloud movement between shots, which can confuse automatic stitchers.

In particular moving objects/subjects (clouds, waves, branches, flags, people, featureless sky, etc.) can confuse the algorithms and prevent them from reaching an optimal solution that makes sense. When additional challenges are added, such as handheld shooting or the use of lens shift, then the likelihood of (partial) failure is increased a lot.

As I said, it's nice if it works. The improvements in automatic stitching are promising, but I wouldn't bet my livelihood on it. I still trust solid solutions like PTGUI a lot more when it comes to such a specialized operation. Also the choice of output projection methods is much better, as is the resampling quality.

Cheers,
Bart

[Kirk Gittings]

I have worked with the pano tool in PS for years and know exactly how I need to shoot one for PS to render it well. It is a stndard tool I use in making my living and have had no problems with it in PS in years. Lets say I haven't had a failure in 5-6 years. I am a bit astonished and dismayed that Adobe would introduce a highly touted new tool in LR that was such a poor cousin of the tool we already had in PS.

[dreed]

It would seem that the panorama feature converts each raw file into DNG and then merges the DNGs?

Has anyone done any testing to see if this is an accurate assessment?

In terms of the merge itself, it really feels like a "version 1.0".

Why?

It doesn't have the ability to show seams in the "middle" step
It doesn't automatically reject photos correctly from a merge (sometimes it includes when it shouldn't, others it excludes when it really shouldn't)
It doesn't have any way of saying "yes, in the image X moved from 1 to 2, so use 2"

Is anyone using panorama mode in ACR to generate DNG files for earlier versions of Lr?

[Cayman]

As I normally use capture one as a raw converter, I tried it with tiffs exported from there.  It warns you that raw is ideal and proceeds to make a panorama.   The stitching was not as good as when done with the raw files. 

[Ann JS]

Lr CC 2014 and using Ps or Bridge-hosted ACR 9 produced virtually identical results. Both are fast but ACR does it twice as quickly as Lr and opened it diectly into Ps as a smart object for final editing, sizing and output.

ACR 9 took just under 3 minutes to merge and generate this Pano from 16 frames. The series was shot hand-held.

I did no local retouchingon this Pano and find it quite remarkable that ACR can stitch a seascape with crashing waves without any apparent artifacts.

[Schewe]

It would seem that the panorama feature converts each raw file into DNG and then merges the DNGs?

Has anyone done any testing to see if this is an accurate assessment?

Pano (and HDR) converts a raw image to Linear DNG (still sorta raw) and then does the DNG/Pano blend. So the image in HDR is 16-bit floating point but the processing is done in 32-bit floating point. The Pano blend is 16-bit Linear DNG.

[Jim-St]

I've found issues with LR's Merge to Pano running on files from my Leica M9.

I posted about it here https://forums.adobe.com/message/7482504 on Adobe LR Forum, and conclude from ensuing discussion (see in particular post 15 in that thread) that the issue arises from the wacky way the Leica digital M's "make up" aperture settings info (as they have no electronic communication with the lens's aperture ring).

It looks like the disparities the camera introduces into recorded aperture settings across a set of shots taken at a single aperture setting may lead ACR/LR to try to apply exposure compensation where none is needed (as the aperture setting info is essentially fictional), and thus to set different tonalities on adjacent "slices" of the pan composition.

Can anyone here confirm if this sounds like a plausible explanation?

Here's a screenshot that shows what I'm seeing in the Merge to Pano preview (same is carried over into final output file)