The Big Ugly, part 3: proper SMD LEDs, but no cigar (?)

In the previous part of this series, I told about the lessons I learned by trying to use a single RGB COB LED as a light source for both RA4 and B&W enlarging. I took those lessons and gave it another go, this time using a fundamentally different approach. As the title suggests, no cigar yet – although this isn’t really accurate. The second generation device I built was actually used for a year or two before I was sufficiently annoyed by its shortcomings to replace it. So the second generation actually did work – albeit with some caveats.

Read the other parts in this series here:

• Part 1: why this project exists anyway, and what it should do
• Part 2: the first generation tests with an RGB COB LED
• Part 4: the third and current generation color enlarger system

Lessons learned up to now: (1) I need a diffusor before the condensor stack in my Durst 138 unless I want to project pretty RGB rainbows onto the baseboard. Easy enough: frosted plexiglass works OK for this, so no need to worry about this any further. (2) I need to ditch the idea of a convenient RGB COB LED because of its fundamental flaws. And (3) I need much more PWM resolution to mimic the kind of filter adjustments that a dichroic head would give me. Let’s give it a go!

Generation 2: SMD LEDs and proper PWM

Let’s tackle the hairy one first: the actual light source. I did the exercise of the analysis of RA4 paper spectral sensitivity and everything to do with it (read about it here) and determined I needed LEDs of around 450nm blue, something green, and 660nm red. I say ‘something green’ because at the time, green just equaled 525nm with no other flavors to be found. Green is the fussy color of LEDs, it just so happens. So the hunt was primarily for the 660nm red ones and the 450nm blue ones. And from this hunt I learned that for some reason, manufacturers *never* (as of now, at least) include 660nm red into compound RGB LED devices. In fact, the same was true at that time for 450nm blue, although I have the impression that we now do see this color in RGB LED products, at least very sparingly. So conveniently available RGB LED strips, COBs etc. were out of the window. I had to go the discrete LED route.

Furthermore, cheap little 3mm or 5mm LEDs, the kinds you know from signal lighting applications and experimentation kits, lacked severely in power. Your typical 5mm red LED will have a forward voltage of around 1.8V at a current of 20mA, which translates into a whopping…36mW. Right, coming from a 100W COB LED, that’s kind of disappointing. I’d need something like 100 of them to get the same kind of power. Alright, that might work, but (1) you can’t have enough red, so 100 may even be on the lean side, and (2) size becomes a bit of an issue. Cramming 300 LEDs into the small-ish space behind the heat filter aperture of my Durst 138 enlarger head would be challenging, if not downright impossible. To make matters worse, a single 5mm or 3mm LED doesn’t make much heat, but if you try and make a 100W light source with them, the total lack of thermal management measures in normal LEDs becomes a massive problem.

This meant that I would have to leave the comfortable world of through-hole components and other items with nice and long legs to solder onto, and make my way into the surface-mount device (SMD) world. Well, at least dip my toes into it, for now. eBay came to the rescue and I ended up with some bags of 3W SMD LED beads in different wavelengths. I got 640-660nm for the red (‘deep red’), 520-530 ’emerald green’ and a variety of blue ones, including 440-450nm ‘royal blue’. Using these I could actually start planning for a somewhat decent light source, taking into account also the even coverage issue I had run into before. So I made this sketch of what it might look like:

As you can tell, I also did some basic arithmetic to get a feeling for how well I could bake an egg on this thing. Well, it really was about available exposure power vs. heat dissipation issues; there’s a tradeoff between the two. As you can see, the light source I designed was pretty small, because I wanted it to fit in the Durst 138 head right behind the heat filter aperture, so it would be sort of a snap-in replacement of the original tungsten bulb light source. Hence the 90mm square dimension.

Having figured already that I needed lots of red, I went with 20 red LEDs and 8 each of blue and green. These LEDs were nominally 3W, but if you actually look at the specifications and multiply forward voltage and permissible current, they fall significantly short of this – even if you run them right at maximum current. So there’s something funny about how they market these. The forward current rating of each of these LEDs is 700mA, but the forward voltage of each color is quite different, ranging from around 2V for red to around 3.25V for blue. So the blue ones would in reality be maybe 2.25 – 2.5W, while the red ones run out of steam (or go up in smoke) beyond about 1.5W. Using these figures, I made an estimate of the real-world power the light source would dissipate in each channel and in total.

Driving the LEDs: constant current source

I also did something with ‘CSSdiss’ as you can read. This has to do with driving the LEDs. CSS stands for Constant Current Source, because LEDs are current and not voltage devices. Which is to say, to properly drive a LED, you supply it with the desired amount of current, and let the forward voltage drop be whatever it works out to be. You do NOT apply the nominal forward voltage and then hope for the best in terms of forward current. While the LEDs may survive this if you’re lucky, it will be an incredibly poor and unstable design, and for color printing this approach would be totally useless. So for this generation of the LED source I made an array of very crude and simple current sources – or rather, current sinks.

Since each LED color has its own typical forward voltage, I also decided to tailor the supply voltage somewhat for each color channel. The blue and green LEDs are somewhat close in terms of forward voltage, so I chose to put 8 of each color in series, for a forward voltage of around 8 x 3.3V = 26,4V. To have some headroom for the current sink, I chose something in the range of 32V as the supply voltage for these channels. The 20 red LEDs I divided into two groups, making two strings of 10 LEDs in series each, for a total forward voltage of around 20V. Again, a little excess to keep the current source happy and functional, gave me a supply voltage of around 26V. I chose a crude (but as it turned out, effective) approach of a 24V switch-mode power supply and some adjustable buck-boost converters to make the 32V and 26V supply voltages, all off-the-shelf components. Nice and easy.

Now for the current sinks. Well, those were quite crude, and at least somewhat effective as well. Although evidently not efficient. I decided to abuse the behavior of the old and trusted LM317 (actually, its beefier brother the LM350T) to keep its reference voltage constant, which can be exploited to make a constant current sink. The schematic is incredibly simple, which was its appeal:

The LM350T will try to maintain 1.25V on the ADJ pin and in doing so, will limit the current to approximately 1.25/R1. I had 700mA LEDs and didn’t want to run them at their maximum capacity, so aimed for roughly 650mA, which gave a desired value of around 1.9 Ohms. I got some 5W power resistors of suitable sizes; I had to parallel some resistors to get the desired values. Remember that P = I²R, hence the beefy resistors. Moreover, I wanted to keep the temperature increase of the resistors at a bare minimum, because this would have made their resistance increase, resulting in a negative thermal coefficient for the LED current. We’ll get back to this later on! For the red channel, I had two strings of LEDs in parallel and I used a single LM350T current limiter for both of the red strings.

Of course, the schematic above wasn’t the full story – it had no provision for PWM dimming! Again, applying the brute force approach, I made a simple modification:

The IRF510 MOSFET acts as a low-side switch and will modulate the current through the LED string and the CSS in accordance with the PWM signal applied to its gate pin. Yes, I actually used an IRF510 (or something eerily similar) instead of a proper logic-level MOSFET. I somehow got away with it, too. If you look at the curves of the IRF510 and keep in mind that I was driving it directly off a 5V logic pin, you’ll recognize that this was really a borderline case and I was pretty lucky this worked halfway decently at all. After all, the IRF510 needs >10V at the gate for it to fully turn on and hence, it’s not made for logic level signals at all. But hey, it did work! God is with the fools and the drunkards, as an old saying in my country used to go.

The numbers labeled as ‘CSSdiss’ in the LED array design earlier probably make sense to you now: they’re approximations of how much power was being dissipated by the LM350T’s and the series current sense resistors. As you can see, the total was pretty significant, and in the range of 15-20W at full power, so the LM350T’s were each mounted onto a fairly hefty heatsink. Especially the one in the red channel ran hot, but not too hot. I think.

Constructing the light source

As for the mechanical construction: I argued earlier that I’m not a mechanical engineer, so it was also extremely crude. I ordered an aluminium bracket (cut and bent to my specified dimensions) to which I stuck the LEDs with thermally conductive adhesive, wired them up and stuck some fans onto the thing for good measure. Actually, I took an old Pentium 4 stock cooler that I had lying around and glued it to the aluminium bracket as the total power dissipation of the light source was well within the limits of what a Pentium 4 on a good day will burn, so its cooler should do fine here (and it did). I tried to take some snaps of the contraption, but be warned – it ain’t pretty.

Pulse width modulation with a little help from NXP

Now for the PWM issue. That one was actually pretty easy. I was using an Arduino Nano clone for the controller and natively this only supports 8-bit PWM. However, I came across PWM driver boards (for servos and/or LEDs) based on the NXP PCA9685, offering 12-bit PWM across 16 channels. These little boards are available from all sorts of suppliers and cost only a handful of Euros.

I divided the electronics setup into three separate physical building blocks: a power supply, the LED light source assembly (see above) and a controller unit. The following block diagrams give some insight into what’s contained in each:

I think in the end I actually fed 12V into the controller unit instead of 24V, but that’s a minor detail. The block diagram shows the Nano as the main controller and an MCP23016 I2C GPIO expander to handle a couple of rotary encoders (with buttons), a foot switch (very happy with this inclusion!) and a switched 230V input. There’s also room for four 7-segment displays, one each for R (or cyan), G (or magenta), B (or yellow) and exposure time. Note finally the PCA9685 PWM controller that drivers the LED channels. I also used a PWM channel for an exhaust fan in the power supply whose speed is varied in accordance with the combined duty cycle of all the LED channels, which is a pretty good approximation of total dissipated power.

Good bye, ColorStar

The switched 230V input requires some explanation: the diagram says this is for a color analyzer, and indeed I had two LiCi ‘ColorStar’ color analyzers sitting around when I built this. One was the original ColorStar which didn’t have a number attached to it, one was the fancier ColorStar 1000 with its replaceable calibration pots. (If you insist on using a color analyzer, try and get one of the LiCi ones. Doesn’t matter exactly which type; they’re all good. They really are the best analyzers out there, hands down.) Although I had mostly given up using them already because I find they don’t make color or B&W printing much easier or faster, I thought it would be nice to make the system compatible with these color analyzers, which includes an exposure timer. The color analyzer simply switches a 230V mains outlet at its back, and the controller unit of my system plugged into this and used that switched 230V as a digital signal to turn the LEDs on or off. So the 230V output on the analyzer didn’t in fact directly switch the LEDs, but it only triggered a signal to the microcontroller in my system to do something with the LEDs. This trigger signal worked beautifully.

What did not work beautifully, was the color analyzer itself. I ran the PWM frequency of the PCA9685 at its maximum rate of around 1.5kHz and the color analyzer was completely thrown off its bearings by these rapidly flickering lights. Instead of neatly showing gradual filter changes, the indicators LEDs on the ColorStar went totally berserk, alternating between all extremes, and the exposure indicator would also show extremely erratic behavior. I simply abandoned the color analyzers, which I had pretty much done anyway. A few years later I opened up one of those analyzers to see how they actually worked, and as far as I could tell they’re fairly simple transimpedance amplifiers that would have been thrown off by anything except a fairly stable light source. Note that these devices pretty much predated the popularity of PWM, let alone high-power LEDs, so it’s really no surprise they didn’t mesh together very well.

User (in)experience

One of the requirements I had was that the system should be at least as convenient to use as a dichroic head. One thing I really wanted to avoid was what I call the “single-button interface syndrome”. Due to space and financial restraints, and perhaps also industrial design considerations, all too many devices these days try to make do with as few buttons and dials as possible. Alright, I get it – if you get into a Saab 9000 or so from the early 1990s, you’ll see what this is a response to. Buttons and dials literally everywhere – it’s so confusing! So we swung all the way to the opposite end of the spectrum and tried to cram the entire user interface of whatever device into a single dial and/or button. Looks nice, doesn’t it? Well, until you actually try to get something done, that is…

So I stole the excellent idea that all dichroic heads implement, which is: One Dial for Each Filter. I added one more for setting the exposure time, so I ended up with four rotary encoders on my control module. These rotary encoders generally come with a built-in button as well, so this gave me four push-buttons ‘for free’. Well, I needed to be able to start and stop exposures, toggle the LEDs for burning, and perhaps switch between exposure modes (color vs. B&W), so the push buttons came in handy. If you then differentiate between a short press, long press and a ‘double-click’ motion, you can even assign 3 different functions to each push-button, and…alright, I fell into my own trap. Although I did allow for several buttons and dials, I still crammed too much functionality into each button, which creates unnecessary confusion. Lesson learned!

One thing you may notice if you use rotary encoders is that it sometimes takes a lot of time if you want to cycle through a long range of values. Take for instance exposure time: if it happens to be set at 1 second, and it changes in 0.1 second increments (which I decided to do, analogous to the resolution of the ColorStar timers), you can twist that dial until your wrist drops off if you need to go all the way up to 20 seconds. I fixed that by detecting how rapidly the encoder was being turned by the user: if it was being turned slowly, it would increment in single steps. If it was turned rapidly, it would increment in bigger steps, proportionally to how fast the dial was being turned. In practice, this worked sort of OK, with one caveat.

In my inexperience with microcontroller programming, I (1) wired up the encoders to an MCP23017, which essentially puts every pin read behind a bunch of I2C transactions, and (2) I also threw the entire logic of reading short presses, long presses and double clicks of the buttons, as well as the detection of slow/rapid rotary turning and the calculation of the proper increment/decrement for each setting inside an interrupt service routine (ISR). So I had a truckload of code, including several I2C calls, comprising an ISR that was triggered by a pin change interrupt on the MCP23017. Surprisingly, this controller crashed only sporadically… With this level of abysmal coding, you’d expect it to crash pretty much every time you’d come near any of the rotary encoders, but somehow, it kept alive for most of the time. I still don’t know why it worked as well as it did, but suffice to say, it wasn’t optimal, and annoyingly it would miss button presses and rotary movements as if it was a bored teen playing Nintendo Duck Hunt in a drunken stupor. Another lesson learned!

Apart from these ‘minor’ issues, and they were in fact fairly minor, as I got pretty good use out of this controller for a year or two, all worked fairly well. For the color filtration settings, I decided to fake dichroic filter settings by labeling the Blue dial ‘Yellow’ and inverting its action, so that from the perspective of the user, an increase in ‘yellow filtration’ would in fact work out as a reduction in blue light. There’s quite a few things to be said for this, I think, although technically it’s of course not entirely correct. You can’t make a subtractive filtration system out of an additive light setup; it just doesn’t work that way. But it works well enough to make the darkroom experience intuitive if you’re used to working with a dichroic head (which I was) and in terms of print quality, everything seemed to work out OK as well.

Show me your pretty curves: linearization and stuff

There’s one quite important thing we need to tackle. In the previous installment of this series, I already said one or two things about using PWM for RA4 printing. Specifically, I discussed the issue of PWM resolution and also the logarithmic nature of color filtering. I showed some arbitrary numbers in some charts, but in this actually operational version of the light source, I had to determine actual PWM values for the light source I constructed.

The PWM resolution I had at my disposal was 12 bits, so that gave me a range of 0 through 4095 to work with. I could have just directly set those values on the blue and green channels and called it good. In fact, the controller did have a ‘raw mode’ in which I could manually set any PWM value between 0 and 4095 on each of the three channels. But even with the ‘rapid rotary’ trick, it was inconvenient to use that for actual printing, and it somehow also didn’t feel very intuitive. I wanted to lean in a little closer to how things feel when using a dichroic head.

So the obvious solution would have been to more or less copy the filtration behavior of the Durst M605 with its dichroic head. I had it set up in the same darkroom as the 138 when I was developing this system, so it was easy enough to go from one enlarger to the next. There were a few snags, however.

Firstly, it’s not that trivial to determine if the additive PWM setting on a LED head matches the filtration setting on a dichroic machine. I tried some things with measuring color temperature using a Canon 7D dSLR as well as some comparative color prints, and I could get close, but it was pretty hard to nail it conclusively, especially if the slope of each filter channel also had to be determined. I’m sure it could be done, but boy, is it a finicky business if you don’t have a spectrophotometer at hand. And even if you do, I wonder how well it works out trying to compare a filtered continuous light source with an additive, narrow-band one.

Secondly, I didn’t quite see the point…I had 12 bits of PWM resolution to play with, so why settle with the same resolution my dichroic head offered? Why not push it a little further and allow for smaller filter increments? If you can have more resolution, it’s kind of hard to resist getting it. The only valid reason I could think of was the scenario in which I would print the same negative in both enlargers and wanted to be able to carry the same filter settings from one machine to the other. But the whole point of the exercise was really to narrow down to having just one enlarger, so why bother jumping through the hoops of trying to align them perfectly? So I ultimately discarded this idea and just settled for an intuitive filter scale for the LED head without the burden of making it identical to the dichroic one.

I then had to determine two things: what is the ‘neutral position’ for my Green (or Magenta) and Blue (or Yellow) filter settings, and more importantly: how big should each change in filtration setting be? I arbitrarily chose 100Y and 100M as the neutral point because they’re nicely rounded numbers, defined the end point of the scale as 300 (again, arbitrarily) and this left sufficient range on either end of the neutral point to do adjustments. The 300-wide range comes somewhat close to twice the 130-range on a Durst dichroic head (actually goes beyond it a bit, evidently) and it felt like a range that was more comfortable to work with than a 4095-count range, while at the same time still offering plenty of resolution to work with.

I then had to create a translation between the arbitrarily chosen user-visible filter number (0-300 with 100 being neutral) and the actual PWM duty cycles. I did this by assuming a third-order relationship between both scales (mimicking the logarithmic nature of dichroic filters), which seemed to be still quite flexible to make adjustments to (a second-order function is a lot less flexible in adjusting the curve; try it out and see for yourself). To determine the actual parameters of the filter function, I simply hit the darkroom and printed away until I had a set of parameters that produced filtration behavior that felt quite intuitive coming from a dichroic setup. The resulting slope and range of this filter behavior is in all likelihood quite different to what a dichroic head actually does, but my aim was to optimize the printing experience, not to re-invent dichroic heads with LED technology. These are the filter curves I ended up programming into the controller:

The cyan curve I never spent a lot of time on; as it’s pretty much never used, I only included it for good measure. In hindsight, I might as well just left out that rotary encoder, display and filter adjustment altogether. Note the difference in parameters for the yellow/blue and magenta/green curves; these were determined empirically to give close to neutral prints on the (expired…) Fuji Superia film I used mostly at the time with a setting of 100/100 onto Crystal Archive paper. I might as well have taken fresh Ektar printed onto Kodak Endura as a starting point, but frankly, who cares? It’s an arbitrary point, anyway. The important thing is that you can go up and down from it far enough on both relevant channels.

Note that the blue and green curves use quite a large portion of the available PWM range. This is due to the choice of power ratios between red, blue and green, with a lot less blue and green LEDs being used than red ones, which acts as the kind of bias I discussed in the previous article. Note also that despite this bias, for the blue channel I still only use PWM values between around 1500 and 4000, so less than half the available PWM resolution is actually used for the filter settings. And within that filter scale, I found my prints always landed between something like 75 and 150 or so on each filter scale. So the effectively used PWM range ends up being substantially less than 20% of the total range, despite the hardware-inherent color balance between red, blue and green. It’s easy to see here that 12 bit PWM resolution really isn’t a luxury, and indeed, 8 bit resolution is totally inadequate by all means.

For B&W, I did a similar exercise to determine the ratios of blue and green that I’d need to print different contrast grades. Here, I also didn’t bother trying to match my ‘grades’ to any objective benchmark. Part of the reason is that contrast grades don’t appear to have a concrete definition to begin with; the best I could find, was ISO-R ranges for each grade (scroll down to ‘the numbers’ on the linked page).

Instead, I printed a step wedge at various blue and green combinations until I had a set that showed more or less equally-spaced contrast steps. Furthermore, I adjusted the blue channel downward (due to the innate high blue sensitivity of B&W emulsions) so that the exposure time to just hit dmax on the paper would remain roughly the same across grades 1 through 4 or so.

It also turned out I had to mix a tiny bit of blue into the filter setting for the lowest grade. Exposing paper with only green light gave excessively low contrast, excessively long exposure times at which dmax would not even be hit, and an excessive amount of halation/image degradation. My conclusion was that even at grade 00, you still need a tiny bit of blue to get the paper producing halfway decent prints. I did most of this testing with Adox MCP RC paper, but it seems that for instance Fomaspeed and Fomatone show pretty much the same behavior.

Finally, I also experimented with non-linear relationships between blue and green to mix the different paper grades, but the benefit of curvilinear relationships turned out to be insignificant, while they did evidently make the controller software a bit more complex. Abandoning that route, I came up with the following blue/green mix gradients to hit all the available paper grades:

In the end, everything worked out so well, that in the preparations for moving to our new home, I actually got rid of both my M305 and my M605 Durst enlargers. While working with the second generation LED head on my Durst 138, I found that the M605 didn’t see any use anymore, even for small formats, and the M305 was disassembled in a corner taking up space. So all considered, the second generation light source was pretty successful. If you have used either the M305 or the M605 with a color head, you know how pleasurable they are in use, generally. So if I say that my own contraption was actually nicer to use, I think that means something. I made thousands of color and B&W prints with it, from all kinds of film and formats, and for the most part, it worked very well indeed. Except for some minor issues that ultimately triggered generation 3.

The cyan drift problem

Pretty soon into the second generation adventure, I noticed something odd – and disconcerting, for sure. Some prints would have a distinct cyan cast, and the issue would come and go, changing in severity, with no clear cause. It took me some time to figure out that the problem was the most severe when I had loaded a new negative into the enlarger and had spent some time focusing and aligning the baseboard. I deduced that probably it was some kind of thermal drift issue: for focusing, I had the light source run at full power (all three color channels at 100% duty cycle, so permanently on), which made things warm up. Although it nothing ever got dangerously hot, both the light source itself and the led drivers/CSS would heat up quite a bit.

Now, I never really bothered to figure out what happened exactly. In one way, the problem was kind of odd: the longer I kept the focus light on, the more a print made immediately afterwards would shift to cyan. So somehow, as things heated up, the output on the red channel would increase. This is rather counter-intuitive, because if you look at typical temperature derating curves of LEDs, they’ll show a reduction of light output as temperature increases. Moreover, the strength of this effect is unique for each type of LED, so it’ll be different for whatever blue, green and red LEDs you use. This translates into a nasty reality: as a combination of R, G and B LEDs heats up, the output ratio between them will shift. In other words: color balance will change with exposure time, as the LEDs heat up as you leave them on longer.

However, as I said, this was not the exact problem I ran into, because (1) it seemed to be limited to the red/cyan channel only and (2) the change was exactly opposite of what you’d expect in a thermal derating situation. I then thought a bit about the current sinks, particularly the series sense resistors, but here as well you’d expect the opposite effect: as these resistors heat up, their resistance increases, but the LM350’s try to keep their reference voltage constant, so the pass current actually drops, as would light output. So again, this would be a negative temperature coefficient, not a positive one.

The best (untested) hypothesis I can come up with is that it’s actually something that happens inside the LM350’s themselves. Perhaps the reference voltage shifts somewhat as the device gets hot, resulting in a positive temperature coefficient. I did not do actual measurements on this, as it would have necessitated partial disassembly of the power supply and possibly the light source as well.

Instead, I took the easy way out and programmed the controller to not use the red channel for focusing. I reasoned that for regular exposures, exposure times would (1) be short enough for the cyan drift problem to not be particularly bad, and (2) exposure times for strips and prints can easily be kept more or less the same, making for no or very little inconsistencies between test strips and consecutive prints. As long as print-to-print consistency was good, I was willing to accept an absolute non-linearity in filtration balance depending on exposure time, with longer exposures requiring a slightly adjusted filtration setting.

The workaround of disabling red for focusing when doing color printing worked so well that the issue didn’t bother me anymore in the darkroom. It also didn’t keep me up at night, but it did bug me in the back of my head. I reached two conclusions based on this phenomenon:

1: Thermal management is a Thing. And the easiest way to limit thermal drift problems is to try and keep the temperature of the head as constant during an exposure as possible. So ensure excellent heat dissipation, and keep exposures short if possible. Interestingly, these are opposing forces: to keep exposures short, you want to throw more power at the problem, but doing so will necessitate even better cooling measures. But there it is, you generally can’t have your cake and eat it.

2: LM350’s (and LM317’s) or basically any kind of crude current sink is just a poor way of driving LEDs. For one thing, it wastes power, which necessitates measures like having separate supply voltages for different LED colors, big heat sinks, etc. Also, I have severe doubts about how precisely a linear voltage regulator will limit current in a situation like this – keeping in mind as well that we’re PWM driving the whole thing, which means we’re basically turning the LM350 on and off very rapidly, giving it very little time to settle especially with high PWM frequencies and/or short duty cycles. I never scoped this, but I suspect there’s a truckload of ringing and drift occurring if you look at the current through the LEDs in a setup like this one. There’s so many effects that will probably mess up with the stability of such a current source that I didn’t even feel it worthwhile to try and analyze the problem. It’s just a fundamentally flawed situation. (Which, of course, worked surprisingly well in practice if you realize how incredibly horrendous it is, conceptually.)

I just can’t do it captain, I don’t have the power!

There was one more thing that I didn’t quite like about the second generation light source. Printing enlargements from 35mm onto B&W warmtone paper was a sloooow affair. The problem had a few causes that interacted:

1: Remember I was using a hybrid diffusor-condensor approach with a large-surface light source shining through a diffusor into a stack of condensors. In practice, this meant that when working with 35mm negatives, I was basically just using the tiny center portion of illuminated rectangle that passed through the condensors. Hence, the majority of the light emitted by the light source didn’t even make it to the negative as it was wasted on the mask. So there’s a gross inefficiency at work here.

2: Warmtone paper is slow to begin with. Generally about a stop or two slower than B&W paper, which in turn is slower than RA4 paper. So even if my prints were nice and quick when doing color, warmtone B&W simply calls for orders of magnitude more light.

3: When doing variable contrast (VC) printing, we’re using a combination of blue and green light. Due to the nature of VC papers, their sensitivity to green light is particularly low. Add to this the ‘green gap’ of LED technology, and it becomes easy to see that green is actually the bottleneck for VC printing, just like red is the bottleneck for RA4 paper. I had dimensioned my light source on the red bottleneck for RA4 printing without realizing how bad the green bottleneck for B&W printing would be. After all, this wasn’t all that easy to determine theoretically, so it was one of the things that just had to pop up in practical experimentation / use.

So that’s one more lesson learned: when designing a light source like this for both color/RA4 and B&W/VC printing, ensure ample red, but also ample green. Especially if a true condensor design isn’t feasible, which to the best of my knowledge is pretty much impossible at this stage with existing LED technology. Well, at least at reasonable power levels – you probably could make a rather dim near-true point source for a condensor setup to make e.g. 5×7″ prints from 35mm negatives or so. Perhaps you feel/think differently and I’m certainly open to corrections at this point (or any other point, really).

Closure – or not

In conclusion, the second generation of this system was pretty successful. The SMD LEDs of my selected wavelengths produced color prints that didn’t look any better or worse than those I made with the Durst dichroic heads. I had to live with a cyan focus light when printing color, which was somewhat inconvenient, but not a major issue. B&W prints also went well and for the most part were problem-free, although printing speeds with warmtone papers were longer than I liked them to be, and very big enlargements (I did up to about 50x60cm from 35mm with this setup) necessitated somewhat long exposures as well. The controller / user interface was intuitive, although plagued by minor bugs that annoyed me at times, but overall, also this aspect worked well enough to happily live with it for a year or two.

But why leave ‘good’ alone if ‘better’ lurks around the corner? There just had to be a 3rd generation at some point. And boy, did things turn ugly at that point! Or…did they?