Automatically take screen shots based on low res source?

[Lyris]

Not sure if that's the quickest explanation.

Basically I have an HD source and I've been sent low-res JPEG screen grabs that were derived from an MPEG-1 compressed screener copy.

I need to match the low-res screen grabs and send back high quality images from the HD source.

Is there any way to automate this process with AVISynth? Or with any other tool? That is, feed the computer a still image and have it search through the file for a similar frame?

[Gavino]

My FindFrame function from this post, or something based on it, might help.

[Lyris]

Thanks Gavino, that looks exactly like what I need - and it does work perfectly when I'm having it match frames against the source. Sadly it waits for a bit then crashes VirtualDub in real-world usage (i.e. when it's fed the JPEG still as a source).

[Gavino]

I expect it's not finding a match, and running out of memory as it recursively searches through all the remaining frames in the clip. Since you're comparing against a low-res copy, you probably need to increase the threshold for declaring a match (although of course this risks getting false positives).

Here is a revised version replacing the recursion with a GScript loop (which didn't exist when I wrote the original function).
# given a clip 'c' and a (potentially one-frame) clip 'f',
# show 'c' starting at frame matching (1st frame of) 'f'.
function findFrame(clip c, clip f, int "thresh") {
thresh = Default(thresh, 2) # threshold for declaring match
f = f.Loop(c.FrameCount, 0, 0)
current_frame = 0
GScript("""
while (current_frame < c.FrameCount-1 && LumaDifference(c, f) > thresh) {
current_frame = current_frame+1
}
""")
return c.Trim(current_frame, 0)
}
It eliminates the memory problem, but is still relatively slow if it has to search thousands of frames. Hence if you know roughly the area in which to search, it would be best to trim the input clip accordingly.

[StainlessS]

Below a mod of Gavino's FindFrame, advantages:-

Deals with a clip of frames to find rather than a single frame.
Can find best match or 1st match below or equal to a threshold.
Float Threshold.
Can show StackHorizontal required 'find' frame alongside source clip 'found' frames.
Can output a command file consisting of frame numbers found.
Command file can be used with FrameSelect() Plugin to select all found frames (useful if viewing StackHorizontal frames without 2nd SLOW run for extraction).

Here it is:-

EDIT: CODE REMOVED, SEE This THREAD:
http://forum.doom9.org/showthread.php?t=164766

[Gavino]

Nice work, StainlessS. :)

One observation on the code:
current_frame = BestSoFar
wrClip=(FileName=="") ? c : c.WriteFile(FileName,"current_frame",append=Append,flush=true)
Append=True
wrClip=wrClip.Trim(BestSoFar,-1)
The assignment to current_frame here has no effect, since the current_frame used in the WriteFile execution will be the value at run-time - fortunately, this has the right value (BestSoFar) because of the subsequent Trim.
You could also instead use
c.WriteFileStart(FileName,"BestSoFar",append=Append,flush=true)
which would be executed at compile-time and allow you to monitor the progress of the slooooow first pass.

[StainlessS]

Thanks Gavino, Had already twigged the superfluous assignment to current_frame (on the
way back from the shops about 15 mins ago), came on-line to amend.
Shall check out the other suggestion and then amend in a few moments.

[StainlessS]

You could also instead use
c.WriteFileStart(FileName,"BestSoFar",append=Append,flush=true)
which would be executed at compile-time and allow you to monitor the progress of the slooooow first pass.

Tried the above.
First time run in VDMod, hung after completion with blank screen.
Subsequent runs went OK but seemed to be no different to
the WriteFile version. As WriteFileStart has no 'flush=true' arg,
think I shall retain as is, unless you can figure out what the
problem might be (also have not experienced any hang with orig code).
Also tried in Media Player Classic (HT), same thing, only displayed on scan completion.

Modded output filename to MatchFramesCmd.txt, ie added 'Cmd' to the name.

EDIT: "monitor the progress", I took it you meant see frames displayed? The MatchFramesCmd.txt
file can be accessed during scanning to monitor progress using WriteFile (flush=true).

EDIT: The VDMod hang was I believe down to my over protective Anti-malware.

[Gavino]

Tried the above.
First time run in VDMod, hung after completion with blank screen.
Subsequent runs went OK but seemed to be no different to
the WriteFile version. As WriteFileStart has no 'flush=true' arg,
think I shall retain as is, unless you can figure out what the
problem might be (also have not experienced any hang with orig code).
Also tried in Media Player Classic (HT), same thing, only displayed on scan completion.
Odd, it works fine for me. Tried in both AvsP and MPC.
Nothing wrong with your original code, but using WriteFileStart has the slight advantage that it writes immediately, so you can see the file building up and look to see how far it has got - you don't even need to render the output clip. (Sorry I forgot it has no flush arg, it always opens and closes the file on each write anyway.)

Just seen your edit:
EDIT: "monitor the progress", I took it you meant see frames displayed? The MatchFramesCmd.txt
file can be accessed during scanning to monitor progress using WriteFile (flush=true).
No, I just meant looking at the text file.
But using WriteFile, nothing is written during the first (ie compile-time) pass, even with flush=true.
The rendering (normal run-time) pass is relatively fast, as it's just selecting the frames already determined during the (very slow) first pass, which is what does the actual searching and comparing.

[StainlessS]

On the 1st time hang, it also produced an empty script file in VDMod Editor, some kind of crash I guess.

EDIT: The VDMod hang was I believe down to my over protective Anti-malware.

nothing is written during the first (ie compile-time) pass, even with flush=true

EDIT: Damn, you're correct, must have executed the wrong version during what I thought was the
WriteFile tests (thats what happens when you have a half a dozen avs files all named nearly the same).
I'll try more playing with the WriteFileStart version, the reason for using "flush=true"
was intended to produce realtime monitoring of the progress.

EDITED:- SEE This THREAD:
http://forum.doom9.org/showthread.php?t=164766