Frank Agbat

I think tracking Z's lens angles, etc, is a worthy topic for a fresh thread. This one needs to get back on the focus of film sync, etc.

Hi John, I appreciate you taking the time to line-up columns, etc. I was very short on time (as always, it seems) and wanted to get the table out there for consumption. I have not been able to determine any tested frame rates of the Muchmore camera yet. Perhaps Gary Mack has this information available, or perhaps it is available elsewhere. Nevertheless, if the cameras are gapping by a frame, it could easily be a slightly different frame rate. Bill Miller is correct -- the NFV/Groden Muchmore film has a splice (right around the headshot, of course). I've been looking into this spliced area and will compare it frame-by-frame to the black and white version provided (which shows no splice). Based on looking at the film a few dozen times, it looks like the film was broken at that frame and taped back together (poorly, too). The frame registration drifts for a frame or two. This may be something that can be digitally "improved", as some preliminary studies I've done seem to indicate that the whitespace in the splice is larger than it needs to be.

Z-# Time (Z325 ref) NS# Time (NS35 ref) Z vs. Nix Delta time 291 -1.8579234973 1 -1.8378378378 -0.0200856594 292 -1.8032786885 2 -1.7837837838 -0.0194949047 293 -1.7486338798 3 -1.7297297297 -0.0189041501 294 -1.6939890710 4 -1.6756756757 -0.0183133954 295 -1.6393442623 5 -1.6216216216 -0.0177226407 296 -1.5846994536 6 -1.5675675676 -0.0171318860 297 -1.5300546448 7 -1.5135135135 -0.0165411313 298 -1.4754098361 8 -1.4594594595 -0.0159503766 299 -1.4207650273 9 -1.4054054054 -0.0153596219 300 -1.3661202186 10 -1.3513513514 -0.0147688672 301 -1.3114754098 11 -1.2972972973 -0.0141781125 302 -1.2568306011 12 -1.2432432432 -0.0135873578 303 -1.2021857923 13 -1.1891891892 -0.0129966032 304 -1.1475409836 14 -1.1351351351 -0.0124058485 305 -1.0928961749 15 -1.0810810811 -0.0118150938 306 -1.0382513661 16 -1.0270270270 -0.0112243391 307 -0.9836065574 17 -0.9729729730 -0.0106335844 308 -0.9289617486 18 -0.9189189189 -0.0100428297 309 -0.8743169399 19 -0.8648648649 -0.0094520750 310 -0.8196721311 20 -0.8108108108 -0.0088613203 311 -0.7650273224 21 -0.7567567568 -0.0082705656 312 -0.7103825137 22 -0.7027027027 -0.0076798110 313 -0.6557377049 23 -0.6486486486 -0.0070890563 314 -0.6010928962 24 -0.5945945946 -0.0064983016 315 -0.5464480874 25 -0.5405405405 -0.0059075469 316 -0.4918032787 26 -0.4864864865 -0.0053167922 317 -0.4371584699 27 -0.4324324324 -0.0047260375 318 -0.3825136612 28 -0.3783783784 -0.0041352828 319 -0.3278688525 29 -0.3243243243 -0.0035445281 320 -0.2732240437 30 -0.2702702703 -0.0029537734 321 -0.2185792350 31 -0.2162162162 -0.0023630188 322 -0.1639344262 32 -0.1621621622 -0.0017722641 323 -0.1092896175 33 -0.1081081081 -0.0011815094 324 -0.0546448087 34 -0.0540540541 -0.0005907547 325 0.0000000000 35 0.0000000000 0.0000000000 (This is the Z325/NS35 Sync Point) 326 0.0546448087 36 0.0540540541 0.0005907547 327 0.1092896175 37 0.1081081081 0.0011815094 328 0.1639344262 38 0.1621621622 0.0017722641 329 0.2185792350 39 0.2162162162 0.0023630188 330 0.2732240437 40 0.2702702703 0.0029537734 331 0.3278688525 41 0.3243243243 0.0035445281 332 0.3825136612 42 0.3783783784 0.0041352828 333 0.4371584699 43 0.4324324324 0.0047260375 334 0.4918032787 44 0.4864864865 0.0053167922 335 0.5464480874 45 0.5405405405 0.0059075469 336 0.6010928962 46 0.5945945946 0.0064983016 337 0.6557377049 47 0.6486486486 0.0070890563 338 0.7103825137 48 0.7027027027 0.0076798110 339 0.7650273224 49 0.7567567568 0.0082705656 340 0.8196721311 50 0.8108108108 0.0088613203 341 0.8743169399 51 0.8648648649 0.0094520750 342 0.9289617486 52 0.9189189189 0.0100428297 343 0.9836065574 53 0.9729729730 0.0106335844 344 1.0382513661 54 1.0270270270 0.0112243391 345 1.0928961749 55 1.0810810811 0.0118150938 346 1.1475409836 56 1.1351351351 0.0124058485 347 1.2021857923 57 1.1891891892 0.0129966032 348 1.2568306011 58 1.2432432432 0.0135873578 349 1.3114754098 59 1.2972972973 0.0141781125 350 1.3661202186 60 1.3513513514 0.0147688672 351 1.4207650273 61 1.4054054054 0.0153596219 352 1.4754098361 62 1.4594594595 0.0159503766 353 1.5300546448 63 1.5135135135 0.0165411313 354 1.5846994536 64 1.5675675676 0.0171318860 355 1.6393442623 65 1.6216216216 0.0177226407 356 1.6939890710 66 1.6756756757 0.0183133954 357 1.7486338798 67 1.7297297297 0.0189041501 358 1.8032786885 68 1.7837837838 0.0194949047 359 1.8579234973 69 1.8378378378 0.0200856594 360 1.9125683060 70 1.8918918919 0.0206764141 361 1.9672131148 71 1.9459459459 0.0212671688 362 2.0218579235 72 2.0000000000 0.0218579235 363 2.0765027322 73 2.0540540541 0.0224486782 364 2.1311475410 74 2.1081081081 0.0230394329 365 2.1857923497 75 2.1621621622 0.0236301876 366 2.2404371585 76 2.2162162162 0.0242209423 367 2.2950819672 77 2.2702702703 0.0248116969 368 2.3497267760 78 2.3243243243 0.0254024516 369 2.4043715847 79 2.3783783784 0.0259932063 370 2.4590163934 80 2.4324324324 0.0265839610 371 2.5136612022 81 2.4864864865 0.0271747157 372 2.5683060109 82 2.5405405405 0.0277654704 373 2.6229508197 83 2.5945945946 0.0283562251 374 2.6775956284 84 2.6486486486 0.0289469798 375 2.7322404372 85 2.7027027027 0.0295377345 376 2.7868852459 86 2.7567567568 0.0301284891 377 2.8415300546 87 2.8108108108 0.0307192438 378 2.8961748634 88 2.8648648649 0.0313099985 379 2.9508196721 89 2.9189189189 0.0319007532 380 3.0054644809 90 2.9729729730 0.0324915079 381 3.0601092896 91 3.0270270270 0.0330822626 382 3.1147540984 92 3.0810810811 0.0336730173 383 3.1693989071 93 3.1351351351 0.0342637720 384 3.2240437158 94 3.1891891892 0.0348545267 385 3.2786885246 95 3.2432432432 0.0354452813 386 3.3333333333 96 3.2972972973 0.0360360360 387 3.3879781421 97 3.3513513514 0.0366267907 388 3.4426229508 98 3.4054054054 0.0372175454 389 3.4972677596 99 3.4594594595 0.0378083001 390 3.5519125683 100 3.5135135135 0.0383990548 391 3.6065573770 101 3.5675675676 0.0389898095 392 3.6612021858 102 3.6216216216 0.0395805642 393 3.7158469945 103 3.6756756757 0.0401713189 394 3.7704918033 104 3.7297297297 0.0407620735 395 3.8251366120 105 3.7837837838 0.0413528282 396 3.8797814208 106 3.8378378378 0.0419435829 397 3.9344262295 107 3.8918918919 0.0425343376 398 3.9890710383 108 3.9459459459 0.0431250923 399 4.0437158470 109 4.0000000000 0.0437158470 400 4.0983606557 110 4.0540540541 0.0443066017 401 4.1530054645 111 4.1081081081 0.0448973564 402 4.2076502732 112 4.1621621622 0.0454881111 403 4.2622950820 113 4.2162162162 0.0460788658 404 4.3169398907 114 4.2702702703 0.0466696204 405 4.3715846995 115 4.3243243243 0.0472603751 406 4.4262295082 116 4.3783783784 0.0478511298 407 4.4808743169 117 4.4324324324 0.0484418845 408 4.5355191257 118 4.4864864865 0.0490326392 409 4.5901639344 119 4.5405405405 0.0496233939 410 4.6448087432 120 4.5945945946 0.0502141486 411 4.6994535519 121 4.6486486486 0.0508049033 412 4.7540983607 122 4.7027027027 0.0513956580

_____________ John, Measured in "Zapruder Frames" Z312 precedes NS22 by 0.140541 frames. Z313 precedes NS23 by 0.129730 "Zapruder frames" I think it is safe to call Z325/NS35 a benchmark point. We should also look in to how constant the frame-rate of a wind-up camera holds as the spring unwinds. While it seems obvious that Z325=NS35 and the observed results seem to align with the math, it would be good to know if the assumption of decently constant framerate is appropriate. I think it is a reasonable time to start looking at the Muchmore sequence as well.

The math of Nix and Zapruder... (I have a spreadsheet I can share if anyone is interested.) I have set Z-325 = NS-35 and am calling this the "zero" point on a timeline. The alignment in this frame is quite good and is a reasonable place to consider a zero point. There is, of course, a valid argument to use 324/34 or 326/36 - I'm not sure it is going to matter that much. Using this as the base point, here is what the math yields: Z312 occurs at -0.7103825137 (0.71038.. seconds BEFORE Z325) (computations based on 18.3 frames per second) Z313 occurs at -0.6557377049 NS22 occurs at -0.7027027027 (computations based on 18.5 frames per second) NS23 occurs at -0.6486486486 (the values are negative because they happen before the zero point of Z325/NS35) Interpretation: The shutter opening for Z312 occurs very slightly (0.0076798110 seconds) BEFORE the shutter opens for NS22. The shutter opening for Z313 occurs very slightly (0.0070890563 seconds) BEFORE the shutter opens for NS23. Sanity check: Given the diverging rate and the math, is the previously observed difference (Clint Hill's Foot) consistent with expectations? The previous alignment paired Z380 with NS90. Z380 Occurs at 3.0054644809 seconds after Z325 NS90 Occurs at 2.9729729730 seconds after NS35 In other words: NS90 occurs 0.0324915079 seconds BEFORE Z380. This is nearly 6/10 of a frame difference with Nix preceding Zapruder. Thus the fact that Hill's foot is OFF the limo in NIX and ON the Limo in Zapruder is expected behavior. Base assumptions: The published frame rates (18.3fps and 18.5fps are accurate) The cameras maintained a constant framerate (at the published rate) through the sequence. Z325 = NS35

The following sequence is from the NFV/Groden DVD's Nix film. The sequence is the NS21 - NS24 headshot area, and has been optically zoomed. Please notice the skull-shape distortion in NS22. This is why I am currently of the opinion that this is the true headshot frame in the Nix film.

Hi Bill, I'm not quite sure I'm ready to say "cannot" either. It is my opinion, at this time, that N22 is the closest frame (between the two films) of the actual headshot. I'll try to post something that illustrates from where this opinion has been formed. However, I must point out that N23 could follow Z313, and what we are seeing is the aftermath of the large splatter in Z313, as opposed to an event preceding it. Also, the Nix camera has more zoom-lens distance-compression effect in play here (plus it is at a greater distance, reducing detail based on the resolving ability of the film). Yeah -- that is a lot of words to say, "I'm not sure..." On the other hand, you could very well be correct. At this writing, I'm fairly comfortable with saying NS35 = Z325. I'd like to make a table with Z325 set as "Zero time" and work forward and back using "shutter interval math" to see where frames line up in this continuum.

and in sequence... and the sync portion slowed down...

John, Nicely done, again. I have looked at this, too, and for my eye, NS35 matches Z325 very, very well. This particular frame has all the characteristics necessary to produce a good temporal alignment. Specifically, it contains very quick motions from muscles capable of exceedingly fast movement (arm, wrist, and fingers.) If you look at my image sequence below, you can see that in Z325, Jackie moves her had away from JFK's head. This is a quick, upward motion of the wrist and fingers - not unlike the motion one makes when shaking water off one's fingers or pulling away from something hot. These muscle groups are VERY capable of rapid motion (just watch a professional percussionist play, you'll see what I mean). That gives this frame the characteristics needed to be a target for alignment. If you look at the surrounding frames, Z324 still shows hand-to-head contact, and Z326 shows the hand well away from the head (like touching something hot.) If you observe the corresponding NIX sequence frame, NS35 is the only one that shows this characteristic hand location and shape. NS34 still shows the hand curved and near/on the head. NS36 shows spacing. NS37 and Z327 both show the right hand descending. I'll post a synched version in a bit (with NS35 = Z325).

John, Terrific work. I had it in my queue to track the vertical error, but I've been running on overload over the past few days. I also need to get back to the Zapruder-Nix synchronization details. Perhaps this weekend will yield some free time. There are several other opportunities to establish a baseline sync estimate. Anyway -- I think the next thing to do is look at how factoring your previous example (with the vertically stacked Z-frames and lines) might be impacted by adjusting the lines relative to the tracking error. I honestly don't know if this accounts for the anomalous areas...

David, There is clearly bloodsplatter in the Nix film. Nix re-started his camera while the limo was on Elm and captured the headshot, along with the resulting aftermath. On the NFV DVD (Groden) it is quite visible. The visible splatter occurs at NS-23 (the 23rd "sequence" frame after the restart). However, close examination of the film shows that skull shape distortion is visible in NS-22. This is why I'm currently leaning toward NS-22 preceding Z313 slightly. According to a message I received from Gary Mack, the Nix camera was tested and found to operate at 18.5 fps.

The following is a still frame-pair from my previous Zapruder-Nix Clint Hill Sync example. Refresher - For this example, NS-22 = Z-313. In this frame, we are looking at Z-380 on the left, NS-89 on the right (67 frames after NS-22). As you can see, the Nix film is slightly behind the Z-film. Agent Hill has both feet on the limo in the Z-film, but hasn't done so yet on the Nix film. The FBI tested the Nix camera to operate at 18.5 frames per second, Zapruder's at 18.3 fps. Thinking out loud for a moment, in 10 seconds, the Nix camera would have exposed 185 frames, Zapruder's camera in the same span of time would have exposed 183 frames. Every 5 seconds, the Nix camera takes 1 more frame than Zapruder's. The Z-frame in the above example was exposed 3.6612 seconds (67 frames) after Z313. *If* we postulate for a moment that NS22 is an *exact* match to Z313, 3.6612 seconds later, we would expect to see some drifting in the sync -- over half a frame worth of drift, based on the 1 frame every 5 seconds baseline. The Nix film would, when matched frame-to-frame with Zapruder, appear to be "behind" by about 3/4 of a frame. By NS-90 (the next frame, which is aligned to Z381 in the clip), Agent Hill's foot is on the bumper of the limo in the Nix film. Here's the associated theory: Assuming the tested frame-rates are accurate and I've done my math correctly, NS-23 cannot be a *perfect* match for Z313. The reason is because this would cause our side-by-side example to show virtually no drift 67 frames later. Thoughts?

Hi John, What I'm talking about when I mean "tracking error" is Zapruder's ability to accurately follow what he was attempting to film. I put together a conceptual example of this by using Z-300 to Z-320 (from the MPI set). I created a vertical yellow line to mark the right hand edge of the frame. I then created a horizontal line and extended it to the crossbar junction on the limo windshield. The following picture shows Z300, Z320, and the position of the limo relative to the edge of the frame. There is a delta of 2-3 pixels on where MPI "registers" the right hand portion of their frame, so there is some "thickness" to the composite vertical line for this reason. Also, some frames were blurry, and my horizontal length indicator was (honestly) just a best guess.

The most obvious follow-up question is: are you sure what you're seeing isn't attributable to "tracking error" by Abraham Zapruder? I didn't have much time yesterday evening, but I looked at length at Z311 and Z312 in particular, and there is something in the sequence of those two frames that I honestly do not understand. I need to think about it more, though, so I don't post something that makes me look like a total imbecile... (some might add an "again" to the end of this sentence!)

John, So, If I get you correctly, you are detecting anomalies in the area where you have left a blank frame on the right-hand side. That is to say, the possible appearance of a missing frame. Based on your graph, if one were to engage in Ashton's "tampering" exercise, is it safe to assume that the sequence below is the one to use: ... 308 - 309 - 310 - 311 - X - 312 - X - 313 - X - 314 - 315 - 316 Where "X" represents where one should create a "tampered" frame? Also, the "tampered" frame should properly align with the white lines on the right-hand side sequence, correct?

I think that would be quite possible, especially if we're allowed some "blurry" frames. Heck, the original z-film is full of 'em... I might be tempted to start with some sort of temporal "smoothing" algorithm to create some faux frames for the "gap". I'm still actively trying to mentally digest what John D. has shared. As with all things, I encourage independent verification of results and replication of technique. Personally, I've got some family obligations for this evening, but I'm certainly planning on looking at this, as well as pursuing other sync studies. These are very much in their infancy. There *is* drift in the Clint Hill video -- it is all but impossible to see in anything except the original frames. I need to find a way to present it, and to see if it makes sense. Another point that this thread has brought into evolution is that we have certainly NOT exhausted the photographic and film evidence. Even independent of super-resolution sources, we have the ability and tools to inspect macroscopic concepts (like sync, drift, etc) in new ways. I haven't even begun to crank up some of the things that I think can be accomplished. (some days I need more "vigah", as you say, Ashton! - along with a winning lottery ticket or two, and a 30-hour clock).

Originally, they are 720x480 JPG (75%Q) images from the "under sprocket" version from the MPI DVD. Again, no processing was applied.

Of course, the MPI video is MPEG-2 content. The largest issue with the DVD source has nothing to do with Inverse Telecine, Interlacing, Pull-down, Progressiveness, frame-rates, and the like. These are nearly non-issues, as fully progressive frames can absolutely, positively be extracted from the source. You hit on the real issue here: "All of this frame-drop frame, 3:2 pulldown, DVD-MPEG2 nonesense could be eliminated if we had access to the *new-1998*35mm frames of the actual in-camera original Z-film..." From your mouth to God's ears! The biggest issue with the MPI DVD is the RESOLUTION and the LOSSY nature of MPEG-2 compression. The DVD spec is ONLY 720x480 resolution, and MPEG-2 is a LOSSY compression technology. MPI even used a superior non-standard GOP on their DVD (IB PB PB PB PB PB P) (God, how big of a loser am I for knowing that) to improve the quality. However, the MPEG2 standard is lossy even at max bit rate and with a superior GOP. 720x480 looks great on a TV, looks OK on an HDTV, and OK on a monitor. However, compared to what should be resolution of the scanned 4x5 trannies, it should be very low. The best thing for the research community would be access to loss-free stills of the individual frame scans.

David, I'll address your message in two parts for (hopefully) the sake of clarity. I'm not personally familiar with that particular Apple tool, as I don't use Apples for anything. However, I' sure their comment doesn't mean that an MPEG-2 source cannot be converted to a progressive format. It may be that this particular tool cannot do it *directly* from an MPEG2 source. MPEG-2 is a temporal compression technology. Frames in an MPEG2 video file are of three different types: I-Frame (Intra-coded frame): This is a compressed, but "full" frame, that doesn't depend on any of the frames that preceed or follow it. P-Frame (Predictive frame): This is a delta frame, that contains information that has changed relative to the preceding I frame. B-Frame (Bi-directional predictive frame): Another variant of a delta frame, these frames look both ways - to the following and preceding frames. The MPEG2 standard organizes these frames into what is called a "Group of Pictures" (GOP), which for most DVDs is: IBB PBB PBB PBB PBP. (The pattern then starts again. Every 15 MPEG2 frames is an I frame in the default pattern). Now -- if I want to look at individual frames within an MPEG2 stream, it is up to the software to be able to build each and every frame in full, because as I mentioned before, computers deal with progressive frames. So, the software working with the MPEG2 stream must be able to build full frames even though any given MPEG2 frame may not be truly "complete". It accomplishes this by starting with the nearest preceding I-frame and building successive frames until the desired frame is built. This is among the many reasons that MPEG2 is NOT the desired format for performing video edits. Many software packages, consumer recording devices, etc, that work with MPEG2 allow breaks ONLY on I-frame boundaries -- every 15 frames. Nevertheless, it is completely possible to recover purely progressive output from an MPEG2 source. It might, however, require two steps to do so -- initially converting the MPEG2 source into another format that is not a temporal compression technology. This is precisely what I did when I converted the DVD VOB files (which are MPEG2 files) into a lossless-compression AVI file. The Apple software you have probably requires a non-temporal input source to perform IVTC. Just convert the MPEG2 to a different format first. Then you can recover the progressive content via IVTC.

The joys of NTSC and film sources... The following frames are from an NTSC DVD source. The frame number is relative to the beginning of the video file, not to the actual film source. To reduce this to purely progressive video: Remove: - frame 353: it contains no unique information. It is a combo of two other frames - frame 356: duplicate - frame 358: duplicate The result is non-interlaced progressive video. This is the Inverse Telecine process "de-automated".

dgh: 3:2 pulldown by hand? Curious, how'd you do that? Thanks.... Pulldown by hand is by far the best way to do it... It just takes a bloody long time. For short clips like these, though, it is tolerable. The key to the whole thing is to remember that computers deal solely with progressive content. Software media players are fully progressive entities, so when they are "playing" something, they are really flipping full images. The file structures (containers, such as .AVI) must contain full frames. When the source DVD is ripped, the resulting files will contain full frame images. Note -- this is NOT to imply that the video is progressive at this point. I'm merely stating that you don't have partial frames, etc. The resulting video container *might* (or might not, depending on how ripping was done) contain up to three things: progressive frames, telecined frames, and interlaced frames. The software that I wrote (and there are dozens of applications that can do the exact same thing) merely grabs one frame at a time from the video container (.avi file, for example) and saves it as a still (.jpg). The result is a folder full of still images -- each one full frame, but not necessarily progressive. I then go through the folder and remove duplicate frames (telecined) and interlaced frames. The result is a series of images that represent the original progressive source frames. This is exactly the same process that IVTC software performs (apps such as TMPG, AfterEffects, Premier, Vegas, et al), except they attempt to discern the pattern based on frame change information, horizontal lines (interlacing), etc. If the pattern is pure, IVTC will work. Odd patterns lead to dropped frames (like we saw on the first NIX example). Doing it by hand takes a while, because I have to check each image. However, it is guaranteed to not go haywire (unless I go haywire, of course). (I'll put a quick example together and show what I'm talking about visually). dgh: good idea, I asked the Lone Nutter's years ago to display the seamlessness of the DP films, this is the closest anyone has come to date... It will be most interesting to see if things are seamless or not. This is a fairly tedious process, and there are still some significant hurdles to cross - most notably in the "presentation" side. Nevertheless, I think there is merit to the technique. Perhaps the 6th floor museum will provide 1st generation digital copies of the film frame, anything short of that and it'll be a tough sell with the alterationists... I think it is fair to say that all would welcome the best possible sources.

David, No need to apologize for questions. Such inquiry is a vital part of any research. The z-film frames that produced the clips are straight from the MPI DVD -- honest! No unsharp-mask, nothing. I'll describe the process that I used for the film frames in detail: * I ripped the DVD to its constituent VOB files. * I opened the VOB file containing the z-film "Under Sprocket Hole" version in VirtualDubMod. * Inside VDubMod, I selected the portion of the video that I wanted. * I saved the resulting clip as an AVI file (no sound) using the Huffy lossless Codec. At this point, I had a very large AVI file, that contained 29.97fps interlaced video. (Huffy is lossless, but tends to produce LARGE files) * I opened the AVI file in a utility that I wrote myself that can produce a JPG (or any other format) image for each video frame in the AVI file. * This utility saved a series of JPG files (Q=75) representing the contents of the AVI. Each file is a 720x480 resolution jpg (same res. as the DVD source, of course) * I then performed the IVTC process by hand. At this point, I had a directory full of jpg images, each one representing one z-film frame. (same process was used for Nix frames, etc) ----------- I do not have an answer to the speed question. It happens only on the gif, and only on firefox. The appearance of missing frames is an illusion that is the result of my attempts to align the n-frames. Agent Hill, which was my target for registration, is obscured from view on several occasions. Plus, Nix's camera is panning to catch up with the limo. As such, the motion (toward the end) appears to hitch (like a missing frame). Nevertheless, I'll verify that all the frames made it in there and in the correct order. I've been a bit under the weather the past few days, so it wouldn't be outside the realm of possibility to have an error in there! I used ImageReady to make the Gif. The "duration" of each frame is set to 0.05 seconds -- this is as close as I can come to 18.3 fps, as ImageReady does not accept 0.0546 -- it merely rounds it to 0.05. Again, though, the Gif is merely for purposes of proving the concept of producing images that have in-sync sources from multiple assassination films. You know all about the limits and problems with Gifs, but for "quick and dirty" stuff (like a proof of concept), they'll do. Ultimately, I hope to be able to produce usable, synchronized footage that allows us to see the events from multiple perspectives simultaneously. This is quite a challenge on two fronts: There are technical issues, of course, but the larger issue is how to present such things in a way that the eye and brain can track.

John, I must be blind for I cannot see your example ... can you point me towards it? Feel free to email me with it if you wish at - Imsjle@aol.com. I would also like to know the source for the film you are using because I have a copy of Groden's 1st generation print from the Nix film and I do not see any missing frames around the kill shot in my copy. I called Groden just now and confirmed my observation with him and this is why I would like to see your example and to find out its source. Knowing this is important because if you are using a latter generation copy that someone has damaged by removing frames - it is a moot point if the same film without missing frames exist. Thanks, Bill Miller Bill, I think we've determined with a reasonable degree of certainty that the frames that were missing from the initial sample were a result of problems with the source AVI file and not with the z-film itself (specifically, the inverse telecine process). When I repeated the test with Groden's DVD as the source, the frame alignment was much more normal. I've posted the spacing distribution earlier in this thread.

David, I don't know exactly why it runs fast in Firefox. It is possible that Firefox is not correctly interpreting the frame duration (0.05 seconds) that I'm adding. It runs at the intended speed in IE. I'll have to look into it a bit more. The only thing I did to the MPI frames was to crop them. (Same for the Nix frames) However, the conversion to GIF undoubtedly produced some changes. The GIF palette is limited due to the nature and age of the standard. Also, to get the sequence to fit on the forum, I had to accept some loss (25% in this case), and the images are dithered (again, due to size limits).

Note -- I have replaced the T. Foster examples with higher-quality versions. Proof of concept 2: Tracking Secret Service Agent Clint Hill Source: Zfilm=MPI Under Sprocket, NFilm=NFV/Groden Generation1 version Temporal Alignment: NS22 = Z313 ZFrame range: Z333-Z390 NSFrame range: NS41-NS98 (Where NS1 is the first frame after the restart) NFrame range: N215-N272 (Where N1 is the very first frame of the Nfilm) Running slightly fast. (If viewing with Firefox, it runs waaaay too fast. IE views the gif at the intended speed)