PTGui 12 - What is the best input format for stitching to get the most dynamic range out?

[Sven Flock]

Hi all,

As I have seen from the release notes from PTGui 12, even non-HDR panoramas are processed in 32bit internally. Following old discussions (https://groups.google.com/g/ptgui/c/MUVnOnLyA4Q) it is recommended to use TIFF 16bit as input. On the other side, 16bit TIFF does not capture all stops available in the raw file (see https://www.dpreview.com/forums/thread/4262265). 

So, starting from version 12, would you recommend to input RAW files directly and output the result as HDR format to have full control of white balance and no loss in dynamic range compared to tiff? 

If so: is dcraw still used as raw converter? Ignoring extra steps: would it be better to input DNG in contrast to camera specific raw files? 

Before version 12, my workflow started in Lightroom applying lens corrections and noise reduction and send it as 16bit TIFF output to PTGui. If indeed I can get more dynamic range from raw/dng input, I would switch my workflow to DxO to apply noise reduction and lens corrections directly to DNG output.

What do you think?

Bye,

Sven

[Erik Krause]

Am 02.04.2021 um 18:41 schrieb Sven Flock:

> On the other side, 16bit TIFF does not capture all
> stops available in the raw file
> (see https://www.dpreview.com/forums/thread/4262265).

The examples on that dpreview page contradict themselves. To show them
on a computer screen they must be converted from raw to some image
format. That alone is evidence enough that it is possible to convert raw
to TIFF such that all dynamic range is preserved. It must be done right,
though. See https://wiki.panotools.org/RAW_dynamic_range_extraction to
get an idea.

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

[Sven Flock]

Hi Erik,

I agree with your link and in particular, it does not contradict the statement from the link that raw includes more data than TIFF, if the raw file is not "compressed" to fit into the file format (of course, other comments are not correct). For a single shot, I think this is a valid approach to fine tune everything in ACR, but for high resolution HDR panoramas, there are a lot of pictures to process. To keep manual steps as low as possible I thought inputing RAW can safe that extra steps as the information is still available in the final 32 bit output (and PTGui 12 does not lose that information as it process the image data in 32bit as well). I would need confirmation that PTGui 12 can handle the full potential of RAW files. If not, I'll need to find a common set of adjustments to all exposure sets to increase dynamic range.

Bye,

Sven

[MD]

It depends if you're planning on doing a lot of color grading after? Are you talking about single images or bracketed? Because for single images i would probably process them beforehand anyway. But if you're doing bracketing the more important thing might be how many images do you bracket and how much EV are they apart. I find that 5 images at 1 2/3 EV apart works best, while 2 EV seems to be too much, and 3 images too little.

The results are much more gradual if there are more exposure steps to work with, and of much greater influence it seems to me.

In fact i've tried to compare the 16-TIFF vs JPG95% as input files but there is no obvious difference to me (as multiple images are combined anyway).

I'm either rendering the final image to JPG directly with PTGui's tonemapping, or to EXR format (16-bit half float) and post-processing the result in SNS-HDR. To prepare the images i use Capture One with the "Film Extra Shadow" curve.

Op vrijdag 2 april 2021 om 19:57:34 UTC+2 schreef sven....@gmail.com:

[Sven Flock]

Let's keep the use case limited to non-bracketed panoramas because those other images help restore the data which got lost by a sub-optimal RAW->TIFF16 conversion.

I want to focus on the new possibilities of PTGui 12, i.e. because of the internal 32-bit processing of ALL panoramas, we have now - theoretically - a larger dynamic range available if the RAWs can be taken to its full potential and now adjustments have been applied to TIFFs in the first place to safe highlights and boost shadows.

I want to avoid the pre-processing of shadows and lights to get the best out of TIFF16 (see link from Erik). This must be done for all images and in worst case, every image must be treated differently resulting in inhomogeneous stitching. This is different than lens corrections as they are globally true.

This is what I want to get answered :-): does PTGui 12 take all RAW image data into internal processing or is some clipping/other limitations done to the RAW files? If not, then we get the complete dynamic range as output without doing any pre-adjustments to the input files (as for TIFF).

Thanks,

Sven

[PTGui Support]

Clipping the highlights is unavoidable when converting raw files.

The raw image data has different rgb chromaticities from the target
color space, so a color conversion is part of the process. Also the
sensor has different clipping levels for each color channel. And
highlights need to be gradually desaturated when they get close to the
clipping levels. All this means that a safety margin is needed for the
highlights. A dedicated raw converter can probably squeeze some more
information from the highlights than PTGui.

But if your bracketing sequence is wide enough to cover all highlights
this will not be an issue.

PTGui doesn't do noise and CA reduction, but if this is not an issue,
raw files are nicely linear and very suitable for generating HDR.

With externally converted files the problem is that PTGui needs to
reverse engineer the raw conversion parameters in order to reconstruct
the linear image data.

Kind regards,

Joost Nieuwenhuijse
www.ptgui.com

> <https://www.dpreview.com/forums/thread/4262265>).

>
> The examples on that dpreview page contradict themselves. To
> show them
> on a computer screen they must be converted from raw to some
> image
> format. That alone is evidence enough that it is possible to
> convert raw
> to TIFF such that all dynamic range is preserved. It must be
> done right,
> though. See
> https://wiki.panotools.org/RAW_dynamic_range_extraction
> <https://wiki.panotools.org/RAW_dynamic_range_extraction> to
> get an idea.
>
> --
> Erik Krause

> http://www.erik-krause.de <http://www.erik-krause.de>
>
> --
> 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 on the web visit
> https://groups.google.com/d/msgid/ptgui/99dd6094-8186-4aa2-80cd-db3a82295c3en%40googlegroups.com
> <https://groups.google.com/d/msgid/ptgui/99dd6094-8186-4aa2-80cd-db3a82295c3en%40googlegroups.com?utm_medium=email&utm_source=footer>.

[MD]

What you say of course is true, and i've struggled with the same idea, but bracketing ended up being the best solution for me. At least the dynamic range and tonality i'm getting in the end is undoubtedly bigger than i know a single Raw contains. I might say i'm getting the 'complete' dynamic range of the scene from the sun to the deepest shadows. It's quite impressive, so that makes it worth the effort.

Have you tried the DNG option? Keep in mind that DNG is essentially just a container. So the question is what is actually exported. For example when merging multiple images to HDR in Lightroom the images will have to be processed one way or another, while DNG i assume is simply used to losslessly store it in 32-bit. Something like this is want you want, only with a single image, and with lens corrections etc already applied.

I don't have Lightroom or DxO to see if that's possible, but let me know if it is!

(when i try exporting to DNG in Capture One it says Not Supported!)

Op vrijdag 2 april 2021 om 20:59:13 UTC+2 schreef sven....@gmail.com:

[Erik Krause]

Am 02.04.2021 um 19:57 schrieb Sven Flock:

> it does not contradict the statement from the link that raw includes
> more data than TIFF, if the raw file is not "compressed" to fit into
> the file format (of course, other comments are not correct).

It might even be that a TIFF converted in a decent raw converter
contains more data than the original raw, due to highlight
reconstruction. As Joost writes the three RGB channels are not clipped
at the same level. To avoid highlight color casts, a simple raw
converter like dcraw or libraw would clip all channels on the level of
the lowest one (or even below, for a safety margin). A decent raw
converter will try to reconstruct the clipped data from the other,
unclipped channels. So if you want to go for maximum dynamic range from
a single exposure you'll most likely be better off if you use ACR /
Lightroom.

dcraw has a parameter (-D) to output totally raw data in an image
format, no de-bayer, no interpolation, no color, just the pixel data. It
is quite astonishing to see what a mess this is. Not only are the
channels not clipped at different levels, the clipping is also not
linear and sometimes reversed. In dcraw you also can do an unclipped
conversion, which often leads to strange colors in and around
highlights. So it takes quite a bit of magic to interpret this correctly.

[Sven Flock]

Ok, I try to sum up all the information that you have given me:

• Going from RAW to TIFF back to HDR ist suboptimal as I convert from a linear format to one with log applied back to a linear floating point format
• Bracketed series are safest workflow to not loose any but increase the dynamic range even more
• dcraw (from my reading) has not been updated since 2018, I would assume that it cannot handle raw data from new released cameras after that, properly. That would confirm issues I had with the Sony a7rIV which came out in late 2019, I think.
• To avoid the conversion described in the first bullet point, I would need a tool that is able to write linear image date with adjustments made to highlights and shados. One would assume that DNG from Lightroom would fit that requirement, but as of my understanding, it's just the raw data standardized with an embedded xmp metadata file which would be ignored by PTGui (dcraw). The only tool I know of which is able to actually apply adjustments destructively to linear image formats (dng) is DxO Photolab. There is an option during export if the settings should be set as xmp or directly written to the sensor data. As DNG ist standardized, dcraw should read the sensor data better than camera specific raw formats which are not supported, yet.

Is there something I got completely wrong?

[PTGui Support]

> * Going from RAW to TIFF back to HDR ist suboptimal as I convert from

> a linear format to one with log applied back to a linear floating
> point format

More or less, yes. True log() wouldn't be a problems since it's
invertible. The problem is all the things raw converters are doing to
make the image look nice, like tone mapping. This is both destructive
and proprietary, so PTGui cannot perfectly reverse this.

> * dcraw (from my reading) has not been updated since 2018, I would

> assume that it cannot handle raw data from new released cameras
> after that, properly. That would confirm issues I had with the Sony
> a7rIV which came out in late 2019, I think.

PTGui switch to LibRaw, I think it supports your camera.

> * To avoid the conversion described in the first bullet point, I would

> need a tool that is able to write linear image date with adjustments
> made to highlights and shados. One would assume that DNG from
> Lightroom would fit that requirement, but as of my understanding,
> it's just the raw data standardized with an embedded xmp metadata
> file which would be ignored by PTGui (dcraw).

Right, DNG is just a container format for raw sensor data. It requires
the same processing as a raw file in order to get a tiff or jpg image.

Consider trying rawtherapee, you can disable all fancy processing.
Unlike lightroom or ACR.

Joost

[PTGui Support]

> the lowest one (or even below, for a safety margin). A decent raw
> converter will try to reconstruct the clipped data from the other,
> unclipped channels.

You cannot reconstruct clipped data. Once a channel hits 255 the color
is ambiguous. A good raw converter will look at surrounding areas, apply
AI or whatever to make an educated guess. But it's not a reconstruction.

> dcraw has a parameter (-D) to output totally raw data in an image
> format, no de-bayer, no interpolation, no color, just the pixel data. It
> is quite astonishing to see what a mess this is. Not only are the
> channels not clipped at different levels, the clipping is also not
> linear and sometimes reversed. In dcraw you also can do an unclipped
> conversion, which often leads to strange colors in and around
> highlights. So it takes quite a bit of magic to interpret this correctly.

Of course it will look strange, colors get scrambled if you clip one
channel. But it's not dramatic, reserving enough headroom in the
highlights solves the clipping problem. All raw converters do this. But
a good raw converter allows you to underexpose a bit more during raw
development, to squeeze out some extra highlight details.

Joost

[PTGui Support]

> be processed one way or another, while DNG i assume is simply used to
> losslessly store it in 32-bit. Something like this is want you want,

> only with a single image, and /with/ lens corrections etc already applied.
Regular DNG just stores the raw 12 or 14 bit sensor data, not
demosaiced. It's just a different container.

But there's also floating point DNG, which is comparable to EXR or
floating point TIFF (in fact DNG is an extension of TIFF).

[Erik Krause]

Am 03.04.2021 um 13:23 schrieb PTGui Support:

> You cannot reconstruct clipped data. Once a channel hits 255 the color
> is ambiguous. A good raw converter will look at surrounding areas, apply
> AI or whatever to make an educated guess. But it's not a reconstruction.

You are right of course. However, Adobe calls it Highlight Recovery,
dcraw Highlight Rebuild, UFRaw Highlight Restoration, while Darktable
and Rawtherapee call it Highlight Reconstruction.

But most of the time it's clipping highlights to white, as you can see
from a setting sun, that was red originally but is white in your images
(which mimics the behavior of analog film BTW).

[Lauks]

I try to follow this thread because its interesting, but until now I did not find the perfect workflow. If LR with ACR has a pretty good raw engine, it seems obvious to me to assemble the HDR in LR (I prefer Bridge, but the engine is the same)which will create an DNG HDR. Now as ptgui cannot understand the xmp from ACR, it makes no sense to me to feed the DNG into ptgui. Would then a 16bit TIFF out of LR be the best option and use ptgui only as stitcher?

Luc

[Erik Krause]

Am 03.04.2021 um 15:33 schrieb Lauks:
> Would then a 16bit TIFF out of LR be the best option and use ptgui
> only as stitcher?

Yes. You can of course merge to HDR beforehand and pass a file in HDR
format (EXR or 32 bit TIFF to PTGui).

[Lauks]

I think LR can’t do 32bit TIFF, only 16 bit, but i am not sure.

My point is more, is there any advantage to do all this in ptgui, why would you do it in ptgui?

or is it just interesting because you do not need to buy or use additional software if done in ptgui (which is of course a good argument)

[Sven Flock]

Lightroom Classic supports importing TIFFs with 32bit at least.

More of interest: does PTGui support HDR DNGs as input? If I use Lightroom to create HDRs (e.g. due to ghost removing), I get HDR DNGs as output.

I think you should use the software which gives you the most satisfying results. It's difficult to get everything from one tool. Lightroom Classic does a pretty good job for HDR, image library and editing with a clean GUI, but lacks performance with large images in size and huge libraries (100.000+ of RAWs). PTGui does the best job for stitching - both in quality and performance, but I rarely use it for HDR merge because of the missing ghost removal options (it's on the wish list as I have seen). So, I go back to Lightroom or Photomatix to create the 32bit file and do the tone-mapping in Lightroom due to the more realistic results. So, currently most of my workflows starts and end with Lightroom. And I prefer not losing quality during intermediate external steps like going to PTGui (it's like using an intermediate codec if you do cutting and sfx -> you have to switch tools and this requires a codec like cineform / DNxHR to not lose any quality). PTGui 12 comes with that option now and what I have learnt from that discussion is that I will do highlight / shadow recovery CA and other lens corrections in DxO and render out a DNG for PTGui to skip the linear/non-linear/linear conversion pipeline.

[Luc S.]

I meant exporting 32bit tiffs from LR classic, not importing... also i am not sure how ptgui will interprete a dng from LR as they both use a different raw engine...

--

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/ptgui/e4d1dc28-04e8-4bf4-a9ba-1f6c28076ed5n%40googlegroups.com.

[PTGui Support]

PTGui uses LibRaw for developing DNG or RAW files into images. The
results will be different from the LR converted images.

PTGui can read floating point DNGs.

Kind regards,

Joost Nieuwenhuijse
www.ptgui.com

> http://www.erik-krause.de <http://www.erik-krause.de>

>
> --
> 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 on the web visit
> https://groups.google.com/d/msgid/ptgui/e4d1dc28-04e8-4bf4-a9ba-1f6c28076ed5n%40googlegroups.com

> <https://groups.google.com/d/msgid/ptgui/e4d1dc28-04e8-4bf4-a9ba-1f6c28076ed5n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> 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 on the web visit

> https://groups.google.com/d/msgid/ptgui/CAHiUCC91sNq8Gfa90NUsduCrEftWinv_jqcxOvgc4wPvOBas4Q%40mail.gmail.com
> <https://groups.google.com/d/msgid/ptgui/CAHiUCC91sNq8Gfa90NUsduCrEftWinv_jqcxOvgc4wPvOBas4Q%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[MD]

I remember reading there is a small disadvantage to finding control points in HDR files due to the low contrast, if i'm not mistaken.

Op zaterdag 3 april 2021 om 15:57:32 UTC+2 schreef Lauks:

[ZAWAYA 360]

I've been battling with this for a long time especially when I have a job that has 50+ Panos, my question was how to get great image quality while using less space on my camera and pc in addition to having small size panos for the virtual tour for a faster experience, therefore after testing I came to this workflow which I haven't seen anyone use but me,  so the workflow goes as follows:

- I shoot at 12mm so all I need is 4 angles at 90°
- 5 Bracketed JPEGS at +-1ev 
- Load up the total of 20 Panos per Pano in PTGui 
- Merge to HDR then Align
Now I have a perfect stitched blended Pano, here comes what I personally do differently
- I export as blend planes (This produces 5 panoramas at the bracketed exposures)
- I load up the 5 different exposure panoramas and load them up into Lightroom
- Merge the 5 panoramas into HDR
- Now I have a HDR stitched Panorama that I can edit knowing it has values needed to control light and dark
- Export full quality to Photoshop
- Edit Nadir out and saves as jpeg lower quality at ~5-8mb 
- Lowering quality in PS for an ideal jpeg size will not cost you actually image quality
- Now I have a beautifully edited Pano ready to be added into a virtual tour software.

I hope this workflow helps people think of a different approach, and to all the experts reading this, if you find a flaw in my workflow please point it out so I can adjust.

Thank you.

[Lauks]

For me your workflow is not useful, jpgs are 8bit, your raw has 14bit... you lose all dynamic range right from the beginning? I would never shoot jpg (except dual save for backup)

[MD]

5 x 8 bit, so technically that's 40 bits. 😉

The dynamic range is created from exposure bracketing.

As mentioned before you end up with much more than you could from a single raw/tiff.

Op zondag 4 april 2021 om 18:42:54 UTC+2 schreef Lauks:

[ZAWAYA 360]

"For me your workflow is not useful, jpgs are 8bit, your raw has 14bit... you lose all dynamic range right from the beginning? I would never shoot jpg (except dual save for backup)"

Did you not read the part where there's exposure bracketing and creating a HDR Pano in lightroom,  therefore you got the dynamic range..

[Erik Krause]

Am 04.04.2021 um 19:16 schrieb MD:

> 5 x 8 bit, so technically that's 40 bits. 😉

I hope the smiley indicates that this is incorrect. If you bracket at
2EV steps and your jpeg images contain 8EV then you have 5 x 2EV + 8EV =
18EV dynamic range (technically). If you use 16 bit TIFF instead which
can be assumed to cover 12EV from a decent camera and well converted
from raw, you get 5 x 2EV + 12EV = 22EV.

This calculation assumes that one bit can cover 1EV, which might or
might not be the case, depending from various camera or conversion
settings. But you get the idea.

[PTGui Support]

> This calculation assumes that one bit can cover 1EV, which might or
> might not be the case, depending from various camera or conversion
> settings.

That's not the case. sRGB uses gamma 2.2, which means that you'll get
more than 16EV dynamic range from an 8 bit image.

Quantization is much coarser than a true 16 bit image, but the low end
is drowned in the camera noise.

So I think using 8 bit (high quality jpeg) images is probably fine when
bracketing. In theory you might see some banding in pitch black shadows,
but the whole purpose of bracketing is to boost those shadows.

Joost

[Erik Krause]

Good to know.

[dher...@gmail.com]

Interesting thought, Erik. 

Is clipping red to white really "intended behavior" in order to mimic film or in order to achieve another goal? 

I thought it's just because even if the sun is red originally, green and blue colors in the light are also just too bright (even if not as bright as red), so green and blue pixels are technically simply also clipped, resulting in 255,255,255 -> white...?

Daniel

 

[dher...@gmail.com]

your workflow sounds reasonable to me, however, it only works as long as the PTGui output is small enough to be loaded into Lightroom. This is the case with 12mm on your camera obviously.

For me, it would still work for 16mm on 42MB full frame sensor (which results in about 260MP). 

But already with 24mm on 42MP Fullframe my images exceed Lightroom's limit of 512 Megapixel per image. 

So if your workflow is useful for others heavily depends on the size of their panoramas. 
Even though I do some panoramas with 16mm, I take most of them with 24 or 35 mm, so postprocessing panoramas in Lightroom is not an option for my standard workflow. 

By the way: Do you know, if that 65.000 px limit and/or the 512MP limit of Lightroom Classic also applies for such complex processing like merging 5 images into HDR, or are the limits for that even lower maybe? (maybe dependent on available RAM...)?

Daniel

[Erik Krause]

Am 06.04.2021 um 20:49 schrieb dher...@gmail.com:
> I thought it's just because even if the sun is red originally, green and
> blue colors in the light are also just too bright (even if not as bright as
> red), so green and blue pixels are technically simply also clipped,
> resulting in 255,255,255 -> white...?

Yes, that's usually the case. But there are edge cases, where you have
one or two channels clipped but no the other. That would cause a color
cast if not handled specially. In my experiments to extract as much
dynamic range as possible with dcraw I frequently got pink clouds.
That's where it gets tricky.

With the setting sun example there is a a region around the sun where
the sky is red or orange. Without sophisticated algorithms there would
either be a color cast, or they would be clipped to white, too.

Another popular example is the cyan transition between blue sky and
white flare around the (midday) sun.