"Bill Pragnell" <bil### [at] hotmailcom> wrote:
>
> Motion blur is (yet) another trick on my to-play-with list...
>
> Bill

My simple averaging method is the 'poor man's way'--it doesn't at all reproduce
the 'photographic film' look of, say, a very bright light smeared across the
frame. In such a case, the smear would be equally bright from beginning to end.
In my case, the darker background of previous/later frames is averaged with each
frame's bright 'static' light pool. The result is a 'different', not
quite-so-bright smear. But it still looks pretty cool.

I think MegaPOV (?) has a built-in motion-blur method (no simple averaging of
frames) that produces a more accurate result.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> Thumbs up for the 360 degrees. I guess it's simply closer to the visual
> experience of real life.

Interesting. I'm sort of 'stuck on the fence' between the two versions. On the
one hand, I do like the 'liquid-like' blur of the 360-deg version. On the other,
I'm so used to seeing/thinking about/dissecting 'film-like' motion blur that
it's the norm for me. (But I wonder if I'm just *telling myself* that it's
better??)

On my older CRT monitor (with a refresh rate of 85Hz), the 360-deg version takes
on a little bit of the 'look' of live video, rather than film. The 180-degree
version seems to reduce that effect, to my eyes (eyes/brain?)--which I find
rather fascinating in itself.

Post a reply to this message

Am 17.01.2013 08:03, schrieb Kenneth:
> "Bill Pragnell" <bil### [at] hotmailcom> wrote:
>>
>> Motion blur is (yet) another trick on my to-play-with list...
>>
>> Bill
>
> My simple averaging method is the 'poor man's way'--it doesn't at all reproduce
> the 'photographic film' look of, say, a very bright light smeared across the
> frame. In such a case, the smear would be equally bright from beginning to end.
> In my case, the darker background of previous/later frames is averaged with each
> frame's bright 'static' light pool. The result is a 'different', not
> quite-so-bright smear. But it still looks pretty cool.

If you'd use OpenEXR for the interim output, you could also get that 
bright light smear right.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> If you'd use OpenEXR for the interim output, you could also get that
> bright light smear right.

Really??! Then I need to do some research; the whole HDRI thing is kind of a
mystery to me, re: its use *in* computer graphics.

Thanks.

Post a reply to this message

Am 17.01.2013 12:14, schrieb Kenneth:

>> If you'd use OpenEXR for the interim output, you could also get that
>> bright light smear right.
>
> Really??! Then I need to do some research; the whole HDRI thing is kind of a
> mystery to me, re: its use *in* computer graphics.

It's really pretty simple, as far as POV-Ray is concerned: While classic 
image formats essentially use integer values to represent colors, 
capping them at 100%, HDRI formats such as OpenEXR use floating-point 
values instead, enabling them to represent color values as high as e.g. 
6,550,400% (in the case of OpenEXR).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 17.01.2013 12:14, schrieb Kenneth:
>
> >> If you'd use OpenEXR for the interim output, you could also get that
> >> bright light smear right.
> >
> > Really??! Then I need to do some research; the whole HDRI thing is kind of a
> > mystery to me, re: its use *in* computer graphics.
>
>
> It's really pretty simple, as far as POV-Ray is concerned:

See, that shows how much I *don't* know ;-)

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.) As a serendipitous side-effect, it has also launched me on a quest
to get a much better understanding of alpha compositing--specifically the
differences between using pre-multiplied alpha and non-pre-multiplied in an
image element.

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.)

Knowledge is good! ;-)

So my animation here is from 6000 re-rendered 'normal' frames, no compositing.

But this scene might be the first (animation) experiment I re-render in 3.7RC6,
as separate elements again--this time using HDRI, assumed_gamma 1.0, and one or
the other of the alpha-multiplication schemes.

Thanks again for the OpenEXR suggestion.

Post a reply to this message

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

"Kenneth" <kdw### [at] gmailcom> wrote:

> A 1280X720 animation, 600 frames, of the camera flying through some space
> debris.

....and...

> ...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...

Oops, I meant to say 300 in both cases, not 600.  Amazingly, that because
6000/20 is 300, not 600! :-[  I shall now re-read my 1st-grade arithmetic
book...

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

>
> 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.

I thought I read somewhere (or maybe not!) that a very specialized display was
available to do that. Maybe in scientific circles; can't remember where I saw
it. Perhaps just wishful thinking!

I've been wondering about the latest whiz-bang flat panel monitors, with their
supposed 10-gazillion-to-1 contrast ratios: whether or not that would suffice to
show HDR images raw. But I suppose the internal circuitry still works in the
standard 8-bit-per-channel way. Not to mention the extreme brightness levels
that would be required of the pixels as well.

>
> 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.

Fascinating! I've never seen it explained that way. More research to do!

Post a reply to this message

Am 18.01.2013 06:10, schrieb Kenneth:

>> 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.
>
> I thought I read somewhere (or maybe not!) that a very specialized display was
> available to do that. Maybe in scientific circles; can't remember where I saw
> it. Perhaps just wishful thinking!

Might be. Not for mortals though.

> I've been wondering about the latest whiz-bang flat panel monitors, with their
> supposed 10-gazillion-to-1 contrast ratios: whether or not that would suffice to
> show HDR images raw. But I suppose the internal circuitry still works in the
> standard 8-bit-per-channel way. Not to mention the extreme brightness levels
> that would be required of the pixels as well.

I guess the best they do is 12 pits per channel. And that high contrast 
is usually not within a single frame, but between successive frames. 
Essentially it just tells you how much they automatically dim the 
backlight in dark scenes.

There are displays that can dim the backlight locally, giving them a 
comparatively high contrast between parts of a single scene - but even 
there it is used solely to get the "black" level down in dark parts of 
the scene.

Post a reply to this message