My tiffcine program reads a bitmap image of a film strip, analyzes the image to detect sprocket perforations, and writes out separate images for the cropped single frames in the strip. These frames can in turn be combined into a digital movie file.

This is experimental software, and as such it requires that you configure a few constants in the C source code for the geometry of your film scanning arrangement. Various manifest constants in the source code indicate the dimensions of the film format, geometry of the gating, edge locations in the scan coordinates, greyscale threshold for perforations, numbered output file name sequence, etc. So to actually use this (not simply to have a look and see how I did it), you will need some programming skills and tools, and you will have to study and modify the code. A full implementation would permit configuring these items without having to recompile the program, but I would rather put my immediate efforts into researching and developing the detection algorithms rather than elaborating something "user friendly".

The program assumes that the input film strip scan is horizontal (that is, the film "runs" along the X axis, like the image at the top of this Web page), with the first frame at the left edge. This assumption reflects the natural configuration of my test scans. As part of its processing, tiffcine rotates the individual frames 90 degrees clockwise to their upright orientation when writing them as TIFF files. There is no provision to mirror, to stretch, or to otherwise transform the images, although such would be desirable for a full implementation. To use tiffcine on other input orientations, you would have to do your own pre-conversions using an image editor.

You will note that there are references in the code to an FFT (fast Fourier transform) library. This is from my experiments using discrete Fourier transforms to correlate perforation patterns. The simpler XOR correlator works so well that I gave up (for now) on the FFT methods. The FFT references are turned off in the code and you should not need that library to compile the program.

My XOR correlator method, which is also described on my FSDT page, examines the strip of pixels you indicate as passing through the sprocket perforations. The correlator first characterizes each pixel in the strip as showing perforated or unperforated film, based on a simple greyscale intensity detector. For positive film (that is, the perforations appear white in the scan), the detector considers pixels above a certain threshold to be perforations; for negative film (digitally reversed after scanning, so perforations appear black in the scan) the detector considers pixels below a certain threshold to be perforations. The location of the 1-pixel perforation strip in the overall scan, and the appropriate threshold greyscale value, are something you must manually characterize, which is easy to do in a bitmap photo editor, typically by cutting and pasting the pixel strip from a sample scan as a new image and examining its intensity histogram. Thus the perforation strip is reduced to a bilevel image with a noisy perforation pattern. Against this post-detector "real strip" (the digital film), the correlator matches an "ideal strip" consisting of the bilevel image that would be expected from a noiseless, undistorted scan of a perfect film perforation pattern (the digital claw). The match is repeatedly applied with a "phase shift" of some number of pixels between the strips, the phase shift varying from 0 to the nominal height (in pixels) of one ideal perforation interval. The result of each match is the count of matching phase-shifted pixels, which reaches 100 percent at the phase shift which aligns the real and ideal perforation patterns. In practice, noise in the detected strip scan only arises from stray marks between perforations (such as "Kodachrome" trademarks, and the like) while the thresholding itself is nearly perfectly accurate. The resulting correlation function, which gives the match count as a function of phase shift, is typically shaped into a flat response with a single sawtooth pattern, with the peak of the tooth corresponding to the phase shift of the leading edge of the ideal versus scanned perforation. Depending on whether the ideal perforation is shorter, equal to, or larger than the scanned image, the sawtooth may peak at some value below 100 percent, or the peak may be flattened over several pixels of phase shift. In any case, we take the first maximum value as the result, which corresponds to the number of pixels from the start of the scan to the leading edge of the perforation. Digital sampling theory implies this technique has an ultimate registration accuracy of plus or minus one pixel, which in practice seems to be achieved with good-quality scans.

Download the tiffcine.c source code in ANSI C for Windows or UNIX.

This program in turn uses the free libtiff library for reading and writing TIFF files. You must first have that library installed before you can compile tiffcine.

To simplify my work, I have used the wonderful ability of libtiff to read virtually any variety of TIFF file into an 24-bit RGB bitmap with one function call to TIFFReadRGBAImage(). Consequently, tiffcine performs all its image manipulations in that form of bitmap, whether particularly appropriate or not, and the output images are always 24-bit RGB uncompressed color TIFF files.

Note that tiffcine implements a "TIFF cropper", that is, it can produce TIFF files which are cropped pieces of a source TIFF file. I don't believe the magnificent libtiff distribution itself contains such a utility, nor am I aware of any other free software for this function. It would seem to be a logical extension to the tiffcp command of libtiff.

To make a movie from the individual frame files produced by tiffcine, you'll need an application with an "animate frames" feature, like Adobe Premiere (a commercial product), to produce a clip as a digital video file. Projects such as the MJPEG tools [sourceforge.net] offer free command-line tools to animate frames.

Once you have a digital video file, VirtualDub is an excellent free utility for compressing it, for cutting and splicing it with others, and for adding audio.

Perhaps I will get around to writing an uncompressed AVI export feature for tiffcine. AVI movies can contain uncompressed DIB bitmaps to represent frames, which in turn are just the RGB pixel array with a header, so this doesn't involve any effort with codecs and the like, which is best left to other tools like Virtualdub.

The application of the tiffcine principle is not restricted to movies. It can, for example, extract still photos from a scanned negative strip.

I invented the name "tiffcine" by combining the file format name "TIFF" and the term "cine" (Gk. kineo, to move) from film terminology. As a telecine process converts analog movie film to analog video (television), so tiffcine converts movie film digital images (as TIFF files) to digital movies. Those ideas are more inverse than parallel, but so what. Pronunciation may be "tiff-seen", "tiff-sin-eh", or "tiff-kin-eh", depending on your mood (accent on the "tiff"), the first being my usual way, but the last being most faithful to the etymological roots. I am fond of ambiguous pronunciation for technical names; it intimidates the naive and uninitiated into a greater respect for the underlying effort.