Hi all. I wanted to revisit cameras with you as there may have been some new developments or products to come out that I have not seen since I last went digging a few years back. I met someone recently who built a DIY scanner using the ZCam linked below and it got me curious about what options might exist beyond the industrial camera route I’ve been on until now with Flir.
Here are a couple links to whet your appettite. As you browse, keep in mind that we’d like to be able to achieve the following:
- minimum 2K, 4K would be nice
- affordable!
- easy to find compatible lenses
- can be triggered by cable/remote, or has a port for I/O signals we could hack
- 10-bit minimum, 12-bit preferable
- as many stops dynamic range as we can get. Ideally > 10.
- compact form factor
Here are a few that I came across after a very quick search. I’d love it if we could vet these together and look for some more.
Zcam E2C (PDF manual)
Blackmagic Micro Cinema camera
Hi Matthew
I recently purchased a Ximea MC050CG-SY
, It’s an industrial camera. I will post soon my setup and results. It’s promising, it records directly in raw dng.
Does he use the lanc port of the Zcam ?
I was looking iinto the Red Komodo for a while. It seemed to be a good option with high resolution (6k), high dynamic range, and global shutter. Also, for someone who has no idea how to write programs it was an easy way to get high quality RAW files. It also has a GPI input.
Unfortunately the firmware on the camera doesn’t have the functions present on their higher end models that would allow for individual frame captures. Maybe that will change at some point. I did contact someone but they never answered my question.
I have recently been looking at the Basler Boost series and that seems to be a decent option.
Of course neither of these options are inexpensive.
I was able to get still frames out of a RED camera several years ago by using a setting that created 1-frame “scene” files. Perhaps that is something the Komodo can do? I had a video on the YouTube channel but is shut down for reasons still unknown. If I come across it again I’ll send it to you.
Will def checkout the Basler. Thanks for the link!
i made a comparison chart here, with commenting powers granted to everyone: Camera Comparison Matrix - Google Sheets
Thanks for the recommendation! I tried finding on the website what kind of shutter the camera has: global or rolling. I’m assuming it’s rolling. Do you know?
The advertised speeds are for 8bit, so they can run a LOT slower when you’re doing 12bit output. The manufactures will let you know about speeds (Emergent has a camera selector spreadsheet that shows the speeds - direct link). 4K is the highest resolution you’ll get fast speeds over USB3 and 12bit.
The Sony Pregius sensors are the best, Pregius S being the best choice. As far as cameras go, heat produces sensor nose and Basler cameras have more issues with heat. So if going with USB3 the Flir cameras (Blackfly S) are a good choice and can produce clean captures without cooling. There’s a good range available at different prices, e.g.: 2K IMX252 $765, 2.5K IMX250 $1,149, 3.2K IMX428 $1,879, 4K IMX253 $2,935, and 5.3K IMX540 $2,500. The 5.3K Blakfly S is an absolute bargain at that price too, but 12bit raw capture will be slow so it will suit those doing slower captures. For the others do note these cameras have been around for a while now and you can often pick them up used for half the retail price.
For faster captures at higher resolutions you need a 10GigE connection, and that runs hotter than USB, making cooling required to eliminate sensor noise. Good choices here are Flir or Emergent and at minimum you want a fan at 45 degrees to the camera body, I’m informed that’s usually sufficient. If noise is still present you could then think about attaching a heatsink as well. You can then go for the 5.3K or 6.5K resolutions and capture at real-time speed. The 5.3K cameras represent excellent value ($4,250 for the Flir being only $100 more than the 4K one), it’s highly unlikely you will need to capture at 6.5K to get all the detail in your films.
1 Like
Great to hear that the Flir cameras are a good choice for the money. I’m liking our options with them. In other threads, folks have mentioned that there’s no easy/direct way of getting raw images from their software. I hope this will be solved if/when we write our own software based on their SDK for developers. Other than that, I see no reason not to go with Flir moving forward for high-res, high-range captures. Not everyone will want to spend that amount of money, but for those who do we can say with confidence that it’s a good use of their precious dollars!
One thing worth looking at (eventually), is decoupling the capture software from the camera entirely. That is, instead of specifying a camera or even a brand of camera, specify the frame grabber (or frame grabber protocol), and use a PCIe frame grabber board. The reason I suggest this is that when you interface with an intermediate layer like this, you don’t have to care about the camera. That opens up the possibility of using different cameras from different manufacturers without having to rewrite software.
We’re using a Euresys CoaxPress frame grabber for the Sasquatch scanner, but their (free and extensive) API is the same for CameraLink or CoaxPress, and is based on the GeniCam standard. I think many of the lower end cameras are GenICam compliant, so this is worth looking into.
At least with Euresys, we got a C API from them that gives us all the functionality we need to get/set parameters on the camera, and to grab frames from the frame buffer. If we switch to another camera at some point, it’s mostly a matter of plugging it in and tweaking a few things.
1 Like
@friolator this is a great suggestion. In our case, the the camera is triggered with a single high digital signal via the GPIO connector on the camera. The camera then performs its transfer of data via its software.
Are you suggesting that we put an abstracted layer on top of the manufacturer’s software? So that as we add other cameras/software one would need to write a plugin for the Kinograph capture software that acts as a wrapper around the manufacturer’s SDK?
it’s even simpler than that. Don’t use the manufacturer’s software at all, instead look for cameras that conform to the GenICam standard. This is your abstraction layer and there are tools to access it for multiple platforms. In our case, Euresys has a simple C API, which we can easily call from our preferred programming environment, but we could just as easily interface with the GenICam libraries directly.
In our case, there’s a lot more that we’re doing than just triggering the camera. For example, the auto-focus routine will be done by taking images rapid-fire, of a small ROI of the overall frame, while stepping the lens position between images, and then comparing the processed frames to find the sharpest. If we did that at full res, it would take quite a while on a 3fps camera, but if we do an ROI, it’s reasonably quick. With the GenICam layer, we can tell it to switch to 8 bit mode and set an ROI, which will speed it up immensely. Then when we’re ready to shoot actual images, we switch back to full frame 16 bit.
Similarly, we’re going to use different regions of interest for different film gauges: 35mm alone would have 8, 4, 3 and 2 perf. The camera is in the same position for these, but we can run the machine faster in 2 perf than 8 perf, because we can set (in software) the region we’re interested in.
Basically any parameter you can set on the camera you can do from software. But using the camera’s software ties you to that manufacturer. Where if you use a more generic standard, you could swap out any camera you want as long as it complies with GenICam (which covers most modern cameras) - if someone wants 2k or 5k, it wouldn’t matter so much because they all use the same basic comm protocol.
More here: GenICam – EMVA
1 Like
Thanks for the clarification. It seems Flir is a member. I will contact them to see if they actually support the standards on their hardware and report back.
Separately, what license will you be using on your software, and what are you writing it in? Is it something that the Kinograph community could fork and build to their own needs?
it’s going to be completely proprietary. We’re building the app in Xojo, the programming environment I prefer. But it’s also going to be very specific to our scanner, and I don’t think would be useful for Kinograph, simply because we’re doing things very differently. all the motion control stuff is through an off the shelf controller, but we’re writing custom firmware for that box, and the LEDs are sequential RGB for intermittent scan, not white light. We’re not using any camera/light triggering from hardware, it’s all done from the control software through a TCP (or maybe serial) layer to the microcontroller.
That being said, we commissioned a couple programmers to make a plain C API for a good chunk of OpenCV to something called OpenCV-C. The reason for that is that Xojo can only interface with external dynamic libraries if they’re in plain C (or on the mac, either C or Objective C). OpenCV is C++ and they’ve deprecated their C API. OpenCV-C will be open source, on github. Soonish. We need to tidy some stuff up.
Along with this, I’ve been working with a couple Xojo regulars to port OpenCV-C to Xojo, so that all the functions are available as Xojo classes and methods, which makes it much easier to interface with than the raw C API. That will also be open source. We’re about 1/3 of the way done with that.
1 Like
I see now that this is all in C++. I understand why they would choose that, but this will be an obstacle for many, I presume. Then again, I could be wrong in assuming that the people who would want to do their own programming for Kinograph is separate from the community of people who know C++. I was hoping to make everything with Python so that folks would only need to know one language, and to lower the barrier of entry.
AN interesting idea, though and I’m glad you brought it up. Interoperability will be something very important to think about as we progress.
Best of luck with all your valiant porting efforts!
And for OpenCV, the Python support is extremely robust out of the box.
I like Xojo because it makes building a complex GUI application pretty simple. It’s essentially a cross-platform version of Visual Basic, but totally object oriented. It can be free to use if you don’t mind running your app from the compiler, or you can buy platform-specific versions which can be compiled for $99/platform.
The nice thing is that you can run it on Mac, Windows or Linux, and compile for all three from any platform. So I’m doing some of the dev work on my mac laptop when I’m away from the office, and some from the Windows workstation where the system actually runs.
But it’s not an open-source programming environment, so I can understand wanting to keep it on python.
Thanks for those links! There was no mention of that on the GenICam documentation pages. Poor documentation is one of my pet-peeves.
Thanks for the tip on Xojo. I’ve been looking at Qt as a possible framework since it has a license for open-source projects.
Not sure when we’ll get to that stage but it’s good to be aware of all the options. Keep the suggestions coming!
M
that python implementation isn’t part of genicam, as far as I’m aware. All the EMVA basically sets is the standard for the protocol, but the implementations are left up to others to put together. I think the C++ version may come from the EMVA, but there are others out there for various languages as well.
1 Like
I lost it temporarily but someone posted or sent me a link to a python library for genicam so I think we’re good on that front. I’ll know more when I get to that stage of the development.
just to be clear - the python genicam implementation you lined to above is the official python implementation, I think. The EMVA doesn’t make one, they make the spec, and it’s up to others to implement it in the language of their choice. So I think that’s the one you want.
1 Like