Luminous Landscape Forum
Raw & Post Processing, Printing => Adobe Lightroom Q&A => Topic started by: Rory on April 23, 2015, 02:40:56 pm
-
I have a pano (2 rows of 7 portrait images from D800) that I have run through almost every pano application known to man.
(http://roryhill.zenfolio.com/img/s6/v148/p1130682639-3.jpg)
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.
(http://roryhill.zenfolio.com/img/s12/v182/p1130682681-3.jpg)
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.
-
Actually, the kudos should go to the Camera Raw team as that's who did the engineering :~)
Lightroom just came along for the ride!
-
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?
-
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.
-
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.
-
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.
-
Hi Rory, just curious: Have you also tried Autopano on your example ?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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.
-
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?
-
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.
-
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.
-
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.
-
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 (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)
-
I use Photomerge in PS CC a lot to merge multi-row panos of artworks that I reproduce. Photomerge generally gets it done fast and without any trouble. I gave such a merge to the new Pano Merge in LR6 and it rejected the files, reporting that they didn't match. I think it needs the source files to have the same pixel dimensions, which is kinda understandable, but it's NOT a requirement for Photomerge in PS.
I DO crop the files that I feed to Photomerge because there is always a background behind the artworks that does not change from shot to shot. If I leave the background in then Photomerge has trouble lining the images up.
So, for now, the LR Pano Merge is not useful for my repro panos.
-
I need to test this a bit more, but I do get very different results from using "PS Merge to HDR/Tone in 32-bits ACR" than I get when using the same files to Merge to HDR in either Lr or ACR.
The former method opens the merged file in 32-bits in ACR, and remains as such in Ps until you mode-change manually to 16 bits. So far I have found that I get smoother tone-transitions with this method although it is much slower than using the direct Lr or ACR route.
The Lr and ACR method is much faster (ACR is even faster than Lr) but I have been getting extenuated edge-effects in textured areas (such as an interior stone wall) which I find to be a bit too HDR-Grungey.
-
I need to test this a bit more, but I do get very different results from using "PS Merge to HDR/Tone in 32-bits ACR" than I get when using the same files to Merge to HDR in either Lr or ACR.
What about panoramas?
With export to TIFF, merge in panorama and back into LR, I get similar results in terms of detail with Lr but the colours are quite different and arguably not as good.
-
I actually use Bridge-hosted ACR for Panos and HDR (because it is so much faster) but it shouldn't make much difference to the results.
More experimenting showed that, when using ACR/Lr HDR, setting de-ghosting to "None" reduces traditional HDR-Grunging considerably.
-
I have a pano (2 rows of 7 portrait images from D800) that I have run through almost every pano application known to man.
(http://roryhill.zenfolio.com/img/s6/v148/p1130682639-3.jpg)
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.
(http://roryhill.zenfolio.com/img/s12/v182/p1130682681-3.jpg)
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.
I haven't done anything more than two-image stitches with this so far. Mostly, it works fine for that and seems faster than doing it in PS. Nice that it creates a dng file of the merge, which retains all of the original RAW adjustments. One glitch I have found so far with one set of photos. LR wouldn't merge these because it said there wasn't enough info to do that, even though there was a substantial amount of overlap between to two images and PS merged them just fine.
-
What about panoramas?
With export to TIFF, merge in panorama and back into LR, I get similar results in terms of detail with Lr but the colours are quite different and arguably not as good.
I did my normal procedure of processing one image, syncing that to the others, then exported to PS and merged (basically same things as making tiffs). I then merged the raw files with no processing inside of LR, and sync’ed the resulting merge from one of the files I had used to make the tiff.
Colors and tones were identical.
I also just used Adobes Flat Field plugin to fix Lens Cast issues from using a tech camera to make the dng’s, merged those and then did all processing after the merge, with great results. I liked that I was doing the processing viewing the final document and not on just one slice of it.
My normal process is to do processing in Capture One, generate tiffs then merge then use ACR or LR for tweaking of the merged file, and I do think that will still give me the best end result. I’m not clear how “raw” a linear DNG file is and if converting the phase .IIQ files to linear .dng costs anything. For some images it might, others maybe not so much. I do know that C1 is much better at cleaning up single pixel noise in shadows that have to be pulled up than LR for my Phase files.