Strange boxes in HDR panorama output
flpm
I have experienced a problem with certain HDR panoramas stitched with
Hugin that I do not begin to understand. I have never experienced
this issue with single-frame HDR images produced with Hugin and do not
always experience it when I stitch HDR panoramas.
The issue is that the final EXR image appears totally black when I
open it in an HDR viewer (Luminance 2.0.0b), apparently because there
are certain pixels in the image that are (erroneously) way off the
appropriate display scale. If I play with the histogram until the
image is viewable, I find that there are large black boxes on the
panorama (see screenshot: http://imagebin.ca/view/ejQiZd.html). This
issue prevents me from tonemapping the image - all I can produce is a
big black jpeg.
Does anyone know why this might be happening or how I can fix it?
If I choose to produce a TIFF image instead of an EXR, I have the same
problem. I could supply a copy of the problematic image, but it is
nearly 100MB.
Nicolas Pelletier
--
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
flpm
That sounds like a good suggestion, although I have just taken a look
and the values range from about 13-17 EV, which seems reasonable given
that I bracketed from -2 to +2 EV.
By the way, I should mention that I'm using Hugin 2010.0.0.5045
On Aug 3, 7:57 am, Nicolas Pelletier <nicolas.pellet...@gmail.com>
wrote:
Lukáš Jirkovský
Hello,
you you check whether the problem is present in the remapped images
(check "Remapped images" in Stitcher output). Checking output of
"Remapped merged stacks" would be nice too.
thanks,
Lukas
flpm
Thank you for your help! I was very curious to investigate your
suggestion. On the stitcher tab, I chose to output all stacks and
remapped images for both the HDR and the enfused image.
The enfused final image looks fine, as do all the remapped images and
stacks. The HDR image still has the same blocky features as before,
but I cannot open any of the remapped images or stacks. Luminance
returns the following nondescript error: "ERROR: Failed loading file."
On Aug 5, 1:37 am, Lukáš Jirkovský <l.jirkov...@gmail.com> wrote:
Lukáš Jirkovský
> Hi,
>
> Thank you for your help! I was very curious to investigate your
> suggestion. On the stitcher tab, I chose to output all stacks and
> remapped images for both the HDR and the enfused image.
>
> The enfused final image looks fine, as do all the remapped images and
> stacks. The HDR image still has the same blocky features as before,
> but I cannot open any of the remapped images or stacks. Luminance
> returns the following nondescript error: "ERROR: Failed loading file."
It seems like the remapped images are already broken. Only thing which
comes to my mind now is that there may be some problem with
multithreading in nona. It's used by default on multi core systems.
I don't think it's possible to disable it in GUI but you should be
able to disable it in the makefile (file with .mk suffix, it's stored
along the project file). Look for the line NONA_OPTS= and add "-t 1"
here (without quotes). Then stitch the project using "make -f
makefile.mk" (replace makefile.mk with real name of the makefile you
edited in the previous step).
Then please report back whether it helped or not.
thanks,
Lukas
PS.: I won't have access to an Internet connection for the next week.
Maybe someone else will be able to respond during that time.
flpm
your suggestion would fix the problem. Unfortunately, after trying
single-threaded operation on two different panoramas exhibiting this
problem, I get what appears to be exactly the same output.
On Aug 7, 6:11 am, Lukáš Jirkovský <l.jirkov...@gmail.com> wrote:
Lukáš Jirkovský
> It's true that I am using a multi-core CPU, so I was very hopeful that
> your suggestion would fix the problem. Unfortunately, after trying
> single-threaded operation on two different panoramas exhibiting this
> problem, I get what appears to be exactly the same output.
>
That's a pity, because it was my only guess. There may be some problem
in photometric optimization as well but I don't know this area very
well.
Lukas
JeCh
latest I could find).
I'm experiencing this with just 2 images taken with different
exposures. You can get them here: http://www.mediafire.com/?75iqb3493hh5y15
I'm not sure if I'm not doing something wrong, but with other sets I
have good results and my workflow is the same.
Vladimir
Lukáš Jirkovský
Hello Vladimir,
I took a quick glance at images you send here. Using align image stack
to create hdr file I've got something not looking like HDR with some
artifacts around edges but no boxes are present. It seems like the
exposures were not determined correctly and only the brighter image
was used.
result:
http://blender6xx.ic.cz/pub/strange_boxes_bug/align_image_stack.hdr
Then I used align_image_stack to create the .pto file and stitched the
file in hugin. The file shows the same behavior as the previous, only
only the brighter part is used to create the image. It can be
confirmed by looking at EV value in the Camera and Lens in Hugin. Both
images gets the same EV value even though it should be different. The
interesting thing is that Luminance can't open this file correctly but
the viewer from pfstools can. The artifacts are not so visible, but it
may be due to the different viewer used.
result:
http://blender6xx.ic.cz/pub/strange_boxes_bug/align_image_stack.pto
http://blender6xx.ic.cz/pub/strange_boxes_bug/align_image_stack_pto.exr
Then I used pto file from the last step, added a new lens and used
"Load EXIF" which set the proper EV values. This one is finally
correct, ie there ire details in both sky and the building. Again it
can't be opened in Luminance but the pfstools can handle it.
result:
http://blender6xx.ic.cz/pub/strange_boxes_bug/align_image_stack_hugin_edited.pto
http://blender6xx.ic.cz/pub/strange_boxes_bug/align_image_stack_hugin_edited.exr
Last I tried to create the panorama completely in hugin. The
optimization placed the on the edge of screen so I moved it manually
to the center. Then I did the Stitch. This one becomes really
interesting. It seems like the images suffers from heavy barrel
distortion, but b is zero. I'll investigate this one more.
result:
http://blender6xx.ic.cz/pub/strange_boxes_bug/hugin_pure.pto
http://blender6xx.ic.cz/pub/strange_boxes_bug/hugin_pure.exr
Lukas
flpm
Lukas, thanks very much for your work. I was just looking back at
your reply and it made me think to try producing the panorama with no
exposure correction by Hugin beyond the EV levels from the EXIF tag.
Interestingly, this produces a panorama with the same problems as
before, but the boxes are in different places (and bigger) than when
using full exposure correction.
Does anyone have any new information about this problem?
On Aug 17, 6:49 am, Lukáš Jirkovský <l.jirkov...@gmail.com> wrote:
>
> > I think I have the same problem with Hugin build 5161 on Windows (the
> > latest I could find).
>
> > I'm experiencing this with just 2 images taken with different
> > exposures. You can get them here:http://www.mediafire.com/?75iqb3493hh5y15
>
> > I'm not sure if I'm not doing something wrong, but with other sets I
> > have good results and my workflow is the same.
>
> > Vladimir
>
> Hello Vladimir,
> I took a quick glance at images you send here. Using align image stack
> to create hdr file I've got something not looking like HDR with some
> artifacts around edges but no boxes are present. It seems like the
> exposures were not determined correctly and only the brighter image
> was used.
>
> result:http://blender6xx.ic.cz/pub/strange_boxes_bug/align_image_stack.hdr
>
> Then I used align_image_stack to create the .pto file and stitched the
> file in hugin. The file shows the same behavior as the previous, only
> only the brighter part is used to create the image. It can be
> confirmed by looking at EV value in the Camera and Lens in Hugin. Both
> images gets the same EV value even though it should be different. The
> interesting thing is that Luminance can't open this file correctly but
> the viewer from pfstools can. The artifacts are not so visible, but it
> may be due to the different viewer used.
>
> Then I used pto file from the last step, added a new lens and used
> "Load EXIF" which set the proper EV values. This one is finally
> correct, ie there ire details in both sky and the building. Again it
> can't be opened in Luminance but the pfstools can handle it.
>
Lukáš Jirkovský
> Hello,
>
> Lukas, thanks very much for your work. I was just looking back at
> your reply and it made me think to try producing the panorama with no
> exposure correction by Hugin beyond the EV levels from the EXIF tag.
> Interestingly, this produces a panorama with the same problems as
> before, but the boxes are in different places (and bigger) than when
> using full exposure correction.
>
> Does anyone have any new information about this problem?
>
>
>
I still can't reproduce the problem. Could you please send me some of
the remapped HDR images (the ones you can't open). It could help us to
find out whether the problem is present in nona (the remapped images
are broken) or hugin_hdrmerge (the remapped images are not broken but
the merged stacks are).
BTW: the problem in hugin_pure.exr was caused by vignetting.