Image Sensor / Optical Components

Hello Matthew and everyone in this forum. First of all: I am a non english-speaking person so sorry for my writing. I´ll try my best. Also: thanks for sharing your efforts and results, this is a great project and everyone seems seriously involved, which is outstanding.

I am just getting started with Kinograph because, as may be the case with others here, I must digitize many 16 mm films that will seriously deteriorate in short term. That is why I should start building the Kinograph soon. I begun with camera/sensor because, due to prices and heavy import taxes, it would be the most difficult item to get.

I have read this whole conversation and found out that the camera/sensor possibilities are more than I expected, so I just wanted to ask for some updated guidance on the subject. What I would finally (and ideally) need is a 4K transfer (aprox.) with good image quality and output format and not too long digitizing times. Also, I need a system that is gentle with film and can work in spite of broken sprockets and other problems (I mention this because of frame sensors and intermittent motion). For the moment budget is an issue, but I might eventually get some funding.

These are the different brands and models that were discussed since august 2015 (and others I found out while reading and searching):

Point Grey
a- Grasshopper3 12.0MP: 4240 x 2824 / 7 FPS / global shutter / frame camera / C-mount / $3695
b- Grasshopper3 12.3 MP : 4096 x 3000 / 30 FPS / global shutter / C-mount / $3095
c- Blackfly S Color 20MP: 5472 x 3648 / 18 FPS / rolling shutter with global reset / C-mount / $695
d- Blackfly S Color 12.3MP: 4096 x 3000 / 30 FPS / global shutter / C-mount / $2795
e- Blackfly S Color 8.9MP: 4096 x 2160 / 42 FPS / global shutter / C-mount / $2495

a- Piranha 4: 4K / Camera Link / requires Frame Grabber hardware / global shutter / $4000 for sensor, $1200 frame grabber, lens?

e-con Systems
a- See3CAM_CU130: 4K / output format: uncompressed YUV 422 (9 and 4.5 fps), compressed MJPEG / electronic rolling shutter / $279
b- See3CAM_CU135: 4K / output format: uncompressed UYVY (15 and 7.5 fps), compressed MJPEG / electronic rolling shutter / $199


Imaging source

Axiom beta
a- Development kit: $3990 / News from Matthew?

a- Lumix DMC-GX8: 5184 x 3888 still res. / electronic rolling shutter / fps? / $849

Z Cam
a- E1: 4640 x 3480 still res. / 15 fps / rolling shutter / $249


If I missed something or if there are new options that weren´t discussed in this conversation please let me know. To get a transfer that meet my needs, should I necessarily think in Point Grey´s expensive models?

Thank you. Greetings.

Thanks for posting this great summary of our camera options, Federico. I think the Point Grey cameras are your best bet. They will, however, require you to use their software which is something I’ve never tried to work with yet. It will likely take some time and effort to get that working and I cannot offer any support as to how to make it work with the machine.

With that in mind, if you want a solution that works with the old version of Kinograph, you need something that can be triggered with a cable. A DSLR would still work in this case, but you should know that the camera’s internal shutter mechanism will likely fail after ~300,000 clicks, which is just under 4 hours of run-time (more or less). You can repair the shutter when it fails, but this will cost money.

I bought the Axiom but it’s still in the box because I haven’t gotten to the optics design yet.

Unfortunately, there is no easy answer yet. If, however, you’re not afraid to try with the Point Grey cameras, I would choose one of the USB options and try it. They have technical support people to help you with setup. But it’s still a risk.


Okay everyone - it’s time to buy a camera for Kinograph 2.0. I got some money from the Simons Foundation through a residency at New Lab here in Brooklyn. It comes with $2K for materials. There are some things I’d like to buy, and at the top of that list is a camera and lenses. Here are our options. What are your recommendations?

My preferred specs are:

  • 2K resolution (price of 4K camera + supporting hardware is prohibitive for some, could be option later)
  • 24fps capable
  • Color, not monochrome (we can do monochrome as an option later if people want to do that)
  • global shutter

res: 1140x1080
price: $395
sensor: CMOS

res: 2048x1536
price: $725
sensor: CMOS

res: 2048x1536
price: $465
sensor: CMOS

res: 1384x1036
price: $1695
sensor: CCD (cheapest one that can do 24fps)

Right now I’m liking the Chameleon3-3.2MP @ $495 for its balance of resolution and price. Let me know what you think!!

@Martin_Weiss I promised I would tag you in this when I posted…so here you go!

I am also interested in the Chameleon3-3.2MP @ $495. Seems it is not yet released. As I understand, there is no need for other hardware i.e: frame grabbers etc. Am I correct in assuming this?

Thanks for tagging me :wink:

Just remember that a 2K Bayern pattern really is .5K in the blue and red channels, and 1K in the green. In other words: a 2k monochrome sensor (with triple exposure) gives a better resolution than a 4k color, single-chip sensor.

It will be a bit more difficult to do mutliple exposures, but on the upside, this would make HDR a much simpler add-on.

As so often, it is all about quality, speed and price, and you cannot have all three.

Awesome that you got the grant. Happy shopping :slight_smile:

Thanks Martin! Thanks for educating me on the differences. I’m prioritizing time (1 pass vs. 3) over quality for now. But there’s nothing stopping a user from swapping the color sensor out for a monochrome one in the final design and doing it their own way. That’s the beauty of the open-source model. I’d love to do a side-by-side comparison one day, though.

1 Like

Yes, that’s correct re: hardware. The Chameleon 3 is available, but backordered. :frowning:

I had a call with FLIR this week and asked them about the differences in the choices I outlined above. The only real difference between the Blackfly and Chameleon is the frame rate they’re capable of. The Blackfly can do more frames per second. It also has a newer sensor and is only compatible with their latest SDK.

The Grasshopper (most expensive choice above) is a larger sensor (2/3") and 14-bit output but that doesn’t justify the $1200 difference in price for Kinograph’s needs, in my opinion.

For the above reasons, I think the Chameleon3 will meet my needs just fine as a first choice. Of course, the camera can be swapped out by anyone should they desire a different one.

I would like to use the monochrome camera as suggested by Martin for optimum 2K resolution, doing three RGB captures separately. As far as I can see, it is to be done in a single pass to avoid registration errors. But how do I separate R, G, B files from the capture? They all will be in a single folder.

@Martin_Weiss @Udayarangi I’d like to hear more about the monochrome. I hadn’t considered that it could all be done in one pass. I think I don’t have enough knowledge on how this would work. Could you guys explain it to me like I’m 10 years old? I have to spend the money this week so sooner is better! Thanks.

I have decided from the beginning that I would use an intermittent transport system. So only I have to do is exposing a single frame three times (three separate captures) while changing the color of the LED, and move to the next frame. It takes time. But I am after the Resolution. My problem is, how to separate this R, G, B captures since they all will be in a single folder.

cool! how about just appending different filenames?

// frame001_0
// frame001_1
// frame001_2

In your software you can have a counter, i.e:

counter = 0;

while (counter <= 3) {


Okay, I did some reading and I think I got it now. This article made it really easy to understand for me.

I see why we would want to go with a monochrome sensor, now. Thanks for bringing this up and helping me understand! That’s exactly what these forums are for. Woo!

So here’s what I’m thinking. The problem that using a monochrome sensor will introduce is that the three color images that are produced for each frame will then have to be aligned and combined. Because we are not using intermittent motion, the film is continuously moving. That means that the film will be in slightly different places for the red, the green, and the blue captures. This extra image processing could add significantly to the time it takes to complete a scan, at least theoretically.

There is a chance that the NVIDIA Jetson TK2 (the board I’ve chosen to develop with for now) can handle all of this just fine on the fly, or even “in post” with no big time addition to the process.

My question then becomes - do I spend $500 on somethng that could add more complexity now? Or save it as an upgrade for later?

If I get a computer vision developer to come on board, it would help to tackle all of these problems in one go. If it’s just me doing the programming it might be better to get something up and running with the color sensor and then add complexity in the next build.


Matthew: could you please re-link the article?

And a question about optics for the Flir C-mount cameras: Is the Schneider Componon the best option? What about a Bolex C-mount lens? Has anyone tried one? I have a Kern-Paillard Yvar 75mm f2.8 AR and a Kern Paillard Switar 25mm f1.4 AR, and I could try them if there is any chance they could work well.

Thanks everyone.


Re: lens I am unfamiliar with the lenses you mentioned. I used this lens calculator and spoke with a FLIR sales rep to choose mine. I’m going with this one, which also requires a C-CS adapter.

This article explains about the Bayer filter.

The disadvantage with a Bayer filter is, we are left with a resolution less than the sensor resolution after Debayering.

Thanks for the suggestion, Matthew, By Software, are you referring to the software that comes with the camera?

Yes @Udayarangi that’s correct. I’m referring to the software that comes with the camera.

I realize that the Bayer filter will reduce the effective resolution. I believe that for the first round of development, it will be acceptable. There are so many other factors to get working in harmony that I’d like to put off the monochrome sensor until all the other parts are working consistently. Also, I suspect getting 3 images per frame and lining them up on a machine that is in constant motion will be harder than we suspect.

Good news - the camera we’re using has much more resolution than we need to reach an HD standard. For that reason I feel we can still offer a quality scan for a good price with minimal technical complication. It’s still a strong start, and anyone is free to swap the camera out and change the code as they wish.


What about using pixelshift like with the Sony a7R III, would it be the same quality as a good pgr mono camera? Shoot each frame with Red, Green, & Blue leds and use pixelshift on each picture.

Yes, capturing 3 separate R G B passes during constant motion will be definitely harder if not impossible. I plan to use a Geneva mechanism taken out of an old 35 mm projector to run the film intermittently. Once the frame is stopped I could do the three separate captures and advance to the next frame. With my very little knowledge of Arduino, (and with the help of you all), I hope I will be able to do so.

Doing multiple exposures without intermittent film movement will indeed add a couple of layers of complexity. Keep in mind that film is a flexible medium, and older film tends to warp. It might run ever so slightly uneven through the gate, thus making the 3 exposures match will be even more difficult.
I think it is a fundamental decision, whether to go with a Bayern pattern or monochrome sensor:

Monochrome/intermittent motion: Sharper (no interpolation of pixels), possibility to do exposure bracketing, possiblity to chose the lightbands (as different film stocks have different colour absorptions)

Bayer Pattern/continuous motion: Simpler software, faster scanning speed, simpler mechanics

I completely agree with your assessment. Thanks for explaining. I’m going to stick to Bayer for now for the sake of development speed and ease of implementation.