Hi all,
As I’m designing the PCBs for the RGB lighting setup, some discussion has popped-up in the Instagram post for day 13 regarding integrated RGBW LEDs and separate LEDs for each color. I’d like to make one of each approach and test them…but I don’t know how to setup a good control situation for comparison.
What kind of test and/or image capture would be good for analyzing the color output of these arrays?
Hi Matthew:
In my device, the lighting tests were carried out with the help of the histogram.
I did it with my own software, but the same procedure can be done by obtaining images of the illuminated window and observing the histogram of the image.
In my opinion, the ideal lighting image should have a histogram consisting of three vertical lines (blue, green and red curves) superimposed. This would mean that all the pixels would receive the same light energy. The image should be a neutral light gray color throughout.
Obviously this situation is ideal and in practice impossible to achieve, but we must get as close to it as we can.
I have followed the following method:
First we turn on the lighting and leave it on long enough for the lamp to reach thermal equilibrium.
In this state, we take images of the illuminated window so that it covers the entire window but does not include borders or dark areas.
The exposure time was adjusted so that the peak of the histogram curves was around 200 (for an 8-bit color depth).
In these conditions, if we have a lamp with independent colors, we are adjusting the intensities of the colors until the three curves overlap.
My lamp does not have the latter, so I did it by adjusting the camera’s color gains.
The narrower the base of the curves, the better. If the base is wide, it would mean that there are many pixels that receive more or less light than the average, which would be at the peak.
This image is from the histogram of the light of my lamp, obtained under the aforementioned conditions.
Best regards
This is very very helpful. Thank you @Manuel_Angel ! I’ll post my findings here as soon as I have the PCBs milled and wired up. This is great!
Just a small comment: because of the response curve of cameras, it is usually of advantage to set the exposure to the center of the working range of the camera. Here, the response curves are more linear than at the edges of the working range. Also, I have seen some cameras with deviating (different) response curves in the very bright regions of an image.
Also keep in mind that 8 bit/channel images are typically processed by the camera taking into account for example the current white balance settings. You have to decide which white balance setting you are going to work with and set this fixed.
A slightly different approach is to analyze the raw images from the camera. These images are measuring directly the intensity falling onto the sensor chip. Do not debayer - in this way, you will get four data channels (red, green1, green2, blue). Some chips seem to have slightly different filter/response curves for the two green channels.
Adjusting your light source on the raw images will ensure that you utilize the full dynamic range of the sensor up to where the further image processing is happening, including white balance.
However, note that equal amplitudes in all four color channels might not be the ideal signal for the later image processing algorithms: natural light situations (like “daylight setting”) do usually not have equal amplitudes in all four raw color channels.
Thank you for your comments @cpixip.
The truth is that the level of 200 that I have used to determine the exposure, I chose it somewhat arbitrarily. You are right that it would have been more logical to place it in the center, with levels around 125 or 130.
On the other hand, I made the histogram on the jpg images provided by the Raspberry Pi HQ camera, which are in fact affected by the camera’s algorithms. In addition to evaluating the uniformity of the lighting in the projection window, I was also trying to find the optimal white balance for the lamp I was using, manually adjusting the blue and red gains.
@Manuel_Angel - I went basically the same way 
. Just in case someone is interested in this, here’s an estimate of the transfer function from illumination levels (EVs, x-axis) to 8bit jpg output values of the HQ camera (y-axis; you need these gain functions for real HDR work):
The curves are centered by my software always at the data point 0.0 EV and 128 output (thus they match at that point).
Well, not to bad a response curve for the HQ camera, and the difference in linearity between 128 and 200 is certainly negligable with the HQ camera. That is however not always the case. For example, the same curve for v1 Raspi camera looks like this
so this camera behaves differently at intermediate gray values (~128) compared to operating at brighter gray values (~200).
After the decision to go for seperate RGB ligthing i started a little research as i didn’t knew much about the benefits of this design.
i found these links to be interesting:
My key take aways are (and please correct me if i am wrong):
ARRI Scanners use RGBI (Infrared), take one or two (HDR) pictures for each color channel. They use a monochromatic sensor. Infrared for dust detection. During the image exposure film, gate, and sensor are locked into position.
For color channel separation it is important to shoot one colour at a time. It is not sufficient to use three leds at once to create “white” light.
The led wavelengths should match the films colour sensitivity peaks.
A monochromatic sensor works best, as it doesn’t have a bayer filter.
I think your approach is generating “white” light with three leds at a time and capturing one image with a bayer sensor. Can this concept really deliver better or same colour quality than the ARRI design or the concept with a high CRI white led? What about bayer sensors an their sensitivity for each colour! Do the leds need to match the bayer sensor rather than the film? I could’t find a discussion on this topic in the forum. I am happy to learn more on this topic.
All the best
Martin
amazing project by the way …
With oversampling, yes. The concerns about bayer sensors, in my opinion, are somewhat overblown, but one way around the limitations of the color sampling is to scan at a higher resolution and then downsample to your target resolution. This effectively gets you the same thing as an RGB scan.
@matthewepler a quick and effective way to look at this is also using the scopes on your preferred software. As a video guy old habits are hard to die.
An example of uneven lighting (my second lamp with a difuser).
THanks all for the great discussion. I’m getting close to being able test the integrated RGB LEDs, and am hunting down smaller LEDs for the separate R, G, and B option.
What software was this you used, @PM490 ?
@matthewepler The screenshots scopes are from DaVinci Resolve
Hi all. I want to confirm some assumptions I’m making as I embark on these tests. Is this how you all are imagining the implementation?
We follow Frank’s example. We get discreet LEDs for each color channel. When the camera shutter opens, all three channels turn on. Each channel has a timer that determines how long it should stay on. When the timer expires, it shuts off. So, for example, Green might stay on a little longer than Red or Blue. All of the channels go dark before the shutter closes. Next frame.
To adjust brightness, you can either a) adjust the timers for each channel (preferred for accuracy), or use a knob to turn all of the LEDs’ intensity down equally. I don’t know why people would use that necessarily but it might be more intuitive for some.
Lastly, in case people want to use white light exclusively, we can provide white LEDs in the same circuit and the user can choose to either use white or RGB for their scan.
Does that line up with what you all are thinking, too?
PS - the Neopixels are def a no-go. They flicker like crazy at high shutter speeds. I’m going to order the LEDs Frank mentions on his site (see link above) unless anyone can point me to an RGB chip that will not flicker and also explain why this would be an advantage over discreet LEDs for each color.
Thanks for the guidance and support as always.
Maybe this can be helpful.
For my scanners (intermittent) I use this board: https://www.tindie.com/products/boundarycondition/high-power-rgb-led-driver/ along with a cheapo 100W Chanzon RGB chip. My camera is set to 1/25th and the arduino code sets the refresh rate. There is no flicker. It may not be the best for the Kinograph but it’s a nice board and super easy to integrate. The board designer is also very nice and helpful.
I made a touchscreen UI to set my colors. Makes very nice negative scans.
Hi @matthewepler, all good stuff.
Full disclosure, I am not controlling LED intensity (yet), and are using some white strips recently in an integrating sphere. Please don’t laugh it is an oversized ping-pong ball, but for 8mm is just about the right size (specially when there is no 3D printer in the house). Also in my case is not real time=slow exposure. Sorry I digressed.
My first reaction is if you are going to get anywhere close to real time or a fraction thereof, the LED drivers should not be switched. I can think of a few reasons, one of them is that LEDs are not great switching diodes, and that if the shutter is fast enough and not synchronized with the LED pulse width it will roll and make the light change at high shutter speeds.
Instead, controlling the forward current is the way to go. I have a background in electronics, but had not open a voltage regulator book in a while, but the 317 can be configured as a current regulator. See item 9.3.3 on this spec sheet.
Looks easy? Nada es facil (nothing is easy). The trick is to find the right LED, and operating these in the right range for voltage an current. If the LEDs you are using are low power, maybe a simple voltage divider is enough. Be aware that most likely the R, G, and B will have different operating points and forward voltage drop Vf or Vled.
Before deciding how to control these, with the 317 you can do a great test bed to characterize your setup. Depending on the VCC available and Vf drop, you can put more than one LED in series, so you do not need a 317 for each LED. Typical Vf is 3 to 3.5 V. Also keep an eye that the 317 requires a minimum of 3V between Vi and Vo. So if you are using 12V, you should be safe with 2 LEDs in series. Given that the LED Vf varies slightly, if you are consider using a parallel/serial array of LED (2 in series, multiple of those in parallel fed by the 317, consider putting a small resistor in series with the LEDs in two, avoiding that the LED pair with the lowest Vf will preclude the other in parallel to work. Also of consideration in your setup is if those surface mounted resistors have enough power for the configuration. If you are looking at bright bright, my take is that you need a bit more powerful stuff. Place a link to the LEDs spec sheets and how many you want, and I’ll spreadsheet some calculations, tomorrow is not a good day, but will do my best to turn these around quickly.
Sorry for the extensive post.
PS. This is a great write up on LEDs (click on lighting), the author provides the light system of the FilmFabriek according to the Contact&Links on the page.
PS2. The circuit on the page above uses a current regulator to power the LEDs but controls the intensity by switching the regulator/led leg. Also would like to point out that in the future you can have a system that taker R/G/B/IR similarly to what flat bed scanners use do find dust/speckles.
LED UPDATE
I did a deep dive on LED research last night. Before I go any further, let me repeat that I claim no expertise in this area whatsoever. I barely get by on the minimal knowledge I have of basic circuits and physics and…just about everything else in life. And, as always, I’m open to feedback so long as it’s respectful of the effort I put into this work and comes with actionable suggestions for how to improve something. In other words, be nice and be helpful. We share and we care around these parts 
Things I learned on the research dive:
Addressable LEDs are not going to work for us. “Addressable” means that a signal is used to send color information to the LEDs. These include PWM, I2C, Serial, DMX, and others. This type of LED will always flicker when not at 100% because dimming is achieved by turning the LED on/off rapidly enough that our eyes can’t see it. But cameras do.
Here is a write-up on LED dimming that helped me understand these concepts.
Measuring the quality of light is tricky business. For white light, the CRI standard is used. But even that is not always very accurate. The same measurement techniques used for white light cannot be used for RGB lights . A testing standard called CRI is used to measure the quality of light for LEDs which emit a spectrum of wavelengths, meaning “white” LEDs. Because RGB LEDs do not emit spectrums, but rather one specific color of the spectrum, CRI is not used to measure light quality.
When we talk about “quality” of light for RGB’s, we’re actually talking about consistency; specifically: a) how consistent is the color across manufacturing batches and b) how consistent is the color from low voltage to max?
Here’s an article on the limits of CRI testing
Given the above, I have chosen to go with standard discrete (R, G, and B wavelengths) LEDs whose brightness is controlled by changing the voltage supplied to each color. I will also include white LEDs on the Kinograph as an alternative to those who prefer a full spectrum, or who just need to do a quick scan for reference and aren’t overly concerned about color profiles.
I will be testing two different setups:
LuiLEDs Rebel family:
In my comparison of other LED types, I was looking for the following characteristics. These may be of use to others wishing to find alternative components:
@PM490 Thank you for the extensive post! It propelled my research even further and I have taken many of your suggestions. I ordered some 317’s to play with and will experiment with the circuit. Any help with calculations is much appreciated! It’s definitely a weak spot of mine. And, funnily enough, we both linked to the same cine2digits article above. We’re on the same wavelength. 
I’m wondering about flashing the LEDs, why is it important? Is it because of the global shutter or for thermal issues / longevity? Wouldn’t be easier to just leave it on while scanning, since scanning will be fast (faster than 10fps). Sorry for the newb question, just wondering.
@robinojones I think it depends on the purpose.
The intention may be to reduce/lower heat (turn them off while not needed for exposure), the timing is not critical.
Or it may be to control the amount of light, which then requires turning them on at or right before opening the shutter, and varying the off point during the exposure to control the light (dimming).
Or both at the same time.
In my comment above I was thinking about the second case, which makes the timing between the camera shutter and the off what controls the dimming.
On hindsight of the comment, 24 fps (about 41 ms) is a long time in Arduino life, then in continued motion setup, dimming feasibility would be dependent on speed of shutter. It then depends on how much light, how fast is the film moving, what shutter is required for that combination, and how fine of dimming control is desired.
I’d stipulate the same, but have been dealing with this LED stuff for the past few months myself, and here’s what I’ve found:
Kind of. You are absolutely correct that directly controlling the brightness via PWM will not work – you’ll get flicker, or lines in the image that correspond to the PWM duty cycle as soon as it drops below 100%. But depending on your LED driver, this can be overcome.
Using an LED driver chip like the ones in the driver we’re using, allows you to dim the LEDs without flicker. The driver is constant current to the LEDs, but the amount of current is controlled by either PWM or analog voltage.
Currently (haha, see what I did there?) the Sparkfun Femtobuck driver we’re using as a stopgap passes the PWM pulses through to the output, which is no good - with a duty cycle below 100%, you get lines in the resulting image. However, that driver can also dim the LEDs by changing an analog voltage on the input signal on a scale of 0-100%, between 0V and 2.5V (instead of using PWM). So you’re still getting constant current to the LEDs, which you want, but you’re not getting the PWM pulse that causes the flicker.
But PWM is great - very easy to quantify brightness from the software side, so it’s preferable if you can do it. The good news is that PWM can be converted to an analog voltage with a DAC chip. Basically, PWM in → Smooth analog voltage out. Modify the PWM duty cycle and you get a corresponding change in voltage. Connect that analog voltage to a driver like the Femtobuck, and you should have smooth dimming.
We’re having someone design this for us now - essentially it’s a clone of the Femtobuck driver with slightly higher allowable voltage, but with an integrated DAC so you can use either straight PWM to the DAC or use a jumper to bypass it, to send analog voltage directly in (assuming you have a device that can output voltage)
If it works, I’ll make it available. Should have the design in the next day or two, and then I can order parts and be testing it in the scanner next week.
I think you should reconsider controlling the brightness with voltage and instead use a constant current driver for each color channel. Using a driver that’s designed to power LEDs with constant current should gets you more consistent lighting across a series. See the first answer here.
Spot on @friolator. The 317 current regulator mentioned by @PM490 does exactly what you describe. You send it a PWM signal, it adjusts the voltage applied to the LED circuit. We get the advantage of digitally controlled brightness of each channel independently while completely avoiding any flicker issue. Same destination, different paths I suppose. I too was thinking of also providing an analog input option. Sometimes it just feels better to turn a knob…and not have to write the software for the other option 
This has been a great thread. Thanks to all who have contributed. It’s helped us all! Looking forward to doing the actual tests too, which is how this all started.
@friolator converting voltage to current can be done with a current mirror.
This particular one is an example of voltage controlled current mirror. Instead of PWM one may use a resistor array to make a DAC out of arduino ports. It is best to use a packaged resistor array. The voltage would need shifting/isolation from the 5V Arduino to the the LED power supply 12V.
@matthewepler I found this white LED. Ordered some from Digikey to test. It is a particular White LED, first because of the color characteristics are above 90 for all, and then it has a high Vf of 9V, which is quite high. It provides about 1W of output; the high Vf translates into a very advantageous forward current of only 100 mA. And it is rated to 118 lumens/w at 25C (with pulsed conditions).
I am thinking these would be a great combination, lower current=lesser the power driver requirements of this LED and the simplicity of a current mirror… maybe I am missing something, it sounds too easy. In a current mirror with a 100mA range/3V collector to emitter would be your everyday 3904. And additional transistor/led can be added as needed. These LEDs put 118 lumens/W, that’s bright and with a color fidelity >94 across.
Just sharing the information/findings, not suggesting changes on the above. Once I get the LEDs, I’ll prototype a current mirror with these and see how it performs.
PS. I found this great write up by Texas Instruments on LED drivers and while is a slightly different application, the explanation of concepts and configurations are very well illustrated.
