HDR and Enblend trouble
rpiontek
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
>
> 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
> 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
> 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
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
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
>
> 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
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!