Ugly artifacts when stitching .hdr files

[Greg Zaal]

I create HDR panos for the purposes of lighting CG scenes - that means I always use the True HDR mode and never want any tonemappping or other effects to compromise the color accuracy of the image.

Because of this, I prefer to merge bracketed exposures using external software, saving them as .hdr files, and then loading those .hdr files into PTGui to stitch and output the 32-bit HDR pano (as described in the first bullet point of 6.11 in the FAQ).

Most of the time this works great, but sometimes when there is a particularly large range of brightness in a small area, PTGui introduces ugly artifacts around areas of strong contrast, for example:

Here is what that same area looks like in the Panorama editor:

So clearly PTGui is doing something really odd with the HDR files when saving out the final pano. I don't understand why it should be modifying the colours at all, considering I have already merged the brackets myself before importing the HDR images into PTGui. All PTGui is supposed to do is stitch them together into a panorama, not adjust the brightness or colours of the images.

To solve this, I had to separate the original raw files into matching exposure sets (photos shot with the same shutter speed), make a template from one of them and then stitch a separate pano for each set. Then finally merge those panos into a single HDR pano at the end using something like photomatix. That gives this result:

The above 3 images are of course not HDRs themselves, just cropped 8-bit pieces of them.

Here are the .hdr and project files if you'd like to test: https://drive.google.com/file/d/0By_7a0xnPplxVzZBZW8yejlKY0U/view?usp=sharing

Am I doing something wrong?

[Erik Krause]

Am 17.04.2016 um 18:23 schrieb Greg Zaal:
> To solve this, I had to separate the original raw files into matching
> exposure sets (photos shot with the same shutter speed), make a template
> from one of them and then stitch a separate pano for each set. Then finally
> merge those panos into a single HDR pano at the end using something like
> photomatix.

Until Joost hopefully fixes this bug you could do a bit shorter by
simply dropping all raw files on PTGui just as if you wanted to use
PTGui's HDR abilities. PTGui should recognize bracketed sets and offer
to link them. Do that. Stitch as usual. On Create Panorama tab select
"LDR file format: TIFF (16 bit)" and under Output "LDR: Blend planes"
only. This will output one blended panorama for each exposure step.

If you want better quality, convert raw to 16bit TIFF beforehand. This
will allow for chromatic aberration correction, eventually white balance
setting, noise removal etc. PTGui's raw conversion is carried out by
dcraw directly, which doesn't give best quality.

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

[Greg Zaal]

Thanks for the response, unfortunately avoiding the problem doesn't solve it.

Using PTGui's own HDR merging is not an option for me, like all other software I've tried it doesn't merge correctly when there is an extremely large dynamic range (e.g. 24 EVs).

[Erik Krause]

Am 17.04.2016 um 19:37 schrieb Greg Zaal:
> Using PTGui's own HDR merging is not an option for me, like all other
> software I've tried it doesn't merge correctly when there is an extremely
> large dynamic range (e.g. 24 EVs).

The described workflow doesn't use the PTGui HDR merging.

[Greg Zaal]

Sorry I misread, but that still won't help me.

[Erik Krause]

Am 17.04.2016 um 20:58 schrieb Greg Zaal:
> Sorry I misread, but that still won't help me

Well, it would produce the same output as your workaround, only quicker...

[PTGui Support]

Hi Greg,

The problem seems to be caused by masking. If I remove the masks the
artifacts are mostly gone (though not perfect yet). See my project file:

https://www.sendspace.com/file/7swl4m

(I've also removed the worst control points and use Heavy+Lens Shift
optimization to improve the alignment).

Because you've masked near a very high contrast area, the blender sees
two totally different images. In one image there's a very dark area near
a very light area, in the other overlapping image there's a transparent
area near a very light area. The multi band blending algorithm cannot
cope with this.

I'll see if this can be improved; perhaps adding a simple alpha blending
option to PTGui would work well for these kind of problems.

Kind regards,

New House Internet Services BV
Joost Nieuwenhuijse

-----------------------------------------------
PTGui - Photo Stitching Software

www.ptgui.com
For support see: http://www.ptgui.com/faq/
-----------------------------------------------

> --
> Many people are reading this forum via email and get every post
> delivered to their inbox. To limit the amount of data please do not add
> attachments or images to your posts; instead upload your files at a file
> sharing site (for example http://ge.tt/ ) and include a link in your
> message.
> ---
> 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 post to this group, send email to pt...@googlegroups.com
> <mailto:pt...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/ptgui.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/ptgui/dc3a1034-4f08-46c2-b297-63a9127c2187%40googlegroups.com
> <https://groups.google.com/d/msgid/ptgui/dc3a1034-4f08-46c2-b297-63a9127c2187%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Greg Zaal]

Thanks for looking into it Joost :)

I see the artifacts are less apparent without the masks, but there's still a weird orange glow that isn't there in the original images. I've seen similar issues in other panos, though not usually this obvious.

I don't understand how your blending algorithm works, but it sounds to me like some simple alpha blending will do the trick. I noticed Enblend and Smartblend don't have this problem, though they only output an image with an 8-bit equivalent range of brightness (so the super bright bits are clipped).

Please let me know if you make a test build that solves this, I'd be happy to test other cases and feedback.