"Kenneth" <kdw### [at] earthlinknet> wrote in message 
news:web.499f1e4d40230f63f50167bc0@news.povray.org...
> Fascinating. It's actually very close to a paradigm I had come up with 
> (but only
> as a thought experiment) concerning a feature that could be added to 
> POV-Ray
> itself--*internally* rendering multiple 'snapshots' of a scene over time, 
> then
> averaging them internally, then spitting out the final blurred frame. So
> MegaPOV already has that; cool.
>
> You had mentioned earlier that this MegaPOV averaging method produces a 
> more
> natural blur than using POV the way I had worked it out (i.e., just 
> averaging
> multiple pre-rendered 24-bit frames during a 2nd render.) Is that solely
> because you've given MegaPOV fifty 'camera views' to average, vs. my 
> smaller
> number of ten? Or is there something about MegaPOV's internal method that
> inherently produces a more accurate blur?  I'm most curious about the
> difference.

The main difference is where you have very bright spots.  Normal 24bit 
images have no way of storing those colors, in POV-Ray-terms, all 
color-components >1 are clipped to 1, hence averaging those images will not 
give accurate results.

Example: let's put it in 1D and black&white.  Let's say you have the 
following frames (every line is a frame)

.1 .1 8 .1 .1
.1 .1 .1 8 .1
.1 .1 .1 .1 8

(so, that's like a very bright spot moving to the right :))
You're 24bit prerendered image will have them stored like:

.1 .1 1 .1 .1
.1 .1 .1 1 .1
.1 .1 .1 .1 1

and averaging those frames will result in the following:

.1 .1 .4 .4 .4

while the actual result should be:

.1 .1 2.73 2.73 2.73
(which will be stored in a 24bit image as .1 .1 1 1 1)

This makes all the difference between a realistic animation and a "there's 
just something synthetic about this!"-animation

> BTW, there *is*, at present, an inherent problem with my own blurring 
> scheme: It
> currently applies the multiple averaged images onto a flat box, positioned 
> in
> front of my orthographic camera for the 2nd render. And it's quite tricky 
> to
> scale the box, to get an exact 1:1 correlation between the pre-rendered 
> images'
> pixels and the 'new' camera's camera rays. (I.e., the 2nd camera's rays 
> should
> exactly intersect each pixel in the averaged composite image, to get a 
> truly
> accurate 2nd render.) I looked through 'screen.inc' to see what I could 
> use
> there instead of my box idea, but I couldn't discern if it produces this
> *exact* 1:1 correspondence. I'm thinking that it does, but I haven't tried 
> yet.

I suppose screen.inc gives a 1:1 correlation, as long as you're output-image 
is the same size as the input-image.  Be sure though not to use 
anti-aliasing and/or jitter.


>> And the second way is by using MegaPOV's noise_pigment.  It renders 
>> faster,
>> but I use this method more for testing-purposes only as it doesn't give
>> really accurate results:
>
> This is a weird one to understand.  I need to read the MegaPOV 
> documentation to
> get a mental picture of what happens here. I'm wondering if it has 
> anything to
> do with the idea of 'frameless rendering'?

I guess there's some similarity, but it certainly isn't frameless rendering. 
With frameless rendering, every ray (or every pixel when not using 
anti-aliasing) is shot at a random point in time in the given time-interval. 
With perfect anti-aliasing, this will produce perfect accuracy.  My second 
method also uses a random time per ray, but only from a predefined (quite 
small) subset of all possible points in time.  Even with perfect 
anti-aliasing the best you'll get is exactly the same as the frist method. 
The only advantage of this second method, is that without anti-aliasing it 
renders much faster than the first method, while still giving you a fairly 
good idea of what's going on in the animation, making it ideal for 
test-renders :)

> http://www.acm.org/crossroads/xrds3-4/ellen.html

That site seems to use a slightly different definition of frameless 
rendering than I used, but the idea remains the same

> That introduced me to a new term: 'temporal antialisaing.' The method 
> seems to
> be more applicable to real-time rendering, though (of game graphics, for
> example.)

as is the definition of frameless rendering that site uses :)
Interesting stuff though!

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

"Zeger Knaepen" <zeg### [at] povplacecom> wrote:

>
> The main difference is where you have very bright spots.  Normal 24bit
> images have no way of storing those colors, in POV-Ray-terms, all
> color-components >1 are clipped to 1, hence averaging those images will not
> give accurate results.
>
> Example: let's put it in 1D and black&white.  Let's say you have the
> following frames (every line is a frame)...
>
> This makes all the difference between a realistic animation and a "there's
> just something synthetic about this!"-animation

Oh! I'm seeing the problem now. Thanks for walking me through it with your good
example. Good food for thought. I guess my own blur method will be a
*temporary* one now, until I get to know MegaPOV. :-(

> I suppose screen.inc gives a 1:1 correlation, as long as you're output-image
> is the same size as the input-image.  Be sure though not to use
> anti-aliasing and/or jitter.

Right, right and right. (I actually tried antialiasing while generating some
blurred composite frames--the original images had no AA--as a lazy man's way of
getting AA 'on the cheap.' And it just didn't look very good. Not that I was
really expecting it to...)

BTW, my overall methodology of turning my final POV 'blur' renders into MPEG
animation is to use monkeyjam to gather all the frames together (and to
temporarily see the animation), then use that along with the nice xvid MPEG
codec to generate the animation file, which I then view in Windows Media
Player.  But *somewhere* in this chain, something isn't exactly 'right'--the
final animation viewed in WMP has what looks like slightly increased contrast.
(Or a gamma shift, I'm not sure which.)  I'm betting it's solely the fault of
WMP. (Or else MPEG encoding itself introduces this as a by-product--but I don't
really believe that.) The animation pre-viewed in monkeyjam looks exactly right
(that is, discounting the 'averaging' problem you described.) Right now, I'm
just living with this 'shift', but it's irritating. I've been all through the
xvid app, to make sure I haven't set something wrong there. (It's actually a
menu-driven app where you set up and tweak the codec, which is nice.) Yet I
can't say that I'm an expert with it; I'm surely not!

KW

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Zeger Knaepen wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote in message 
> news:web.499cf56640230f63f50167bc0@news.povray.org...
>> Does MegaPOV actually blur the motion *during* a single-frame render?
> 
> if you ask it to :)
> in MegaPOV you have a camera_view pigment, which gives you, with some 
> scripting, the possibility to have multiple camera's in your scene and 
> average the result of all of them.  There are two ways of doing this.  The 
> first is simply using an average pattern:
> --- START CODE ---
> snip...
> --- END CODE ---
> 
> hope this helps :)
> 
	By the way, you *do* know about the "motion_blur" keyword don't
you? It's not quite as flexible as averaging multiple images, but it
can be much faster if only a few objects move...

		Jerome
- --
mailto:jeb### [at] freefr
http://jeberger.free.fr
Jabber: jeb### [at] jabberfr
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkmfq2oACgkQd0kWM4JG3k9AEgCeLICDP0cGJZZn7aDyps8einEE
WjwAn3awgjryzuLfnpmv9TepqV8wBrck
=9Pv9
-----END PGP SIGNATURE-----

Post a reply to this message

news:499fab6d@news.povray.org...
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Zeger Knaepen wrote:
>> "Kenneth" <kdw### [at] earthlinknet> wrote in message
>> news:web.499cf56640230f63f50167bc0@news.povray.org...
>>> Does MegaPOV actually blur the motion *during* a single-frame render?
>>
>> if you ask it to :)
>> in MegaPOV you have a camera_view pigment, which gives you, with some
>> scripting, the possibility to have multiple camera's in your scene and
>> average the result of all of them.  There are two ways of doing this. 
>> The
>> first is simply using an average pattern:
>> --- START CODE ---
>> snip...
>> --- END CODE ---
>>
>> hope this helps :)
>>
> By the way, you *do* know about the "motion_blur" keyword don't
> you? It's not quite as flexible as averaging multiple images, but it
> can be much faster if only a few objects move...

yes, but that doesn't work for camera motion AFAIK

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote in message 
news:web.499f80b940230f63f50167bc0@news.povray.org...
> BTW, my overall methodology of turning my final POV 'blur' renders into 
> MPEG
> animation is to use monkeyjam to gather all the frames together (and to
> temporarily see the animation), then use that along with the nice xvid 
> MPEG
> codec to generate the animation file, which I then view in Windows Media
> Player.  But *somewhere* in this chain, something isn't exactly 
> 'right'--the
> final animation viewed in WMP has what looks like slightly increased 
> contrast.
> (Or a gamma shift, I'm not sure which.)  I'm betting it's solely the fault 
> of
> WMP. (Or else MPEG encoding itself introduces this as a by-product--but I 
> don't
> really believe that.) The animation pre-viewed in monkeyjam looks exactly 
> right
> (that is, discounting the 'averaging' problem you described.) Right now, 
> I'm
> just living with this 'shift', but it's irritating. I've been all through 
> the
> xvid app, to make sure I haven't set something wrong there. (It's actually 
> a
> menu-driven app where you set up and tweak the codec, which is nice.) Yet 
> I
> can't say that I'm an expert with it; I'm surely not!

I suppose your gamma-settings for overlay video are wrong.  You should be 
able to adjust them at Display Properties -> Settings -> Advanced -> [name 
(of the brand) of your graphics card] -> [something with overlay and/or 
color/gamma settings]

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

"Zeger Knaepen" <zeg### [at] povplacecom> wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote in message
> But *somewhere* in this chain, something isn't exactly 'right'--the
> > final animation viewed in WMP has what looks like slightly increased
> > contrast. (Or a gamma shift, I'm not sure which.)
>
> I suppose your gamma-settings for overlay video are wrong.  You should be
> able to adjust them at Display Properties -> Settings -> Advanced -> [name
> (of the brand) of your graphics card] -> [something with overlay and/or
> color/gamma settings]
>

Ah yes, the video card--another link in the chain. Mine is an ATI Radeon 200
series (it came with my machine.) Following your advice, I looked at the
'Overlay' tab, and it tells me that the settings there are automatically
applied "to any video file type that supports overlay adjustments"--five slider
settings including gamma. But the sliders are ALL dimmed out (even the 'Set to
defaults' button) so I can't adjust them. I don't understand why; but they are
all at their good default 'mid-points' anyway, with gamma at 1.0. Then I looked
under the 'Color' tab, which has three sliders--contrast, brightness and gamma--
that *can* be adjusted, but they affect *everything* on my system, instantly, so
I'll leave them as-is (again, set to their defaults, with gamma at 1.0.)

I took a closer look at the other videos I've created (all made with monkeyjam)
and they ALL have the slight contrast/gamma problem, regardless of
the video codec I used at the time--CINEPAK, Sorenson, etc. So I'm pretty sure
it isn't the xvid codec.

I have no real way of knowing if video from ALL sources (DVDs, etc.) show this
problem when played back on my system; I guess so. Never thought about it until
now.

BTW, I'm running Windows XP SP3.

Ken W.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote in message 
news:web.49a0333340230f63f50167bc0@news.povray.org...
> Ah yes, the video card--another link in the chain. Mine is an ATI Radeon 200
> series (it came with my machine.) Following your advice, I looked at the
> 'Overlay' tab, and it tells me that the settings there are automatically
> applied "to any video file type that supports overlay adjustments"--five 
> slider
> settings including gamma. But the sliders are ALL dimmed out (even the 'Set to
> defaults' button) so I can't adjust them. I don't understand why; but they are
> all at their good default 'mid-points' anyway, with gamma at 1.0.

You should be able to adjust them while a video is playing

> Then I looked
> under the 'Color' tab, which has three sliders--contrast, brightness and 
> gamma--
> that *can* be adjusted, but they affect *everything* on my system, instantly, 
> so
> I'll leave them as-is (again, set to their defaults, with gamma at 1.0.)

They actually affect everything except overlay-video :)

> I took a closer look at the other videos I've created (all made with 
> monkeyjam)
> and they ALL have the slight contrast/gamma problem, regardless of
> the video codec I used at the time--CINEPAK, Sorenson, etc. So I'm pretty sure
> it isn't the xvid codec.

has nothing to do with the codec, only with the way you play them, which most 
probably is with overlay

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

"Zeger Knaepen" <zeg### [at] povplacecom> wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote in message
> ...But the sliders are ALL dimmed out (even the 'Set to
> > defaults' button) so I can't adjust them. I don't understand why; but they > > are
all at their good default 'mid-p
oints' anyway, with gamma at 1.0.
>
> You should be able to adjust them while a video is playing
>

Of course, fiddling with the 'playback appearance' on my own machine brings up a
larger problem, now that I think of it. Since I don't yet know where the
'increased contrast' is coming from in the chain, I'm wondering what my
animation will look like on others' systems if I post it to the newsgroups.
Will others see the animation the way I intended, or will it show the contrast
problem? I have no clue.

BTW, the only trick I can use at present--to *try* and correct this slight shift
on my own system--is to tell the xvid codec to decode (play back) the animation
with a very slight increase in brightness, using its 'brightness' slider
(which may be a gamma adjustment instead, I can't yet tell.) Not such a great
work-around, because it doesn't *really* restore the exact look of the
animation.

KW

Post a reply to this message

"Zeger Knaepen" <zeg### [at] povplacecom> wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote in message
> > Following your advice, I looked at the
> > 'Overlay' tab, and it tells me that the settings there are automatically
> > applied "to any video file type that supports overlay adjustments"--five
> > slider
> > settings including gamma. But the sliders are ALL dimmed out...

> You should be able to adjust them while a video is playing

Hey, this DOES work!  I never through to try; I figured since they were dimmed
out (when a video *isn't* playing), that was the way they would be no matter
what. Thanks for the tip! I'm still fiddling with the controls to see how well
I can 'match' the original animation look.

This kind of Windows behavior *really* bugs me--the programmers could easily
have added "And BTW, these controls are only dimmed when a video isn't playing"
to the 'Overlay' menu. Or some other clue. But no. After all, most computer menu
commands are chosen *before* the command needs to be used, not *during* an
operation.

Anyway, thanks!

KW

Post a reply to this message

> I'm wondering what my
> animation will look like on others' systems if I post it to the newsgroups.
> Will others see the animation the way I intended, or will it show the contrast
> problem? I have no clue.

Have you tried using a different media player?
I personally find media player classic very good because of the light system
load, but in my eyes VLC ( http://www.videolan.org/vlc/ ) does a better job at
decoding some videos. It often just have prettier, more accurat colors overall,
imho.

-Peter

Post a reply to this message