HDR and Enblend trouble

25 views
Skip to first unread message

rpiontek

unread,
Aug 16, 2007, 9:51:19 AM8/16/07
to hugin and other free panoramic software
I have been trying hard to get hugin/enblend to stitch hdr, but I'm
stumped. Please see the link below.

http://mtbtopos.com/en/images/problem.jpg

I believe the problem is with enblend, as the individual tiffs seem to
look ok. There are these black patches in the trees where the image
is darkest, and generally the color is screwed up. I am using this
most recent version of enblend that solves the bug with the alpha mask
on 32 bit files that was posted here. Any suggestions?

Bruno Postle

unread,
Aug 16, 2007, 12:38:47 PM8/16/07
to Hugin ptx
On Thu 16-Aug-2007 at 13:51 -0000, rpiontek wrote:
>
> I have been trying hard to get hugin/enblend to stitch hdr, but I'm
> stumped. Please see the link below.
>
> http://mtbtopos.com/en/images/problem.jpg
>
> I believe the problem is with enblend, as the individual tiffs seem to
> look ok. There are these black patches in the trees where the image
> is darkest, and generally the color is screwed up.

This is a known problem with enblend and HDR data.

I have the same problem with linear 16bit data (ie. the kind of
image you get with `dcraw -4 myfile.nef`).

The solution for me is to apply a gamma correction before stitching
and blending, ie. `convert -gamma '2.2' myfile.ppm myfile.tif`.
This can be reversed after blending if required.

I keep intending to see if this workaround can be applied to HDR
images too, but haven't found the time (you can apply gamma to HDR
data with pfstools).

I've also hunted for this bug in enblend, but can't find any
suspicious log(), exp() or sqrt() code - Somebody who actually
understands what they are doing is going to be needed to fix this
one.

Some test files here:

https://sourceforge.net/forum/forum.php?thread_id=1642234&forum_id=420370
https://sourceforge.net/tracker/index.php?func=detail&aid=1652013&group_id=123407&atid=696410

--
Bruno

Milan Knizek

unread,
Aug 17, 2007, 1:25:24 AM8/17/07
to hugi...@googlegroups.com
On Thursday 16 August 2007, Bruno Postle wrote:
> On Thu 16-Aug-2007 at 13:51 -0000, rpiontek wrote:
> > I have been trying hard to get hugin/enblend to stitch hdr, but I'm
> > stumped. Please see the link below.

> This is a known problem with enblend and HDR data.


>
> I have the same problem with linear 16bit data (ie. the kind of
> image you get with `dcraw -4 myfile.nef`).
>
> The solution for me is to apply a gamma correction before stitching
> and blending, ie. `convert -gamma '2.2' myfile.ppm myfile.tif`.
> This can be reversed after blending if required.
>
> I keep intending to see if this workaround can be applied to HDR
> images too, but haven't found the time (you can apply gamma to HDR
> data with pfstools).

I haven't tested the Bruno's workaround either (the test hdr images on SF
forum are mine). Maybe during the weekend and let you know then.

In fact, this is the only problem I had in my HDR pano workflow, so it would
be great to have it solved.

--
Milan Knizek
knizek (na) volny (tecka) cz
http://www.milan-knizek.net/

Milan Knizek

unread,
Aug 17, 2007, 5:30:04 PM8/17/07
to hugi...@googlegroups.com
On Thursday 16 August 2007, Bruno Postle wrote:

> The solution for me is to apply a gamma correction before stitching
> and blending, ie. `convert -gamma '2.2' myfile.ppm myfile.tif`.
> This can be reversed after blending if required.
>
> I keep intending to see if this workaround can be applied to HDR
> images too, but haven't found the time (you can apply gamma to HDR
> data with pfstools).

This seems to work with hdr, no artifacts in my test images.

for i in exp_??.hdr; do pfsin $i | pfsgamma -g 2.0 | pfsout g2.0_$i; done

Then process with hugin and enblend (both current cvs versions) and

pfsin pano_g2.0.tif | pfsgamma -g 0.5 -m 200 | pfsout pano_g_corr.hdr

As a final step, I use Qtpfsgui to tone map to ldr.

(W/o the multiplicator, the values on pfsview scale were too on the left hand
side, probably not a problem, but the multiplicator got it closer to 0 in the
middle of the scale, which is then more convenient for viewing in cinepaint)

Thanks for sharing the workaround!

rpiontek

unread,
Aug 17, 2007, 9:17:48 PM8/17/07
to hugin and other free panoramic software
I tried changing my gamma last night with artizenhdr, but this didn't
seem to help.

The interesting thing was, though, that I decided to blend my images 1
by 1 and see how things progressed. This is with no gamma
correction. The catch is that I'm making 'little planets' like maybe
you noticed in my test image. My source shots are three row
sphericals. I was able to blend the inner two rows (core of the
planet) with no trouble. These are the smallest images, ie the
smallest 'pieces' of the final image, and the blending process goes
pretty quick. It's only the third row, the sky row, which occupies
the most area, that gives me trouble. My system has only 384mb of
ram, and sometimes the system must swap. Maybe this is a clue for
what the problem might be. Possibly a memory issue?

I think that my hdr files are 'linear' to start with, but is there any
way to know this? What happens if i apply a gamma 2.2 to a file that
already is gamma 2.2? I will try again with the gamma tonight.
Thanks for the suggestions!

rpiontek

unread,
Aug 18, 2007, 2:15:09 AM8/18/07
to hugin and other free panoramic software
I just trying applying the gamma with pfstools. The resulting image
no longer shows any black areas, and looks OK. But, basically nothing
shows up on the histogram when I open to tonemap, and the resulting
image is really noisy. I tried with and without the -m 200 option for
the final correction step.

I realized that it turns out I can't use hugin to create control
points for 16 bit files. I can open and stitch them with a jpeg
template, though.

Bruno Postle

unread,
Aug 19, 2007, 7:14:08 AM8/19/07
to Hugin ptx
On Sat 18-Aug-2007 at 06:15 -0000, rpiontek wrote:
>
> I just trying applying the gamma with pfstools. The resulting
> image no longer shows any black areas, and looks OK. But,
> basically nothing shows up on the histogram when I open to
> tonemap, and the resulting image is really noisy. I tried with
> and without the -m 200 option for the final correction step.

The pfsgamma trick is a workaround, this really needs to be fixed in
enblend. Applying a gamma of 2 is effectively applying a square
root to all your brightness values, so strange things may happen.

> I realized that it turns out I can't use hugin to create control
> points for 16 bit files. I can open and stitch them with a jpeg
> template, though.

This should be ok, what is the problem? autopano-sift won't work
with HDR data, but should be ok with 16bit TIFFs.

--
Bruno

rpiontek

unread,
Aug 20, 2007, 2:08:54 AM8/20/07
to hugin and other free panoramic software
I mentioned the 16-bit stuff because you said you had trouble with 16-
bit files, but now I see this must be particular to linear 16 bit
files.

I finally got enblend to stitch HDR last night, thanks to the gamma
trick. Turns out I needed a newer version of Hugin to get things
working correctly. Thanks for the help!

Reply all
Reply to author
Forward
0 new messages