well Jim, thanks for the comment. Your point is certainly a good thing to consider.
I checked the performance of the light source throughly when I constructed that light source.
Some background information: I realize different exposures of a single frame by rapidly changing the illumination levels of my light source while keeping the camera at a fixed exposure. Later, I combine these different exposures into a single frame.
So the precision of the light source is essential to my film scanner.
The LED light source I am using is made out of three LEDs, one red, one green and one blue, which are each driven by a programmable current source. Each LED has a 12bit digital-to-analog converter, which drives the LED with the current requested by the software.
Here’s a piece of an older version of the circuit I am using (still with 10bit digital-analog-converters MCP4812 in the picture):
Not perfect, but it works. The software writes the requested current to the DAC-IC (now a MCP4822 with 12bit resolution) which drives a simple current source made out of an OpAmp (1/4 of a LM324) and a IRF101 FET (I had these parts in my part bin when I constructed this). “J1 Out” is where the LED is connected.
This current source drives the LEDs quite fast and precise. In addition, I typically wait about 5 frames after switching to a different illumination level before I capture a frame, mainly because the camera I am using is a rolling shutter camera and the imaging pipeline has a certain delay.
The above examples are direct MJPEG-captures (well, in reality: cut-outs) as they were streamed from the different cameras used.
Well, it was interesting for me to compare the scans of three different camera models (Raspberry Pi V1-camera, see3Cam_CU135 and finally the new Raspberry Pi HQCam). Franky, I did not expect such a difference in the appearance. And I actually did expect that the HQCam would perform better than it did on this particular frame. I am not sure whether this can be attributed to the camera, or whether the camera, the film and the lightsource interact in a funny way.
For normal applications, the HQCam does quite a descent job, and color test charts are rendered ok. But in the film scanner application, it seems that the HQCam performs somewhat better if I set both red and blue gains to 1.0 and set the white balance not with the camera, but with the light source.
I am thinking of exchanging the blueish stock IR-filter of the Raspi HQCam with a proper one, having a flat filter response in the visible light region (I have one in my part bin - it looks like clear glas in the visible light range and is pitch black in the infrared). If my suspicion is correct, the red gain required for a whitebalanced image would become similar to the blue gain, leading to a scan result similar to the last image in my post above. I am still a little bit hesitant, as the removal of the blueish stock IR-filter from the HQCam is an irreversible action…