Delete Every 5th or 6th frame, no pattern

[johnmeyer]

I need to remove duplicate frames. (Discussion on my project is here: http://forum.doom9.org/showthread.php?t=106837).

Problem is that they don't follow a regular pattern. They are always every fifth or every sixth frame, but there is no regularity as to which of those two they will be. Fortunately they are easy to detect (because of the nature of the source of my video) using YDifferenceFromPrevious() or LumaDifference(a,b) or almost any other function. In pseudo code, what I need to do is basically this:

clip = ( "LumaDifference(a,b)" < "0.1" ) ? DeleteFrame(a) : a

It would be even better if I could add pattern guidance (i.e., ignore next four frames after a deletion), but I'd be pretty happy right now if I could simply figure out how to delete a frame whenever this condition is true.

I realize that AVISynth conditionals require that the frame count be unchanged. I've searched this forum and elsewhere, and have looked at Stickboy's functions, which may be able to help. I've read the scripts that use MVTools to interpolate the duplicate frame, but I'd much rather remove it and reduce the framecount (this is for silent films, and even for sound films, I have a whole 'nother plan about how to handle the sound).

Any hints, clues, or ideas would be greatly appreciated. Thanks!

P.S. I read this thread: http://forum.doom9.org/showthread.php?t=106108&highlight=delete, so I think I know the answer about actually deleting a frame, but I thought I'd ask anyway. Also, is there a way to perhaps, instead of deleting the frame directly, perhaps a way to vary the Decimate cycle?

[Guest]

Try MultiDecimate() in its Global: Naive mode. Of course, you'll remove static scenes. To avoid that, try Global: Protect Static Scenes.

http://neuron2.net/multidecimate/multidecimate.html

[Zep]

Try MultiDecimate() in its Global: Naive mode. Of course, you'll remove static scenes. To avoid that, try Global: Protect Static Scenes.

http://neuron2.net/multidecimate/multidecimate.html


DG your multi MultiDecimate() works very well in these cases
and even the harder cases as we found out last year on that
wacky 5-5-7-7-2 pattern last year :D

[johnmeyer]

Thanks for the idea. I played around with Multidecimate a few days ago. At your suggestion, I went back and tried again. The problem is that it does a very poor job, for some reason, at detecting duplicates. I don't know why this is, because -- due to the nature of the input video (as described in the post I linked to earlier) the duplicates are extremely obvious. The metrics file it creates contains a bunch of numbers that don't show the obvious duplicates. You can see this below where the MultiDecimate numbers are in the first column, and the results from my very simple AVISynth script compare function are on the right. I used Multidecimate at the same point in my script where I had my own compare function, so it should have been looking at the same video.

Frame MultiDec MyFunction
602 2.02382 0.000003
603 2.519851 6.222512
604 2.168259 3.787949
605 1.180542 4.031979
606 1.715744 4.471725
607 1.90286 7.669187
608 5.099297 0.000003
609 5.227183 5.723142
610 11.151471 5.424387
611 10.659882 4.634873
612 1.97229 5.586189
613 5.279505 0.000003
614 5.563361 6.107726
615 2.218376 4.283788
616 1.294556 4.026997
617 1.667588 3.517095
618 1.49665 4.344997
619 1.935511 0.000003
620 2.09891 3.706016


However, the idea of writing my metrics to a file in one pass and then using this file to read and then write frames in the second pass is the way I have started to proceed. The problem I'm now having is that I can't get the following simple lines to work. It keeps telling me that y1 is not defined. I have tried dozens of variations, but I'm not getting anywhere.

z=FrameEvaluate(a, (y1 < 1) ? WriteFile(a,filename,"current_frame") : WriteFile(a,filename,"msg") )
x=FrameEvaluate(a, "global y1=Lumadifference(a,b)")


It doesn't matter which of these lines is first; I get the same error.

AVISynth has seemed very straightforward until this project. Hopefully I'll get my head around this whole conditional thing and be able to finish.

Thanks again for your help.

[johnmeyer]

OK, I got the the Write file function to work. I can now create a text file that includes a zero (0) next to each frame number I want to eliminate, using the following code:

j=FrameEvaluate(a,"""var1=(LumaDifference(a,b)> 1) ? 1 : 0""" )
ScriptClip(j, "Subtitle(String(var1 ))")
WriteFile(j,filename,"current_frame","sep","var1")

I don't know why I need the ScriptClip function between the FrameEvaluate and the WriteFile, but it didn't work until I stumbled on that sequence of code. Usually once I get it working, I can see why it didn't work before, but for the life of me I don't see the need for the ScriptClip.

Anyway, after I got it working I was next (stupidly) trying to figure out how to create a script that would read this back in somehow, and pass through only those frames that had non-zero numbers next to them. Fortunately, before I spent too much time on that exercise, I came back and re-read your suggestion on your MultiDecimate plugin and I realized that its 2nd pass facility is exactly what I need.

So, tomorrow, when my head is clear, I'll clean up my code, make sure I create a "mfile.txt" text file that is exactly the syntax needed by MultiDecimate, and I may just be home free. In addition, I can actually do cadence "guidance" using a simple Excel spreadsheet function. A little bit of a kludge, but I've only got about 50 cans of film to do at this point, and I think the workflow won't be too bad.

I finally feel like I'm turning the corner on this one ...

[Wilbert]

It keeps telling me that y1 is not defined.
You have to initialize y1 at the beginning of your script:

global y1=0
...

Could you post your full script?

[colinb]

This looks like a really interesting project. If you get a final solution I'd be very interested to see a complete summary of it.

I too have some 8mm file that I would like to telecine one day. But I think my current camcorder may not be suitable as you can't set the shutter speed explicitly so it would probably change with the brightness of the projected image.

[johnmeyer]

Thanks for the global initialization hint. I actually was able to find that in a post from long ago, just before you posted. That indeed was the solution.

I'll post the script in a few days when it's finished. It's pretty darn ugly right now (although not very long).

I'm glad some of you find this interesting. I'm actually looking into applying for a patent on the process. The way it works is unique (I've already done some research) and while none of the individual elements is a completely new discovery, the whole package is definitely quite new.

As to your camcorder, you might be surprised about the shutter speed setting. Most cameras, even those on the low end, can set the shutter speed, although usually not explicitly. My old consumer Sony DV camera, for instance, has settings for Sports, Spotlight, Sunset, etc. I was able to find a site online that described what these actually do, and some of them either fix the shutter speed or else put the camera into "shutter-preferred" mode where the shutter speed is set high, and then the aperture is varied. As long as the picture from the projector is bright, the shutter speed will be set high.

As I stated in the original post, the camera shutter has to be really short for this technique to work. The film is stationary in the gate for exactly 1/24 of a second MINUS the time it takes to pulldown. The pulldown time can be estimated VERY precisely by measuring the diameter of the entire shutter blade assembly, calculating its circumference, measuring the width of an individual shutter blade (mine has three blades), and finally subtracting the distance shutter travels from when the film actually stops (you have to watch the claw while moving the shutter by hand), and when the shutter completely uncovers the gate. On my projector, this comes out to 12.8% of the 1/24 of the second. Thus, the film is stationary for 87.2% of 1/24 which comes to 0.036333. If the video camera could take pictures at infinitely high shutter speed, it can take two fields (one frame) exactly 1/(2 * 29.97) seconds apart or 0.0166833 seconds. However, the camera is not synced to the projector, so it is possible that the video camera takes a field of video just before the film comes to rest. Thus, the next field will be taken just under 0.0166833 second later, and you still need to get the second field 0.0166833 seconds after that. So, the film ACTUALLY has to be stationary for the full 1/29.97 second, or 0.0333666.

Finally, since the camera DOES have a finite shutter speed, that has to be added, TWICE (once for the field that might be taken just before the film comes to rest, and once for the last field which must be completely snapped before the film starts moving again). You can calculate the minimum shutter speed needed by subtracting 0.0333666 from the film dwell time of 0.036333. This is 0.0029664. Taking the reciprocal yields the minimum TOTAL required shutter speed of 1/337 second. Since this is twice the shutter speed, the actual shutter speed must be 1/674 or faster.

You obviously want a slightly faster shutter, in case the projector runs fast or the shutter blade measurements weren't perfectly accurate. However, it actually makes the IVTC software "happier" to have more blur during the pulldown (causes a HUGE mismatch vector), so you don't want to set the shutter any faster than needed. On my semi-pro FX1 HDV camera, I can set it to 1/750.

BTW, I couldn't get to sleep last night without trying the MultiDecimate read of the file I created. Works like a charm. The only thing left to do is to perfect the Excel "pulldown guidance" algorithms. I may finally have to resort to writing a little VB code to do this, although the simple Excel approach handled all but a few pathological cases (not likely to occur with normal film segments -- I had silent film title cards in my test that were all black except for a few white letters -- nasty).