Am 18.01.2013 03:33, schrieb Kenneth:

> I've been reading up on OpenEXR today--fascinating stuff (including the
> odd/different gamma computations that it uses internally, to ultimately display
> the image on typical 8-bit monitors. At least as a Photoshop plug-in. The
> *display* of HDRI images is one of the things that I've never clearly
> understood.)

Display of HDRI images is quite simple, too: Essentially you /can't/ 
display them. There aren't any displays out there that would provide the 
necessary dynamic range.

So what you do is simulate the effects it would have on photographic 
film or to the naked eye (they, too, don't have HDRI capability): You 
make the >100% portions of the image "bleed" into their neighborhood, by 
mixing in a low-brightness highly blurred copy of the HDR image. If 
you're going for fancy, you can also add lens flares based on the HDR image.

> For my animation here, I initially came up with a scheme to render the various
> elements separately--meteors, moon and background--using POV-Ray's
> Image_Alpha=on for the meteors and moon. Basically to see if I could save time
> in the rendering process, as well as adding AA solely to the moon (6000 frames
> for the meteors, but only 600 for the moon and background elements, as they
> didn't need blurring, IMO.) I ran into some trouble though (in 3.62) when
> averaging-together just the meteor elements as a pre-step (again using
> Image_Alpha): The resulting meteor blur, when finally overlaid onto the other
> elements, showed dark fringes. I now realize that alpha-multiplication (or non-)
> is one of the culprits (as well as 3.7 having corrected some errors in how alpha
> image_maps are applied.)

Isn't 3.7 great? :-)

The problem you ran into with 3.6 was probably that it expected a 
different alpha for input files than what it generated itself in output 
files. Apparently the authors of the old code didn't really know the 
difference.

Post a reply to this message