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. |
13th July 2016, 04:07 | #1 | Link |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,691
|
Separating Kinescope Fields -- Not As Easy As I Hoped
A museum wants me to restore a beautiful Kinescope from the late 1950s showing Jim Henson's puppets, long before he was widely known.
Here is a single frame that shows the problem I'm trying to solve: And, here is a link to a few seconds of the original professional film scan: https://www.mediafire.com/?l5cl361w6mnfo16 It was scanned in HD and saved to ProRes. I couldn't edit that (although I can play it), so I converted to HuffYUV which is what I uploaded (cut with VirtudalDub's direct stream copy). I don't think I changed or re-encoded anything, and the quality of the download should be identical to the original Spirit scan. Here is the problem I'm trying to solve: both fields were exposed onto a single frame of film. Since the film is 24 fps, progressive, this results in ghosting on fast-moving images. This is what you see in the still image above. There is also a glitch that is known in Kinescope circles as a "splice." You will see this glitch every few frames. This happens because during the time when film camera shutter was closed and the film was being advanced to the next frame ("pull down"), the fields are still painting on the CRT. When the film shutter re-opened, it resumed recording fields, but missed approximately 12 fields during the time the shutter was closed, resulting in a visible discontinuity. For the moment I'm not concerned about the splice. I'll deal with that later. My main goal is to figure out how to separate the original odd and even fields. This is turning out to be difficult because the original NTSC video had, nominally, 525 scan lines. Not all of these were recorded to the 16mm Kinescope film. Then, when the 16mm Kinescope film was transferred to digital by the professional film transfer lab, they scanned at 1920x1080. This video representation of the original film therefore has multiple horizontal lines for each original NTSC video scan line. Thus, I cannot simply use "separatefields()" to recover the even and odd fields. So, what I need to do is to figure out how to create two new video streams, one for the original odd and one for the original even fields. I've tried re-sizing back to 525 vertical lines, but that doesn't work, and re-sizing seems to introduce distortions. What I'm thinking of doing is something along the lines of what I did to recover an interlaced video that had been resized without first deinterlacing. I described my idea here: Repair Bad Deinterlacing So, does anyone have some ideas of how I can separate each frame into two individual half-height frames. What I need is a function that is similar to separatfields() but which uses 2-3 lines in a row for one "field" followed by the next 2-3 lines in a row for the next "field." The tricky part is that, because of all the conversions involved, there isn't going to be some magic single number of lines that I can "tune" to in order to get the conversion to work. Any ideas would be wonderful. Thanks! Last edited by johnmeyer; 14th September 2020 at 17:18. |
13th July 2016, 13:31 | #2 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
John, I'll take a peek at this later today, still gotta get some sleep though before, did not get a wink last night,
going to do some shoppin' then a little shuteye.
__________________
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 ??? |
13th July 2016, 18:00 | #3 | Link |
Formerly davidh*****
Join Date: Jan 2004
Posts: 2,493
|
The Mediafire link isn't working at the moment, for some reason.
Anyway, this'll be a tricky one. The picture geometry is off, which is why you'll have no luck just resizing or culling lines. You'll need to correct the geometry first, which is tricky enough even if it remains perfectly stable, which it probably won't. Is the video higher res than the screenshot? Or is it a crop? |
13th July 2016, 19:56 | #5 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
SourceForge was down earlier today for everyone, for whatever reason.
I got the clip and so assume that others did too. Not gonna DL another 125MB (or whatever it was) to reafirm above. So far as I know, it now works OK.
__________________
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 ??? |
13th July 2016, 21:22 | #6 | Link |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,691
|
Sorry for the size, even though it is only a few seconds long. If I could have easily cut the original Prores MOV file using ffmpeg, I would have done that instead. The good news is that I think pretty much everyone here can easily deal with an HuffYUV video.
|
13th July 2016, 22:19 | #7 | Link | |
Registered User
Join Date: Sep 2007
Posts: 5,345
|
Quote:
-t is duration of the clip -ss is starting time Notation is in hours:minutes:seconds.milliseconds -c:v copy means stream copy the vdieo -an means no audio e.g. If you wanted to cut (stream copy) a clip from 1 min, to 1 min 10seconds for a total duration of 10 seconds Code:
ffmpeg -ss 00:01:00 -t 00:00:10 -i input.mov -c:v copy -an output.mov I doubt it will make a difference for this in the end - but the method it was converted down from 10bit to 8bit huffyuv might make a difference on the edge pixels of the scanlines (ie. dithering used or algorithm used). You'll get slightly different pixel values depending on the method used. That might affect the accuracy of a mask. |
|
14th July 2016, 00:30 | #8 | Link |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,691
|
Thanks for the ffmpeg code. Here is 10 seconds of the video:
10 second clip (210 MB) It is actually larger, but this version is completely unaltered from the original Prores delivered by the lab. |
15th July 2016, 00:11 | #9 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
John can you confirm that we are looking for more like 480 scanlines rather than 525 (rest being some kind of missing overscan, frame blanking).
One other thing, the film seems to be jiggling up and down and so probably of no use to try to ascertain scanline positions using more than a single frame. (BUT, Is it jiggling up/down prior to CRT, or in Kine capture film ?).
__________________
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 ??? Last edited by StainlessS; 15th July 2016 at 00:15. |
15th July 2016, 02:14 | #10 | Link |
Registered User
Join Date: Sep 2007
Posts: 5,345
|
The prores sample is larger, only because it's 240 frames vs. 69. The "10 seconds" was just an example for the ffmpeg code - you didn't have to use it , but thanks for the sample
The jiggling and warping makes it difficult because if you were to use a mask to separate even/odd scanlines, it would have to be a procedurally generated one |
15th July 2016, 02:21 | #11 | Link | ||
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,691
|
Quote:
Quote:
At this point in my thinking, I see several steps to this challenge: 1. Stabilize. 2. Rotate to make scan lines perfectly horizontal. 3. Flatten the lines. The CRT and film camera lens geometry conspire to warp the lines. I need to "de-barrel" the image so that these lines become perfectly straight. I feel pretty confident I can do these first three steps and get a pretty good result. My big hangup is from this point forward. 4. Recover the original even and odd fields. There are several challenges here. I will neglect, for the moment, issues of the image drifting, even after steps 1-3. Let's assume for the moment we manage to get each frame aligned with the adjacent frames. The question then becomes, how do we select which lines in the existing 1920x1080 video to combine together, and how do we deal with fractional lines (because some of the 1080 lines will actually be sampled from a combination of two adjacent lines from the original video). One possibility is that, because we do have slightly more (hopefully) than 2x the original number of lines, that we may be able to parse through the video and match pairs of lines that are identical, or near-identical, and then take the "better" of the two. This thinking has, of course, at least two flaws. The first is figuring out how to make the decision on which is "better," and the second problem is the fact that, because we don't have exactly two rows of pixels for each original scan line, the algorithm may have to occasionally throw away a third field or, alternatively, use two adjacent fields. What would be really useful would be the ability to "tune" the filter by adjusting the parameter for step #4 until two reasonably clean images appear. If you look again at that still image I showed in my initial post, what I want is to be able to tune the "number of scan lines" (a vague concept) until the ghosted top of the puppet's head becomes a clear, separate image, without any traces of the other field. If I can achieve that on even one field, I can then worry about how to make the filter adapt as it goes along. So, rather than solve the whole problem at once, I would like to see if, for just one frame, I could successfully extract two half-height images (i.e., two fields) that are reasonably clean. Perhaps I should look more closely at various blended field algorithms that have already been created, although I'm pretty sure none of these are designed to deal with images where the even and odd field are not defined within the video file itself. This project reminds me a lot of that amateur Kinescope of an NFL football game you helped me with a few years ago. You may remember that it had horrible white noise bars that resulted from not syncing the film camera to the video camera. You made some wonderful mods to RT_Stats, and once I got the video horizontally aligned, was able to create a moving exposure mask that helped me completely eliminate the noise bar, except at the edges (because I was too lazy to implement the boundary condition code to handle partial noise bars at the top and bottom of the screen). In case you don't remember that video, here is the before and after (and thanks again for your work on that project): NFL Amateur Kinescope Noise Bar Removal So, at this point I'm looking for ideas, not code, and any hints or ideas that you (or anyone else) can come up with would be greatly appreciated. |
||
15th July 2016, 02:26 | #12 | Link |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,691
|
P.S. One other thought: there are some places where the original scan lines are clearly visible. Here is an extreme blow up, which thanks to the wonderful film scan, is quite clear (as you can see, I didn't yet attempt to rotate the image to make the lines perfectly horizontal):
I don't know if there is a way to look for these artifacts and use them to tune the filter. BTW, you'll notice that the lines are "wobbly." That is actually something that was intentionally introduced by the circuitry driving the CRT. If you read about Kinescope, you'll find that the BBC invented something called "spot wobble" which was designed to make the actual scan lines (like the one shown in this image) less visually apparent when the film was re-broadcast or when it was viewed on the movie screen. Last edited by johnmeyer; 14th September 2020 at 17:17. |
15th July 2016, 07:35 | #13 | Link |
Registered User
Join Date: May 2010
Posts: 28
|
Only an idea from geometrical point of view (after your corrections of jitter, distortion, horizontal)
- A CRT line is higher than 2 pixel (1080/525 >2). Not all 525 CRT lines are visible. A border should be added on the bottom so that the resulting hight represents 540 CRT lines (enables easy splitting). - pointresize back to 1080 pix hight - split in 4 frames (a ..lines 4x, b .. 4x+1, c .. 4x+2, d .. 4x+3) - b + d (or a+c) should contain odd respective even CRT lines, the other two are maybe rubbish Regards |
15th July 2016, 07:53 | #14 | Link |
Registered User
Join Date: May 2006
Posts: 3,997
|
Not sure whether this would lead to somewhere:
- Select a picture (a) and make a copy of it (b). Select a combed area. - Shift and rotate the copy and subtract the 2 pictures (a-b) - When the the copy is left untouched, (a-b) should be zero - Now shift and rotate the copy. When the copy matches the ghost picture, one could possibly see a local minimum of (a-b). - This could possibly help to find a mask. More sophistic methods than simple subtracting may lead to better results, e.g. combined with filtering or correlation. Just a vague idea. |
15th July 2016, 17:52 | #15 | Link | |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,691
|
Quote:
|
|
30th March 2017, 23:27 | #16 | Link |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,691
|
I realize it has been nine months since I started this thread, but the museum asked me to re-visit this, which I just did. I was able to get rid of the herring bones by re-sizing back down to the original size, throwing away one of the fields, duplicating the remaining field, and then re-sizing back up to 1920x1080. It is a trivial script:
Code:
bob() LanczosResize(480,270) selecteven() LanczosResize(1920,1080) and here is the same frame after: The ghosting on the fast-moving Jim Henson puppet, however, still remains. I did try SRestore, ExBlend, and FixBlendIVTC(). StainlessS was able to make dramatic improvement on another clip I had by using Exblend: ExBlend deblender but that was not a Kinescope and the ghosting therefore had a different characteristic. I am about to tell the museum that I can't fix the video, but I thought it was worth posting one more time just to see if anyone has other ideas. Last edited by johnmeyer; 14th September 2020 at 17:32. |
31st March 2017, 02:32 | #17 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Maybe of some limited use, Grid(), V.C.Mohan. NOTE, On Wiki at least, gives VBColor as VBold (ie two entries in arg description for vbold)
Code:
Color=$0000FF BColor=$00FF00 VBColor=$FFFF00 AVISource("D:\Meyer\Kinescope (10 seconds).mov.AVI") ConvertToRGB32 Grid(color=Color,BColor=Bcolor,VBColor=VBColor) Return Last Still has blending. EDIT: Re-did estimated vertical size, ~446. Inserted this code block before last one. Code:
# Blue grid = 10 pixels. # Count number of scanlines, 31 white/black pairs over 150 pixel rows, # 150 / (2 * 31) ~= 2.419 clip scanlines per original scanlines. # 1080 / 2.419 ~= 446 pixels original height. Color=$0000FF BColor=$00FF00 VBColor=$FFFF00 Gamma=0.7 Th=0.4 AVISource("D:\Meyer\Kinescope (10 seconds).mov.AVI") ConvertToRGB32 Trim(113,-1) Crop(550,500,160,216) mn=RT_YPlaneMin(n=0,Threshold=Th) mx=RT_YPlaneMax(n=0,Threshold=Th) RT_DebugF("Min=%d Max=%d",mn,mx) Levels(mn,Gamma,mx,0,255) Grid(color=Color,BColor=Bcolor,VBColor=VBColor) Return Last looking for 'splice' only on even or odd field (presume that should only exist on 1 field), but no joy. Perhaps needs to be unskewed first. Code:
Color=$0000FF BColor=$00FF00 VBColor=$FFFF00 H=446 # EDITED AVISource("D:\Meyer\Kinescope (10 seconds).mov.AVI") ConvertToRGB32 Trim(223,-1) PointResize(720,H) SeparateFields #Grid(color=Color,BColor=Bcolor,VBColor=VBColor) Return Last de-skewed/de-barrelled first. EDIT: Can you check my count in 2nd script John. (Zoom 400% in VirtualDubFilterMod or other)
__________________
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 ??? Last edited by StainlessS; 31st March 2017 at 15:34. |
31st March 2017, 04:30 | #18 | Link |
Registered User
Join Date: Feb 2002
Location: California
Posts: 2,691
|
StainlessS,
Thanks for the help and ideas. Kinescopes are tough because there were so many ways the transfer was done, and there were all sorts of things done (like "wobble") to hide the scan lines, but these efforts introduced artifacts of their own. Also, since analog is a continuous process whereas the film process is discrete. As a result there are all sorts of ways to generate discontinuities, like that line. This is one of the more professional Kinescope transfers I've ever dealt with. The museum has the original film, and had it transferred on a proper Spirit film transfer system. They recorded it in ProRes at 1920x1080, so every detail available is in that video. The point being that these various issues were in the original transfer, and not in anything done to the film or video subsequent to that time. I'm just going to tell them that I can't do anything except reduce the scan lines and eliminate the dirt. I might be able to eliminate the line, since it only lasts for one frame. Despot can be set to get rid of long single-frame horizontal lines. However, there is no way to get rid of the ghosts, which is the original reason I was approached to do this project. Those puppets are moving so fast that there is no way to interpolate from adjacent frames, and there is no difference between fields that can be exploited. Again, as always, thanks for your help. |
31st March 2017, 04:55 | #19 | Link |
HeartlessS Usurer
Join Date: Dec 2009
Location: Over the rainbow
Posts: 10,980
|
Very diplomatic of you John, , Its well past my bedtime I think.
Of course the film captures both fields at once due to persistence (think I got it back to front in my noggin). Back to the drawing board ("Time for bed" said Florence, "Boing" said Zebedee).
__________________
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 ??? |
Thread Tools | Search this Thread |
Display Modes | |
|
|