nona -r hdr creates INF pixels
David Brodsky
[ Andrew, I'm Ccing you because I don't know if you're on the list ]
first of all, thanks for the great tool (hugin). But I've run into a
problem I can't solve. When I try to create hdr panorama with hugin,
some areas looks like [1]. The red areas actually represents pixels with
infinite values in red channel.
At first I thought it was an error in enblend, but now I've discovered
that nona creates one pixel with infinite value in red channel. I've put
all necessary files at [2]. If I do
nona -r hdr -m EXR_m -o small1-small9_hdr_ -i 4 small1-small9.pto
then the output contains bad pixel. Its coords are x: 227 y: 247,
counting from zero. I can imagine that this makes enblend create bad
areas, because infinity propagates all the way through the pyramids.
(This is only my guess).
So I think that it is an error that nona creates a pixel with infinite
value and therefor looses any precision.
One final thing: As you can see on the image [1] there is something what
looks like black dashed horizontal lines. This is caused by
hugin_hdrmerge which creates images like [3]. See dots on the left and
line on the bottom. Again I thing this can make enblend create pictures
with errors.
Please let me know if there is anything I can do to correct these errors
or help invastigating.
Regards
David Brodsky
P.S. Andrew, as you can see you can discard my previous email to you
because it may not be an error in enfuse. Thanks.
[1]: http://trekie.sinister.cz/enblend.jpg
[2]: http://trekie.sinister.cz/nona-inf.zip
[3]: http://trekie.sinister.cz/nona.jpg
tennevin.yves
https://sourceforge.net/tracker/index.php?func=detail&aid=1850361&group_id=77506&atid=550441
Yves Tennevin / esby
David Brodsky
>
> This looks related to this bug:
>
> https://sourceforge.net/tracker/index.php?func=detail&aid=1850361&group_id=77506&atid=550441
Ok, I see the problem, but I dont see a solution. Can someone please
give me a hint? I'm willing to work on it.
As d'Angelo wrote in the thread clipping alone is not a right direction.
Another option is to store each channel in 32 bit float (OpenEXR allows
that), but I'm not sure if it could be read by other programs that
expect half. And finally there may be a way how to not exceed max half
and thus not create INF.
Regards
David Brodsky
Brent
then the WhiteLuminance set in the OpenEXR header to keep track of the
scaling for any subsequent program in the pipeline if needed.
Brent
On Oct 10, 2:29 am, David Brodsky <tre...@sinister.cz> wrote:
> On Thu, 9 Oct 2008, tennevin.yves wrote:
>
> > This looks related to this bug:
>