hugin-devs team mailing list archive

[Rich <678694@xxxxxxxxxxxxxxxxxx>]

This page is such a relief! I am not the only one suffering from serious HDR issues.
Have got much better at shooting HDR 360 panos, but have been getting worse (if any) results from Hugin!

The most successful approach I have found on recent versions of Hugin is
to process my images in 32bit Tiff images with another program and then
align and stitch then together with Hugin. Manual control point
selection and slow performance are the price to pay.

-- 
You received this bug notification because you are a member of Hugin
Developers, which is subscribed to Hugin.
https://bugs.launchpad.net/bugs/678694

Title:
  EXR files quietly clipped (black rectangles in output)

Status in Hugin - Panorama Tools GUI:
  Confirmed

Bug description:
  The EXR file format has a maximum encoding value of 65504.   The Hugin
  data flow maintains the absolute exposure through use of the Ev field
  which effectively scales pixel values.   When using Hugin/Nona on an
  HDR series that includes very bright elements (such as a very bright
  sky with a very short exposure), some pixels end up with values above
  65504.   When these are written out by Nona, those pixels are written
  as NaN's in the EXR output file.

  If enblend is then used, the problem is further exacerbated.   A
  single NaN pixel results in NaN for entire rectangle of enblend's
  pyramids.   The end result are large black rectangles in the output
  file.

  If output is changed to TIFF, then everything works fine.

  Nona should warn when clipping occurs and then output the maximum
  possible value rather than a NaN.   I assume this is the OpenEXR
  library itself and probably affects other applications.   In fact, if
  a TIFF generated as above is opened in PhotoShop, it looks fine, but
  if it is resaved as EXR, the same NaN pixels are created.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hugin/+bug/678694/+subscriptions