Log in

View Full Version : RemoveGrain: Invalid mode 19


JClement
9th November 2011, 21:04
I am trying to detelecine a blended video and have tried both FixBlendIVTC and Srestore, but now I get the error noted in the title. So how do I fix this problem. The documentation is not much help. I am not an expert in Avisyth or the various arcane formats. The video is an old black and white which appears to be 3-2 telecined with blending. When detelecined normally, frames with fast motion have a half frame ghost from the previous frame, and another half frame ghost from the next frame before. This is really necessary to be able to remove spots from the film. I would buy a good copy if it were available because it is the only movie with my grandmother in the cast.

Also I would appreciate a suitable incantation which might solve my deblend/detelecine problem.

Keiyakusha
9th November 2011, 21:08
Not sure but this maybe due to old version of RemoveGrain. Latest one is 1.0

JClement
9th November 2011, 22:06
Thanks, that fixed the error. But now what incantations are necessary to get rid of the half frame ghost images? I have tried several options in either SRestore, or FixBlendIVTC. As I said there are two such images, one from the previous frame, and another from the next previous. Both of these scripts appear to do as well as SmartDecimate, and none of the ghosting is removed.

cobo
9th November 2011, 22:17
Looking at the date of the original discussion (http://forum.doom9.org/showthread.php?t=101477) it looks like v1.0b "beta" release was the latest version of RemoveGrain at the time.

There are links to all but the latest(RemoveGrainHD) here: http://avisynth.org/mediawiki/Removegrain

Wiki page for FixBlendIVTC: http://avisynth.org/mediawiki/FixBlendIVTC

JClement
9th November 2011, 23:20
Yes, I have looked at the Wiki, and it does not give the needed information. I did miss the fact that version 1 was needed. Nowhere is there any mention that the blended ghosts are removed. It does use the word blurr, but I would not interpret that as the ghosting due to the blending. Should Deblend also or instead be used? OR how about Unblend? Nowhere have I seen comments that the resulting frames have the ghosting removed. Mostly comments talk about discarding or replacing frames, but not about subtracting out the blended ghost artifact. So I would say the documentation is a wee bit sparse, and uses terms and makes assumptions about the reader that may not be valid. From what I can seen neither Srestore nor FixBlendIVTC remove the ghosts properly.

JClement
10th November 2011, 01:12
Looking at the ghost images, there is a strong ghost from one half frame, and then a weaker one from the other half frame, and it seems to go on. My hypothesis is that this is not necessarily deliberate blending, but due to a persistence in the video tube that they use for capturing the movie. So the first half frame of a new frame will have a strong ghost, and the second half frame a weaker one. I don't know what happens when you get the two video frames with mixtures of the previous film frames. It depends on whether the film is run at a constant rate, or the camera at a constant rate. This persistance may actually result in stronger ghosts at one end of the frame than at the other. So at that point my question is: Do the current deblenders use an algorithm which can handle this situation?

The blend could be any ratio, such as 50%, 30%,..., so is there a deblender which has a settable ratio. This would seem to be necessary.

JClement
10th November 2011, 02:08
Looking at some frames where the motion was very fast, I estimated that the primary ghost was 75% of the original value, and the ghost in the other half frame was correspondingly reduced to around 50%, with the secondary ghost also reduced correspondingly. So my hypothesis would seem to be confirmed. Other evidence is that a large white spot saturates the picture and shows a definite long decay. Of course this could not be compensated for by any deghosting operation. I did the analysis by converting several frames to JPGs, and then by using the eye dropper tool on individual pixels to look at the intensity. I think the analysis could have a 5 to 10% uncertainty, but I can fairly definitely say the ghosting between two consecutive A or B half frames is greater than 50%.

There is still the problem of the mixed video frames. There are 3 scenarios, 1. the 3-2 is achieved by software, 2. The film frame rate is adjusted to have hiccups or 3. The video tube frame rate is adjusted to have hiccups. I did not find any explicit explanations of which is most likely to be done on old equipment. The algorithm used to detelecine would need to take into account which scenario is most likely. I am sure there are some people on this list who would know which of these was common practice. I would discount #1 because old equipment was not digital, and my video was most probably originally to analog tape.

JClement
10th November 2011, 06:47
I split a portion of the video into half frame jpgs and then produced deghosted half frames by subtraction of every other one. The results fell into a pattern which indicates the following.
1. A half frame which comes immediately after the film frame was changed had a 60% ghost.
2. A half frame which is the second half needed only 30% deghosting.
3. The half frame which is a duplicate also needed only 30% deghosting. Only a secondary ghost is cancelled and there is not primary ghost from the previous film frame.

This does very much look like the ghosting is due to persistence in the video detector, and may not be intentional.

So now the question is how to deghost this sequence. A uniform 30 to 50% subtraction of every other half frame followed by IVTC & Decimate would yield fair results. To ID the duplicate half frames there would have to be a comparison of 30% subtraction with 60% subtraction. Would anyone be up for doing this? I suspect that a lot of videos have this same pattern when telecined by old equipment.

manono
10th November 2011, 10:39
You could save yourself a lot of typing and bumping of your thread by just posting a 10 second clip from the source that shows the problem.

JClement
10th November 2011, 17:23
Actually the careful analysis is what took a lot of time. The typing and bumping was very small. I have uploaded a very short clip, the same one I analyzed.