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. |
2nd July 2008, 07:23 | #21 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
@florinandrei,
Interlaced resizing is fast, but you pay a price for generating each new field based only on the original field. Any new pixels spacially between 2 original field lines will effectivly be a weighted average of only the pixels above and below in that field, i.e. a blur. Effectively all the pixels in the new fields are vertically blurred slightly. Using the SmartBob/Resize/ReInterlace method, although slower, will give vastly superior results in static areas because each new field can be based on a full frame. In static areas there is no "spacially between 2 original field lines". Those new pixels are rendered from complete frame data. i.e. no blur in static areas. Of course in motion areas any difference can be attributed to how good the SmartBob interpolates the missing pixels. If using linear interpolators like in KernelBob or DGBob there will be no difference to Interlaced Resizing. i.e. a blur again. If using Edge Directed and/or Motion Compensated interpolators then the results can be a significant step up from bog interlaced resizing. And apart from everything else the eye has trouble seeing bluring of things in high motion, it attributes motion to the blur, instead of blur to the blur. So it is a little unfair to look at individual fields on a PC screen, you really should evaluate the results on an interlaced display device at normal speed. |
2nd July 2008, 10:28 | #22 | Link |
Registered User
Join Date: Apr 2008
Location: St. Petersburg, Russia
Posts: 334
|
NNEDI is newer, but this doesn't mean it can replace the 'outdated' Kernel bobber for any type of image - it works differently. Theoretically, in case of an image being as sharp as HD pixel resolution provides, it simply can't work correctly. It throws away one of the fields at interpolation and this means it halves vertical sampling frequency for an image which demands twice higher value by discretization theorem (by Kotelnikov/Nyquist). To have an illustration to what could happen sometimes, imagine a radical case of image type: all even lines in a still HD frame are black and all odd ones are white. NNEDI would simply alternate black and white frames, while Kernel bobber would still work somehow since it uses data from both fields. Of course the problem doesn't appear with softer or upsampled images and NNEDI is good there.
|
2nd July 2008, 10:36 | #23 | Link | |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
Quote:
1. You will then resize vertically to less than half the original resolution (or a little more than half the original resolution for "PAL") - that's a fair amount of blur! 2. You will then throw away half the remaining lines in each field to interlace the signal - that's a fair amount of lost information. 3. You will then rely on the deinterlacing in the display, if any, to restore those missing lines - or view on a native interlaced display, which will display inter-line twitter on sharp vertical details unless they are blurred before interlacing! Either way, you will be very lucky to see any extra detail you recovered with a "smart" bob. As for "why not use X smart bobber - it's still fast?" – fast, yes, but everyone one I've seen (that counts as "fast") is prone to artefacts on something - sometimes quite nasty artefacts. The artefacts can be far more visible on the downconversion than any slight softness due to bobbing. Of course mcbob to tgmc will do a better job and are almost always artefact free - but with these the slow down is considerable. Cheers, David. |
|
2nd July 2008, 11:05 | #24 | Link | |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
Quote:
However your extreme example is too extreme. In an interlaced system, that image is ambiguous - the original image (before interlacing) could equally well be one frame black, then one frame white - or it could be two identical frames with alternate black/white lines. There is no way of knowing which, other than assuming. All "smart" deinterlacing is based on assumptions - basically that the content changes little field by field - the camera is still pointing at roughly the same scene. If every field was completely independent, then a dumb bob would be the best you could do. There are interesting graphs on pages 23 and 24 of this... http://www.snellwilcox.com/community...des/edecod.pdf ...and I don't claim to fully understand them(!) but the stars represent typical content - mostly low detail and low movement (the centre of the stars) but a little fine detail and significant movement (the "arms" of the stars). If you had lots of fine detail and significant movement - almost random content, the frequency response wouldn't look like a star, but more like a square (up to the Nyquist limits for each dimension). If you turn the stars into squares in the progressive plot, they don't overlap. If you turn the stars into in the interlaced plot, they do overlap. That's the ambiguous region. Your example is right in the middle of the overlap. Cheers, David. |
|
2nd July 2008, 12:03 | #25 | Link |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
I've attached two pictures.
The first one compares the output of bob (dumbest bobber available!) and mcbob (smartest bobber available). I've stacked the output vertically, resized to 704x480, and added limitedsharpenfaster since the OP seems to want a sharp output (I don't think it's necessary). The script is: Code:
avcsource("00000.dga") assumetff() lanczosresize(704,last.height) a=bob() b=mcbob() stackvertical(a,b) lanczosresize(last.width,480*2) limitedsharpenfaster() However, that's not what the OP wants to do - the OP wants interlaced output. If you interlace the image, and then do your best to watch it (either on an interlaced display, or via a great deinterlacer like mcbob) then it becomes almost impossible to see any difference. Really. The lines look the same, and their stability is the same. This is shown in interlaced.jpg, where I took the video shown in progressive.jpg, interlaced it, and then ran it through mcbob. This is the code: Code:
avisource("dga test.avi") assumetff() separatefields().SelectEvery(4,0,3).Weave() converttoyv12(interlaced=true) mcbob() The advantage of better bobbers in HD is not visible in the interlaced SD output for this content. btw, either way, it's too sharp vertically for interlaced displays IMO - if anything, it needs slight softening in the vertical direction before interlacing, if you expect to watch it on a CRT. Cheers, David. Last edited by 2Bdecided; 2nd July 2008 at 12:11. |
2nd July 2008, 16:56 | #26 | Link |
Registered User
Join Date: Mar 2004
Posts: 889
|
florinandrei, while you are bothering with the interlacing stuffs, you may want to consider another issue: aspect ratio.
Do you find your encoded NTSC 16:9 DVD looking a bit "wider/fatter" than your original 1920x1080 source? As far as I know, if we take the pixel aspect ratio of NTSC 16:9 DVD as 40:33, your 1920x1080 1:1 material will scale to 704x480 [704 = 1920*(33/40)*(480/1080)]; after left and right pads of 8 pixels each, you have 720x480. On the contrary, if you resize to 720x480 directly, the resultant DVD will look a bit "wider/fatter" than your source. If you don't want to have two thin black bars on the two sides, you may crop 12 pixels from (both) the top and bottom, making it 1920x1056, before resizing to 720x480. Last edited by henryho_hk; 2nd July 2008 at 17:05. Reason: Just notice that 2Bdecided is resizing to 704x480 too. ^_^ |
2nd July 2008, 17:40 | #27 | Link |
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
I just go to 704 - it's a legal DVD resolution and saves confusion. It gets you the correct aspect ratio in software players and stand-alones (to within one pixel). No need to pad to 720.
http://forum.doom9.org/showthread.php?t=132378 http://forum.doom9.org/showthread.ph...87#post1100187 However, most pros go to 720, and don't care about the slight error which they sometimes introduce, and sometimes don't. Cheers, David. |
2nd July 2008, 19:02 | #28 | Link | ||||||
Registered User
Join Date: Jul 2006
Posts: 120
|
OK, I'm starting to understand a few things.
Quote:
And bob is the first script? If that's the case your prediction appears correct, the second script seems to create output slightly blurred vertically, compared to the first one (at least on a computer and on the PS3 + flat panel). Encoding speed has no importance to me. I prefer something that's very slow but very accurate. Encode once, watch forever - so better encode it right. So, in that context, I guess you're saying: "use the first script but with the best bob you can find." Quote:
Code:
DirectShowSource("E:\video\birthday\STREAM\00000.MTS") MCBob() LanczosResize(720,480) AssumeTFF() SeparateFields() SelectEvery(4,0,3) Weave() ConvertToYV12() Quote:
OTOH, the DVD will be watched on progressive displays too, not just on old CRT. So I can't neglect either. Quote:
Quote:
Quote:
What I want is a reduced-size copy that looks, statically and dynamically, as close to the original as possible, aside from the smaller resolution. The master is interlaced HD video captured with a camera (not computer-generated) and has no scene changes. The result will be watched on a variety of screens, from plain old CRT to new smart upscalers + progressive HD panels. I am aware that there might be conflicting requirements hidden here (such as accurate statically and dynamically). If that's true, that's one of the things I'm hoping to learn from this discussion. |
||||||
2nd July 2008, 19:11 | #29 | Link |
Registered User
Join Date: Jul 2006
Posts: 120
|
To put "accuracy" in perspective: I'm shooting with a consumer-level camera, but it's tweaked to be as neutral as possible. It has a Cinema mode which gives a somewhat flatter, non-aggressive gamma curve (unlike the "torch mode" on most cheap cameras) and I also changed settings such as saturation, brightness, etc. to make the result as neutral as possible. If I need brighter colors or bigger contrast, that can be taken care of in post - and now I see AviSynth could be used for that (but that's not the subject of this discussion).
I guess I should really use a "prosumer" camera, but those are 5 times more expensive. Can't do that now. So I don't need something that looks flashy or "sharp" to the average user. I need something that is close to the original. |
2nd July 2008, 19:20 | #30 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
|
I think you're taking a very good approach to this project. Kudos for sticking it out and trying to understand what's really happening, instead of throwing in the towel, copying and pasting a script, and being done with it. For reference, here's a little explanation of your script:
Code:
DirectShowSource("E:\video\birthday\STREAM\00000.MTS") #At this point, your video is untouched true 1080i MCBob() #Now, we've bobbed 1080i to 1920x1080 @ 59.94fps. #99.9% of your processing time will be spent here. LanczosResize(720,480) #Now we're down to 720x480 @ 59.94fps AssumeTFF() SeparateFields() #Now we've pulled the progressive frames apart into 720x240 fields. #It's technically at 119.89fps, but that doesnt matter ATM SelectEvery(4,0,3) #Now we've decimated away half the information like this: #Input: A B C D #Output: A C #So, we're back to 59.94fps, still 720x240 Weave() #Now we actually interlace the fields to produce interlaced frames. #So, we're at 720x480 @ 29.97i fps ConvertToYV12() #And finally we convert the colorspace from something else to YV12 #(odd, because AVCHD should be YV12 - must be a decoder error). #Actually, ConvertToYV12(interlaced=true) would be better ~MiSfit
__________________
These are all my personal statements, not those of my employer :) Last edited by Blue_MiSfit; 2nd July 2008 at 19:31. |
2nd July 2008, 20:06 | #31 | Link |
Resize Abuser
Join Date: Apr 2005
Location: Seattle, WA
Posts: 623
|
Building off of Blue_MiSfit's script
Code:
DirectShowSource("E:\video\birthday\STREAM\00000.MTS") #At this point, your video is untouched true 1080i MCBob() #Now, we've bobbed 1080i to 1920x1080 @ 59.94fps (1080P). #99.9% of your processing time will be spent here. ZoomBox(704,480,"LanczosResize", SourceDAR=16.0/9.0, TargetDAR=16.0/9.0, align=-5) #Now we're down to 704x480 @ 59.94fps #Resizer set for a source and target DAR of 16/9. #Set Align=5 to get rid of black bars and crop instead of adding borders AssumeTFF() SeparateFields() #Now we've pulled the progressive frames apart into 704x240 fields. #It's technically at 119.89fps, but that doesnt matter ATM #ConvertToYV12() #Uncomment this to change colorspace. It's a good idea to change color space while it's still progressive video. SelectEvery(4,0,3) #Now we've decimated away half the information like this: #Input: A B C D #Output: A C #So, we're back to 59.94fps, still 704x240 Weave() #Now we actually interlace the fields to produce interlaced frames. #So, we're at 704x480 @ 29.97i fps MCBob takes YV12() so your video is already YV12 Edit: Changed 720 to 704 after reading about DVD players from the links that 2Bdecided gave above (post 27).
__________________
Mine: KenBurnsEffect/ZoomBox CutFrames Helped: DissolveAGG ColorBalance LQ Animation Fixer Last edited by mikeytown2; 2nd July 2008 at 20:44. |
3rd July 2008, 00:19 | #32 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
It seems a lot of the evaluation is being done here looking at static images. As this material is originally interlaced and motion fluidity is important it is vital to view the results in motion at normal speed, preferably on all the target displays. Having really great individual static bobbed frames that vertically twitter like crazy when viewed is about the worst result I could imagine. Examine carefully all thin vertical, horizontal and diagonal lines and sharp high contrast edges.
And one last point, if a ConvertToYV12() is required, where should it go. I would recommend straight after the Bob and before the Resize. There is a whole raft of discussion about chroma positioning with interlaced 4:2:0 material. Summary is the chroma is positioned the same with both interlaced and progressive, but with interlaced, alternate lines are temporally distinct. This means for a static scene there is no difference between progressive and interlaced chroma. See these threads for the gorey details, AutoYUY2() updated and Adaptive chroma upsampling |
3rd July 2008, 21:24 | #34 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,988
|
True
But the golden rule here is - whatever makes the user happy! If that means encoding Blu-ray using Apple's MPEG-4 SP encoder at 512kbit, so be it! ~MiSfit
__________________
These are all my personal statements, not those of my employer :) |
4th July 2008, 04:39 | #35 | Link |
Registered User
Join Date: Mar 2004
Posts: 889
|
Assuming that Bob() is good enough for 1080i to 480i downsizing, what about this?
Code:
AVCSource(dga="mts00000.dga") #1920x1080i @29.97fps YV12 AutoYUY2() #1920x1080i @29.97fps YUY2 Bob(0, 1, 480) # .... or Bob(0, 0.5, 480) ? #1920x480p @59.94fps YUY2; shift correction automatically performed for the vertical resize AssumeTFF() #Dunno if the field order is preserved, so play safe Separatefields().SelectEvery(4,0,3).Weave() #1920x480i @29.97fps YUY2 ConvertToYV12(interlaced=true) #1920x480i @29.97fps YV12; will it destroy the AutoYUY2() effects? BicubicResize(704, 480, 0, 0.5) #704x480i @29.97fps YV12 Last edited by henryho_hk; 4th July 2008 at 17:09. Reason: AutoYUY2() can be downloaded from in http://neuron2.net/autoyuy2/autoyuy2.html |
4th July 2008, 11:44 | #36 | Link | ||
Registered User
Join Date: Dec 2002
Location: UK
Posts: 1,673
|
Quote:
I'm still thinking about this statement... Quote:
If you do a bicubic resize and leave it at that, it'll all look a bit soft. If you do a lanczos resize and run limitedsharpenfaster, it'll all look very sharp (too sharp?). Neither will always "keep the perceived sharpness of the original, but on a smaller scale" - resizing doesn't work like that. You have to use the appropriate tools to get the sharpness you want, which is partly independent of the source. If you want it to look like the source, you'll have to throw in the processes that "recreate" that look at the new resolution, because it won't happen by magic. I think I'm explaining this really badly, but I hope it make sense to someone. Anyway, at least having a 60i input and 60i output will keep the motion looking the same - that part at least is "easy". The problem is it contradicts the sharpness goal somewhat: whenever I see really sharp SD, it's progressive (25p in the UK). Interlaced SD never seems to look quite as sharp. Cheers, David. |
||
6th July 2008, 01:43 | #39 | Link |
Registered User
Join Date: Mar 2004
Posts: 889
|
Sorry that my english is not good. Perhaps, when the shift adjustment is wrong, the two fields are misplaced. Hence, it makes the wire looking "broken" on computer monitor and the video looking "fuzzy" on CRT TV.
MVBob -> Separatefields -> Weave: Bob(0, 0.5, 480) -> Separatefields -> Weave: Separatefields -> Spline36Resize (with shift adjustment) -> Weave: Last edited by henryho_hk; 6th July 2008 at 09:57. Reason: The 3rd image is corrected. |
6th July 2008, 06:35 | #40 | Link |
Avisynth Developer
Join Date: Jan 2003
Location: Melbourne, Australia
Posts: 3,167
|
@henryho_hk,
Your last image looks like you had the 2 red statements reversed. Code:
Global NewHeight=480 Global NewWidth=720 AssumeTFF() SeparateFields() Shift=(Height()/Float(NewHeight/2)-1.0)*0.25 Tf=SelectEven().LanczosResize(NewWidth, NewHeight/2, 0, -Shift, Width(), Height()) Bf=SelectOdd().LanczosResize(NewWidth, NewHeight/2, 0, Shift, Width(), Height()) Interleave(Tf, Bf) Weave() |
Thread Tools | Search this Thread |
Display Modes | |
|
|