The Big Ugly, part 2: the RGB COB LED approach to color enlarging

Previously, I explained why I thought I needed a color light source and in general terms what it should be capable of. I also highlighted that it’s not so much a project with a clearly defined end (or at least, that hasn’t materialized yet), but more of a journey that continues into the present, and probably future as well. In this part, I’ll go through the phases this project has gone through. That is to say, there are really three distinct generations of the device I’ve built, and each has taught me different lessons. Before going into some details of the current (and 3rd) rendition, I’ll try to go through each generation and explain what it was/is and what its main caveats were (especially generations 1 & 2). Let’s start with the first generation I built.

Read the other parts here:

Generation 1: the COB LED approach

At the start of a project, hopes are high and you don’t really expect all the complexities that bite you in the end. So enthusiastically, I picked up a couple of 100W COB RGB LEDs from eBay. At that point, these COB LEDs were pretty new still and the 100W arrays were really the most powerful you could get. They weren’t as cheap as today, but still quite affordable. I did not spend much time pondering wavelengths or sensitivity curves of paper, and instead just gave it a go. This is what the light source looked like:

100W RGB COB LED mounted onto CPU cooler

Yep, just a COB LED module pasted onto a decommissioned CPU cooler. A heavy duty cooler, granted, but a crude and basically somewhat effective approach, at least when it comes to thermal management. One thing I figured out is that the COB LED modules had a common anode that could simply be cut, yielding access to separate anodes and cathodes for each array. Hence, it was possible to drive each array completely dependently from the others, which makes it possible to adjust the supply voltage to something close to the forward voltage of each array, and at the same time use low-side PWM switching for dimming purposes.

Bare RGB COB LED, Chinese type with low thermal mass. Note the common anode lug on the left side; this can be cut in two places to give access to separate anodes for each color so the arrays can be driven completely independently.

This reduced the complexity of the drive electronics; I think I used an LM317-based current source for this, like in the next generation. With the inevitable drawbacks; see later.

I fashioned this light source into something I could use, at least in a prototype/awkward fashion, by simply putting the COB LED module in the same spot as the original light bulb in the Durst 138 (using a mount fashioned from a piece of PVC tubing) and running some cables outside the chassis for the drive electronics. This allowed me to make some prints and do initial testing.

Lessons learned from this phase included three important ones:

1: A COB LED array does not act as a point source. It’s kind of evident, but without a diffusor, each LED array just images as a distinct color band when it shines through the condensors and the enlarging lens. Hence, a diffusor is needed somewhere between the LED source and the condensor stack (if used).

2: The kind of filter adjustments you need for RA4 printing are finer than what you can make with the 8-bit PWM resolution of a typical Arduino Nano / ATMega328P, which was the controller I happened to use for this version. So the 255 steps of 8-bit PWM were inadequate and better controller technology was needed.

3: A COB LED just doesn’t work for RA4 paper. I wrote a separate article all about this issue. It has also triggered some further discussion, thoughts and ramblings on a Photrio thread I started about it.

Condense the diffusion

I’d like to elaborate a bit on #1 and #2. Concerning the diffusor/condensor setup – I’m as much an optical engineer as I am a mechanical engineer. In other words: my working knowledge on the topic is limited to the basics I need to find my way round enlargers and view cameras. As a result, I have a vague awareness of diffusor (or diffuser, which is it?) and condensor enlargers, and I’m also aware that a hybrid type exists. So when I hit problems with uneven illumination and a COB LED, the logical solution at least for me was to shove a plate of frosted plexiglass somewhere in the light path. There happens to be an aperture in the 138’s head just behind the holder for the glass heat filter that I used for this.

Durst 138 head; the mirror is removed for this image and we’re looking through the aperture where the heat filter normally sits. The opaque white square is a piece of frosted plexiglass that acts as a diffusor.

This makeshift diffusor was perfectly effective as it allowed for nice and even coverage. But it did come at the cost of a significant loss of light. Given the fairly wide angle of LEDs (generally 120 degrees), illumination losses are high over the entire light path. We’ll come back to the issue of power and efficiency later, I’m sure.

Pulse-width modulation and its color printing caveats

Concerning the PWM resolution: it helps if you read the other post about why RGB COB LEDs aren’t a good choice for RA4 prints, because I also go into the sensitivity of RA4 paper and the resulting need for lots of red light. You’re basically mimicking a tungsten bulb shining through yellow and magenta filters – ultra warm light, really. If you take a COB LED that distributes its power roughly equally across Red, Green and Blue, this means you’re in practice running green and especially blue at very low duty cycles if you’re doing PWM dimming. After all, you want a lot of Red in the spectrum, a lot less green and only a tiny bit of blue if you’re pretending this to be a warm tungsten bulb filtered through yellow and magenta filters!

Now, think of the realities of color filtering for RA4 prints. With a dichroic head, you’ll have a starting point of something in the order of magnitude of 40 yellow and 50 magenta. From this, you may deviate perhaps 20 points at the most for negatives that are within reasonably normal ranges of development and lighting. Incidentally, you may even end up with more drastic deviations; for instance when printing cross-processed film, for artistic effects and/or lighting that’s way outside the range of the normal daylight-shade routines etc.

With a typical dichroic head, I understand from online lore (but never actually measured) that a change of 30cc across magenta, yellow and cyan (the latter we don’t really use for RA4 printing) equals about one stop change in overall luminous flux. I.e., adding 30cc to the M, Y and C channels will require a one stop increase in printing time (or opening the aperture by a stop) to obtain the same density in the print. This translates to 30cc of change in either magenta or yellow will equal roughly 1/3 of a stop. This probably simplifies matters a bit by ignoring the dominant color of the film (the orange mask!), but it’s a ballpark argument only at this point. Taken together, the normal filtering range that you’re likely to play with is perhaps a stop, at most, on both the yellow and magenta filters, and those are really drastic changes in color rendition. More common, and subtle, filter adjustments you’re likely to make between one test strip and another will be something like 6cc or 4cc – or even smaller if you’re doing critical corrections.

A small side note: if you ask experienced RA4 printers about what a noticeable change in color balance is, they’ll give varying answers ranging from about 0.5CC up to 4CC. I guess I fall somewhere in-between; I usually find about 2cc on a dichroic head a noticeable difference if I’m looking for it, and 1cc if I really try very hard, under excellent lighting conditions, comparing prints side by side.

From here on, I assume you have a basic knowledge of what pulse-width modulation (PWM) dimming entails and what terms like ‘duty cycle’ mean. If you are clueless, just Google a bit, it’s not all that complicated (unless you get to the nitty gritty details, but that’s for a different blog). I found e.g. this page that offers a decent and still concise explanation.

Where does this leave us? Well, if you translate the typical filter changes from a dichroic head to the changes in PWM dimming duty cycle for a LED light source where each R, G and B channel has more or less the same power to begin with, you arrive at the conclusion that typical filter adjustments are in fact pretty tiny differences in PWM duty cycle. Since we somehow have to ‘translate’ yellow and magenta dichroic filters to a LED situation, the best we can do is follow additive filtration logic and adjust intensity on the blue channel (by adjusting PWM duty cycle) when we would apply a yellow filter change for a dichroic head, and adjust the green PWM duty cycle in lieu of a magenta dichroic filter adjustment.

I’ll try to illustrate the rather wordy description of the problem a bit; my apologies, because it remains a little abstract:

An attempt to visualize the PWM dimming range actually used for RA4 printing, assuming more or less equal power distribution across the red, green and blue channels. See text for detailed explanation. Bar heights are not to any particular scale and only a schematic representation of the real-world relationships, which will vary with LED choice and other hardware decisions such as diffusor material.

In a typical RA4 printing situation, you need all the red you can get, so that channel tends to run at 100% power. Also, it isn’t adjusted between test strips; after all, we don’t adjust cyan either when printing RA4. (Yes, you could, but really, there’s no point to it in the vast majority of cases, so let’s ignore this anomaly.) All the color adjustment is done on the green and the blue channels, but keep in mind we run these a lot dimmer to begin with than the red channel, because of the mimicking of a tungsten bulb and the innate sensitivity of RA4 paper which is severely skewed across the color spectrum. So we’re running the green channel quite low, and we may vary that channel a bit depending on the color balance we want.

We’ll never dial the green channel all the way to zero, just like we will never dial a magenta filter all the way to its maximum, so there’s only a small part of the green bar in the chart above that represents the actual dimming range. For blue, the situation is similar, but even more pronounced: only a rather tiny portion of the blue bar is the actual variation we use to adjust color. I did not draw the chart above to scale, but if you did, you might find that the actual dimming ranges are even narrower than the depiction above.

On the vertical axis, I mention that on an 8-bit scale, the maximum light intensity (a 100% duty cycle) would be numeric 255 (hex 0xFF). Please keep in mind that the numbers that follow now are fictive, but they convey the gist of the problem. If you look at the usable filter range of the green channel, you may find it only ranges from something like 100 to 125 or so, and blue may be a numeric range that’s even smaller, let’s say 30 to 40. So the entire filter range that we actually use for real-world printing on a dichroic head, which comprises 30 cc or even more, is only 25 steps for the green channel and 10 steps for the blue channel. In other words, what used to be a 4CC yellow increment on a dichroic head, would be something like an decrement of 1 (we can’t do fractions, this is digital!) on the blue LEDs’ PWM duty cycle. The filter resolution we need to make fine adjustments is basically gone. In other words: too low bit resolution in PWM dimming leaves us with the possibility to do only crude color adjustments. You might not realize how bad this situation is, unless you remember one more thing we’ve discussed.

I mentioned that 30CC across all channels on a dichroic head equals around 1 stop. In other words: filtration adjustments on a dichroic head aren’t linear, but logarithmic. On the other hand, PWM dimming is always (to the best of my knowledge) a linear affair: a change of one point on an 8-bit scale is just as long, regardless if it’s from 1 to 2 or from 200 to 201. This implies that if we want to mimic color adjustment filters, we will have to map a logarithmic scale onto the linear PWM scale. So if you choose for instance that the green channel is set on average at a setting of ‘100’ (an arbitrary choice), then you’ll need to ensure that a change from a filter setting of 90 to 91 is actually a far smaller step than the step from 110 to 111, even though it looks like the same single-number increment. Look at how all this might just work out for the blue channel:

Example ‘filter setting’ vs. actual PWM duty cycle for Blue when printing RA4. Note that lower filter settings result in higher duty cycles, which is the opposite of how a Yellow filter on a dichroic head works. Let it sink in for a second; it’ll make sense. We’re working with additive color instead of subtractive filtering now.

I purposefully scaled the vertical axis from 0-100% because this is the full PWM dimming range – this is from 0 to 255 if we’re talking about 8 bit. See how it becomes very problematic to do any meaningful filter adjustments. A 255 point scale would mean we can work with 100%/255 = 0.39% increments in actual PWM duty cycle. As you can see, filter increments of 5 points at the higher end of the scale are only 0.1% increments (rounded to one decimal!) at the high end of the filter scale. Even somewhere at one third of the range, at around a filter setting of 30, it’s still around 0.3% for a 5 point filter change. This means that even with an ideal negative, we only have very limited filter resolution to play with to correct colors, and if you happen to have shot a tungsten scene on daylight film and you want to balance that, you’re basically out of luck.

With a COB RGB LED, I had no choice in the ratio between the actual ratings of the Red, Green and Blue LEDs. As an escape from the resolution problem, I could of course have biased them differently. By this, I mean that I could have chosen to run the blue and green ones at a much lower base current than the red ones, and thereby ‘preserve’ more of the 8-bit PWM resolution. For instance, let’s say the red channel would run at around 1000mA, I could have run green at maybe 400mA and blue at 200mA or so. By doing this, the chart above would change in the sense that the blue channel now never reaches the intensity of 100%, but instead our entire PWM dimming range is crammed into the lower 20% of the vertical scale. All of the 255 duty cycle increments of an 8-bit dimming scale would now fit neatly into the range we’re actually using. Well, not all, because the blue and the green channels never go down to 0, so we’re still left with maybe only half the duty cycle range as usable resolution. But this might have brought us closer to something usable, right? Let’s see how that works out, theoretically:

Same chart as above, but with the addition of a bias on the blue channel that runs it at maximum 20% of its previous intensity. Our PWM dimming range now aligns with the actual light intensity range we’re using, at least towards the top end.

I expanded the data we saw before to add the effect of a bias as described above. The chart to the far right shows the PWM values (vertical axis) for the same filter settings. Well, turns out it didn’t help that much; if you look at the higher filter settings, you’ll still see very poor PWM resolution for very big filter changes. So biasing doesn’t help sufficiently; we need an order of magnitude better resolution to accommodate the realities of color printing.

There’s one more reason why biasing the blue and green channels at a fraction of the power of the red channel wouldn’t have worked: it’s black and white. Remember I also wanted to do B&W with my light source, and it so happens that variable contrast papers work with green and blue light, and no red. If I were to bias or trim the green and blue LEDs at a substantially lower maximum current than the red channel, I would effectively truncate the power I would have for making B&W prints. Add to this the fact that color paper is generally a lot faster than B&W papers, especially warmtone papers, and you’ll see that I’d be throwing out power actually need for B&W to solve a problem in RA4.

Hence, my conclusion at this point was that I simply needed more PWM resolution to give me the wiggle room to accommodate the logarithmic nature of color filtering. And of course I had already included a diffusor into the optical path, and I had decided that a COB RGB LED wouldn’t work for RA4. So at the end of round 1 of experimentation, I was left with some valuable knowledge, and the overall conclusion that pretty much every aspect of my design, well, sucked badly.

6 thoughts on “The Big Ugly, part 2: the RGB COB LED approach to color enlarging”

  1. Hello,

    Interesting series of post, which I only discovered recently. Sorry if my question is stupid (but I’m sure the reason why, is interesting anyway. So, please, shame me if I deserve it 😉
    I see you’re struggling with PWM resolution and that you had to use a 12 bits PWM chip. So, here’s my question: Why not simply light for different durations in the three colors. You mention the paper has a ~25ISO sensibility in the blue. I suppose the total expose is long enough that you can simply light in RGB for say 100ms, then only light in RG for another 200ms and finally light in R for say 800ms. These duration can be adjusted much more precisely when you don’t need to switch your light on and off at +100Hz like a PWM does. Even if the total exposure duration is sub-second, the timer resolution of an arduino would easily do the job and provide more than the equivalent of 8 bits of relative duration.
    I hope that make sense.
    I’m not a paper chemistry expert, but I could understand that exposing like this poses a problem of color filter opacity that will require a specific order and/or make this totally impractical.

    1. Hi Yann, thanks for your comment, and your question is not stupid at all. In fact, it makes perfect sense! The only reason I didn’t use your method is that it makes burning & dodging difficult. It’s something I don’t do that much with color printing anyway, so in practice it’s not much of a drawback, but this was one of the main reasons behind it. As you said, sub-second timings are relatively easy to do with a microcontroller. And it will certainly work just fine with the paper; there are some intricacies, but these don’t play a significant role in practice.

  2. Hi Koreks – just stumbled across your blog and journey into the color LED printer. This article is fascinating. For those of us who may instead purchase equipment, rather than build it, did you ever reconsider the strengths or weaknesses of the Heiland LED lights? The system is mainly around splitgrade B&W but they sell a RGB controller. You observe interesting considerations about nailing the wavelength very specifically. I wonder if we know that’s the case with the Heiland LED selections.

    https://heilandelectronic.de/color_timer/lang:en

    1. Hi Michael, thanks for reaching out! I have considered the Heiland system, yes, but to be frank, I’ve never actually worked with one and I’ve never been in a position to analyze the hardware. All I have is some photos online and the experiences of others, and frankly, that doesn’t say much. All I can gather from it is that there seem to be several versions of ‘the’ Heiland light source with what seems to be quite different LEDs being used across these versions. How well they perform, I really could not say. I did converse with someone who used a Heiland system and a dichroic head side by side and he did notice distinct differences in color rendition between them. But that in itself doesn’t say much and it’s really to be expected, since a dichroic filter system and an additive LED system are so fundamentally different in many ways that it’s only logical that there will be differences in the prints.

      1. That makes sense! Thanks for the response. And thanks for this amazing blog we all get to learn from.

Leave a Reply

Your email address will not be published. Required fields are marked *