Workflow for RAW to Stitched DNG Pano?

[pegot]

So I just upgraded to PTGui 13 and am looking into developing a workflow for stitching directly from RAW files and exporting to a DNG panorama.

Before working with DNG files, I would make all my lens, noise, and other basic light adjustments in Adobe Camera Raw, then export as Tiff to be stitched in PTGui.

With current version I can use the RAW files and stitch directly to a DNG, which can be further processed in ACR.  This is necessary since PTGui cannot currently read any of the processing data from native RAW files adjusted through ACR, nor any of those ACR adjustments when exported as individual DNG files.  I don't see this as much of an issue as long as the final pano, in DNG format, can still be processed in ACR afterwards, with the benefit of not needing an extra set of input files.  

To me this provides great flexibility.  My question, though, is what offers the best overall quality?  Stitching from 16bit Tiff files that were adjusted in and exported from ACR, or stitching the RAW files directly to DNG and making ACR adjustments on the final pano afterwards?

What workflow are others using and why?

Do you still output individual Tiff files for stitching?

If using RAW files directly, do you use PTGui’s RAW processing? Or do you denoise and fix chromatic aberration and fringing in a more complete RAW processor on the stitched DNG pano afterwards?   Is there any benefit to adjusting these parameters directly in PTGui before stitching, as was the usual workflow when using Tiff files?

Also: why does PTGui only offer the ability to fix purple fringing?  ACR has options for both purple and green fringing.

At some point, might it be possible for PTGui to be able to interpret edits made to RAW files from ACR? I did find this previous older post which partially addresses this:

DNG output needs improvements (missing profiles, metadata issues, compression):

https://groups.google.com/g/ptgui/c/cPbfkawhs7U

[PTGui Support]

Hi,

On 3/5/26 19:06, pegot wrote:
> This is necessary since
> PTGui cannot currently read any of the processing data from native RAW
> files adjusted through ACR, nor any of those ACR adjustments when
> exported as individual DNG files.

This impossible. The DNG files are not actually changed. ACR stores its
adjustment parameters but those parameters are specific to ACR's own
algorithms.

> At some point, might it be possible for PTGui to be able to interpret
> edits made to RAW files from ACR? I did find this previous older post
> which partially addresses this:
>
> DNG output needs improvements (missing profiles, metadata issues,
> compression):
>

> https://groups.google.com/g/ptgui/c/cPbfkawhs7U <https://
> groups.google.com/g/ptgui/c/cPbfkawhs7U>

This is mostly solved n the current version, I'll post a reply in that
thread.

Kind regards,

Joost Nieuwenhuijse
www.ptgui.com

[sc...@highton.com]

I've been doing this for so long that my process seems second nature now, but it does involve multiple files.

I shoot everything in Nikon's NEF raw format.  I then use the Bridge/Photoshop (open them all in Bridge, which then calls upon ACR and Photoshop) combination to make all adjustments to these raw source images.  These adjustments are stored as sidecar XMP files, so the original RAW file is never changed.  Once I've done adjustments this way (still in Bridge), which can be applied to all images or individually, I then batch export them as TIFF files into their own folder – which all have my adjustments incorporated.  It is these TIFF files that I then bring into PTGui for stitching.

If I find further adjustments are needed, I can go back into any (or all, if necessary) raw NEF file in Bridge and repeat the process.  The I just replace the old TIFFs in the PTGui stitching folder with the new ones.  Closing the PTGui project and reopening it automatically updates the source TIFFs.

Once my stitching is completed satisfactorily, I'll often tweak the completed equirectangular panorama in Photoshop again before putting it into Pano2VR for tour production.

I find it far more effective and less time consuming to make all my initial adjustments to the individual source images, and then stitching them, than just stiching them and trying to adjust only in the stitched equirect.  Most cameras have slight (1/4 to 1/3 stop) exposure varaiations between shots, even when set in manual exposure mode.  Also, exposures at the same settings look lighter or darker as the camera pans due to internal light flares in the lens.  It's best to make these match as closely as possible before stitching.  Otherwise, you wind up trying to make adjustments across blended gradations in the stitched panorama, which can be a nightmare.

If I knew of a more efficient way to do this and still have the precise control I need, I'd do it.  But after a couple decades of doing it this way, I've not found it.  :-)

[Erik Krause]

Am 05.03.2026 um 19:06 schrieb pegot:

> Or do you denoise and fix chromatic aberration and fringing in a
> more complete RAW processor on the stitched DNG pano afterwards?

You can not fix chromatic aberration (lateral CA) on a stitched
panorama, since depends on the distance from the optical axis in the
shot image. See https://wiki.panotools.org/Chromatic_aberration on
details about CA.

Fringing doesn't depend on image geometry, hence it can be possibly
removed in a stitched panorama. However, often they are mixed with CA
and hard to remove alone.

A spherical panoramic image is heavily distorted toward the top and
bottom edge, which makes it hard to denoise, since most denoising
algorithms assume noise to be uniform throughout an image.

That's why I would always leave CA and fringes correction as well as
denoising to a decent raw converter and stick to stitching 16 bit TIFFs.

Also note that the DNG files written by PTGui are not true raw files, as
they do not contain raw data from the sensor, but rather a debayered
image. DNG is a container format after all, basically a TIFF with added
metadata.

BTW.: You can f.e. use Adobe Bridge to pass most image file formats to
ACR, not only raw files. Or in Photoshop do Filter - Camera RAW Filter.

--
Erik Krause
http://www.erik-krause.de

[pegot]

Thank you.  Your described work flow is exactly how I too have been making my panos for years.  And now I can continue using that method knowing it is generally the most optimal.  

[Philip Chong]

For me, I still use the first method. I edit everything in ACR, then save it as 16 bit TIFF and pass it to PTGui for stitching only. After all, PTGui is very good for stitching only, it is not a photo editor. 

I do believe 16 bit TIFF is as good as DNG. What about you?

I have to give PTGui credit for correcting the darkening stitch lines of Samsung Gear 2017 because of the dark vignetting at the corner of the lens.

[PTGui Support]

Just be careful when developing your raw images prior to stitching: it's
best not to enable shadow/highlight adjustments, and ensure that all
source images are developed using the same settings.

Otherwise there will be local brightness differences which the blender
will have to undo again. And these can lead to blending artifacts,
especially visible in skies. The same problem occurs if you try to
stitch pre-tonemapped images. It can be insightful to switch the
panorama editor to Unblended mode, any differences will clearly show.

This is even more an issue if you use PTGui to create true HDR images.
The best results are obtained from DNG/RAW source images because they
are perfectly linear. If you use non-raw source images, PTGui will need
to figure out what magic was applied during raw conversion and undo this
in order to find out the actual luminance and color of each pixel.

Kind regards,

Joost Nieuwenhuijse
www.ptgui.com

> groups.google.com/g/ptgui/c/cPbfkawhs7U> <https://
> > groups.google.com/g/ptgui/c/cPbfkawhs7U <http://

> groups.google.com/g/ptgui/c/cPbfkawhs7U>>
>
> This is mostly solved n the current version, I'll post a
> reply in that
> thread.
>
> Kind regards,
>
> Joost Nieuwenhuijse

> www.ptgui.com <http://www.ptgui.com>
>
> --
> You received this message because you are subscribed to the Google
> Groups "PTGui Support" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to ptgui+un...@googlegroups.com
> <mailto:ptgui+un...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/ptgui/
> dbf81bb0-fdbd-44c7-867f-38f758606f91n%40googlegroups.com <https://
> groups.google.com/d/msgid/ptgui/dbf81bb0-
> fdbd-44c7-867f-38f758606f91n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

[sc...@highton.com]

Hi Joost,

Unfortunately, correcting and optimizing source images prior to stitching is generally a necessity – particularly for shadow & highlight adjustments in panoramas shot outdoors or under higher contrast lighting conditions.  Even exposure adjustments that differ between source images are necessary prior to stitching, due not only to subtle exposure differences by the camera (even with matched exposure settings), internal lens flaring, and brighter/darker areas of the scene (sunlit direction vs. shaded direction), etc.

Failing to make these adjustments results in often complex (and inferior) work in post production after stitching.  Your warning, however, may explain why I get horrible stitching artifacts in sky areas at times, or in other large areas of subtle color & brightness differences.

To correct this, I've found that turning off Find Optimum Seams (and sometimes Exposure Correction) in the Panorama Editor (Blending) will produce the expected smooth sky, but loses the better seams of Find Optimum Seams.  I'll output two different versions of the panorama with all other settings the same and combine the best parts of both in Photoshop for a final result.  It adds some unfortunate steps, but mitigates the poor sky stitching issues.  I should add that much of my panoramic work is shot with the camera on a pole, so NPP alignment is rarely as perfect as it can be with tripod shooting.  After Optimizing all images to the first and masking carefully, Find Optimum Seams is a wonderful tool to mask remaining stitching errors.  It just doesn't seem to handle skies terribly well, whether clear blue or with moving clouds.

It's interesting to know that these issues may be the result of making source image adjustments (such as shadow & highlight) prior to stitching in PTGui.  I'll have to do further testing.

Thanks.

Scott Highton

Author, Virtual Yosemite

Web: https://www.virtualyosemite.org

[PTGui Support]

Hi Scott,

Try switching the panorama editor to Unblended mode. If you see large brightness differences then you know the blender has to do a difficult job. Indeed the optimum seam finder may fail if the difference is large. After all it is looking for similarities in the overlap area.

PTGui offers several workflow options, and since PTGui 13 one of them is to stitch DNG source images to DNG output. It's not flawless (see Erik's remarks), and if you're used to spending lots of time during raw conversion then it will probably not meet your standards. But it is convenient and it does avoid some pitfalls. Just wanted to put that on the table, for those looking for workflow recommendations.

[Erik Krause]

Am 06.03.2026 um 22:46 schrieb 'PTGui Support' via PTGui Support:

> Try switching the panorama editor to Unblended mode. If you see large
> brightness differences then you know the blender has to do a difficult job.
> Indeed the optimum seam finder may fail if the difference is large. After
> all it is looking for similarities in the overlap area.

I must admit, that like Scott, I do some preprocessing in the initial
raw conversion step, namely boosting shadows and reducing highlights.
However, since I do a lot of my panoramas handheld, even the bracketed
ones (I use PTGui to align, then do SNS-HDR batch merging before
stitching), Optimize Brightness in PTGui does a poor job usually. What I
do if the sky is not smooth enough, is hand-tweaking Exposure offset for
some of the sky images in Pano Editor unblended mode.

My recent WWP panorama was a handheld bracketed shot in the dark, quite
a while after sunset. For this I boosted the brightness extremely during
raw conversion, simply to have some information to align the brackets
with PTGui. Having batch-created all the project files for aligning the
single images, I did the raw conversion again with some more reasonable
settings, before I started the actual "stitch" and merge of the single
images. PTGui deals well with the resulting non-uniform brightness
differences. I didn't even need to tweak exposure offset for single
images. The result is here: https://worldwidepanorama.org/go/n10600