Resize 1080/25p to 576/50i avoiding flicker

[hanfrunz]

Hello everyone,

if i resize progressive HD material to SD, i get flicker on thin horizontal lines when played on a normal crt monitor, because of interlaced scaning. What is the commonly used method to avoid this? How do the professional resizers handle that problem?

Is a GeneralConvultion like that a good start?


GeneralConvolution(0, "
00 00 01 00 00
00 00 02 00 00
00 00 04 00 00
00 00 02 00 00
00 00 01 00 00 ", 10, false)


regards,
hanfrunz

[2Bdecided]

Just
LanczosResize(704,576)
blur(0.0,1.0)
Reduce the 1.0 (e.g. try 0.75, 0.5 etc) to maintain more vertical sharpness at the expense of more flicker.

Cheers,
David.

[pandy]

Just
LanczosResize(704,576)
blur(0.0,1.0)
Reduce the 1.0 (e.g. try 0.75, 0.5 etc) to maintain more vertical sharpness at the expense of more flicker.


IMO better is to do some bandlimiting before downscaling, also spline36 or spline64 should do resizing better.

so:
Blur (-0.5, 0.75).Spline64Resize (720, 576)

[smok3]

how about using resizer to control bluring?
LanczosResize(704,576)
LanczosResize(1408,1152)
LanczosResize(704,576)

[2Bdecided]

...and you thought it was a simple question hanfrunz? ;)

Cheers,
David.

[SeeMoreDigital]

Why do you need to convert a 1080p25 source to 576i50... Why not convert to 576p25?

[pandy]

Why do you need to convert a 1080p25 source to 576i50... Why not convert to 576p25?

I believe that this is 576p25 (there is no 576i50)

[2Bdecided]

I'm guessing it's being watched on an SD CRT, hence it's 576p25-wrapped-in-576i50, hence interline flicker becomes an issue.

Cheers,
David.

[hanfrunz]

Why do you need to convert a 1080p25 source to 576i50... Why not convert to 576p25?

it's for a dvd production. And when it is played on a crt-monitor it should look good :-)

EDIT: oh 2Bdecided was quicker :-)

i think a simple FIR lowpassfilter should be enough. Is there maybe any SMPTE, ITU or EBU document that recommends a filter?

[IanB]

Try this to get better control of the V-Low Pass. Adjust the intermediate height, 504, and the Gauss sharpness parameter to tune.LanczosResize(704,504)
GaussResize(704,576, P=30.0)

[pandy]

I'm guessing it's being watched on an SD CRT, hence it's 576p25-wrapped-in-576i50, hence interline flicker becomes an issue.

There is no 576i50 (which mean that picture of 576 lines are displayed 50 times per second by interlace fashion e.g. by two fields, each field have 288 lines and there is 100 fields per second).

[2Bdecided]

Some people say 25i, some people say 50i - at first I thought one was right, and the other wrong - but I've seen both used in various places that should know which is correct, so I've come to the conclusion that both are correct. In any case, most people understand that both mean the same thing, and understand exactly what they mean.

If I was wanting to describe 100 fields per second (e.g. the function of 100Hz interlaced TVs) I would say it explicitly to avoid confusion.

Cheers,
David.

[SeeMoreDigital]

it's for a dvd production. And when it is played on a crt-monitor it should look good :-)Given your source is progressive. As far as I'm aware MPEG-2 video encoded at 576p25 will look no worse than MPEG-2 video encoded at 576i50 when viewed via an interlaced CRT display.

[IanB]

@SeeMoreDigital,

And in both cases if you have fine picture information that appears only in 1 field, i.e. single fine horizontal lines, then you will get flicker. To make them completely go away you need to brick wall low pass at the vertical frequency equivalent to 288 lines. This is usually way to harsh, hence my first round suggestion to start at 1.75 time that frequency. A simple V-Blur will make the flicker go away but will also nuke the fine detail. My approach suggested building a much sharper roll-off low pass filter out of standard Avisynth components.

[*.mp4 guy]

try this, its similar to a brickwall filter, but toned down a bit (only 17 sample points) to avoid ringing. It performs a vertical only lowpass to aproximately 1/3.75 of the nyquist frequency with -20db rolloff, on a source with 1080 vertical samples this will reduce the passband upper frequency to around 160-180hz, which is a bit more then half of the maximum possible frequency that can be stored in 576 vertical samples. IE use this on a 1080P source before resizing to 576, to avoid flickering on interlaced displays.

mt_convolution(horizontal=" 1 ", vertical=" 0.038210901657426959 -0.037550193209593907 -0.071321291957842009 -0.089513860956413741 -0.059487989097957106 0.028344726218269046 0.149710222693422800 0.255497189418900370 0.297427044507872330 0.255497189418900370 0.149710222693422800 0.028344726218269046 -0.059487989097957106 -0.089513860956413741 -0.071321291957842009 -0.037550193209593907 0.038210901657426959 ", u=3, v=3)

If this isn't strong enough, I can make a stronger one, but at that point your going to start getting ringing and missing detail.

[hanfrunz]

Thanks *.mp4 guy,
that's exactly what i wanted, and why i love this forum so much :-)

regards,
hanfrunz

[*.mp4 guy]

I did some testing, and I noticed some questionable results on chroma (color shift, and ringing), you should probably set u=2, and v=2, and just apply a simple blur to chroma, instead of using u=3, v=3 and processing the chroma with the filter, as I originally posted.

[hanfrunz]

I did some testing, and I noticed some questionable results on chroma (color shift, and ringing), you should probably set u=2, and v=2, and just apply a simple blur to chroma, instead of using u=3, v=3 and processing the chroma with the filter, as I originally posted.

Is your source yv12? My source is yuy2(4:2:2) so there should be no problem using the same filter for chroma, because the height is the same, right?
I think we would need a second filter for chroma if i had yv12(4:2:0) because height would be the half.

[*.mp4 guy]

I don't know if mt_convolution even works on anything but yv12, but if it does, you should be fine if luma and chroma are the same resolution.

[Alex_ander]

Yeah, for me that function only worked while I stayed in YV12, if ConvertToYUY2 was previously used, this caused error message from AVSP or full crush of VDub. In older masktools the function was called 'YV12Convolution', so probably it still shouldn't work with YUY2. Thanks for the filter, *.mp4 guy!

[hanfrunz]

thanks to everyone,

i came up with this script:


source=directshowsource("somefile.avi")

#source is yuy2. extract y,u and v to three seperate YV12-y-planes:
y=source.converttoyv12()
u=utoy(source).converttoyv12()
v=vtoy(source).converttoyv12()

#add filter and convert to yuy2
y_new=y.mt_convolution(horizontal=" 1 ", vertical=" 0.038210901657426959 -0.037550193209593907 -0.071321291957842009 -0.089513860956413741 -0.059487989097957106 0.028344726218269046 0.149710222693422800 0.255497189418900370 0.297427044507872330 0.255497189418900370 0.149710222693422800 0.028344726218269046 -0.059487989097957106 -0.089513860956413741 -0.071321291957842009 -0.037550193209593907 0.038210901657426959 ", u=2, v=2).converttoyuy2()
u_new=u.mt_convolution(horizontal=" 1 ", vertical=" 0.038210901657426959 -0.037550193209593907 -0.071321291957842009 -0.089513860956413741 -0.059487989097957106 0.028344726218269046 0.149710222693422800 0.255497189418900370 0.297427044507872330 0.255497189418900370 0.149710222693422800 0.028344726218269046 -0.059487989097957106 -0.089513860956413741 -0.071321291957842009 -0.037550193209593907 0.038210901657426959 ", u=2, v=2).converttoyuy2()
v_new=v.mt_convolution(horizontal=" 1 ", vertical=" 0.038210901657426959 -0.037550193209593907 -0.071321291957842009 -0.089513860956413741 -0.059487989097957106 0.028344726218269046 0.149710222693422800 0.255497189418900370 0.297427044507872330 0.255497189418900370 0.149710222693422800 0.028344726218269046 -0.059487989097957106 -0.089513860956413741 -0.071321291957842009 -0.037550193209593907 0.038210901657426959 ", u=2, v=2).converttoyuy2()

#put y,u and v back together
ytouv(u_new,v_new,y_new)

#resize to SD
spline36resize(720,576)



now i will check this on my hd-footage and will report later

[2Bdecided]

It looks "sharp", but adds quite a lot of ringing on thin near-horizontal lines. I realise this is a difficult trade off. This filter successfully kills the twittering on fine detail, while maintaining a "sharp" look.


However, HD downconverted to SD normally has a "nice" look which native SD rarely has - this is due to doing aperture correction in HD rather than SD, which makes the SD downconversion look much cleaner than native SD. Sadly, this filtering completely destroys that "nice" look - the result just looks like native SD, and soft-then-oversharpened SD at that.

btw, if you compromise the footage for interlaced display like this, and then watch it via a good deinterlacer, it looks even worse...

RawSource("station2.yuv",1920,1080,"YV12")

orig=last

mt_convolution(horizontal=" 1 ", vertical=" 0.038210901657426959 -0.037550193209593907 \
-0.071321291957842009 -0.089513860956413741 -0.059487989097957106 0.028344726218269046 \
0.149710222693422800 0.255497189418900370 0.297427044507872330 0.255497189418900370 \
0.149710222693422800 0.028344726218269046 -0.059487989097957106 -0.089513860956413741 \
-0.071321291957842009 -0.037550193209593907 0.038210901657426959 ", u=2, v=2)
a=last.spline36resize(704,576)

orig.spline36resize(704,576)

return last

b=last.limitedsharpenfaster().Sharpen(0.5,0.0).Blur(0.0,1.0).Sharpen(0.0,0.5)

stackhorizontal(a,b)
mcbob()

I misused mcbob to try to make it a fair comparison - obviously a progressive-aware deinterlacer would just weave the output, and the aggressively filtered version would look even worse compared with the "gently/simply" filtered version.

Output attached. left = convolution, right = sharpen.blur. Also straight spline36 attached, showing image "accurately" (which means a lot less sharpening than either of the above!).

Cheers,
David.

[hanfrunz]

thanks 2Bdecided for your comparison,

so maybe another aproach would be better -> Only filter areas where flicker occures. But how would i do that?

[Alex_ander]

so maybe another aproach would be better -> Only filter areas where flicker occures.
I tend to agree. Something like LP filtering (to half SD vertical bandwidth) needs to be applied (before downsampling) to motion parts of the frame (which are represented with samples of twice lower vert. spacial frequency than still parts) and filtering with twice higher cut-off frequency - for still parts of the frame. So far it's an imaginary solution :) .
After some experimenting with my current (1080i to 480i) conversions (although I'm usually satisfied with LeakKernelBob before resizing). Tried to compare the discussed above shift-corrected field-separated resizing, my usual LKB and NNEDI(-2) as bob. Not on interlaced display, just watching by frame in AVSP. HDMV channel's rectangular logo with its thin horizontal edges in front of video appeared to be a suitable test object. I couldn't find any clear difference in performance for the main picture, but that still logo (with motion picture as background) showed some clear artifacts (it looked perfect in original HD) before any flicker. Field separated resizing (shift-corrected) gave visible emphasis above the logo's upper horizontal edge (the logo itself was almost black at that edge) making a line above brighter. This effect was much softer with LKB and almost invisible with NNEDI (but it was TERRIBLY slow). Had no luck with vertical filtering in different places in the script. So I proceeded with LKB as usual.

[2Bdecided]

...but you can get horrible flicker on stationary parts of the image, so just filtering movement won't help I don't think...


I suppose we should be thankful that we have this dilemma. It's not as if any of these results from HD look worse than typical SD (IMO, YMMV).

Cheers,
David.

[Gavino]

... motion parts of the frame (which are represented with samples of twice lower vert. spacial frequency than still parts)
Can you explain this? Doesn't it depend on the relative vertical speed of the motion (in pixels per frame interval)?

[Alex_ander]

...but you can get horrible flicker on stationary parts of the image, so just filtering movement won't help I don't think...

I suggested to (hypothetically) filter both, but with different (twice bigger) filter bandwidth for stationary parts. And such a filter should be applied before downsizing or field separation (I don't know any practical solution for separate filtering of motion/stationary parts). Then it would be possible to have the same reproduction as with original SD footage (without extra artifacts from conversion), that's what I meant.

@Gavino
:
Originally Posted by Alex_ander View Post
... motion parts of the frame (which are represented with samples of twice lower vert. spacial frequency than still parts)

Can you explain this? Doesn't it depend on the relative vertical speed of the motion (in pixels per frame interval)?

Here I meant that if you have a single interlaced frame representing two motion phases, there can be still parts (in case camera doesn't move) and moving objects. The still parts can be restored (without aliasing artifacts) to analog in case the image had been filtered to proper bandwidth before digitizing. The motion parts of this frame can't use for restoration the samples from adjacent lines (different content). To be properly restored from twice lower number of samples per height, those parts should have twice lower max spacial frequency before digitizing. Assuming the original conversion to HD 'perfect', the same approach to filtering for downconversion to SD looks desirable.
Since it all was about spacial only filtering (not motion detecting), I didn't take into account motion speed.

[IanB]

...but you can get horrible flicker on stationary parts of the image, so just filtering movement won't help I don't think...Strikes me that here is another case for detecting motion versus static areas in a video stream and changing the processing behaviour.

If there is motion, the eye will be happy and see the motion as motion and there will be no flicker.

If the area is static but there is some fine detail present in 1 field only, then the eye will mistake it as motion and there will be flicker.

Proposition :- For optimal results when displaying 25p material on a 50i display, you should vertically low pass filter only the areas that are static from 1 25p frame to the next.

[2Bdecided]

Yeah but...

You (maybe) won't notice the filtering so much in the moving areas anyway - so if you have to filter the stationary part, you might as well filter everything.


I think it's even more complicated. High contrast patterns flicker - low contrast ones don't (or not as much). If you filter everything to kill the flicker on the high contrast fine detail, then everything else looks even softer than it has to.

Then again, potential artefacts from an adaptive filter might be far more objectionable?

Cheers,
David.

[yup]

Hi all!
May be need low pass filter in both directions not only at vertical, and after downsize, at same style work script in Matlab for downsizing images.
yup.

[Didée]

so maybe another aproach would be better -> Only filter areas where flicker occures. But how would i do that?
That's the way I would try to walk.

Make a vertical lowpass by using a vertical median filter. (The median will "cut out" the parts that tend to flicker.) Downsize the lowpass normally, say with SplineResize. Make Difference (original-lowpass). Make a blurry downsize of this difference. Apply downsized difference to the downsized lowpass. Finished.

source = last
Vmedian2 = mt_luts(source,source,mode="median",pixels= "0 -2 0 -1 0 0 0 1 0 2", expr="y",U=2,V=2)
Vmedian3 = mt_luts(source,source,mode="median",pixels="0 -3 0 -2 0 -1 0 0 0 1 0 2 0 3",expr="y",U=1,V=1)
Vmedian = mt_average(Vmedian2,Vmedian3,U=2,V=2)
VmedianDiff = mt_makediff(source,Vmedian)
small1 = Vmedian.Spline36resize(720,576)
smallDiff = VmedianDiff.GaussResize(720,576, p= ?20? ) # adjust "p" ...
result = small1.mt_makediff(smallDiff,U=2,V=2)

Code is not tested, just scribbled down. Can't foresee if radius=2 is sufficient, or radius=3 is needed, so made an average of them ... try and see.

[SilaSurfer]

Hi Didée

Your script above gave me some nice results dowsizing from 1080p Bluray source to 720p . I had to put Spline36 line to get my desired resolution, is this ok? The picture quality is great. Do you have maybe any newer versions of this script? Thanks

[Didée]

I'm not quite sure what you mean with "I had to put spline36resize to get my desired resolution" ?

[SilaSurfer]

crop(x,y)
source = last
Vmedian2 = mt_luts(source,source,mode="median",pixels= 0 -2 0 -1 0 0 0 1 0 2", expr="y",U=2,V=2)
Vmedian3 = mt_luts(source,source,mode="median",pixels="0 -3 0 -2 0 -1 0 0 0 1 0 2 0 3",expr="y",U=1,V=1)
Vmedian = mt_average(Vmedian2,Vmedian3,U=2,V=2)
VmedianDiff = mt_makediff(source,Vmedian)
small1 = Vmedian.Spline36resize(1280,528)
smallDiff = VmedianDiff.GaussResize(1280,528, p= ?20? ) # adjust "p" ...
result = small1.mt_makediff(smallDiff,U=2,V=2)
Spline36Resize(1280,528) #had to add this line otherwise it stays at 1920, 800

[Didée]

You don't know Avisynth's grammar all too well?

All processing is done via named clip-variables. The result is stored in the "result" clip variable.

With your not-named resize at the end, you get no processing at all, everything has been bypassed. The SplineResize refers to "last", and the latest "last" that exists is the source clip itself, after crop().


crop(x,y)
source = last
Vmedian2 = mt_luts(source,source,mode="median",pixels="0 -2 0 -1 0 0 0 1 0 2", expr="y",U=2,V=2)
Vmedian3 = mt_luts(source,source,mode="median",pixels="0 -3 0 -2 0 -1 0 0 0 1 0 2 0 3",expr="y",U=1,V=1)
Vmedian = mt_average(Vmedian2,Vmedian3,U=2,V=2)
VmedianDiff = mt_makediff(source,Vmedian)
small1 = Vmedian.Spline36resize(1280,528)
smallDiff = VmedianDiff.GaussResize(1280,528, p= ?20? ) # adjust "p" ...
small1.mt_makediff(smallDiff,U=2,V=2)


For you, like ^so^.

[SilaSurfer]

Yes I know Avisynth's grammar. Thanks for your example above.

[Gavino]

Your script above gave me some nice results dowsizing from 1080p Bluray source to 720p . I had to put Spline36 line to get my desired resolution, is this ok? The picture quality is great.
With your not-named resize at the end, you get no processing at all, everything has been bypassed.
A fine example of the placebo effect. :)
Or maybe it shows that Spline36Resize on its own is good enough for many sources.

[Didée]

A fine example of the placebo effect. :)
Definetly. :D

Or maybe it shows that Spline36Resize on its own is good enough for many sources.
Rather an example of "wrong usage case".

Look at the topic ... the function is not meant for purely progressive downsizing. It is meant to be used in conjunction with a final "separatefields().selectevery(4,0,3).weave()" to create interlaced output. Rationale is to use the lowpass-blur not on "everything", but only on those parts that are most prone to show flicker after re-interlacing.

Since SilaSurfer targets 720p, and since there is no interlaced 720p(i) to start with, it's pretty pointless alltogether.

[SilaSurfer]

Since SilaSurfer targets 720p, and since there is no interlaced 720p(i) to start with, it's pretty pointless alltogether.

:rolleyes: