RePal and Anime. A suggestion for the development of this filter.Is Back still here?

[Pentajet]

I understand absolutely nothing on compiling and that sort of stuff and I don't have enough time to learn - otherwise I would do this myself. But I noticed a defect in RePal and it would be cool if someone who has the know how could fix it.

OK so RePal converts back to PAL, NTSC material that was once already PAL and has been coverted by creating 12 fields A AB B BC C C CD D DE E EF EF from 5 frames ABCDE (F being the A frame of the next sequence). It does so by looking for the "C" frame and it works WONDERS iff A B C D & E are ALL different from each other as is the case during pans and zooms in Anime.

But normally in Anime in any other scene other then pans and zooms there are DUPLICATE FRAMES. So that rather than five distinct frames the very original PAL version has a set such as A A B B C which results in the twelve NTSC fields being A A A AB B B B B BC C C C. This makes it really difficult for the filter to find the anchor (in fact during such scenes the filter fails and constructs frames from field like AB or BC above which should have been discarded resulting in ghosting during static scenes).

Now there are 30 possible combinations for duplicate frames (assuming that stuff like A A B A A does not happen in anime). Can someone update this filter to take into account the other 29 instances rather than just the case "all frames different"?

THANKS

[Mug Funky]

hmm. it'd be interesting, but there's so many exceptions to any rules we can come up with that i think another approach entirely would be needed.

for example, in filmed animation (and in fact the CG'd stuff as well), it's common practice to shoot off 2 frames for every animation cel - giving the AABBCCDD pattern you refer to.

it's also common practice when compositing 2 of the above elements to offset them by 1 frame, returning us to the ABCD pattern. things get messier when some scenes (of less important objects) are shot 3 or 4 frames for each cel. you'll have all kinds of patterns coming up.

clouded came very close to a good solution, and restore24 does quite well too, but the best solution (if it's possible) is to just grab the title in its original format. there's not much out there that's native PAL progressive (i can think of 2 offhand) - usually it's the other way round.

[edit]

try this:

function PALunblend (clip c)
{
c.tdeint(1,1,mtnmode=1,expand=4,tryweave=true,cthresh=8,mi=12,type=2).vinverse()#,edeint=Interp).vinverse()
global clippidoo=last
global edge=clippidoo.mt_edge(mode="prewitt",thy1=0,thy2=255,y=3,u=-128,v=-128).levels(0,.25,255,0,255,coring=false)
scriptclip(clippidoo,""" edge.averageluma() < edge.selectevery(1,-1).averageluma() && edge.averageluma() < edge.selectevery(1,1).averageluma() ? clippidoo.ydifferencefromprevious() > clippidoo.ydifferencetonext() ? clippidoo.selectevery(1,1) : clippidoo.selectevery(1,-1) : clippidoo """)
tdecimate(cycleR=7,cycle=12)
changefps(25)
}

tack that into the top of your script and put "palunblend()" at the bottom.

[Pentajet]

I tried that function and at first glance it works TERRIBLY WELL on scenes with repeated frames. I checked about 10mins of video and couldn;t find a single blend.

Unfortunately it fails on pans and zooms where all frames are different. RePal does much better on those scenes. So to summarize your function works on repeated frames (and repal doesn't) and repal works with no repeated frames (and your function doesn't). If only there was a way to choose between the two at the appropriate moment the result would be a perfect clip.......

[Mug Funky]

hehe... i don't know about mixing the two. it could be possible to do some motion-mask on the outputs of both repal and the above function, and choosing the one where the previous-to-current and current-to-next differences are closer together. i'm not sure it's a good solution, but i haven't dealt with this material enough to say for sure (i usually make stuff like that rather than undo it). to be honest i just very quickly adapted my NTSC->PAL unblending script to different framerates and posted it without testing.

i've got it to work reasonably well with NTSC to PAL stuff, but i have limited use for it so it's not too refined.