RGB LEDs for color enlargers

[koraks]

Per Koraks' suggestion, here are the oscilloscope traces of the + and - inputs

Well, to be honest, I never suggested this particular measurement, but a voltage trace across a small value resistor in series with the LEDs. What voltage the LEDs see isn't particularly interesting due to its non-linear relationship with light output. It would be much more interesting to see the correct that goes through them. My expectation is that the 0-signal 4 to 2.8V output doesn't do anything in terms of current (and it may or may not be due to an output filter cap; it's a buck topology driver so it may just be driving the switching FET just below the set current threshold) and that the rounded corner on the onset of the duty cycle will be there in a current measurement and not be (purely) due to LED V/I characteristics. As you see, an actual current measurement takes away much of the guesswork, which is why I recommended it before as well.

Are you planning to use a LUT for color as well? That sounds like a big table; see my earlier remark on this.
I'd be wary of a 10% deviation for color printing, but maybe it isn't half as bad in reality as it would seem in my head!

 

[albada]

but a voltage trace across a small value resistor in series with the LEDs.

I'm slow on the uptake, but I see now why a current measurement is better. It's below. The top two traces are both sides of a 3-ohm power-resistor, and the bottom trace is the phototransistor.

Now it's clear that I goofed (which koraks probably suspected the whole time ). Mean Well is outputting approximate square waves, yet the scope is seeing RC smoothing of them. A calculation tells me the 20 pF capacitance in the probes can't do that, so it must be that the phototransistor (Vishay TEPT5700) responds slowly. Its datasheet says it's for measuring ambient light, and it makes no claims about response time/frequency. I should have known better.

Are you planning to use a LUT for color as well? That sounds like a big table; see my earlier remark on this.
I'd be wary of a 10% deviation for color printing, but maybe it isn't half as bad in reality as it would seem in my head!

For each color, I use a LUT to convert the attenuation of that LED-chain into its PWM. Attenuations (i.e., stops of dimming) are in the range 0.0 to 6.0 (in steps of .1), so that's 61 entries. Three colors means that these three calibration-tables consume 183 entries, which is small. The theoretical curve is PWM = 4096 / 2atten, and my calibrated-values in the LUTs don't stray by more than 10% from that formula.

I calibrate a color using the easel-meter by Darkroom Automation. After calibrating an entry, with the LED on, I calibrate the next entry by reducing PWM (using the rotary encoder) until the meter shows exactly 0.10 stops less light. Calibrating all 183 entries takes 30-45 minutes, which is tedious, but it's only done once.

So I don't have a big color-table. Rather, I have three small tables that ensure attenuations are accurately converted into PWM values.

 

[koraks]

Thanks for the follow up, this is very clear and looks much more sensible indeed
I indeed sort of evaded the issue of your sensing circuit because I knew a direct measurement of current would eliminate this variable. Anyway, you now have a pretty decent way to determine actual LED current.

Now you could (if you're interested) check the linearity of your LUT tables by comparing the LED duty cycles to the color values reported by your meter. The reasoning behind this is that non-linearity of overall LED output will be pretty much insignificant above a certain threshold PWM value (very short pulses tend to suffer from issues depending on the driver and PWM frequency).

It would be interesting to see if there's a non-linear relationship between the actual duty cycle and the light levels reported by your meter. If so, this would present an interesting puzzle, let's put it that way

 

[albada]

Now you could (if you're interested) check the linearity of your LUT tables by comparing the LED duty cycles to the color values reported by your meter. The reasoning behind this is that non-linearity of overall LED output will be pretty much insignificant above a certain threshold PWM value (very short pulses tend to suffer from issues depending on the driver and PWM frequency).

It would be interesting to see if there's a non-linear relationship between the actual duty cycle and the light levels reported by your meter. If so, this would present an interesting puzzle, let's put it that way

Sure; I'm up for a challenge . Here's the plot of my three attenuation-to-PWM tables (which are actually calibration tables):

The black line is the theoretical ideal (PWM = 4096/2atten). As you can see, green strays the farthest from the ideal curve, but even it's no further than 10% off. BTW, the table goes up to 31 instead of 61 because I deleted the odd entries and interpolated them, to reduce EEPROM usage.

Staggering. I recommend that the colors turn-on staggered within the first PWM-period to avoid voltage-sag in the power-supply that might occur if all colors were to turn on at the same instant.

 

[koraks]

As you can see, green strays the farthest from the ideal curve, but even it's no further than 10% off.

Yeah, looks pretty good and I'd be tempted to think that this 10% deviation is more of a measurement problem than an actual light output reality.

I recommend that the colors turn-on staggered within the first PWM-period to avoid voltage-sag in the power-supply that might occur if all colors were to turn on at the same instant.

Or just add a somewhat larger output capacitor on the power supply. The response of a decent SMPS is pretty quick, so you only have to bridge that initial rising slope with it. You could run the numbers on it, but the outcome would be that you don't need all that much capacitance for it, really.

 

[albada]

For those interested in building a DIY LED-head, Mean Well has obsoleted their LDD models of LED-drivers, and introduced the new NLDD models. For example, "NLDD-700H" is the 700 mA model. Following koraks' advice to boost my power, I just ordered three NLDD-1400H (the 1.4 amp model) from mouser.com, and I'll soon order some 3 amp Cree XE-G LEDs, which I'll drive at about half-power, leaving lots of headroom.

If you are considering building a LED-head, the info below about the latest LEDs and drivers will interest you.

To double the power of red and green in my LED-head, I ordered a larger power-supply, the NLDD-1400H drivers mentioned above, the "photo red" and green XE-G LEDs, and copper "stars" onto which the LEDs are soldered. The NLDD-1400H (by Mean Well) and XE-G LEDs (by Cree) are new products. After removing old electronics, and much soldering, all the new electronics are running. And working (whew!).

I need to recalibrate red and green, but measurements with my easel meter are reasonable. The new Mean Well drivers doubled the red brightness. Green brightness increased by 0.75 stops. I'm speculating that the 0.25 stop shortfall is due to tolerances in both the old and new drivers.

I'll report later on printing with the new XE-G LEDs. These LEDs are rated at 3 amps (!), but I'm running them at 1.4 amps, leaving plenty of margin (and producing less heat). The spectral distribution of green is slightly narrower than the old Cree LEDs, so I can't imagine these new green LEDs will cause any problems. The red LEDs are "photo red", which means 660 nm; my old ones were the typical 630 nm. 660 nm is better for RA4, so I switched based on koraks' advice.

I kept the old royal blue LEDs (Cree XTE family) because their power is adequate (B&W and RA4 papers need less blue), and the electronics-supply companies didn't have royal blue XE-G LEDs in stock.

EDIT: After reading the specifications of the new XE-G LEDs, I discovered why green fell short by 0.25 stops when doubling current: LEDs become less efficient at higher currents. The current-flux curve for green predicts a 0.29-stop shortfall for a .7-to-1.4 amp change, whereas the curve for photo-red has almost no shortfall (virtually a straight line). So this behavior is expected, and all is well.

 

[albada]

A recap: @koraks suggested that I boost my LED-power, so I upgraded my red and green LEDs to the new Cree XE-G family, and have been printing with them for a few weeks. Blue needs less light because paper is most sensitive to blue, so I didn't try to upgrade those. ledsupply.com is not yet offering these LEDs on stars (metal disks), so I bought blank stars from Cutter electronics in Australia, and the LEDs from an electronics supplier, and soldered them myself. The soldering is delicate work because the electrical pads are tiny even by SMT standards. Solder paste must be applied very sparingly, and the LEDs must be positioned accurately. I soldered them by placing each star on a kludged hot-plate. Below are my comments about these XE-G LEDs.

They work well for black and white (I haven't tried color). The focus light (all LEDs at max power) is almost too bright for small enlargements. It's nice to have light to spare.

A nasty surprise: Most XE-G LEDs become inefficient above 1 or 1.5 amps. For example if you boost current of green from 1 amp up to 3 amps, you would expect to get about 3 times as much light. Well, you get less than twice the light! That's because green becomes inefficient at high power. Therefore, I recommend not running these LEDs above about 1.5 amps. I'm running mine at 1.4 amps, so the efficiency of green is still decent. Colors at the extremes of the visible range (red and violet) are more efficient; their curves are almost straight lines. But the green curve sags significantly at the high end. This is the "green gap" that @koraks mentioned.

Be careful about heat dissipation. I mounted the stars on a sheet of aluminum to conduct the heat away, and it now gets rather hot in the middle when everything runs at max power for a few minutes. So I bought a much thicker aluminum plate and will mount the LEDs to that. And this is at 1.4 amps; I hate to imagine how much heat the rated max of 3 amps would produce, especially at the reduced efficiency.

Anyway, I recommend these LEDs, but I suggest running them at 1.4 amps or lower. The Mean Well NLDD-1400H drivers supply 1.4 amps and are stable, so I recommend them as well.

 

[koraks]

Very interesting findings! The efficiency drop is especially interesting, especially the question if it's also true for very brief, short periods as in a PWM situation with <100% duty cycle.

 

[albada]

Very interesting findings! The efficiency drop is especially interesting, especially the question if it's also true for very brief, short periods as in a PWM situation with <100% duty cycle.

In a month of printing with both medium and low duty-cycles of green, I've seen no evidence that efficiency is affected by PWM duty-cycle, at least not at 1.4 amps. But I use calibrated PWM settings.
To answer this interesting question, I just performed an experiment: I put the controller into PWM calibration mode, and ran green at 100, 50, 25, and 12.5% duty-cycles, and measured the light relative to 100% with my easel meter (bought from Darkroom Automation). The results:

• 50%: light dropped by .99 stops
• 25%: light dropped by 1.98 stops
• 12.5%: light dropped by 2.95 stops

Apparent efficiency improves slightly at lower PWM. But these small deviations might also be due to rise/fall characteristics of the Mean Well drivers. I don't know. I use calibration tables for PWM to hide such quirks in the electronics. My conclusion from this quick experiment is that PWM might have a small effect on LED efficiency.

 

[albada]

In his article, @koraks wrote:

Has @koraks or anyone else tested a 480-490 nm LED for blue? I measured the curves in his article with a ruler, and found the peak to be at 487 nm, not that it makes any difference. I ask because the gap between the blue and green curves is greatest there, so it seems to me that 480-490 would yield the most saturated yellow.

Also, I sure would like to know the wavelengths of the lasers in the commercial RA-4 printers.

 

[koraks]

Apparent efficiency improves slightly at lower PWM.

Yeah, but that's not a very substantial effect, so it seems the efficiency degradation is instantaneous. In a way, this is good news because it suggests only marginal non-linearities in the startup-behavior of the LEDs. My thinking was that they might heat up and over that time lose efficiency. This would result in a high peak at turn-on, followed by a slope towards their ultimate (lower) efficiency. Seems this either happens within microseconds (or even faster) - or not at all. Mind you, the underlying physics are probably complicated, with differences and interactions between actual junction temperature and substrate thermal inertia etc.

Has @koraks or anyone else tested a 480-490 nm LED for blue?

Nope, but I still find it a tantalizing avenue! Indeed, my thinking as well it should produce the purest hues possible from the paper.

Also, I sure would like to know the wavelengths of the lasers in the commercial RA-4 printers.

You're not the only one, but so far I haven't found anything on this in the public domain. Years ago I worked at a place where people would have known, since they engineered that sort of equipment. Well, somewhere in the organization, at least. But it's too long ago to bug them about it now.

 

[pwadoc]

So I'm a little late to this game, but I've spent the last two years designing an LED light for scanning film, which is actually this same problem just in reverse. You need LEDs that emit specific wavelengths, you need a good power output, a linear response and in my case I also needed very high resolution and frequency PWM. One problem I also had that I believe you will run into is that it's very hard to diffuse an array of LEDs composed of different color emitters rather than an array of RGB emitters.

I initially pursued the same approach you tried here, attempting to source commercial LEDs that fit my requirements. However, after running into some serious issues with diffusion, I contacted a Chinese company (http://www.bestsmd.com) that manufactures custom RGB LED emitters, and sourced a few hundred of them for ~$200. There are order size limits that apply to certain wavelengths, but if you're willing to hit their minimum order quantities you can configure an emitter with any wavelengths you want on it. You can even have more than three colors, so that if you need warm ore blue than the other colors for instance, you can add an additional blue emitter. For this use case you'll probably want their high output emitters, which consume about 1W per RGB emitter.

Having done a lot of investigation into how film dyes work in various photographic emulsions (I highly recommend Digital Color Management Encoding Solutions, by Giorgianni and Madden if you interested in how exactly it all works) I don't see any reason you can't make this work with LEDs. The fact that LEDs emit narrow wavelengths is actually an advantage rather than a drawback, the fact that the dyes in RA-4 paper have sensitivity curves that aren't linear was actually a problem to be combatted, and using narrow band light sources makes the process a lot easier. As for light output and efficiency, LED are radically more efficient than anything than anything that would have been used in a traditional enlarger. The reason LEDs need thermal control is not because they are inefficient, but rather because if you heat up an LED it will start to draw more current, which makes it even hotter, and if this process isn't curtailed you encounter a thermal runaway condition that will exceed the maximum operating temperature of the emitter. To get the kind of output you need for an enlarger you'll likely need a beefy heatsink with a couple of fans.

I also noted that you're manufacturing boards at home for your emitters, which implies you have at least some familiarity with PCB design. I would highly recommend checking out JLCPCB.com. They will build you 5 boards for < $40 shipped, and that included aluminum substrate boards which are perfect for LEDs since they act as a heatsink. This is the board I designed for my light with the custom RGB emitters soldered on:

 

[koraks]

One problem I also had that I believe you will run into is that it's very hard to diffuse an array of LEDs composed of different color emitters rather than an array of RGB emitters.

It's not a big issue. Yes, you need a diffusor, and that comes at the cost of available flux. So there's just the compromise between power and diffusion.

Your solution of having custom emitters made sounds interesting, although I'm not exactly sure how it would make an enlarger light source design any easier.

To get the kind of output you need for an enlarger you'll likely need a beefy heatsink with a couple of fans.

That's correct. Well, at least the heatsink. For a small format enlarger (e.g. 35mm only) and modest enlargements, you could certainly get away with a passively cooled system.

 

[pwadoc]

It's not a big issue. Yes, you need a diffusor, and that comes at the cost of available flux. So there's just the compromise between power and diffusion.

Your solution of having custom emitters made sounds interesting, although I'm not exactly sure how it would make an enlarger light source design any easier.

There are a couple of advantages. The first is that you can customize the color output profile to an extent that would be difficult with individual emitters. Like I said before, you can add an additional emitter in a specific color for more output, you can choose exactly the wavelengths you want, you can add a white emitter for focussing, etc. As you noted, RA4 paper needs some extra red relative to the blue and green. Maybe just add another red emitter to your custom chip.

Also, as you noted diffusion is a compromise with power. You can pack a lot more emitters on the board and the individual emitters on each chip are very close together so you can get away with a lot less diffusion and realize more light output.

Finally, and in some ways more importantly the big problem is heat distribution. I note you have already encountered this problem, and designed that op-amp heat sensor setup. I had similar problems, I had a series parallel layout, and some strings would heat up more than others. You can get discrete components that are designed to balance out the current in parallel LED strings, but I wanted to keep my design as simple as possible, and the RGB emitters pretty much entirely eliminated the heat distribution problems. The density of the emitters means that one strand is a lot less likely to get hotter than the other strands, and as long as the heat on the board is distributed _evenly_ you can rely on dumb cooling.

A fewnotes on the board design:

I think the linearity issues you are experiencing have a few possible culprits. The first and simplest might be that you don't have a resistor driving the gate of the PWM MOSFET. While the FET you are using has a threshold Gs voltage of 4V max, you'll notice that a lot of the specs for stuff like RDSos and Qgc are noted at 10V, which is pretty typical for FETs. What this means is that while your FET is going to conduct at the 5V that the PWM output pin of the driver puts out, it might not be turning on all the way, and its definitely not turning on as fast as specified. The data sheet doesn't actually have any of the critical specifications listed at 5V, but if I assume that you're using 10Khz PWM at 8bits, and using the 10V specifications, you'd need 30mA to turn the thing on, which means ~170Ω resistor at 5V. Those numbers will be different at 5V, and you will almost certainly need more current to turn it on, so I'd play around with resistor values and see how they affect your PWM waveform. I'd also consider picking a different FET that has specifications for 5V so you can do the frequency/input capacitance/gate charge calculation to figure out what input current you need to turn it on at the speed you want. Alternatively you can add a gate drive that will feed it 10V, but that involves adding a 10V power supply to your board.

You could try removing the output capacitor from the board. 100nF probably isn't hurting it too much, but you might also be able to get away without it. Any output capacitance is going to slow the transition times on your output signal though.

The EMI issues you note with the board can definitely have consequences for the operation of the driver. Switching regulators are very finicky and sensitive to layout problems, particularly with discontinuous ground return paths. You want to make sure that any components that are switching have very short path to ground. It canoe difficult to intuit exactly where the current is flowing, but it's important to making sure you're not creating a situation where a signal is bleeding into other parts of the board. Non linearity is one of the most common symptoms of this sort of problem in a LED drivers.

I also think you might be introducing some unnecessary complexity by choosing such a high PWM frequency. As you noted in one of your blog posts, you need a high PWM resolution, but since RA-4 paper doesn't have a shutter speed you can actually get away with a pretty low frequency. The other thing about 10Khz is its still in the audible frequency range, so you may hear an audible whine from your drivers. For this reason a lot of applications that require high frequency PWM shoot for 20Khz and above.

This is a super cool project! Seems like you put a ton of work into it, and it seems like it functions pretty well aside from the small things you've noted.

 

[koraks]

Thanks for your thoughts, but I have a feeling you're commenting on a very old version of my build. The present version uses LEd driver chips - yes, with an external MOSFET, but the chip has a dedicated gate driver that handles your concerns.

Also, I'm not sure I necessarily agree with the things you say. For instance, adding a gate resistor will limit the gate current and hence protect the driver, but it will certainly not make any PWM more linear. It will just make the PWM block wave more rounded - and produce non-linearities as a result.

You could try removing the output capacitor from the board.

I think you're mixing up a variety of projects here. There's @albada's design, which has gone through a couple of versions, and he uses off the shelf led drivers that supposedly have output filtering caps. I'm not sure if his latest version has an output filtering capacitor. None of my designs ever had one, and my designs have always been fundamentally different from his.

The data sheet doesn't actually have any of the critical specifications listed at 5V, but if I assume that you're using 10Khz PWM at 8bits, and using the 10V specifications, you'd need 30mA to turn the thing on, which means ~170Ω resistor at 5V.

That's a very crude way of trying to model the response of a MOSFET. Frankly, what I'd do (and what I indeed did, many times) is simply model it in SPICE with realistic component parameters to see what gives a desirable PWM waveform. That tends to involve low impedance to handle line capacitance and of course input capacitance of any MOSFET switches.

As you noted in one of your blog posts, you need a high PWM resolution, but since RA-4 paper doesn't have a shutter speed you can actually get away with a pretty low frequency.

The high PWM frequency was/is there for another reason; it has to do with part of the system that hasn't materialized yet. But indeed, it might just as well run at 100Hz or 1kHz.
Btw, there's no noise as it's running now.

As to the LEDs: I see your point, but again, I don't necessarily agree. Bundling more emitters on the same COB is not necessarily a bad thing, but for instance it won't help with the diffusion issue necessarily. In addition, with discrete LEDs it's perfectly feasible to attain very high power levels that far succeed the real-world requirements of an enlarger. So I'm sure your solution works, but frankly it sounds like a bit of a roundabout way if adequate off the shelf components are readily available. Still, very interesting to hear about the possibilities of doing low MoQ customizations!

 

[pwadoc]

Thanks for your thoughts, but I have a feeling you're commenting on a very old version of my build. The present version uses LEd driver chips - yes, with an external MOSFET, but the chip has a dedicated gate driver that handles your concerns.

Also, I'm not sure I necessarily agree with the things you say. For instance, adding a gate resistor will limit the gate current and hence protect the driver, but it will certainly not make any PWM more linear. It will just make the PWM block wave more rounded - and produce non-linearities as a result.



I think you're mixing up a variety of projects here. There's @albada's design, which has gone through a couple of versions, and he uses off the shelf led drivers that supposedly have output filtering caps. I'm not sure if his latest version has an output filtering capacitor. None of my designs ever had one, and my designs have always been fundamentally different from his.



That's a very crude way of trying to model the response of a MOSFET. Frankly, what I'd do (and what I indeed did, many times) is simply model it in SPICE with realistic component parameters to see what gives a desirable PWM waveform. That tends to involve low impedance to handle line capacitance and of course input capacitance of any MOSFET switches.



The high PWM frequency was/is there for another reason; it has to do with part of the system that hasn't materialized yet. But indeed, it might just as well run at 100Hz or 1kHz.
Btw, there's no noise as it's running now.

As to the LEDs: I see your point, but again, I don't necessarily agree. Bundling more emitters on the same COB is not necessarily a bad thing, but for instance it won't help with the diffusion issue necessarily. In addition, with discrete LEDs it's perfectly feasible to attain very high power levels that far succeed the real-world requirements of an enlarger. So I'm sure your solution works, but frankly it sounds like a bit of a roundabout way if adequate off the shelf components are readily available. Still, very interesting to hear about the possibilities of doing low MoQ customizations!

Ah, OK I was a little confused because it didn't look like the driver in your blog post could turn the fet all the way on, (just back of the napkin calculations based on the data sheet values) but it sounds like it does what you need it to regardless. Sorry for confusing the two projects, I've just been up to my elbows in LED driver optimization for months now so it's exciting to see a similar application.

 

[koraks]

The very first version I used indeed was a marginal application of something like an irf840 or so driven from a 5V PWM signal. I'd have to look it up to get the details straight. They did turn on alright, but as you noted, it was far from ideal. The current version uses buck drivers and that works quite well. There are of course many ways to skin a cat. And yes, it's nice to come across people who are working on similar things; the issues you mention I also spent a lot of time on figuring out and optimizing. Currently I'm working on other things; the color enlarger works and is being used regularly, mostly for color work as intended.

 

[albada]

@koraks : I re-read your article, and this statement stood out:

Experimentally I found that royal blue LEDs with a peak emission closer to 450nm work better than regular blue ones with a peak around 460-465nm, and also better than shorter-wavelength LEDs.​

We can phrase that mathematically as follows, where 'quality' is a function yielding visual quality (mostly hue purity).

quality(shortWaveLength) < quality(450)​

quality(465) < quality(450)​

These imply that royal blue (450) is optimal, or close thereto, because moving either direction away from 450 reduces quality. This reasoning assumes the quality function has only one peak, and not another around 485. Furthermore, you have made many prints using 450, and they look fine.

My question is: Is the second inequality (quality(465) < quality(450)) an error?
As wavelength increases, the B-G difference between the curves increases, which should improve purity, especially of yellow. Should the quality of 465 (regular blue) be re-checked?

 

[koraks]

If you're in a position to recheck or verify it I'd certainly encourage it. There's always a possibilty that my observation was tainted by another parameter.

 

[albada]

Further reading of @koraks article might have answered my question above. He states that Kodak uses a Wratten #98 for blue, and he shows its graph, which has a minimum at 425 nm. We must remember that tungsten's spectrum is roughly an angled line through blue, so those two spectral curves should be multiplied together (actually added because they are logarithms). Then a weighted centroid of the resultant curve must be computed, and I believe that both computations will shift the minimum rightward, making it land near 450 nm, which is the royal blue that @koraks recommends.

But why would 450 nm give better results than longer wavelengths in which the blue-green spread is larger? I'll guess the answer is in the thresholds of green and blue. In black and white paper, the green emulsion has low sensitivity and some threshold; blue has high sensitivity and a different threshold (i.e., it needs a different amount of light than green to produce a tone). In color paper, I suspect that the emulsion-thresholds were chosen to make 450 nm work well.

I was thinking of buying some regular blue LEDs, but Kodak's use of Wratten #98 made me think of the multiplication/threshold/centroid ideas, and made me decide that royal blue (450 nm) is probably best after all.

 

[eli griggs]

I've not read the majority rty of post to this thread and dinner is waiting, but I'll ask if anyone has tried any of the RGB panels from Lume Cube, in an enlarger, particularly a small one?

I have the current RGB Panel Pro, with Bluetooth connection controller software to my cell phone or PC, and I've a few smaller enlargers that I believe will do just fine, should I return to colour printing.

This panel has a wide lighting range from 7500K down to 2700K lighting and a typical 'pie' colour pallet, with adjustable light levels, from one (1) to one hundred (100) and a saturation control, all adjustable by way of the cell phone.

Cheers,
Eli

 

[koraks]

@eli griggs that will probably work in combination with dichroic (subtractive) filters. This thread is about additive filtering using red, green and blue LEDs, however. There have been threads about replacing incandescent bulbs in enlargers with white LED lights; do a search on that, you may find something color-related as well. If not, maybe make a new thread on it.

 

[ic-racer]

Impressive work in this thread!

 

[koraks]

Impressive work in this thread!

Thanks, without taking credit of course for the valuable comments and contribution by others.
Quite recently, I followed up on this with the (for now) most recent version of my system: https://tinker.koraks.nl/photograph...gly-rgb-led-head-for-color-printing-revision/
This version is a lot more compact (and a little less powerful) than the previous version I used. The concept is still very much the same and since I first posted about this, I've made many hundreds of perfectly fine prints from negatives ranging from 35mm up to 4x5" with this setup, both in color and B&W.

 

[ic-racer]

A little off topic, but I saw on your blog you had a durst print processor. Is that what you are currently using?