[v2 dev] Milestone 3 - Lighting

[mbaur]

@cpixip I was mulling over your design a bit more and was wondering a few things:

Did you notice any difference in running temp on the different LEDs? Like the top one staying cooler because the hot air having an easy way out? If so, how about setting the baffles or tongues at 60 degrees instead of 120 effectively putting all the lighting sources on the top half? And to avoid direct light from the LED maybe try adding a slight angle of the LED openings toward the front? That way the LED would be “aimed” more towards the back of the sphere away from opening where the light exits.

And the second question I thought about was the surface: Have you tried reflective spray paint to coat the inside of your sphere? There might be some rattle can paints that could work.

And thank you so much for publishing your whole design evolution. Especially the steps that didn’t work so well are very helpful in knowing what not to try

[cpixip]

… well, the 3D printing takes about 2 days on my printer, which is a cheap Anet A8 (200 €).

Add about half an hour of spray-painting the inner side of the sphere. Assembly is rather simple and might be done in a few hours. You take the 3 LEDs with their squared PCB and solder wires to the pads of the PCB. Then an adhesive pad is used to glue the LED-PCB and the heat sink together. I guess you will need at most an hour for this task. The next step is to insert the LED together with the supply wires into the grooves of a half unit.

This cut-away rendering shows how this done (I hope ). The straight dark red lines are the wires:

Once that is done, the back and front halfs of the unit are pushed together. There’s a rim on one half and a corresponding grove on the other half, so some sort of snap-fit is achieved. Just to be sure, 3 long M3-screws are used (on the bottom part of the above cut, you can see the channel of these screws). All that doesn’t take too much time and that is the final assembly step.

With respect to costs: each LED-unit is composed of

• one Osram LED on a 10x10 mm square PCB, about 3 € (I am in Europe)
• heat conducting pad, about 10 cents
• 10 x 10 x 10 mm heat sink, about 1 €

So that would be about 4 € per LED-unit, so a total of 12 € for the LEDs. PLA-material for printing the sphere is negligible, probably less than a 2 €, while printing time is not (2x days with my printer).

The real costs are probably hidden in the electronics which drive the LEDs - these are programmable constant current sources. For my setup, I did not want to use PWM-type of LED-dimming (which usual LED-strips do).

However, I can’t really give an estimate on these costs, since I used parts I had already available. Basically, the electronics consists of two dual DAC (10 bit resolution, SPI-interface), a quad operational amplifier and 4 power fets on heat sinks. Part costs might be around 30 €, at most. I created a first (through-hole) version of a PCB for this unit, but that circuit design still needs some improvements.

Which brings me to your second question, the software. I do develop my own software. As my system splits the work onto three processors, it depends a little bit on the processor which software environment I am using.

First, there’s an Arduino Nano which drives four stepper motors, reads potentiometer values from two tension control arms and adjust the LED-currents to the requested values. This part of the software uses the Arduino-IDE (so essentially C++).

The Arduino gets its commands via a serial interface from a Raspberry Pi 4. Connected to this Raspberry Pi is also the camera used to scan the film. It features a v1-sensor chip and a Schneider Componon-S 50mm as lens. Both camera and serial communication with the Arduino are handled by a server running on the Raspberry Pi, written in plain Python 3.6.

This setup is very similar to other people which utilized a Raspberry Pi for telecine. A special library which is utilzed in the server software is the “picamera”-library. The server is able to stream low-res images (800x600) @ 38 fps, but drops down to a few frames per second for the highest resolution and color definition.

Anyway, I do use a special version of the picamera library, which is able to handle lens shading compensation. This is absolutely necessary if - as I did - you change the lens of the camera (remark: via lens shading compensation, a partial compensation of color shifts can be achieved which are introduced by a lens change. Turned out to be sufficient for my needs in case of the (older) v1-camera. The newer v2-cameras become unusable if you change the lens).

Well, the Raspberry Pi server delivers a camera stream plus additional camera data to a client software which is running on a rather fast Win10 machine. This software is also written in Python 3.6 and uses a few additional libraries. Specifically,

• Qt-bindings (PyQt5) for the graphical user interface
• pyqtgraph for graphical displays like histogram and vectorscope
• cv2 for a lot of image processing
• and finally numpy for the rest

This client software can request an exposure stack from the Raspberry Pi and essentially stores the original .jpg-files of the Raspberry Pi camera on disk for later processing.

The next piece of software is a simple Python script which does the exposure fusion (Exposure Fusion). While cv2 has its own implementation, I actually opted to implement this by myself in order to have more control over the internal workings. This script takes different exposures of the same frame and combines them into a single intermediate, stored again as 48-bit RGB image on disk.

Note that this exposure-fused image is not a real HDR-image. Actually, the client software mentioned above has the subroutines available to calculate real HDR imagery (which consists of estimating the gain-curves for the camera, and than combine the exposure stack into a real HDR-image), but I did not find a satisfactory way to tone-map the resulting HDR-movie into a normal 24bit RGB-stream. So I settled with the exposure-fusion algorithm of Mertens.

Anyway, the 48-bit pseudo-HDR images are than read by my third piece of software, also written in Python 3.6 + PyQt5 + pyqtgraph + cv2 + numpy, which allows me to do sprocket registration and various color and other adjustments. Here’s a screenshot of this program to give you some idea:

The 48-bit intermediate image can be seen in the top-right corner of the frame display for reference. At this point in time, the software works stable, albeit a little bit slow. Also, too much experiments left their traces in the code. So I am planning a total rewrite of this software once I think it has reached its final form…

@mbaur: this teardown is interesting! Because: this setup is very similar to illumination setups used in LCD-screens (edge-lid backlights). The white dots which are visible are used to “extract” the light from the sideways placed LEDs perpendicular into the surface to be illuminated. Sometimes (in LCDs), these dots do vary slightly across the surface to counterbalance the otherwise uneven light distribution of such an setup. So actually, ripping apart an old LCD screen to get the diffusor might be an interesting basis for some experiments with a brand new telecine lamp!

[bwrich]

I used to work for a company that designed and built integrating-sphere light sources. The very fragile Barium Sulfate was typically replaced by Spectralon, a trademarked form of PTFE (Teflon). In this case the sphere was made from a block of that material. It did not just reflect at its surface, but through the volume of the material. So wall thickness had to be kept high.

There were specialty sources for which we used good old fashioned Krylon 1502 Flat White spray paint. We had to use a surface scatterer, because we were working with very short laser pulses that would get stretched by passage through the spectralon. The pulse spreading just due to the integration sphere geometry was much less (the spheres were quite small). But not an issue in the Kinograph application anyway.
Why is it that you, @cpixip can’t use PWM LEDs? Is there an exposure effect due to too-low a frequency driving the modulation?
Also, the 5% opening diameter was sometimes violated (by a lot) without noticeable non-uniformity.

[cpixip]

@mbaur:

Did you notice any difference in running temp on the different LEDs? Like the top one staying cooler because the hot air having an easy way out?

No, not really. After adding the airducts, the temperature of the LEDs were quite similar, within a few degrees Celsius. There was a larger difference without the active cooling, exactly as you have described above. Note that the LEDs are driven with slightly different currents as they have different efficiencies. Typical values are 294.7 mA (red LED), 425 mA (green LED) and 278.5 mA (blue LED). That results also in slightly different temperatures by itself. The cooling with the little fan (it is a 5V fan used by Raspberry Pi units) is quite effective.

If so, how about setting the baffles or tongues at 60 degrees instead of 120 effectively putting all the lighting sources on the top half?

That could probably be done by going back to the original design were the wires and heat sinks are kept out of the unit. The current design holds the LEDs mainly in place by the supply wires. These wires are running through straigth channels in the body of the integrating sphere. Easy mounting, but you also have to dismantle the unit if you want to replace a LED…

And to avoid direct light from the LED maybe try adding a slight angle of the LED openings toward the front? That way the LED would be “aimed” more towards the back of the sphere away from opening where the light exits.

This is actually the current design (have a look the cut-away drawing I posted above). The LEDs are tilted by 45° and the baffles are now just small tongues close to the LEDs which also act as fixation points.

And the second question I thought about was the surface: Have you tried reflective spray paint to coat the inside of your sphere? There might be some rattle can paints that could work.

No, I have not tried any other spray paints. I have printed the second version with black PLA, in order to reduce the light shining through the unit, but that did not help too much. From the theory of the integrating sphere, you do not want to have highly reflecting surfaces. Ideally, the surface should be “ideally dull” (more technical: it should have a Lambertian reflectance function). Barium sulfate is a material which comes close to this. I used simply several coats of white radiator paint. That is far from ideal, but currently sufficient for my setup (it mixes the light from the LEDs ok and the exposure times are short enough that I can work with them).

[cpixip]

@bwrich:

Why is it that you, @cpixip can’t use PWM LEDs? Is there an exposure effect due to too-low a frequency driving the modulation?

At least that was what I was afraid of. The camera I am using, a standard Raspberry Pi camera, is a rolling shutter camera. I was afraid if I would use pulsed LEDs, the intensity variation of the LEDs might show up as bright and dark horizontal stripes in the images I am taking. Or at least as some sort of color/intensity noise.

Of course, a high enough PWM frequency would certainly take care of any such effects. But I am not sure how high such a frequency would need to be. I think WS2812 LEDs for example work with 800kHz typically. Given, this would result in 800 pulses during a single exposure time of 1/1000 sec. Probably enough pulses averaged during that exposure time to avoid any negative effects on image quality.

For me it was easier to use constant current sources, as I had the parts already available.

[cpixip]

An additional comment: my decision to not use PWM was done years ago, and I can not really remember the research I did at that time.

Anyway, trying to clarify some points a little bit more, I discovered that the RGB-Led I cited in the first reply of your question, the WS2812 LED, seems to have only a PWM-frequency of 400 Hz, not the 800KHz I mentioned above - that is the frequncy these units can communicate with. Now 400 Hz is way to low not to show up as intensity stripes during short exposure times.

The troubles you can come into with PWM’ed LEDs is well-known, see for example this video Oh Come All Ye Faithful LED Fix Comparison where a recording suffering from PWM is fixed. Also, this short article here LED Color Shift Under PWM Dimming discusses other issues related to PWM’ed LED setups.

Things like this pushed me into my decision to use constant current sources for driving the LEDs, just to be on the save side.

[PM490]

@cpixip I am doing some improvements to light source for the second round of a frame-by-frame 8mm/super 8mm DIY.

First and foremost, I have no clue on what are the particulars for best light source. I did some experimenting using a circular polarizer placing it in various locations and comparing, and had some interesting (and some puzzling) results. The setup is light source - film - inverted Nikor 50mm F2.8 - below - DSLR Nikon D3200.
When the polarize was set between the light source and the film, there seem to be an slight improvement in details (dust/scratches) and the grain seems less prominent. In other locations, the grain seemed to improve at the expense of less details. To say that the changes were subtle is an understatement… but given my clueless approach, would like to ask if you have any experience before I chase the rabit down this rabit hole.
Thank you

[johnarthurkelly]

Interesting - were you by any chance using pairs of polarizers? Or was it just the one circular polarizer placed between the light source and the film?

The Callier Effect has more to do with collimation but it’s possible a similar effect could be observed with polarized light… you could also have a well-collimated light source and I just don’t know about it

[PM490]

Only a single circular polarizer. Do not have a linear polarizer, although thinking about getting a linear film to do more testing.
Definitely do not have a well collimated source.

[cpixip]

If you introduce polarizers into your imaging pathway, be aware that there iexists the so-called photoelastic effect. Many translucent plastics show stress birefringence and you can make colorful images of the stress distribution in a sheet of plastic with polarizers.

With respect to “optimal” LEDs: I actually tried to approach that issue somewhat scientifically, and calculated the transfer functions of my intended “LED->film->camera” setup. To do so, you need the emission spectra of the LEDs, the transmission spectra of the film stock you are working with, and finally the spectral response curve of camera chip you are using. Needless to say, it is quite difficult to get hold of such data.

I did the calculations anyway and came up with an “optimized” setup. However, as it turned out, this setup was far from optimal. For example, the RED LED was way too far emitting in the infrared and the scanner picked up and amplified uneven exposure of film stock which I did not see in a normal projection of the same movie.

So in the end, I simply tried out different sets of LEDs until I got something workable for me (details are noted above somewhere). It seems to depends only slightly on the film stock, much more on the camera and how its internal color calculations work. Also of course on the design of the illumination system. I opted (as detailed above) for a very diffuse one - it reduces the amount of scratches you are going to pick up. But, as @johnarthurkelly already noted, it reduces image contrast…

[johnarthurkelly]

It’d be very interesting to see the work you’ve done calculating the transfer functions for your setup @cpixip!

Would you mind sharing your camera and lens setup as well? I believe this information could help shed some light on the concept of the imaging chain/system for other group members.

@PM490 @cpixip I actually think both of you would find this paper interesting:

Optical Detection of Dust and Scratches on Photographic Film

[cpixip]

@johnarthurkelly: well, that was long ago (2018) and did not result in anything usable. What I did was basically the following: I searched the internet for characteristic curves of movie stock and the camera I was using at this point in time (a Raspberry Pi v1 camera). I then digitized these curves from 400 nm to 700 nm and combined them. This allowed me for a specific LED to calculate the response as well as the cross-talk to other channels. Here’s an example:

The red graph is the expected main response, the green line is a slight cross-talk. The idea was to maximize the difference in the color channels to capture most of the colors. However, the set of LEDs that I ended up with did not perform well. Specifically, as far as I can remember, the following issues arouse:

1. The LEDs choosen had quite different efficiences. I had only access to relative intensity graphs, and there was no easy way for me to correct that.
2. The Red LED turned out to be too much on the IR-edge, actually enhancing some fixed dark red pattern which might have been caused by the uneven coverage of the daylight filter of the Super-8 camera. This was only visible in a test movie I bought via eBay and in my scans of that movie, not during normal projection of that movie. However, it prompted me to abandon that approach. I do not have a good example available any longer, but here
   
   you can notice a dark read glow in the lower right corner of the frame, in the shadows. It is a pattern fixed to the film frame and has a form similar to a too small filter.
3. I discovered that the cross-talk of the Raspberry Pi camera chip v1, if combined with my Schneider 50mm lens is much more noticable than the cross-talk I was trying to minimize with my transfer calculations anyway…

So in the end, I simply bought a bunch of LEDs and swapped them around until I got something which worked…

Ok. Now for the camera/lens setup. Initially, I started with a Raspberry Pi v1 camera. I was aware that there is a slight color shift introduced by the mismatch of the microlens array of the sensor and the lens I was going to use: a Schneider Componon-S 50 mm.

But I developed a technique to compensate that, basically taking several exposures, calculating an HDR image from that and then compensating in HDR-space. However, that was a slow process.

When the v2 version of the Raspberry Pi camera came out, I immediately tried to switch to that camera - only to find out that the mismatch between microlens array and a long focal length lens (compared to the standard lenses these cheap sensor are designed for) is even worse. However, at that point in time the Raspberry camera software introduced the possibility of a lens shading table. I implemented that in my software, and I got resonable results with the v1 camera sensor, using a modified picamera library. It was much faster than my HDR-space based compensation.

With the newer v2 camera sensor however, the results kept being disappointing. I could compensate the color shifts, but the cross-talk resulted in a noticable loss of saturation towards the edges of the image frame. So I reverted to the v1 sensor chip.

I finally abandoned the Raspberry Pi setup alltogether because I discovered that certain colors were not really reproduced good enough - especially brown tones still showed a tendency to be saturated in the center of the frame, but desaturated on the edges of the frame.

My current setup consists now of a See3CAM_CU135 camera, mounted onto a Novoflex bellows with a custom 3D printed attachment. On the other side, the Schneider lens is mounted, fixed at an f-stop of 5.6. Supposably, this is the f-stop with the sharpest image. This setup is currently on a freely movable platform which is moved as a single unit to get the frame into sharp focus. There is certainly room for improvement here.

Here’s an image for illustration

In the background, you can see the film gate attached to an integrating sphere, which I described in detail above. A note about the See3CAM_CU135 camera: if you consider this camera, it is best to use a Linux-based host computer and v4l2. At least I was not able to interface the camera well enough with Win7 or Win10 systems to use it. Example captures can be seen in my post found in this thread: HDR / Exposure Bracketing

And finally: thanks @johnarthurkelly for the link to the paper. Indeed interesting!

[PM490]

Thanks @cpixip for the setup, and @johnarthurkelly for the link to the paper. Interesting foundation for playing some more with the polarizer setup. Thank you

[junker]

@cpixip Can you explain your gate design? I see the two tabs for horizontal alignment on springs, but I also see two ramps on the right side of the film path. Looks very interesting, but I’m unclear on each part’s function.
Thanks!

[cpixip]

@junker - Ok, here’s the story of this gate design.

My goal was to create a mostly 3D-printed design of a Super-8 film scanner. The illumination approach I am using is an integrating sphere (see above). This light source requires for its intended function a film gate very close to the exit pupil of the sphere. If that is the case, small scratches are reduced by the mostly diffuse illumination.

My initial attempts with film gates scrapped from old Super-8 projectors turned out way to bulky, so I decided to take the challenge and design a very flat 3D-printed gate. The specific challenge was here that my 3D-printer, an ANET A8, can print reliably only with about 0.2 mm in the z-axis. That is larger than the average thickness of Super-8 film stock.

The core design is a block with a V-shaped groove, which guides the film only on the edges:

The film channel of the V-groove has the minimum width possible with my printer, of about 0.2 mm. Two identical blocks together with a mounting box compromise the film path:

The two V-groove holding the film in place are attached via some 3D-printed springs to the enclosure; I borrowed that idea from the designs of xyz-flexure stages which are routinely used for very precise movements. These springs are very stiff in the direction of the camera, so the film always stays in focus, but move easily if the film width or film thickness changes.

Of course, it took several iterations before the spring design action worked as intended. Here are some examples of the iterations this design went through:

If I do a next generation, I will fix the lower V-groove to the enclosure. Only the upper V-groove will be able to move via springs. This will minimize a slight wobble which is noticable in the current design if a film cut is encountered. Super-8 film was spliced together with adhesive pads, and they wrap around on the side of the perforation, increasing the width of the film material at that side only. With the current design, both V-groove adapt and move. Ideally, only the upper V-groove should react.

Finally, the two ramps you are seeing in the final design are just guides which ensure that the film, when inserted manually into the gate, is directly aiming at the tiny V-grooves of the film gate. Without these ramps, it is rather difficult to correctly insert the film into the gate. Here are two enlarged view of these ramps and the V-grooves:

If you look closely, the ramps do not reach the level of the V-groove, ensuring that when the scanner is in operation, the ramps do never touch the film. They are just there to help the manual insertion of the film.

In closing, here’s a full view of the gate.

I hope the images and remarks above clarified the design; it the end, it’s a rather simple piece of plastic, with only three 3D-printed parts.

[junker]

Brilliant. Thanks for the detailed write up and clear images.

Having first thought of trying a Wet Gate to reduce scratches, I’ve also started pursuing an integrating sphere design.

Thanks for being so willing to share so much of your knowledge.

[matthewepler]

Agreed! Thank @cpixip. This is fantastic. Are the 3D-printable files available somewhere online?

[bainzy]

Awesome work on the gate design @cpixip. I’m surprised at the depths you’ve gone to with every aspect of the system, whether that be physics and experimentation for the parts, or programming for the software.

With S8 cameras there always seems to be talk about lack of pin registration compared to decent 16mm cameras, and then videos like this (https://vimeo.com/129700087) crop up that suggest when a camera does have it, the difference in overall impression from S8 footage is notable. I guess the tautness of the springs in the direction of the film edges is hopefully doing the same thing as pin registration, but without needing to touch the perforations at all.

[bainzy]

Whilst an RGB LED setup definitely seems like the optimum for extracting as much quality from the film as possible, just to get the system working these white COB LEDs look interesting: https://uk.farnell.com/bridgelux/bxrh-30h1000-b-73/cob-led-warm-white-1033lm-3000k/dp/3106841?st=white%20led

From what I can see the specs (eg. CRI, response curves) look very similar to what other people have been using, but very cheap at under £2 each.

[cpixip]

@bainzy: thanks for the comment!

@bainzy

With S8 cameras there always seems to be talk about lack of pin registration compared to decent 16mm cameras, and then videos like this (https://vimeo.com/129700087) crop up that suggest when a camera does have it, the difference in overall impression from S8 footage is notable.

The video you linked to shows frame-stabilized footage. So the nice impression this example display is not really correlated with perfect pin registration in the camera. In fact, if you look closely at the sprocket next to the film, it is dancing like hell, up and down as well as left and right.

The “up and down” is certainly related to bad pin registration, presumably in the camera. More on this below. Maybe also in the scanner - but that is hard to say.

The “left to right” dance is amazing - I do not have seen this with my own Super-8 scans.

@bainzy

I guess the tautness of the springs in the direction of the film edges is hopefully doing the same thing as pin registration, but without needing to touch the perforations at all.

Well, the width of the Super-8 film stays pretty much constant. So the two V-grooves in my gate design do not move at all most of the time in a left and right direction. Neither does the film.

The grooves do move occationally. This is when there is a cut in the film - as the adhesive tape used to connect two pieces of Super-8 film enlarges the film width during the 4 four frames these pads cover. Here’s an old image which shows this situation:

You see such an adhesive pad just right to the v-grooves, before it enters the gate area.

The small movement of the v-grooves during such a cut is barely noticable however. It could be improved by making the groove opposite to the sprocket hole unmovable, but since I usually frame-stabilize my material anyway, it is currently of no concern in my scanning environment.

To be precise: my scanner does not pin-register the scanned frame at all. The sprocket and the film image dances up and down quite a bit in the scan window (but not sideways, due to the v-grooves). It is only approximately centered in the view of the camera by a stepper motor. I use a simple software to pin-register the frame after the capture. This recovers the original film. Since that is usually shaky like hell (no tripod, for a starter), I usually use VirtualDub with the DeShaker plugin to stabilize the movie.

Some more thoughts about bad pin registration. This is caused from my experience by two factors:

First, the camera registers the current frame to a different sprocket, which is 2 frames ahead. Every Super-8 projector I know is using this 2-frame distance as well for registering the frame. But frankly, this is in my view not the main cause of the sprockets moving up and down.

I suspect that the cause is the following: all Super-8 cameras used as part of the film gate a plastic part hidden in the case of the film.

Here’s a picture of that back part of the film gate of a Kodachrome 40 Super-8 cartridge, for reference:

Clearly, this is not what one would call precision engineering… That part of the camera gate would also be swapped out (changed) with every cartridge of film.

While there have been Super-8 cameras with a good pin registration, my own camera certainly was not. It did display (after some years of usage) the tendency to jitter noticably with the first few frames of a scene. It was simply not a very expensive camera. I can easily cover that issue however with frame-registration in the post.

Also, I bought several old Super-8 projectors to study the technology used in the old times to precisely register the current frame during projection. There are substantial differences engineering-wise here as well, depending on the brand and original cost of the projector. So pin registration in projectors was probably also not always optimal.

Lastly, another factor for “frame jitter” with Super-8 material is certainly that these home movies were barely shot with a tripod. So in a way it is rather “natural” for Super-8 material to jitter around…

The approach with Super-8 depends on the goal you are after. I keep the raw scans with the sprocket neighbouring the current frame for archival purposes and to have the option to process them later in a different, improved way. We will see.

My primary goal is to make that old material available again to young and old folks of my family. Here, heavy processing is involved going from the raw scans to a final movie. I am still looking into this. I know from experiments that my audience prefers more stabilizated films (ie frame-stabilization), less grain and media sizes transferable via social media (where frame-stabilization as well as grain reduction also helps). There exists approaches for Super-8 film, most notably VideoFreds avisynth-based approach (8 mm Film Restoration), but I think I will try to write my own software.

For the Kinograph project, with the focus on 35 mm material, the inital conditions with respect to pin registration and camera movement are very different from my old Super-8 material. 35mm film is professional material. The challenge here is to register as best as you can, possibly even in the case that some sprockets are heavily damaged or distorted by film shrinkage.