Need help restoring progressive frames to anime

[Melanchthon]

I'm trying to restore this anime to progressive frames (or close enough) at 23.97 / 24fps, but I don't know what I should be doing with it. I know Trigun is a difficult source, but I took that as an opportunity to play with some unfamiliar functions. I've tried CDeBlend and Restore24, neither of which have worked for me. I don't know whether this is due to my inability to configure the filters (I don't understand the threads or the parameters for the functions, and I still don't know how to use the functions themselves-- this is way over my head) or due to their unsuitability for the source, but the best results I've gotten have been from TDeint followed by Unblend. This leaves some blends during motion, but almost all the blended frames are comprised of the clean frames around them. Since the blends themselves are pretty random (sometimes a clean mix, sometimes little more than a shadow) and caused by prior processing, I have no idea how to deal with them.

Tdeint configured as follows: Tdeint(mode=2,order=-1,field=1,mthreshL=9,mthreshc=2,type=1,mtnmode=1,link=0)
Unblend is at default settings.

This was done before I was fully aware of the source's problems, and since I wasn't able to find any kind of pattern to the non-clean frames I just deinterlaced the whole thing. Now I'd like to deal with it properly, but I don't know what script will be most effective.

Vob sample 1: http://www.yousendit.com/transfer.php?action=download&ufid=A2CF3B7C53820936

Apologies for the (clothed) breast-grabbing; it's the most action there is in the vob I have to hand. A sample field. (http://img49.imageshack.us/img49/1373/crappyfieldjb9.png)

Vob sample 2: http://www.yousendit.com/transfer.php?action=download&ufid=AFA361BA6CB6F00A

This is a typical pan, and jerky even on a TV screen. What process causes it, and is there anything that can be done about the jerkiness or the blending?

Vob sample 3: http://www.yousendit.com/transfer.php?action=download&ufid=6E39CC6405A53579

I took this one as an example of the wacky blending/interlacing.

Edited to correct links in OP.

[Pookie]

You're out of luck on that one. You can do a few things to reduce the damage, but it isn't going to go away :(

Here's the original - see the macroblocking ?

http://fileserver1.jpghosting.com/images/tn_Frame38-blue_476a0b949971752f34219ef10a7d7887.png (http://fileserver1.jpghosting.com/images/Frame38-blue_476a0b949971752f34219ef10a7d7887.png)

Here's the same frame deblocked - you can do a better job on it yourself. Look up deblocking scripts, or read the DGdecode documentation.

http://fileserver1.jpghosting.com/images/tn_Frame38-cpu4_11b602d991b34ff38d9ede11f7ccc844.png (http://fileserver1.jpghosting.com/images/Frame38-cpu4_11b602d991b34ff38d9ede11f7ccc844.png)

You can get to 23.976 with something like the following: (Needs TIVTC , EEDI2 , TDEINT)

interp = separatefields().selecteven().EEDI2(field=1)
deinted=tdeint(edeint=interp,order=1,field=1)
TFM(mode=1,order=1,clip2=deinted)
TDecimate(mode=1,denoise=true)

You'll still see the blends, however.

[Your_Idol]

sorry i can't see your pics Pookie

I have some amime like this too and i am completely puzzeled as to why when the fields are seperated, there are some fields that are still blured?

[Awatef]

This is inherent with the telecine process used. There are telecine types that produce blending and/or shifting within fields.
I guess you're working on the R1 DVDs, you may want to get the R3 ones instead. I *HEARD* that those have a proper telecine and no cross coloration.

[Guest]

Field blending is not "inherent to telecining". It is the result of applying a standards conversion, such as PAL->NTSC or vice versa. It also sometimes results from doing silly things like deinterlacing 3:2 content.

[Awatef]

He's not using a PAL source, so there shouldn't be a standards conversion problem.
I wasn't talking about telecine generally. I said, SOME telecine techniques use blending and/or shifting to transfer from 24p Film to 60i NTSC tape (similiar artefacts to standards conversions).
Many animes were treated this way. I mention "Ranma 1/2" for example, the NTSC transfer is a piece of ****, where the AB french PAL transfer is perfectly progressive, but the german PAL transfer was done from the NTSC transfer, so it is the crappiest with lots lots of artefacts.

[Guest]

@Awatef

No profanity please. This is a high class forum. Thank you.

[Melanchthon]

Yeah, the blocking is awful (when it appears, which is thankfully rare), but I'm alright with image-cleaning scripts. It's just restoring the clean frames that's the trouble.

You can get to 23.976 with something like the following: (Needs TIVTC , EEDI2 , TDEINT)

interp = separatefields().selecteven().EEDI2(field=1)
deinted=tdeint(edeint=interp,order=1,field=1)
TFM(mode=1,order=1,clip2=deinted)
TDecimate(mode=1,denoise=true)

You'll still see the blends, however.
I tried that, and I prefer the results from Tdeint followed by TDecimate (less combing). I'll see if I can tweak it any, as I haven't used EEDI2 or TFM before.

How were the R3 DVDs produced? I'm a little wary of buying Trigun DVDs now, as I thought the new releases were completely new instead of I-don't-know-what-the-heck-they-did plus a load of edge enhancement. Oh well, at least the tins are nice. :rolleyes: The blending is similar to Evangelion's original release, which I know has been discussed here, but I can't seem to find the topics on it.

Quick question: if the blending comes from the film--> NTSC conversion, why is it interlaced as well? The discs are NTSC (yup, they are the R1s).

[Awatef]

Well, NTSC *is* an interlaced standard, so it is normal that the signal gets interlaced after the telecine.
The problem with the Trigun R1 DVDs is that they were not telecined the traditional way, say "3:2 pulldown" where the fields just get duplicated after a given pattern.
They used another telecine type that uses motion blur algorithms and this produces a whole new video that has little to do with the original video, say an "in-depth" work, if you understand what I mean ;)
Obviously the R3 DVDs were encoded from a different source, which had a regular 3:2 pulldown.
Here I want to quote on Evangelion, which was telecined the bad way back in the days. The newer remastered DVDs have a proper telecine, so there is no blending and such anymore, they're 100% clean ;)

[Melanchthon]

They used another telecine type that uses motion blur algorithms and this produces a whole new video that has little to do with the original video, say an "in-depth" work, if you understand what I mean ;)
I noticed that frames hung around for a while after scene changes. I'll have to keep an eye out for the R3s, although I'm really not keen on rebuying another anime series.

I think I might be onto something with the following script:

leakkernelbob(order=1)
blendbob(show=false,pnthresh=0.1,diffbias=-0.2)
unblend(threshold=1,dthresh=0)
tdecimate(mode=1,denoise=true)

Needs tweaking maybe and is not kind to pans (the one I linked above especially), but it leaves about two badly-blended frames in the first sample and a couple more of the barely-noticeable 'echoey' blends.

[foxyshadis]

Since anime releases are usually so low budget, they usually used prism telecines up until digital telecines got dirt cheap. Prisms are ok for movies, but chew up low framerate animation with all that blending. Any old series stands a good chance of looking like that, most of the laserdisc captures I've seen do. PAL speedups are nice, but not when they try some funky mocomp that destroys the animation.

It's too bad you can't demand your money back from the production company!

[Awatef]

Melanchton, I know how you feel, but if you're looking for quality, that may be your only option. May be you could try selling your R1s on eBay, that way you won't feel thaat bad :)
And as foxy said, it's unfortunate that you can't get your money back for poorly encoded DVDs, especially those Anime-DVDs that cost at least 20 bucks each with little over an hour content, I think one is in the right to expect great quality for the price :sly:

[MOmonster]

Yes, if you find a better version, take this.
To the blending problem:
Cdeblend works imo (with your small samples better than unblend). Omode=3 clears nearly all blends, but gives a bad motion. Your small samples were 12fps scenes, so no problem here. But generally I advice omode=2 with tdecimate:
leakkernelbob(order=1,sharp=false,twoway=true,threshold=2)
Cdeblend(omode=2, clip2=last.bilinearresize(352,288))
tdecimate(mode=7,rate=24)

Omode 0 and 1 give maybe better motion, but don´t clear the blends so good.
I don´t know if the small samples are from the same source and they were to short to find the real framerate (22.976 - 24 - 25), but the samples have a different field order.

[Melanchthon]

Sorry for the slightly late reply...

leakkernelbob(order=1,sharp=false,twoway=true,threshold=2)
Cdeblend(omode=2, clip2=last.bilinearresize(352,288))
tdecimate(mode=7,rate=24)

Omode 0 and 1 give maybe better motion, but don´t clear the blends so good.
Ah, so _that's_ how you get it working. I couldn't figure it out from the 1.0 readme (the phrase "progressive (bobbed) source" had me scratching my head). Omode 2 produces footage that's not noticeably more jerky than the original, and it works across the whole episode. The exception is a slow vertical pan over a still with lots of near-horizontal lines, but I think that part would be impossible to recover anyway. It also produces footage with a lot of stairstepping (pic (http://img333.imageshack.us/img333/9558/jaggiesgy0.png)), but AAA() deals with that very nicely (pic (http://img108.imageshack.us/img108/4426/jaggiesgonerx8.png)). The only problem is that AAA is very, very slow, taking the encoding rate down from ~15fps to ~0.2fps. TIsophote is a lot faster, but I don't think it's sutable for the source. The settings that remove the stairstepping also soften the picture a little and take a couple of pixels off the ends of lines (pic of default settings (http://img454.imageshack.us/img454/2627/jaggiestisophoteox6.png)). Those are the only two filters I know of for this kind of thing -- any more suggestions?

I don´t know if the small samples are from the same source and they were to short to find the real framerate (22.976 - 24 - 25), but the samples have a different field order.
The samples were from the same chapter of the DVD, and I rechecked the scenes using AssumeTFF and SeparateFields and they all seem to be TFF. What were you using to check the order? Either way, I can post some longer samples if you like. How many frames would you want?

[foxyshadis]

For antialiasing I usually use EEDI2.BicubicResize(Width,Height). It's fairly slow, but faster than that. You may be better off using TIsophote with Soothe, perhaps.

Don't ever use Sangnom - it's the equivalent of SeparateFields.SelectEven.EEDI2, though its edge interpolation is only as good as TDeint's.

Pretty show, btw! =D

[Melanchthon]

For antialiasing I usually use EEDI2.BicubicResize(Width,Height). It's fairly slow, but faster than that. You may be better off using TIsophote with Soothe, perhaps.
Heck, I tried them both together. TIsophote / Soothe didn't have much of an effect, so I just went with EEDI2.

Don't ever use Sangnom - it's the equivalent of SeparateFields.SelectEven.EEDI2, though its edge interpolation is only as good as TDeint's.
*tries that chain* Yuck. Whatever AAA does with it seems to work great, although the minor differences between it and EEDI2 / resize aren't enough to justify the speed hit (now there's something I never thought I'd say...).

Pretty show, btw! =D
The visual quality is quite nice if you can cut through the noise and general grime and you don't hit one of the badly-blended frames, and I like the look of cel anime anyway. I'm almost where I want to be with the visual quality (http://img147.imageshack.us/my.php?image=jaggiesfullscriptae5.png), but I'm still looking for a denoiser that'll target the source's distinctive noise and spare the details (note the grass around the base of the tree).

I think that's the best decomb / deblend I'm going to get out of these DVDs without manually removing offending frames, which is kind of a pity. I wonder how long it'll be before Geneon go the Evangelion route and make a proper job of mastering and encoding Trigun.

[MOmonster]

You don´t have to use leakernelbob. If another bobber (tdeint(mode1)) works better for you than use this one.
The fieldorder I get with the bobbing. With order=1 I think the second sample run fluid and the first shows stuttering, with order=0 of course the opposite way. Maybe I´m just mistaken, but if I´m right, it is important to do something against.
Just a longer sample (>10s) could help. I don´t have all the time an inet connection, so the next report will take some time.

[Melanchthon]

Link to a longer sample:
http://rapidshare.de/files/27023860/clip_2b_general2.vob.html

I couldn't figure out how to get rid of the sound, sorry. I usually rip only the video stream.

[MOmonster]

Sorry that I let you wait.
Indeed your source have big fieldorder problems.
Function repair_ff(clip "tff", clip "bff", float "mthresh", float "thresh", bool "booldup", bool "booltff", bool "halfrate", bool "sd")
{
###### PARAMETERS ######
global tff = tff
global bff = bff

global booltff = default(booltff, true)
global mmotion = default(mthresh, 0.3)
global squared = default(sd, false)
global proc = default(thresh, 0.12) + 1.0
global booldup = default(booldup, false)

hmode = default(halfrate, false)
rate = framerate(tff)

###### lut strings ######
global ystring = "x y - 2 ^"
global ustring = "x"
global vstring = "x"

###### VAR.. ######
global tffdiffc = 1.0
global tffdiffn = 1.0
global bffdiffc = 1.0
global bffdiffn = 1.0
global vdup = 0

###### Conditional Function Chain, evaluated from bottom to top (!) ######
g99=scriptclip(tff, " booltff==true ? (vdup==2 ? tff.trim(1,0) : tff) : (vdup==2 ? bff.trim(1,0) : bff)")

g2=FrameEvaluate(g99, " booltff = fi_diff<fr_diff*proc || fi_diff<mmotion || current_frame%2==1 || vdup==1 ? booltff : (booltff==true ? false : true)
vdup = fi_diff>fr_diff*proc && fi_diff>mmotion && current_frame%2==1 && vdup!=2 ? 1 :
\ (vdup==1 || (booldup==true && fi_diff>fr_diff*proc && fi_diff>mmotion && current_frame%2==0) ? 2 : 0)")

g1=FrameEvaluate(g2, " fi_diff = squared==false ? ( booltff==true ? YDifferenceToNEXT(tff.duplicateframe(0)) : YDifferenceToNext(bff.duplicateframe(0)) ) :
\ ( booltff==true ? AverageLuma(mt_lutxy(tff.duplicateframe(0), tff, yexpr=ystring, uexpr=ustring, vexpr=vstring)) :
\ AverageLuma(mt_lutxy(bff.duplicateframe(0), bff, yexpr=ystring, uexpr=ustring, vexpr=vstring)) )
fr_diff = squared==false ? ( booltff==true ? LumaDifference(tff.duplicateframe(0),tff.trim(1,0)) : LumaDifference(bff.duplicateframe(0),bff.trim(1,0)) ) :
\ ( booltff==true ? AverageLuma(mt_lutxy(tff.duplicateframe(0), tff.trim(1,0), yexpr=ystring, uexpr=ustring, vexpr=vstring)) :
\ AverageLuma(mt_lutxy(bff.duplicateframe(0), bff.trim(1,0), yexpr=ystring, uexpr=ustring, vexpr=vstring)) ) ")

recl = hmode==true ? g1.changefps(rate*0.5) : g1.changefps(rate*2).changefps(rate,linear=true)
return(recl.addborders(8,0,0,0).crop(8,0,-0,-0))
}
This function handles the most of these problems. This function is not created for fieldblended sources, but Cdeblend can still clear the most blends.
This is the full script I used for your sample:
a = last.tdeint(order=0,mode=1)
b = last.tdeint(order=1,mode=1)

repair_ff(a,b, booldup=true)

Cdeblend(omode=1, dthresh=70, clip2=last.crop(8,8,-8,-8).bilinearresize(352,288))
tdecimate(mode=7,rate=23.976)


#### enhancement ####

DeHalo_alpha(rx=2.5,ry=2.5,lowsens=80,darkstr=0.5)
mergechroma(blur(1))
LimitedSharpenFaster(strength=36, radius=2)
aWarpSharp(depth=10,cm=1)
FRFun7(Lambda=1.2,T=3.3,Tuv=1.5)


#### layout ####

LanczosResize(652,488)
Crop(8,4,-4,-4)
Removegrain(1)
It is really slow but it performs good in my opinion. Leakkernelbob + AA or something similar is maybe faster and will also look good. A antialiasing and omode=2 instead 0 or 1 you should test so or so.
Hope this helps.

[JMP]

Looks much like a problem that I have... I have a case of an animation show, apparently after a 24fps->NTSC->PAL conversion. Bobbing it reveals, that about half of the fields are actually blends.

Up till now I handled it by bobbing, apllying Removeblend(), then reweaving (to get rid of bob artefacts from frames, that contained no blends) and Teleciding the result. Worked well, leaving very few blends in, but resulted sometimes in losing frames. This because RemoveBlend() replaces the blend always with the frame, that it thinks has more weight in the blend. Thus, say a sequence (+ means blend)
a a+b b b+c c
often gets replaced with
a b b b c
and the following Telecide loses frame "a" completely and replaces it with a duplicate of "b"

Now, I got all exctied by CDeblend, because with omode 0 or 1 I could avoid the problem. However I somehow can't get CDeblend to detect and remove blends as efficiently, as RemoveBlend does. I tried to tweak the parameters, but it generally only worsened the result. Do you have any suggestions how could I improve CDeblend's efficiency?

My material is, as I said, an animation show, comes from a DVB recording (thus is not noisy, but some blockiness is sometimes visible).

Thanks, JMP

[Melanchthon]

Sorry that I let you wait.
Indeed your source have big fieldorder problems.

[code snipped]

This function handles the most of these problems. This function is not created for fieldblended sources, but Cdeblend can still clear the most blends.
This is the full script I used for your sample:

[code snipped]

It is really slow but it performs good in my opinion. Leakkernelbob + AA or something similar is maybe faster and will also look good. A antialiasing and omode=2 instead 0 or 1 you should test so or so.
Hope this helps.
Oh, it was worth waiting for. It clears the major blends (such as those in the very first sample I posted) really well, and the motion is good as well. I've settled on EEDI2().BicubicResize(720,480) for the anti-aliasing, and while I don't see much difference between the modes I think it's better in theory to keep the replacements consistent. TDeint(mode=1) is still my choice for bobbing here. I don't know why it produces so few bothersome little artifacts, but it works nicely.

What does that repair_ff do? Compare fields (or frames) against each other to swap the field order as necessary? I really can't read a function like that.

As for the filtering... I have an idea, but I don't knom what to do with it. The noise on the lighter parts of the picture is stronger than some of the details on the darker parts of the picture, so I was thinking of using the clip itself as a mask and nuking the noise that way. YLevelsG(32,0.5,255,0,255) seems a good place to start, but I don't know the most efficient way of applying it.

I've tried all of the filters in your cleanup script except MergeChroma (which I didn't know about previously but have now added, as it helps with the red 'beading' on lines -- thanks), and I eventually skipped the other denoisers in favour of RemoveNoiseMC's lq_filter... which kept details very well but still couldn't handle the noise in the sky. I'd like to stress that I wouldn't be this heavy-handed with most sources, but Trigun is pure cel anime and it's nice and flat under all that noise. Plus, I'm new to AviSynth, so any excuse to learn new filters and stuff is fine by me.

[MOmonster]

Repair_ff outputs the fluid more fluid input stream (tff or bff). I have added the function that single "fall back fields" are replaced with dups, because your source has not only fieldorder problems but also these single fall backs.
You can limit a denoising to a pixelvalue-range for example with mt_lutxy:
denoised = last.denoiser() (removegrain, hqdn3d ...)
mt_lutxy(last, denoised, yexpr="x 160 < x 230 > | x y ?", uexpr="x", vexpr="x")

The denoiser is this way only applied for pixelvalues between 160 and 230.

@jmp
Could you please upload a small sample. I will need some time till I can download and look at it, but I can´t give you any advice without looking at the source.
Indeed it sounds like a standard conversion so you can try restore24 and Mrestore. If these work there is no need for Cdeblend (should be only used if the other two solutions don´t work).

[JMP]

Hi MOmonster, thank you for your offer, but I think I found out :). At first, after reading the instructions, I thought I'd better use high dmode (as I have classic animation source). It however turned out, that dmode>0 performs poorly on my material, whereas dmode=0 works almost perfectly, leaving only very few blends, and killing practically all the worst ones (i.e. those that are close to 50/50 between frames with much movement). With omode=0, subsequent reweave and telecide kill practically all the remaining blends, while still keeping 21-22 frames out of each 24 (in true 24 fps parts of the clip) - this is better than what I was getting with RemoveBlend, and probably as good as possible to get with this source
:thanks:
JMP