Kinograph design criteria

1

Hi all,

I get a lot of questions about how decisions about Kinograph’s design are made. I’ve mentioned it here and there what the priorities are and how I try to maintain adherence to a few basic tenets, but I’ve never gathered them in one place, explicitly. This is a rough draft of my thoughts after a long week so it should not be considered complete and will be refined through discussion with you all here.

You will notice his is more about process than specifics. I think that’s an important place to start. Anyone who has read more than 10 posts on this forum will see that there are a lot of opinions on how/what Kinograph should be. That’s a good thing, but it can also be maddening. What I am attempting to do in this draft is define a way of working that embraces a wide variety of opinions while also moving forward at a steady and consistent pace. Our process should welcome all voices, and respond with one.

What follows as the start of an ongoing, open discussion. I would love to hear your thoughts.

Outline:

  1. Philosophy
  2. Principles
  3. Process
  4. Current design goals and specifications

Philosophy

All cultural heritage is inherently valuable.
All collections should be accessible and the Kinograph is designed to be affordable and reproducible for anyone in the world. Where financial help is needed, we will help with fundraising for a Kinograph. Get in touch if that’s you.

Communities of cooperation are the strongest tool we have for saving and sharing cultural heritage.
Companies and governments come and go, the people always remain. By sharing our resources with one another and reaching beyond the limits of private interests we can safeguard the future of film heritage securely.

Mutual Abundance and Generosity of Spirit.
Sharing our knowledge, skills, and resources encourages others to do the same. When we greet each other with respect and openness, in knowledge and in identity, we create a spirit of generosity. This abundance is mutually available to all who uphold these same values within the community. What I have to give I give to you knowing that the community will give back to me when I need it.

Principles

These ranked principles help guide our decision making process in every aspect of Kinograph. It’s a way for all contributors to frame a conversation around a an idea, feature, or design when there is more than one option. When faced with a decision, we can look at each of these (in order!) and ask ourselves: “How does option A affect the cost?" When we have done this for each principle for each options, we usually find that one option starts to reveal itself as the solution. It’s not always perfect, but it usually helps keep the conversation on the right track which isn’t always easy.

It’s a dance of compromise, but in general, these are the tunes we dance to:

  1. Affordable: The Kinograph design should be financially accessible to as many people as possible. Where expensive options are available, the design should also be able to accommodate inexpensive alternatives (e.g. cameras, PCs, etc).
  2. Flexible: The Kinograph design should be easy to modify and improve. Components should be designed modularly so that they are not dependent on one another.
  3. Accessible: Kinograph design should be easy to build, assemble, and operate. No special skills, tools, or knowledge should be required.
  4. Repeatable: any customized parts should be able to be reproduced using common technology widely available throughout the world (e.g. 3D printers) without special training or certification. Where there is no access to technologies required to produce parts, the community is encouraged to provide parts by mail. While Kinograph has no policies on how these transactions should or should not be monetized, we encourage all participants to act in according to our philosophy of generosity and abundance as much as possible.
  5. Good enough: While Kinograph aims to provide a high quality result, we recognize that the definition of “good enough” varies wildly. As our philosophy states (see above), the Kinograph design prioritizes accessibility of content over preservation or perfection. Our mission is to make visual heritage available with a low barrier of entry financially and technically.The official design may not be up to the standards of some, but its flexibility will allow it to be modified to meet the varying needs of every user.

Process

Kinograph’s design is made to be hacked, changed, altered, and extended by its users. Many minds working on Kinograph in a variety of contexts will strengthen its evolution. To support these efforts, an “official” version of the design will exist to maintain consistency. Every part of Kinograph will have both an “official” specificiation, and a number of community alternates.
A council of Kinography community members will be responsible for overseeing the process of accepting new design ideas into the canoncial Kinograph design. For you Python people, this is similar to the PEP process. In our case, it’s an “X-ABC-D” process:

X = experimental
A = alpha
B = beta
C = community accepted

X: Experimental proposals for a new or alternate design for Kinograph can be submitted by anyone at anytime. This will likely happen on the forums or through a dedicated proposal page.
A: To qualify for an official review, the experimental proposal must be implemented successfully in at least 2 other machines. This is “alpha” testing, and is self-organized by the author and community members. This should encourage active, self-sustaining cooperation as well “window shopping” for folks with technical skills who want to get more involved.
B: All qualifying proposals will be reviewed by an engineering board. A proposal has three possible outcomes: revision (needs work), community solution (good alternative, published to wiki), or accepted solution (becomes part of long-term support).

Naturally, this may be too slow for some folks. That’s okay. They can blaze ahead and we’ll catch up. Our goal is not to be the bleeding edge, but to provide a stable foundation from which anyone can spring ahead to solve their own problem, while also continuing to support for existing machine owners and not leaving them in the proverbial dust.

Design Goals

Given all of the above, we are focused on the following simple goal:

A machine that can scan 4K at 24fps for <$8,000 USD, including PC and camera. This is based on an assumed price of $5K for a 4K camera and $1K for a PC capable of handling capture (read: not all of your post-processing dreams, just capture).

To do this, I have made the following choices (more detail to come as the design is finished and I have more time to write documentation):

For sure stuff

  • 35/16 for now. A large 16mm reel is about the same diameter as a standard 35mm reel. The spatial requirements of machines for either format are very similar, so it makes sense to to tackle them both at the same time. The spatical requirements for 8mm are not close to either format and therefore makes more sense to exist as its own separate machine. Doing so will also create an opportunity to design from scratch without inheriting any of the decisions made for the larger machine.
  • Tilted frame to enable scanning of film on cores without a split reel.
  • 8mm x 8mm grid, and the use of goBilda parts for as much of the design as possible. They’re highly quality and can do just about anything. They’re also easy to reproduce with a mail-order CNC service if required (note that goBilda’s parts are copyrighted and would require alteration to legally reproduce). The grid ensures overall compatibility of parts and sets a standard for other people to use to ensure their parts can be shared. Using goBilda’s other hardware makes it easier for non-engineers to create new modules without the need for CAD or specialized fabrication tools. Also, goBilda ships from from the U.S. and Europe.
  • Lighting. Kinograph will support scanning with white or RGB lights. It uses a custom lighting circuit and driver that accepts commands through serial prototcol. The current design has only RGB, but a new design is in development that combines both RGB and white on the same board. See below re: light housing.
  • Machine controls: custom PCB easily reproducible, common parts, with physical controls and optional touchscreen interface via i2c.
  • Software:
    • Kinograph’s control software is written in C++, but I would like us to use Python in the future moving forward to lower the barrier to entry for contributions.
    • No GUI (graphical user interface) will not be provided with the first version of Kinograph due to lack of resources (time and money). The features we need to build are not hard, but will require coordination. It is a perfect opportunity for the community to extend the project and provide high value to machine uses early on. I foresee us adopting Python as our overall preferred language, and using open-source and/or common standards for anything we build. For now, we will use software that comes.
  • Gates will be swappable and dedicated to a single format. I had a design that was mostly working for a flat gate with a pressure plate, but I was noticing some lateral pinching and I’m taking a two-path approach to fixing it. First, I’ll just make a curved gate and I’m going to have it fabricated at a local CNC shop. Second, I’m going to revisit my roller design and make sure that’s solid and not contributing to any shifting of the film as it enters or exits the gate. I’ll re-try the flat gate and test the curved gate in parallel.
  • Film is moved with a large diameter capstan roller. A larger diameter spreads the surface tension along a longer segment of the film (less stress per frame).
  • You buy the camera yourself. This is mostly because you will need to own the license for the software that comes with it in order to use it legally. The software that comes with the cameras is meant for trial purposes only, not as part of a reseller’s offering.
  • Bring your own PC. If you don’t need to scan 4K or run at 24fps, you can get away with an older PC and save money. Typically, the camera software runs best on Windows, although some do offer applications for Mac and Linux.
  • Newly adopted features to the “official” design will never make a Kinograph non-functional. They may, however, require the adoption of other proceeding features in order to work. Adoption of new features is always optional. Long-term support of official designs and is prioritized until a new version set is required to ensure on-going stability.
  • Community support is the primary means of resolving technical issues. When that is not enough, issues could be escalated to a member of the engineering council or me directly if the user is unable to solve their problem. I may later decide to offer a paid support tier, but that’s very TBD. Basically we’ll all do our best to help people out and share the work of doing so. If it gets to be too much, we’ve either got a bad design, or we need a more formal process…but we’ll cross that bridge when we get there.

Not-so-sure stuff

  • Lighting: integration sphere or flat box…TBD with more testing.
  • Idle rollers are currently small PTR rollers, but I am seeing some side-to-side shifting of the film currently. I’m troubleshooting and am not ruling out the possibility of going with a different roller design. I will know in a couple of weeks.
  • When non-profit status, boards and councils, or community management will be implemented
  • Film cleaning. For now it is assumed films have been cleaned before they are put on Kinograph. If not, debris build-up could affect results. There are two possibilities to pursue in the future, however: a wet gate, and the ability to run the machine in “inspection” mode, which could be used for basic cleaning.
  • Support.

Whew, okay. Have at it.

2 Likes
2

I think this is a smart move. The Northlight scanner is all command line, with a simple GUI that just calls that command line. Anything you can do in the GUI you can do from the command line as well. This opens the door for a few things:

  1. You can run the machine remotely if necessary
  2. You can integrate scanning into a batch script (So you could set up a script that scans a reel and when complete copies it to some location, or tars it up, or some other post-scan processing sep).
  3. You can build a custom GUI on top of that command line that fits your specific needs

It significantly reduces development time, debugging time, and overall dev cost, so I think it’s a good idea. And if you switch it to python but keep the command line arguments the same, then it’s more or less seamless for any GUI to move from the C++ to the Python back end.

3

@matthewepler sorry I could not make the zoom/townhall. Glad to see that you are back with your project, and pushing it forward.

Some thoughts for consideration…

From what I have seen in other forums, particularly the great results of @Matteo_Ricchetti1 in his Facebook contributions on the DIY Cine Film Scanner Makers Group continuous movement it would make a significant improvement for the light driver to have a direct digital input to control in real time the on/off of whatever is set via serial.

White or RGB… only? assume that means no WRBG.

The shape of the light kind of define the illuminant intensity requirements, and those kind of define the driver / controller. Suggest to nail that not-so-sure light shape to avoid putting the carriage in front of the horse in designing the LED electronics/controller.

Not sure 8 should be left alone… 8/S8/9.5/16?

Smaller formats, smaller lengths, and much smaller budgets (1/6 of above) are also looking for generosity of know-how, technology… tools. No need to get as fast as 24 fps… even stop-motion is better. But understand that neither (8 or stop motion) are part of Kinograph, and best not to distract from realizing 35/16. Just a thought.

4

Is this continuos movement of the film, or is it stop action, either mechanical or driven? If the film is moving through the gate during the exposure, wouldn’t that mean you need a very short exposure time. I don’t know the frame height for 35mm off the top of my head, but if we assume about 22mm, the film is moving over 500 mm / second. 4K video is 3840x 2160 pixels (give or take). Rounding off some of the numbers, a pixel, at the film plane is about .01 mm, so at a pixel level, the pixels are moving through the frame nearly 50,000 pixels per second. So, to have “only one” pixel of smear, your exposure would have to be 1/50,000 second. Coming at the math a different way, 24 fps x 2160 pixels per frame is 51,840 pixels a second.

When one is taking a film movie, the film stops temporarily during exposure. At 24 fps, you could possibly get to as slow a shutterspeed as 1/30 of a second, but let’s be more reasonable and say 1/60th or 1/125 s way slower than one would need with a moving film.

At f4 and assuming one one is using the sensor at ISO 100, and 1/50,000 s exposure time, this is an EV of between 19 and 20. I think this works out to about an illuminance of 1.3 to 2.6 million lux. Lux being lums/m2. If we figure out the area of the film (about 22x18 mm) which 396mm2 and a square meter is 1,000,000 mm2, we get 1/2,525 of a square meter or about 500-600 lumen output if all of that is uniformly across the area of the film gate. No extra at the edges, no distance, etc. In reality this number will be quite a bit higher in order to have unifrom illumination at the film plane. There are plenty of LEDs that will put this out, but you will probably need active cooling. Perhaps this has been penciled out already and it’s not an issue, or perhaps my back of the envelope estimate is way off. I just thought I would mention what thought might be challenging.

2 Likes
5

You forgot to highlight your key axiom: open-source film digitization! As much of the Kinograph as possible should be under open-source community control, even if there are better and easier to utilise solutions/alternatives.

There’s nothing wrong with supplying modules pre-assembled/built IMO, so long as it is clearly documented how to build it yourself. If you ask me it’s ideal if someone builds the LED light module and sends it out as that is quite a complicated part to build yourself.

Agreed, and that design will allow users the option to set them as dedicated to just one format as well (eg 16mm-only).

Then ditch their software. It’s just a basic wrapper for API calls to the camera, it’s nothing you can’t do yourself and then you can discuss wholesaling the cameras instead of buying them retail bringing down the overall costs. Plus it brings the software under open-source control, which means you can add things to it that the camera manufacturer won’t do with their “evaluation software”. Debayering algorithms, colour inversion LUTs for different film stocks, etc.

The cameras are dirt cheap now too, here are some suitable Teledyne cameras 2K/4K/5K res, ranging in retail price from $740-$4,800.

You also need a global-shutter camera, and it’s why you need a bright light. This trailer was scanned DIY with a 50W Yujiled COB light and a 4K Blackfly S camera (in a modified Retroscan) vs ScanStation. The Yujiled was permanently on, hence why you see some smearing in the scan. The ScanStation was run at 6.5K 2-flash which is 7.5fps. It’s not the best quality trailer, but you can see that the quality is perfectly fine in terms of scanning while in-motion, most people would not even notice that smearing if it’s not pointed out to them. The scan does not have excessive sensor noise.

In terms of the Kinograph, the light needs to flash anyway because otherwise you need even more cooling and it’ll fail/blow-out sooner. So it’s not just a question of scan quality, a good light module will last many years without ever wearing out. Think of it like the camera - the machine-vision CMOS camera will last you as long as you want now.

In terms of the continuous-motion reducing optical resolution due to blur - that does happen when you run the commercial scanners at high speeds like 30fps or 60fps, and will also depend on the type of film and its condition. That’s one reason why you have the ability to slow them down artificially. For the Kinograph’s purposes the preference should be 24fps with the ability to go slower if the operator wants.

None of the commercial machines have projector-loops anymore. They’re either continuous-motion through the gate, or full intermittent motion like the Arriscan which makes them hardware incompatible with audio readers. I will note that LaserGraphics gets around that limitation for optical audio by using a line camera to extract optical sound and then it does software decoding, that’s why the Director has an “optical sound reader” but not magnetic sound readers.

For the Kinograph’s purposes there’s no reason you can’t make an intermittent motion film transport module for R/G/B sequential with a monochrome camera, but you need to start with a simpler continuous-motion module first. R/G/B sequential is definitely not required to get a GOOD scan with a good quality CMOS camera. The issue with trying to do that from the very start is that most people will never need it, and for RGB sequential you have the option to build the projector loop later as its own module whether as a complete second transport module, or as something you insert into the “Kinograph base film transport module”:

Sony FVS 1000 film transport module
Sony FVS 1000 film transport module1050×905 120 KB

(Sony FVS 1000 film transport module)

For the Kinograph that would allow much faster RGB sequential scanning compared to a full intermittent motion transport module.

6

quote
You forgot to highlight your key axiom: open-source film digitization! As much of the Kinograph as possible should be under open-source community control, even if there are better and easier to utilise solutions/alternatives.

/quote]

I think the machine could be a completely open source device and be a completely assembled product at the same time. I purchase lots of electronics components from the likes of Adafruit, Sparkfun, Pololu, etc. The circuit designs and software (typically libraries) are all made available, but who wants to layout their own PCB, have it made, then assemble from separately purchase components. In small quantities it is neither cost effective, nor worth ones time.

I’ve got to say that not all 3D printing is the same and just having an STL file to print a component does not mean you can make a component of adequate quality to perform properly. If I am running a film scanning service, I most likely don’t want to build a machine, I probably don’t have all the tools to do it properly, nor personnel to do a proper job. Not to mention, even if I have those items, is it really worthwhile to spend time tinkering and assembling, or just get down to the business of scanning. I suspect the later.

The link to the Sony machine is quite informative.

I suspect a large number of components will be expensive to source at the individual level as they are going to be semi-custom parts. Lets face it, a single PCB order, plus buying all the little parts to populate it, then assembling and not screwing up by putting a diode or cap in backwards, compared to a run of say 100 boards doe by a PCB house are two different things. Now if it’s open source, 5-10 years down the road, I could repair or replicate it to keep a machine running instead of junking it.

1 Like
7

If you need to design electronic circuits, expect it to be quite complicated. On my scanner, the two printed circuits I had made serve only as connection nodes. The other components—power supply, optocoupler, etc.—are all off-the-shelf parts.

The best 3D part is the one you don’t have to design (well, that’s a bit of humor, but I’m not sure how well it translates). When designing for 3D printing, always prioritize parts that don’t require extreme precision. Even more importantly, every part must be adjustable—this is non-negotiable. EVERYTHING must be adjustable. Friction and movement should always rely on purchased metal components, such as slides and ball bearings. These parts are lightweight, durable, and easy to ship.

A quick side note… When you say something is impossible, 90% of people will believe you. When you say it can be done, getting even 10% support is already a win.
(@Friolator, this time, the numbers are just my gut feeling.) :slight_smile:

This time I won’t intervene, of course.

8

All good points, thank you for the feedback. A brief reply in bullet points:

  • I think we’re saying the same thing re: light and continuous movement. Digital input to LED driver for precise control of color, duration of light flash, etc. Or did I get that wrong?
  • W/RGB - I will check with my PCB designer to ensure we can run both the W and RGB at the same time. The LEDs themselves are not integrated as WRGB. I wanted to be able to select the wavelength of each color myself.
  • Light box shape. Yup. You’re right. Best way to know for sure is to test. PCB design is almost done and boards will be ordered this week.
  • 8 solo…the other formats were implied, but I could have been more explicit. I will do so in the future to avoid confusion.
  • 24fps…yes, I hesitated to include that 24 was a goal, but not a “must.” As Octavia Butler once wrote, when aiming, aim slightly above your target.
9

Thanks for the feedback, John.

  • Motion is continuous. Your assumptions regarding the need for a quick flash of light are correct. Building an intermittent motion mechanism from scratch that can handle fragile film, retain tension, and remain consistent in its registration of frames was beyond my interest or capabilities. I would welcome anyone to bring their expertise to the task! It has been my experience that most machines do not use intermittent motion.
  • Re: math. It’s a beautiful thing, but not my strong suit. It often gets you a good first guess, but there is no substitution for hands-on experimentation. I hope to get machines out to a few engineering types who can do that and expand the overall capabilities of the machine accordingly.
10

Thanks for the feedback @filmkeeper !

  • Re: “open-source film digitization” is implied and hopefully obvious to the audience on this forum. But it’s a good note if I decide to take that text and post it elsewhere.
  • We’re saying the same thing. Modules, parts, etc. The point is peer-to-peer manufacturing and distribution of custom parts.
  • Software…agreed. Using manufacturer software is not a long-term solution. I can’t build the machine and develop the software at the same time. Instead of waiting on both, I’m releasing the machine with software that does the same thing, at zero cost to me or the consumer. Win-win. Once the machine is out there, we can start working on software together, since we’ll have machines to test it with and more than one human working on them.
  • Motion, lights, etc…you’re spot on. We’re keeping it simple so that we have the basics done right from the beginning. Basic scan with basic lights with basic motion - but good results. We can add complexity when/where we see a need as we go.
1 Like
11

(post deleted by author)

12

I could use some information on the 35mm and 16mm film stock dimensions, ie normal gate size, precise width, sprocket locations and dimensions. I’ve not penciled out the accelerations and decelerations the film and any rotational components have to go through, but I suspect that they are not so bad that a pawl-less intermittent motion could not be achieved. I would still use the idea of optically locating the film. It would not be too hard to have an acceleration/deceleration profile that has the film slowed shortly before the sprocket would be detected, so coming to a quick stop would not be hard.