banding in hugin_hdrmerge output

[kfj]

Hi group!

When going through some old panoramas I had rendered as HDR in openEXR, I tried to recreate these images. But the output wasn't as before; I noticed ugly banding where there were smooth transitions in the sky before. So I went to investigate. Looking at the intermediate stages I noticed the single merged HDR stack images already had the flaw, so I concluded that hugin_hdrmerge might cause the problem. In the relevant bit of code which hugin_hdrmerge uses, namely

hugin/src/hugin_base/vigra_ext/HDRUtils.h, lines 70ff,

the function to HDR-merge pixels (ReduceToHDRFunctor) had the gaussian weight function commented out and instead, after a comment reading

'simple triangular function should also work ok'

there was other code instead. I activated the use of the gaussian weighting function and this removed the problem, now my output is corrrect again. I'd recommend using the gaussian weighting in favour of the other code.

Since it's just a matter of commenting out a line and uncommenting another, I refrain from filing a bug, sending a patch etc., but I wonder why noone has stumbled upon this before. Maybe openEXR output isn't used much... and of course there is the possibility that my system has peculiarities producing a bug where other environments don't, so I'd like to hear if anyone else has had problems with hugin_hdrmerge.

with regards

Kay

[T. Modes]

Hi Kay,

Am Donnerstag, 6. April 2017 10:43:02 UTC+2 schrieb kfj:

But the output wasn't as before; I noticed ugly banding where there were smooth transitions in the sky before.

<snip>

hugin/src/hugin_base/vigra_ext/HDRUtils.h, lines 70ff,

But this file was last touched in 2007. So "before" is earlier than 2007?

the function to HDR-merge pixels (ReduceToHDRFunctor) had the gaussian weight function commented out and instead, after a comment reading

'simple triangular function should also work ok'

there was other code instead. I activated the use of the gaussian weighting function and this removed the problem, now my output is corrrect again. I'd recommend using the gaussian weighting in favour of the other code.

So please provide a test case: images and pto file which shows the problem (one stack, when possible with downscaled images would be sufficient).
So I can have a look on my one before doing the change.

Thomas

PS: Which viewer do you use to look at the EXR images?

[Kay F. Jahnke]

Am 06.04.2017 um 16:54 schrieb T. Modes:

Thank you for the prompt reply!

> Hi Kay,
>
> Am Donnerstag, 6. April 2017 10:43:02 UTC+2 schrieb kfj:
>
> But the output wasn't as before; I noticed ugly banding where there
> were smooth transitions in the sky before.
>
> <snip>
>
> hugin/src/hugin_base/vigra_ext/HDRUtils.h, lines 70ff,
>
>
> But this file was last touched in 2007. So "before" is earlier than 2007?

This is odd indeed. Maybe I did something different when I last stitched
to openEXR, honestly I can't tell anymore.

>
> the function to HDR-merge pixels (ReduceToHDRFunctor) had the
> gaussian weight function commented out and instead, after a comment
> reading
>
> 'simple triangular function should also work ok'
>
> there was other code instead. I activated the use of the gaussian
> weighting function and this removed the problem, now my output is
> corrrect again. I'd recommend using the gaussian weighting in favour
> of the other code.
>
>

> So please provide a test case: images and pto file which shows the
> problem (one stack, when possible with downscaled images would be
> sufficient).

I uploaded the data producing the problem here, one stack but sorry no
downscaling. PTO included. Images are 16bit TIFF made with dcraw from CR2s:

https://www.magentacloud.de/lnk/RriBhGE3

> So I can have a look on my one before doing the change.

Please have a look. In the zip folder there is output from the unpatched
version: banding_problem_stack_hdr_0000.exr
and also from the patched version, using the gaussian weights:
banding_problem_stack_hdr_0000_with_gaussian_weight.exr

> PS: Which viewer do you use to look at the EXR images?

Here, I use some homebrew unreleased software, but you can see the
problem for example when looking at the exr images with darktable.

Kay

[T. Modes]

Hi Kay,

Am Donnerstag, 6. April 2017 19:58:04 UTC+2 schrieb kfj:

I uploaded the data producing the problem here, one stack but sorry no
downscaling.

What is so complicated with downscaling? I could also reproduce the issue with significant smaller images. This makes debugging also easier. (My test files were together smaller than 20 MB, this would also speed up down and up loading.)

 

PTO included. Images are 16bit TIFF made with dcraw from CR2s:

Okay. I can reproduce the issue. But the bug was not the weight function itself. It was the internal handling of the weights, which are used to handle over/under exposured pixels.
That switching to a gaussian weight function fixed the issue was pure random.
It should be fixed in repository now.

Thomas

[Kay F. Jahnke]

Am 07.04.2017 um 21:12 schrieb T. Modes:
>
> Am Donnerstag, 6. April 2017 19:58:04 UTC+2 schrieb kfj:
>
> I uploaded the data producing the problem here, one stack but sorry no
> downscaling.
>
> What is so complicated with downscaling? I could also reproduce the
> issue with significant smaller images. This makes debugging also easier.
> (My test files were together smaller than 20 MB, this would also speed
> up down and up loading.)

Sorry about the fat Download. I'll try and be better next time around.

> Okay. I can reproduce the issue. But the bug was not the weight function
> itself. It was the internal handling of the weights, which are used to
> handle over/under exposured pixels.

Good thing you are more thorough than I am. I did already get a niggling
feeling my proposal was a bit of a quick shot.

> That switching to a gaussian weight function fixed the issue was pure
> random.
> It should be fixed in repository now.

I tried your modifications here, and I can confirm that they fixed my
problem. Thank you very much for your quick help! Surprising how such a
bug can survive for ten years without being noticed, isn't it?

With regards

Kay

[T. Modes]

Hi Kay,

Am Samstag, 8. April 2017 09:10:06 UTC+2 schrieb kfj:

Surprising how such a
bug can survive for ten years without being noticed, isn't it?

Yes, that is strange. Especially the HDR part seems to be used not so frequently. Otherwise this bug (and other one with HDR display and optimizer which were fixed recently) would have not survived to long.
Maybe there are other places which are not used so often.

Thomas