Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion. Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules. |
28th November 2020, 02:02 | #1 | Link |
Registered User
Join Date: Dec 2010
Posts: 6
|
inverse telecine and de-interlace of 8mm film scan
Hi,
In 2012 I had a couple of 7" reels of standard 8mm scan by these guys. They scanned them into digital files and also a DVD. The digital files are MJPEG interlaced in an avi container. I now want to try to clean them up using VideoFred's scripts. To do this I need to apply RemoveDirt and DeScratch . To use these filters I need to remove any duplicate frames and de-interlace. The telecine seems to be aabbccddeeffggh to convert from 16 FPS to 29.97 FPS. I don't know how the interlace works, but it does seem to be interlaced. Here is a sample of the file: sample.avi Maybe someone could take a look and give me some advice on how to do inverse telecine and deinterlace into 16 FPS progressive? Thanks. |
28th November 2020, 03:12 | #2 | Link |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,695
|
I developed IVTC scripts for both 18 fps (Super 8) and 16 fps (common speed for 16mm and 8mm amateur silent). Yours has the standard pulldown for 16 fps, requiring removal of 7 frames out of every 15 frames. I walked through the clip, just to make sure, and then applied this simple two-line IVTC:
Code:
tfm(display=false) tdecimate(cycleR=7,cycle=15) #16 fps Your sample simply repeats entire frames to achieve the goal of having 16 fps material play at the correct speed when shown on a device only capable of playing 30 fps (which is actually 29.97 fps, but that subtlety doesn't matter at all for non-sound silent film) You can get slightly smoother playback on CRT devices when you repeat fields across frames rather than simply repeating frames, but since you're removing all the repeats in order to do your restoration with Fred's script, that doesn't matter. Bottom line: you cannot use deinterlacing tools on your sample and hope to achieve any useful result. You must use IVTC, and TIVTC (where you'll find TFM/TDecimate) is the tool you should use. |
2nd December 2020, 00:02 | #3 | Link | |
Registered User
Join Date: Dec 2010
Posts: 6
|
Quote:
Now that I have studied your solution, I realize that the tfm filter does the deinterlace operation before the tdecimate removes the duplicate frames, resulting in a true progressive 16 FPS file. Thanks for your time. |
|
2nd December 2020, 04:14 | #4 | Link |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,695
|
TFM doesn't deinterlace. Instead it matches fields and then provides "hints" to TDecimate to tell it which fields are duplicates, from the same moment in time.
As I said in my earlier post, deinterlacing is related, but it is a different animal and you can't use deinterlacing tools to achieve inverse telecine. |
2nd December 2020, 08:33 | #5 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
CaptainTivo, As best as I can tell looking at your sample, IVTC isn't required as it's not telecined. There's definitely what appears to be combing, but TFM is doing nothing but de-interlacing, so in that respect you could de-interlace with your de-interlacer of choice and follow it with TDecimate. However.... While I know nothing about digitising old films and how it's done, it looks to me like one of the fields is shifted by something like half a scanline, causing the combing. Maybe that's something to do with the MJPG format and the way fields are encoded. I know nothing about that either. Try the following (edited to fix pasting PointResize onto the wrong line) SeparateFields() A = SelectEven() B = SelectOdd().PointResize(1920,540, 0,-0.5,1920,540) Interleave(A,B) Weave() Follow it with TFM this way, and for your sample at least, you'll see it isn't needing to do much. TFM(Display=true, PP=1) The trouble is though, I either didn't get the shift 100% correct or it's not consistent (the fade in at the beginning is mostly the culprit), so for some frames there's very fine "combing" TFM doesn't detect unless you make it more sensitive. If you use TFM on it's own it'll be de-interlacing virtually every frame when, in theory at least, it shouldn't need to, but after shifting a field if you make the combing detection too sensitive it'll still do the same, so I played around a little and the following seemed a reasonable compromise. TFM should leave most frames untouched while still de-interlacing where any residual combing might be noticeable. SeparateFields() A = SelectEven() B = SelectOdd().PointResize(1920,540, 0,-0.5,1920,540) Interleave(A,B) Weave() TFM(Metric=1, MI=50) TDecimate(CycleR=7, Cycle=15) Last edited by hello_hello; 2nd December 2020 at 09:51. |
|
2nd December 2020, 16:18 | #6 | Link |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,695
|
I do film transfer for a living, and have used every single TFM mode. The previous post, while well-meaning, is wrong.
Deinterlacing is NOT inverse telecine. The statement "de-interlacing is all it's doing" is wrong. The sample is 100% progressive. There is not one frame which has its two fields from different moments in time, which is the definition of interlacing. Instead, as I stated in my long post, the company that did his transfer performed the telecine (a.k.a. "pulldown") by simply repeating entire frames. Therefore, there is not one frame which is interlaced, and de-interlacing will fail to do anything. It is important to be clear on this because so many people already have incorrect views about interlacing, and this just adds to it. As for field shifting, I didn't notice that, but I suppose it is possible. I'd have to go back to the original clip, deconstruct it into individual fields, and then look to see if things line up. |
2nd December 2020, 17:18 | #7 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,374
|
In this specific sample , all fields are already matched (all frames already have their matched field pair) - technically you don't need to field match. But on a longer section , some fields might be out of sequence, so it does not "hurt" to include TFM in case you need to field match
By default, TFM potentially deinterlaces as a post processing function when detection thresholds are met. If you use TFM(PP=0), you can check with deinterlacing 100% disabled TFM is deinterlacing this sample, when using FFMS2 as the source filter , otherwise there would be no differences detected by this script Code:
FFVideoSource("sample1.avi") TFM() a=last FFVideoSource("sample1.avi") TFM(pp=0) b=last Overlay(a,b , mode="Difference", pc_range=true) Levels(127, 1, 129, 0, 255, false) Some MJPEG en/decoders often have fields swapped, some automatically adjust for this. You can use swapfields() in avisynth if your mjpeg decoder does not have that toggle option. If you check with swapfields, it's clearly better, and this is the likely the explanation. But there is still residual combing. This can occur from interlaced encoding compression artifacts, and also from a lighting mismatch from the sample times . 16 is not evenly divisible into 59.94 fields/s and the fades are worse as expected (one field has a different brightness than it's partner field) I would finish with vinverse2 for the residual combing. You don't lose fine detail because this is a very soft upscale to begin with. 8mm does not need 1080 lines; it's really overkill Code:
FFVideoSource() SwapFields() TFM(pp=0) #just in case TDecimate(CycleR=7, Cycle=15) Vinverse2() Note, that FFVideoSource returns the original full range 0-255 YUV 422 mjpeg data . This is the original storage format. If you use AVISource, some decoders may range compress the output automatically, others might return RGB Last edited by poisondeathray; 2nd December 2020 at 17:21. |
2nd December 2020, 18:29 | #8 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
PDR Masterclass
__________________
I sometimes post sober. StainlessS@MediaFire ::: AND/OR ::: StainlessS@SendSpace "Some infinities are bigger than other infinities", but how many of them are infinitely bigger ??? |
2nd December 2020, 22:19 | #9 | Link | ||
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
"You can also use the "clip2" parameter to specify an externally deinterlaced clip from which TFM will take frames instead of doing the deinterlacing itself." For Clip2 it says: "Don't specify anything for clip2 to use TFM's internal deinterlacing." Quote:
TFM(Display=true, pp=1) shows the match used is almost always "c" which means: "the field from the current frame and of the opposite parity to that of the field being matched from is used" So it's not shuffling fields around to create progressive frames because there's no better match. It's failing to find a better match, detecting the combing and de-interlacing to repair it. I can't imagine what else you think is happening to produce uncombed frames, given you're sure only whole frames are duplicated and the video is progressive. Unless the fields are "out of phase", why would field matching normally be required when there's no unmatched fields created by duplicating whole progressive frames? Last edited by hello_hello; 3rd December 2020 at 00:44. |
||
2nd December 2020, 22:51 | #10 | Link |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,695
|
Agree on most points. TFM does field matching, and part of that means that it can sense when fields are from the same moment in time, or not. However, deinterlacing involves making a decision as to how to get two fields in each frame which are from the same moment in time, either by synthesizing those fields, or by discarding fields. I guess you could to this with TFM, but I'm not sure why.
As for all the matching parameters, I've used all the "micmatching" parameters when I invented a film transfer system which uses a standard projector from which the shutter has been removed. I used all the advanced settings of TFM in order to take the 1/1000 second shutter speed capture and determine which fields included the pulldown (blurred, and doesn't match anything, so must be deleted), and which fields need to be combined together to create a full, progressive frame. When capturing 24 fps (sound speed) film with a 60 field/second NTSC interlaced camera, some fields are duplicates of fields in adjacent frames and must be removed. Other fields need to be re-combined with fields in adjacent frames. It is very complicated, and to make it work I exported all the TFM metrics to a spreadsheet where I developed formulas which look forward and backwards through all the matching metrics in order to determine which fields need to be moved to other frames, and which have to be decimated. I use MultiDecimate for the actual decimation. It is a real real Rube Goldberg, but it works. The point is, I know TFM about as well as I think anyone can know it. However, if I want to deinterlace, I'll use Yadif, QTGMC, or something that is dedicated to the task. Last edited by johnmeyer; 2nd December 2020 at 22:55. |
2nd December 2020, 22:52 | #11 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
As you said, SwapFields still leaves some mild combing, mainly during the fade in, and a quick look that seems to indicate the result is the same as shifting one field, at least in respect to fixing the combing, only SwapFields is obviously the better way to do it. I'm not sure I've got my head wrapped around why that is though, as I thought I was only shifting one field by half a scanline. After the fields are interleaved and re-weaved again though, does that mean the field ends up shifted by more than just half a pixel? Or maybe the result only appears similar to SwapFields()? I'll continue to ponder that one... |
|
3rd December 2020, 00:15 | #12 | Link | ||
Registered User
Join Date: Sep 2007
Posts: 5,374
|
Quote:
If you open up a regular image jpeg with FFMS2, it returns full range YUV too (for YUV jpegs, which are 99.9999% of jpegs) . Imagesource will return converted RGB. mjpeg is just an extension of jpeg Quote:
For the other residual combing, it's mainly from interlaced encoding compression artifacts . Another way to treat those is amdct with some tweaked settings . But this source is so soft at 1080 that just vinverse/vinverse2 is probably more than good enough |
||
3rd December 2020, 00:40 | #13 | Link | |
Registered User
Join Date: Mar 2011
Posts: 4,829
|
Quote:
That wasn't really the point. |
|
3rd December 2020, 04:45 | #14 | Link | |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,695
|
Quote:
https://forum.doom9.org/showthread.php?t=162784 I was actually going to apply for a patent (I've always wanted one), and I'm sure I would have gotten one, but I found out the price of my vanity when I spent an hour with a patent lawyer who told me what I already pretty much knew: $10,000 just for a provisional, and $50,000 to see it all the way through. I ain't that vain. The reason I'm sure it could be patented, however, is that the idea is extremely difficult to grasp, and therefore not "obvious," a key requirement for a patent. Since I have posted the idea here, I obviously don't intend to defend it in any way. |
|
Thread Tools | Search this Thread |
Display Modes | |
|
|