[hugin-ptx] very poor hdr/exr results

[slaterson]

i have been experimenting with creating hdr exr images from hugin. i
have tried this a couple ways and so far the images that were output
are very bad, filled with off colored pixels and noise that doesn't
appear in the ldr output. is this a known issue or is there perhaps
something wrong with my workflow, images, or installation of hugin and/
or libraries?

my workflow is the following:
1) process images as 8bit, usually using only one image from each
bracketed set (1/3 of the entire image set), as tif
2) import 8bit tif files to hugin
3) generate control points, clean, optimize and stitch until i am
happy with the ouput
4) generate 16bit tifs for all images (-, 0 and + ev)
5) copy my pto file from hugin to a new directory where the 16bit tifs
were written and open
6) import the additional images (usually the - and + ev shots) and use
align_image_stack or, lately with the svn version of hugin, set the
stack # correctly for each stack of images
7) check the preview window
8) stitch as hdr and write output to an exr file.

when i open the exr file it is very bad quality. the ldr output from
my initial alignment and setup is much better (regardless of
tonemapping, etc...). the noise i am seeing is not present in the
individual photos.

i am using hugin from svn and enblend 4.0 on gentoo 64 bit. happy to
put some samples on flickr or picasa to illustrate what is happening.

--
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[slaterson]

i have uploaded two images illustrate the problem i am encountering.
the first image is a blended and fused pano, the second is the exr
output shown in luminancehdr (i have also opened the image in
photomatix pro in windows - the same problem exists).

while there is still noise, there is not as much as was previously
there. i'm not sure what changed to address that...

the images can be seen here: http://picasaweb.google.com/campbell.christopher/HuginEXRLDRFused#

[Zac]

I cant comment too much on your worflow because I havent experimented
much. however, I have had some great results by working as follows:

- generating HDR images first for the bracketed sets. ( I've been
using Photomatix to batch combine all images if there is no movement
or manually with Dynamic Photo HDR if there is some movement)
-Using these images in hugin, generating control points etc and
outputting only an EXR file
-tonemapping in either photmatix or dynamic photo hdr.

Its worked great for me so long as the images are lined up well
although I have found parallax and alignment errors really show up
with HDR.

With regard to your workflow - How are you generating your 16bit TIFs?
and how come your working that way, ie not importing HDR images into
hugin just out of interest?

Zac

[slaterson]

On Apr 23, 8:30 am, Zac <zacpo...@googlemail.com> wrote:
> With regard to your workflow - How are you generating your 16bit TIFs?
> and how come your working that way, ie not importing HDR images into
> hugin just out of interest?

i am generating 16 bit tifs from ufraw. they are twice as big as 8
bit and therefore much slower, hence the prep work on 8 bit tifs to
get everything lined up and 'happy.'

in the past, i have fused each bracketed stack prior to importing to
hugin. this has worked and saves some time in hugin, however i wasn't
always happy with the results. i saw the new stack # setting for
images in hugin and wanted to give it a try and so far it has made
working with these image sets very easy. i also like to take a look
at different workflows/techniques to learn what/if i am missing. on
paper, it looks a lot easier to me to work with 3 (or more) completed
panos at various exposures to create an hdr as opposed to setting up 8
(or more) stacks or 3 (or more) photos. with the new tools (stack #
and masking) coming in hugin it looks like this could become true.

i use a pano head and a tripod or clamp mount, so there is very little
to no parallax between stacks and each stack doesn't need alignment.
i have not used exr files in the past, its not clear to me how
sensitive they are to alignment yet.

and, lastly, working this way is something that hugin supports. i
suppose part of what i'm doing is 'unofficial' testing...

[Bruno Postle]

On Fri 23-Apr-2010 at 07:33 -0700, slaterson wrote:
>i have uploaded two images illustrate the problem i am encountering.
>the first image is a blended and fused pano, the second is the exr
>output shown in luminancehdr (i have also opened the image in
>photomatix pro in windows - the same problem exists).

>the images can be seen here: http://picasaweb.google.com/campbell.christopher/HuginEXRLDRFused#

The HDR version is a big mess, are you stitching using the GPU
acceleration?

In general we recommend stitching a spherical panorama to the
'standard' equirectangular projection first - Stitching directly to
a very wide stereographic image means that some photos are remapped
to extreme shapes and scales, this takes longer and the geometry can
cause problems.

Once you have a single equirectangular file it is quick and easy to
extract a 'little planet' or any other view.

--
Bruno

[slaterson]

On Apr 23, 5:18 pm, Bruno Postle <br...@postle.net> wrote:
> The HDR version is a big mess, are you stitching using the GPU
> acceleration?

i use the gpu with nona but not enblend. i have tried using it with
enblend but it crashes a lot. :( the remapped images all look good,
so this is likely a problem with enblend.

> In general we recommend stitching a spherical panorama to the
> 'standard' equirectangular projection first - Stitching directly to
> a very wide stereographic image means that some photos are remapped
> to extreme shapes and scales, this takes longer and the geometry can
> cause problems.
>
> Once you have a single equirectangular file it is quick and easy to
> extract a 'little planet' or any other view.

i have used that workflow several times and in the past 6 months or so
i have been using stereographic as a first run. i have been getting
very good results, it saves me a step and in some cases the results
are better than going from equirectangular -> stereo. will hugin
accept an exr image as input? i.e., if i create an equirectangular
exr image will hugin take that as input to make a stereographic? i
haven't tried this yet, of course.

[slaterson]

> > In general we recommend stitching a spherical panorama to the
> > 'standard' equirectangular projection first - Stitching directly to
> > a very wide stereographic image means that some photos are remapped
> > to extreme shapes and scales, this takes longer and the geometry can
> > cause problems.
>
> > Once you have a single equirectangular file it is quick and easy to
> > extract a 'little planet' or any other view.
>
> i have used that workflow several times and in the past 6 months or so
> i have been using stereographic as a first run.

to clarify, when i say 'i have used that workflow...' i am referring
to the workflow of creating an equirectangular image and re-projecting
it as stereographic. i have found that it isn't necessary to do that
with my panos, i have had a lot of success going straight to
stereographic output from my image set.

[Bruno Postle]

On Sat 24-Apr-2010 at 09:42 -0700, slaterson wrote:
>On Apr 23, 5:18 pm, Bruno Postle <br...@postle.net> wrote:
>> The HDR version is a big mess, are you stitching using the GPU
>> acceleration?
>
>i use the gpu with nona but not enblend. i have tried using it with
>enblend but it crashes a lot. :( the remapped images all look good,
>so this is likely a problem with enblend.

HDR combined with GPU acceleration hasn't had as much testing.

The messed-up image looks to me like it happened at the nona stage
rather than enblend.

>will hugin accept an exr image as input? i.e., if i create an
>equirectangular exr image will hugin take that as input to make a
>stereographic? i haven't tried this yet, of course.

This should work.

--
Bruno

[slaterson]

On Apr 24, 3:07 pm, Bruno Postle <br...@postle.net> wrote:
> HDR combined with GPU acceleration hasn't had as much testing.  
>
> The messed-up image looks to me like it happened at the nona stage
> rather than enblend.

i will give this another try and be sure to save the remapped images,
might be a day or two before i can test that, though.

[slaterson]

On Apr 24, 4:39 pm, slaterson <campbell.christop...@gmail.com> wrote:
> i will give this another try and be sure to save the remapped images,
> might be a day or two before i can test that, though.

i went ahead and did a test this morning. interesting results. i
selected 'remapped merged stacks' and 'remapped images' from the HDR
Merging output options. the pgm 'gray' files and exr for each image
at each exposure was output without any problems, with the exception
of the nadir (i cannot open any of the three nadir exr files). the
merged stacks were generated however they all exhibit streaking/
smearing. essentially, at the edge of the image where the
transparency starts, the pixel color is smeared or streaked
horizontally for the remainder of the image space. i have posted a
sample here: http://picasaweb.google.com/campbell.christopher/HuginEXRLDRFused#5464096424753937746

this is true of all image stacks. i cannot check the nadir as it will
not open (i tried luminanceHDR in linux, not sure if it this is an
issue with luminance or hugin or perhaps both).

happy to test further if there is anything specific you'd like to see.

[Bruno Postle]

On Sun 25-Apr-2010 at 08:34 -0700, slaterson wrote:
> the merged stacks were generated however they all exhibit
> streaking/ smearing. essentially, at the edge of the image where
> the transparency starts, the pixel color is smeared or streaked
> horizontally for the remainder of the image space. i have posted
> a sample here:
> http://picasaweb.google.com/campbell.christopher/HuginEXRLDRFused#5464096424753937746

Just to clarify: the individual remapped images are ok, but the
merged stack is where you see the streaks?

This suggests that nona is ok, but the problem is happening when the
stacks are being merged.

It isn't clear if your image is an LDR 'exposure fused' output
created by enfuse? or if it is a HDR created by Hugin (with
hugin_hdr_merge), that you have tonemapped before uploading?

--
Bruno

[slaterson]

On Apr 25, 3:25 pm, Bruno Postle <br...@postle.net> wrote:
> Just to clarify: the individual remapped images are ok, but the
> merged stack is where you see the streaks?

yes, the individual remapped images are ok. three exr images are
output for remapping (along with a pgm 'gray' image) for each stack.
all of these images open and display ok.

> It isn't clear if your image is an LDR 'exposure fused' output
> created by enfuse? or if it is a HDR created by Hugin (with
> hugin_hdr_merge), that you have tonemapped before uploading?

i am not sure which tool is being used. the merged image that i
uploaded is directly from hugin, i didn't see enfuse start but then
again i wasn't paying very close attention to hugin when it was
running this test. my steps to generate this:

1) load my pto file in hugin
2) select 'remapped merged stacks' and 'remapped images' from the HDR
Merging output options on the stitch tab of hugin
3) press the stitch button

once the images were created and hugin was done, i tried opening each
one in luminance hdr. (i don't have any other application that will
view exr images, if you can recommend one i'll try to install it.)
luminance hdr displays the exr without tonemapping, but it is a bit
dark so i went into the tonemapper to brighten it up a bit. the
streaking was not changed or affected at all.

[Bruno Postle]

On Sun 25-Apr-2010 at 19:44 -0700, slaterson wrote:
>On Apr 25, 3:25 pm, Bruno Postle <br...@postle.net> wrote:
>> Just to clarify: the individual remapped images are ok, but the
>> merged stack is where you see the streaks?
>
>yes, the individual remapped images are ok. three exr images are
>output for remapping (along with a pgm 'gray' image) for each stack.
>all of these images open and display ok.

>1) load my pto file in hugin
>2) select 'remapped merged stacks' and 'remapped images' from the HDR
>Merging output options on the stitch tab of hugin
>3) press the stitch button

Ok, this isn't an exposure fusion 'enfuse' workflow. The HDR menu
creates remapped floating-point HDR files for each photo, each stack
is then merged with hugin_hdr_merge into a single floating-point HDR
file.

It looks like hugin_hdr_merge is failing and generating these
streaks.

What version of Hugin do you have? hugin_hdr_merge had some changes
in 2010.0.0.

Can you try a TIFF workflow instead of EXR? (TIFF supports
floating-point HDR data too).

--
Bruno

[slaterson]

On Apr 26, 4:05 pm, Bruno Postle <br...@postle.net> wrote:
> What version of Hugin do you have?  hugin_hdr_merge had some changes
> in 2010.0.0.

i have 2010.1.0.5118 installed right now. downloaded from svn and
compiled/installed within the last week.

> Can you try a TIFF workflow instead of EXR? (TIFF supports
> floating-point HDR data too).

i tried changing the output option for hdr to tiff. i still got exr
files! i'm not sure if that is expected or not. the (other) bad news
is the images are identical to the streaked images - the individual
remapped images are fine, the merged stacks are streaked.

[Bruno Postle]

On Mon 26-Apr-2010 at 21:04 -0700, slaterson wrote:
> On Apr 26, 4:05 pm, Bruno Postle <br...@postle.net> wrote:
>
> > Can you try a TIFF workflow instead of EXR? (TIFF supports
> > floating-point HDR data too).
>
> i tried changing the output option for hdr to tiff. i still got
> exr files! i'm not sure if that is expected or not.

Yes it seems that Hugin uses EXR for the intermediate stitching
files.

> the (other) bad news is the images are identical to the streaked
> images - the individual remapped images are fine, the merged stacks
> are streaked.

I tried one of my bracketed panoramas and it is ok (HDR merged and
blended with Hugin trunk and enblend-3.2, then tonemapped with
fattal in qtpfsgui):

http://www.flickr.com/photos/36383814@N00/4564263738/

Actually this is the first time I've tried a HDR worklow since I
gave up on the whole thing when enfuse arrived.

Here is one of the intermediate images, I don't see any streaking:

http://www.flickr.com/photos/36383814@N00/4563645783/

This is with OpenEXR-1.4.0a

--
Bruno

[slaterson]

On Apr 29, 3:24 pm, Bruno Postle <br...@postle.net> wrote:
> Yes it seems that Hugin uses EXR for the intermediate stitching
> files.

ok. so only the final panorama is output as tiff? the merged stacks
are exr, also?

> I tried one of my bracketed panoramas and it is ok (HDR merged and
> blended with Hugin trunk and enblend-3.2, then tonemapped with
> fattal in qtpfsgui):
>
> http://www.flickr.com/photos/36383814@N00/4564263738/
>
> Actually this is the first time I've tried a HDR worklow since I
> gave up on the whole thing when enfuse arrived.
>
> Here is one of the intermediate images, I don't see any streaking:
>
> http://www.flickr.com/photos/36383814@N00/4563645783/
>
> This is with OpenEXR-1.4.0a

this suggests its something with my software install. i'll try
rebuilding openexr and see what happens. perhaps there is something
amiss with gentoo's openexr...

thanks, if you have any other suggestions i'm all ears.

[slaterson]

On Apr 29, 6:39 pm, slaterson <campbell.christop...@gmail.com> wrote:
> On Apr 29, 3:24 pm, Bruno Postle <br...@postle.net> wrote:

> > This is with OpenEXR-1.4.0a

i just checked my version of openexr. it's 1.6.1. do you know if the
newer version is compatible?

[Lukáš Jirkovský]

On 30 April 2010 03:47, slaterson <campbell.c...@gmail.com> wrote:
> On Apr 29, 6:39 pm, slaterson <campbell.christop...@gmail.com> wrote:
>> On Apr 29, 3:24 pm, Bruno Postle <br...@postle.net> wrote:
>> > This is with OpenEXR-1.4.0a
>
> i just checked my version of openexr.  it's 1.6.1.  do you know if the
> newer version is compatible?
>

Certainly, I use it for several years without problems.

BTW: I would collaborate more on this topic but I'm a bit tied up at the moment.

Lukas

[slaterson]

On Apr 29, 10:30 pm, Lukáš Jirkovský <l.jirkov...@gmail.com> wrote:
> Certainly, I use it for several years without problems.
>
> BTW: I would collaborate more on this topic but I'm a bit tied up at the moment.

i tried running hugin_hdrmerge from the command line. it is
apparently using the avg method by default and complete very quickly
(just a few seconds). i tried using the khan method and let it run
for about 20 minutes, it appeared to be about half done with the image
and i had to cancel it. i was running this on just one stack. i will
try again this weekend.