Fadeout never seems smooth

[Floatingshed]

Two people have separately commented now that whenever I use a slow fadeout it seems to flicker as it fades and is not smooth.
I'm working on something at the moment that has a 50 frame fade to black and it doesn't look right at all.

Any ideas please...

[Gavino]

:script:

Is your output interlaced?

[Floatingshed]

:script:

Is your output interlaced?

Mostly yes but not always...
Sorry that is a bit vague but the problem seems to happen with interlaced or progressive. The current problem is interlaced.

Is there a special way to handle interlaced fading?

[Gavino]

In principle, you should get a smoother fade by applying the fade to the fields intead of to frames, eg

AssumeTFF() # or BFF as appropriate
SeparateFields()
FadeOut(n) # apply fade to fields (n = 2 x no of frames)
Weave()

In practice, I'm not sure you'd really notice the difference.
Try it and see - if it doesn't cure the problem, post a sample (and your script!).

[IanB]

Frame versus field based fading is the major consideration, the other consideration is that the Fade*() routines do a linear fade on a Gamma effected signal. i.e. (x**2.2)*fade <> (x*fade)**2.2

The eye interprets changing relative luminance between pixels as movement because it detects a moving edge gradient by tracking where the relative luminance gradients are the same. Think of a predator moving in and out of the shadows.

[Floatingshed]

Interesting! You know your stuff.

However as most fades seen in video productions look OK and mine don't I think it must be something silly that I'm doing.
When I get chance I'll re-asses this with the simplest of scripts and try to work out where the problem is.

In the meantime if anything more occurs to you...

Thanks.

[IanB]

Another issue is as the luminance range becomes more squashed during the fade, banding can become noticable. As groups of pixels apparently move between adjacent bands false motion artefacts can be observed.

I tried :-...
Levels(0, Gamma, 255, 0, 255)
FadeOut(n)
Levels(0, 1.0/Gamma, 255, 0, 255)
...but the banding effect was really horrible. 8 bit's is just not enough to do this with.

[Didée]

Here's some raw code to do gamma-corrected fadeout with "16bit precision".
(Precisely, luma is gamma-corrected, chroma is just linear. Not fully sure what the expected thing would be in YUV.)

function FadeOutWithGammaCompensationIn16bit(clip c, int frames)
{
start = framecount(c)-frames
end = framecount(c)-1
c.Animate(start,end,"lut_fade",1.0,0.0)
}

function lut_fade(clip c, float mult)
{
c.mt_lut(expr="x 128 - "+string(mult)+" * 128 +",yexpr="x 2.2 ^ "+string(mult)+" * 1 2.2 / ^",U=3,V=3)
}

[Gavino]

function FadeOutWithGammaCompensationIn16bit(clip c, int frames)
{
start = framecount(c)-frames
end = framecount(c)-1
c.Animate(start,end,"lut_fade",1.0,0.0)
}
More accurate would be to set start = framecount(c)-frames-1, since the frame with mult=1.0 is not part of the fade.

[IanB]

yexpr probably should be "x 16 - 1 2.2 / ^ "+string(mult)+" * 2.2 ^ 16 +"

Black should stay black.

The algorithm should be undo the gamma, fade, redo the gamma.

There probably should be some sort of x < 16 ? : logic to stop any weirdness from stray super black values. -1^2.2 means what?