Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
10th August 2008, 23:46 | #1 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Deinterlace should preserve original pixels?
Yes, I'm afraid it's Yadiq - Yet Another Deinterlacing Question
Given that deinterlacing is basically a problem of interpolation, is it considered a) essential, b) desirable or c) unimportant that a deinterlacer/bobber preserves the original pixel values. Please explain your answers To clarify, what I am asking is, given the interlaced input, with dots representing pixels, Code:
y \ time--------------> | . . . . | . . . . | . . . . v . . . . etc Is the answer the same for both 'normal' deinterlacing (50i->25p) and bobbing (50i->50p)? (Clearly, in the first case, you throw some information away as well.) How do some of the well-known deinterlacers behave in this respect? Aside - deinterlacing seems to be one of those mysterious topics, like quantum mechanics or relativity, where the more you learn, the more you realise how much further you still have to go... |
11th August 2008, 00:52 | #4 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
Ideally the input pixels should be preserved. As you say "the work be limited to 'filling in the blanks'".
But this is a perfect world view. In reality you have to invent the new pixel values to fill in the gaps and this will occasionally lead to mistakes. Sometimes these mistake lead to visually unpleasant artefacts. If a given implementation chooses to do some extra processing to limit the visual significance of these mistake, and it involves tweaking the value of the original input pixels, and this truly makes these mistakes less objectionable, then I would say it is okay to munge the input values slightly to improve the total result. The dumb internal Bob() filter takes this approach. It moves the top field down 0.5 pixel and the bottom field up 0.5 pixel using the Bicubic resizer to do the work. This is so that all output frames are equally processed. Using some clever values for B, C and Height the input pixel values can be retained, I do not like the look of the result, but for some applications it is relevant. |
11th August 2008, 06:02 | #5 | Link |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
I checked, and bob keep (alternatively) one field at the same position, and recreates the other field by moving the first one 0.5 pixel up or down. However, the field looks slightly lowpassed, which makes sense for a dumb spatial bob since a field taken alone necessarily has some aliasing.
__________________
|
11th August 2008, 10:55 | #6 | Link |
Registered User
Join Date: Apr 2008
Location: St. Petersburg, Russia
Posts: 334
|
Probably, NNEDI does keep original pixels. Don't know about its internal procedures, but documentation says it 'interpolates the missing pixels using only information from the kept field'. Considering its speed looks like it doesn't do it some dumb way. It wouldn't work good at plain deinterlacing in some critical cases (e.g. one field black, the other white), but at bob -> resize -> interlace the same example somehow should work.
|
11th August 2008, 11:06 | #7 | Link |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
There's a post somewhere where Didee explained that mcbob strictly preserves the original fields, but this constraint could be relaxed - and this might potentially give a nicer looking output in some circumstances.
I care about preserving the original fields if I'm generating a progressive version for processing, and will revert to interlaced for the final output. It at least gives the chance of the whole thing becoming a NOP (at least in theory!) if/where necessary. I care about the nicest looking output if the progressive version is the final output - and in that case, I'll use whatever looks best - whether it preserves, or not. Interlacing, and deinterlacing, are compromises. You have to throw ideals away sometimes when working with compromises! Cheers, David. |
13th August 2008, 00:25 | #8 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Thanks for the responses, everyone. I think the answers show that the question was not a trivial one.
Encouraged by that, I have done a bit more investigation, and have found that the truth about Bob [sounds like the title of a bad movie] is a bit more complex than the documentation says. Since Bob uses a Bicubic (aka Mitchell-Netravali) reconstruction filter, it will keep the original pixels when that filter acts as a pure interpolator, ie if and only if b=0 (regardless of the value of c). Hence the default values (b=c=1/3) do not preserve the input data. As the documentation states, (b=0, c=1) will do so, but so will b=0 and any other value of c, including c=0.5 (the Catmull-Rom spline) which keeps the desirable property b+2*c=1. I have verified this in practice by undoing the Bob (via SeparateFields, SelectEvery and Weave) and doing a Compare with the original. What no-one mentioned (perhaps because they thought it self-evident) is that for YV12 it is wrong and makes no sense for any deinterlacer to preserve the original chroma data, because of the different way YV12 chroma is stored in interlaced and progressive frames. Last edited by Gavino; 13th August 2008 at 01:20. |
13th August 2008, 03:49 | #10 | Link |
Registered User
Join Date: Jul 2003
Location: India
Posts: 890
|
I am interested to know how the yv12 chroma is originally arrived at in case of interlaced video? U and V values correspond to two by two pixels. In this case the two vertical pixels may have completely different chroma values. I am intending to do a rotation in my spinner plugin and need to know the chroma scheme.
|
13th August 2008, 08:13 | #11 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
@IanB
You're right that in the case of Bob (or anything that works on only one field at a time), input chroma could be preserved by changing the resampling positions for the chroma (but I'm not sure if this would be theoretically 'correct'). For deinterlacers that combine the two fields, I think it would be wrong. Consider the effect on a stationary scene. @vcmohan. See here for all the gory details. I'm not sure it makes sense to do rotation on interlaced video. Or do you plan to deinterlace, rotate and re-interlace? Even then I don't think it could work right. Last edited by Gavino; 13th August 2008 at 08:30. |
13th August 2008, 08:26 | #12 | Link | |
Registered User
Join Date: Jan 2002
Location: France
Posts: 2,856
|
Quote:
Code:
X X X X ----> Top luma O O ----> Top chroma X X X X ----> Bottom luma X X X X ----> Top luma O O ----> Bottom chroma X X X X ----> Bottom luma Code:
X X X X O O X X X X Code:
X X X X O O X X X X
__________________
|
|
13th August 2008, 10:10 | #13 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
Borrowing and correcting (Mpeg1 versus Mpeg2 placement) Manao's nice ascii art :-
Code:
X X X X ----> Top luma O O ----> Top chroma * * * * ----> Interpolated luma X X X X ----> Top luma + + ----> Interpolated chroma * * * * ----> Interpolated luma |
13th August 2008, 17:01 | #14 | Link | |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
Quote:
Thanks for that - now what you and IanB are saying makes perfect sense. I was assuming that each field was equivalent to a half-sized progressive YV12 image, whereas, as far as the chroma sampling positions are concerned, it is not the same. However, the corollary of this seems to be that Bob is actually operating wrongly on YV12 chroma, since it resizes each field as if it were a standard progressive image. (This is independent of whether or not it retains the original pixels.) Should it not be shifting the chroma differently from the luma before resizing? Going further, it also suggests that the approach of resizing an interlaced image by SeparateFields, etc, will also introduce a chroma error with YV12 unless the chroma is treated specially. Can this be right? Last edited by Gavino; 13th August 2008 at 17:03. |
|
14th August 2008, 01:11 | #15 | Link | ||
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
Quote:
Internally the chroma planes are offset +/-0.125 as the luma planes are offset +/-0.25 so the overall effect is correct. Quote:
The input crop value is the result of 3 components
Code:
Top field Luma = 0.0 Top field chroma = 0.125 Bottom field Luma = 0.5 Bottom field chroma = 0.625 Code:
// the following translates such that the image center remains fixed double pos = subrange_start + ((subrange_width - target_width) / (target_width*2)); or = subrange_start - 0.5*(1 - subrange_width/target_width); |
||
14th August 2008, 03:51 | #16 | Link |
Registered User
Join Date: Jul 2003
Location: India
Posts: 890
|
Is there a flag to find out if a image is bobbed or just plain separated?
In case of RGB what happens for bobbed clip if we trim and join at places not matching? @Gavino: I have provision to linearly move the coordinates of rotation center along clip. In such case I need to know where exactly these coordinates are in each field. |
14th August 2008, 09:13 | #18 | Link |
Avisynth language lover
Join Date: Dec 2007
Location: Spain
Posts: 3,431
|
IanB, thanks for the explanation.
Can you please clarify one detail for me - do the resizers treat fieldbased and framebased clips differently, or are you saying specifically there is no need for them to do so (because it 'comes out in the wash')? |
14th August 2008, 09:40 | #19 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
No the resizer always treats the frame as framebased. This is why you need to manually calculate the offset for the top and bottom fields when using my interlaced resizing function.
To answer the question I think you were really trying to ask :- Because the resizer is centre of image referenced the relationship between luma and chroma is maintained during a resize. If chroma is 0.125 old pixels up in input it will still be 0.125 new pixels up on output. |
Tags |
yv12 chroma offset |
Thread Tools | Search this Thread |
Display Modes | |
|
|