Log in

View Full Version : Dust/Flaw Elimination using two copies of a source?


Karyudo
16th July 2004, 21:55
(this has been mostly reposted, separating it from the existing TooT thread.)

Thanks to E-male's recent work in this area, there are now some cool new tools that assume you have access to more than one copy of a source!

His TooT (Two out of Three) filter works great where you have three copies of the same source: two will be nearly identical, and it's clear the oddball to be ignored is the third. However, it's more common (not to mention cheaper) to have just two copies of a given source. For example, I have two copies of the "faces" THX LD of The Empire Strikes Back, which is already more than most people want to pay good money for!

Clearly, there is almost certainly enough *picture* data to create a clean copy from two flawed sources, but without a way to "inform" the filter, there's not enough *decision-making* data (with three sources, it's the redundancy that provides the decision-making data). Without any decision-making data, a filter can't choose which of the two copies is correct when it finds differences between them.

I've thought of some possible solutions:

1) a "control" clip that is only used to decide on differences between two clips; and/or
2) some temporal analysis to see which of two clips is more likely to be flawed; and/or
3) some spatial analysis to see which of two clips is more likely to be flawed.

In case (1), the control clip could be a lesser-quality capture (for example, a lower-quality capture from VHS used to compare two higher-quality LD captures), or a capture from a different release of the same material (for example, I have a copy of The Empire Strikes Back Special Edition that could help a filter decide on which of two "faces" captures is right at any given point).

In case (2), deriving some sort of numerical value for frames 1 and 3 (that is, nearly-identical frame 1's and frame 3's one frame before and after dissimilar frame 2's) might indicate whether frame 2a is more likely correct than frame 2b. For example, in a low-motion scene, if the values for frame 1 and 3 are 115 and 117 respectively, and the values calculated for frames 2a and 2b are 12 and 118, then it's more likely that picture data from frame 2b is a better choice than data from frame 2a. Some user-selectable threshold would be desirable, to reduce artifacts (like motion blur from temporal smoothers).

In case (3), comparing a pixel to the surrounding pixels in both sources may indicate which source is more likely correct. For example, if a pixel differs from its 8 nearest (spatial) neighbours by no more than 5 levels in one source, but differs by 100 levels in the other source, then the first source is likely the one to choose. Again, some user-selectable threshold would be desirable, to reduce artifacts.

In fact, just using the temporal and spatial techniques developed for other filters should probably be enough, because a lot of those filters are both trying to identify problems *and create data to fix them*. In the case of two flawed sources, the problem is merely to decide which of the two is more likely correct; no picture information needs to be created. As long as even a quick-and-dirty analysis is reasonably sound, the resulting picture should be perfect.

I'm trying to simulate (theoretically -- I'm no coder) a decision process that a person would use to decide between two frame candidates.

If you were to step through a pair of sources, knowing that it was equally likely that each was flawed at any given frame, then there would be some clues available to tell you which was the better choice:

1. If you had another copy -- even though it didn't match exactly -- you'd be able to see which of the two candidates looked more like the third copy. The more the flawed copy deviated, the easier it would be. And the less it deviated, the less it would matter! Of course, making the filter "see" the clip in a way that would let it approximate the decision-making process a person would use is the tough part (as underlined by E-male in the TooT thread).

2. If the frames before and after the candidate frames didn't have a flaw, you'd probably be able to see the flaw pop on for the one frame in question, and you'd know to keep the other frame candidate.

3. If there's junk flying around the frame anyway (like an explosion), then the size, shape, hardness and intensity of the flaw would give you information about whether it's a video problem, a film problem, or supposed to be there! For example, a black or white line of a dozen pixels or so, confined to a single horizontal line, is probably a dropout, and should be fixed.

I don't know how good just a Type 1 comparison of something like a whole-frame histogram would be in determining which source is right. A user-selected threshold value would probably be good. Because you're only ever replacing from a frame that *is* the same (except for the flaw), the control source shouldn't need to be colour-corrected or super-close on the alignment, etc.

At least, I hope not!

In fact, since most (all??) video flaws and most film flaws are primarily black or white, how about comparing monochrome histograms, with a heavy bias to the 0-54 and 200-255 range? I suspect that it would be fairly informative to look at these highly-specific histograms for decision-making. I mean, that's about what you're doing when you look at the frame yourself and note, "There's a black spot here," isn't it?

Two further details/abstractions might be possible:

- using two different sources (for example, from two different video transfers), eliminate dust, etc., included as part of the video on pre-recorded sources. Note that none of the analysis above can correct dust, etc., that's actually been recorded (as opposed to dropouts or rot) on a tape or LD!

That might be a bit of a magic bullet, and would definitely involve *a lot* of pre-processing, in order to get the sources to match closely enough for this sort of comparison. So perhaps a less-automated solution might be better?

- The Decomb package by Donald Graft (aka neuron2) allows dumping the field-matching results to a text file, and allows a user-created text file to override the field-matching process. In a similar way, a list of data from frames that differ between two versions (including the filter's selection) could be exported to the proposed comparison filter, and then this (hopefully short) list of frames could be reviewed by the user, to semi-automatically clean the video. An
imported text file could include rows with [frame_number, source] included (for example, "2354, a") that would tell the filter which of the input sources should be used. This would get a lot more complicated in the case of both frames being flawed, but in different parts of the picture.

Anyway, that's a lot of rambling on my part. It's what I do best; I have no coding ability...

kingmob
16th July 2004, 23:41
Maybe i'm completely missing what you want, but if you just average the clips with overlay, you reduce your theoretical Noise by SQRT(2) If they are identical besides the noise. This is the best you can get (and it's very good) with averaging.
E-Male's filter would imo only work better if one of your captures is severely more flawed than the others, and tbh i think still then it would be better to analyze the areas where the Standard deviation is about the same on al 3 and averaging those, thus improving those areas by SQRT(3).

So all in all, all i think you need is:

Overlay(clip1, clip2, mode="blend", opacity=0.5)

If you think after that it is still noisy, 'normal' noise filters will probably give you better results.

What i've been thinking, but since i don't capture i don't know for sure, is that you could remove standard errors from your capturing device. I'm just assuming that it has some, but no device is perfect now, is it ;). By capturing a perfect black movie, you'd get, what we call a Flat Field in astronomy, giving you information of your Noise level (the standard deviation of your whole image).
If you take another capture, add to it some high amount like 150 and substract your other capture from it, you'd get a noisy only, centered around 150 'perfect' image, that is, no standard errors. Thus you can use your flat field to remove those errors.
But capture devices are normally not imaging devices, , so they'd not have these positoinal errors, but you could substantially improve old VHS movies this way. Only problem is you'd add Noise :rolleyes:.

Dunno why i wrote that really, guess i was bored :P.

Karyudo
17th July 2004, 00:20
Originally posted by kingmob
Maybe i'm completely missing what you want, but if you just average the clips with overlay, you reduce your theoretical Noise by SQRT(2) If they are identical besides the noise. This is the best you can get (and it's very good) with averaging.

Yeah, you are missing what I want a bit. The two caps I have aren't identical except for noise; they're from two near-identical pressings of the same LD. So where one LD might have a flaw (due to rot, or dust on the disc, or whatever), the other probably won't.

What E-male's TooT filter does (and does well) is to take three separate caps from three separate copies of the same pressing of an LD (or same airing of a TV show on three different tapes, etc.), compare them, dump the outlier, and average the remaining two. Voila: no video flaws. And noise is down by SQRT(2), I guess.

Problem is, I don't have three copies of all the LDs I'd like to process with TooT. So I'd like to devise some way of determining which of the two sources is the "correct" source, and use its pixels in the regions where the two sources differ (i.e. where there's a video flaw).



...it would be better to analyze the areas where the Standard deviation is about the same on all 3 and averaging those, thus improving those areas by SQRT(3).

I agree! That is what I first suggested. That's not quite what E-male coded -- but I don't mind all that much, since (a) the incremental improvement would be very small on the decent caps I'm using; and (b) I can't code the damn thing myself.


What i've been thinking, but since i don't capture i don't know for sure, is that you could remove standard errors from your capturing device. {etc.)

Sounds kind of interesting. But in my (albeit limited) experience in analog capping, the sources you're capping from have probably an order of magnitude more noise than the capture device itself. That is, I'll bet a purely black field generated from a DVD player would probably be captured with a variation at any pixel of just a few levels, while capping from LD or tape introduces noise of up to 20 or so levels. Maybe it's only half an order of magnitude, but still: I doubt it would be worth the trouble you suggest. Too bad, because I like the idea.

tedkunich
12th August 2004, 02:14
@Karyudo

We are in the same predicament.... :) I wound up coding a filter that compares two clips, and if they are different from each other by xxx (Luma), then list that frame in a file that I use later in a conditional filter. It does have problems with scenes that have a lot of detail, so I'm hand massaging the list now.... It discards/ignors frames that differ by more than 20 pixels... had to do this because one of my LD's is a CAV and the other is CLV and there are enough differences that force this on scenes with lots of variations (lots of detail, fast motion, etc).

Don't want to start a CAV-CLV discussion, but of the two certified THX versions of a certain trilogy, I can consistently see a better picture with the CAV version in my caps from beggining to end..... We won't even go into the significant Luma difference between the two pressings....

sh0dan
12th August 2004, 18:17
Originally posted by Karyudo
Problem is, I don't have three copies of all the LDs I'd like to process with TooT. So I'd like to devise some way of determining which of the two sources is the "correct" source, and use its pixels in the regions where the two sources differ (i.e. where there's a video flaw).
My guess: "The pixel closest to a blurred version of the picture is the correct one." At least more than 50% of the time. What about using:reduceby2().reduceby2().bilinearresize(width(), height()) to create the third source?

Karyudo
14th August 2004, 03:23
@ sh0dan:

Hmm... if I only had one source, I'd like your idea a lot. As it is, I'd have to pick one of two flawed sources and blur that, maybe? I think your reasoning is pretty sound (blur the crap out of one source, and then compare), but I'm not so sure what should be blurred.

If we're blurring anyway, maybe some sort of temporal median filter would do? That would mitigate against one-frame flaws: the filtered frame would look like hell, but would probably give a more-accurate comparison for decision-making.

Jeez, even a simple spatial median filter might do enough: the dirt and crap is most noticable in relatively-static, relatively-large areas of relatively the same colour.

Or maybe a resized and median-filtered copy would work? Lots of things to try...

@ tedkunich:

You and I gotta talk. I've seen you posting in the huge videohelp thread, too. I've got some improvements (?) to E-Male's TooT filter that need compiling. I'm interested to hear how your script works for marking crapped-up frames, and what you do to fix 'em. I've got a wicked PAL CAV source that is nicer than the DC, but the actual film quality (dust, burns, splices) isn't as good in places. I'd like to compare the PAL source to the NTSC one, along with either manual correction or some sort of automatic comparison to the sort of faked-together decision-making-only clip, as discussed above.

Karyudo
3rd September 2004, 05:06
To slightly bump the thread I started...

I have been working with an app developed elsewhere on this forum that allows selection, editing and replacement of any frame(s) of a clip. This is great, because it allows hand editing (rotoscoping) of troublesome frames, without having to tweak all sorts of filter input parameters. Problem is, it's sort of slow going.

On the other side, there is Toot. By its very nature, TooT will automatically fix crapped up frames, but only when it has a third source to compare two candidate sources to. That makes it sort of useless for automagically fixing a clip when only two sources are available.

However, I'm thinking it must be somehow possible to tweak TooT (or a subsequent improvement/abstraction) to take two sources, and be able to export the two candidates for a given frame (as a pair of PNG or BMP files) when it hits a frame that differs significantly between the two input sources. Those two candidate frames would be "Mostly source A, except for where A differs from B, in which case use the pixels from B" and "Mostly source B, except for where A differs from B, in which case use the pixels from A". Except for rare cases, presumably one of those candidates would be a flawless frame, suitable for re-importation to the clip!

If the filter (e.g. modified TooT?) also wrote out a text file giving the frame number where it paused to write out the pair of candidate frames, then the re-importation could be made trivial.

The only hard, manual labour would now be having to run through all the pairs of candidate frames, and deleting the ones where the flaws are apparent. That's something a machine can't do by looking at two frames, but any idiot (i.e. me, for one) can discern in a second!

As I've mentioned before, I'm no programmer. I've been very fortunate recently to have several clever people take my wild-ass ideas and turn them into AviSynth gold. I'm hoping that I stay lucky, and that someone might be interested to take a crack at this one?

tedkunich
3rd September 2004, 06:36
Originally posted by Karyudo

If the filter (e.g. modified TooT?) also wrote out a text file giving the frame number where it paused to write out the pair of candidate frames, then the re-importation could be made trivial.



We are sorta on the same wavelength... :) I cooked up a modified version of what toot does - you give it two clips and a pixel compare threshold, and it will write out the frame number which meets the criteria... very crude, but it got the job done.... 15K flawed frames..... :angry:

I have no hosting capabilities, so it would have to be via email.... let me know....



T

Karyudo
3rd September 2004, 07:18
Originally posted by tedkunich
We are sorta on the same wavelength... :)

I know! I didn't come up with everything in a vacuum -- I've read most of your posts here and on videohelp, and that's been added to the pool of know-how and ideas currently simmering in my head. You writing out frame numbers helped things along a bit, that's for sure.

I cooked up a modified version of what toot does - you give it two clips and a pixel compare threshold, and it will write out the frame number which meets the criteria... very crude, but it got the job done.... 15K flawed frames..... :angry:

It's precisely that sort of number of frames to be corrected that makes me conjure up any number of possible strategies to reduce the brute force necessary to get good results! I wouldn't mind choosing between 15K candidate pairs (using something speedy like ACDSee), but I don't think I'd be all that keen to have to make changes to 15K frames by hand. Boo...

If that's what you've done, then kudos. That's a pile of work, man.

On a slight tangent, I'd love to be able to "cook up" some new stuff myself. You obviously know a little C++ (or something), and have figured out how to compile source code. That's a couple of steps beyond what I've done thus far. Was it tough? I'm willing to learn a few new tricks -- and I'd like to think I'm fairly easily educable. Could you let me know what sort of steps I'd have to take to get some reasonable results?

I have no hosting capabilities, so it would have to be via email.... let me know....

I'll PM you an e-mail address shortly!

tedkunich
3rd September 2004, 08:16
Originally posted by Karyudo
[B]I know! I didn't come up with everything in a vacuum -- I've read most of your posts here and on videohelp, and that's been added to the pool of know-how and ideas currently simmering in my head. You writing out frame numbers helped things along a bit, that's for sure.
:o


If that's what you've done, then kudos. That's a pile of work, man.


Think I'm THAT nuts?!??!?! Used Frizik's Despot filter on all but 500 or so. Ahnd touched up those that his filter had trouble on.



Was it tough? I'm willing to learn a few new tricks -- and I'd like to think I'm fairly easily educable. Could you let me know what sort of steps I'd have to take to get some reasonable results?


I know C quite well.... C++ is a quite different animal.... I was able to get a grasp of what all the setup stuff that happens in the filter (SimpleSample was the basis of the code). Getting the filter to do what I wanted afterwards was another task altogether :D For simple stuff like this, it is not hard... if you understand a little programming.. implementing a complex algorithm is another story... still have not got a clue on that one....

Setting up the VC++ takes nothing more than downloading the compiler and istalling it. It has a shell/command prompt setup with the environment. You just cook up a batch file to compile your source with the various compiler flags and you are all set :D


Later

T