Printalyzer - Darkroom enlarging timer & exposure meter

[koraks]

So it really comes down to a simple question of where to draw the dotted line on the block diagram

My suggestion would be to sick with #1. Those who prefer #2 and #3 will figure it out even with minimal/no help from you and just the basic documentation you already provide for your project. Option #1 would pave the way for less advanced users to also get into this technology, and they seem to outnumber the people who would opt for #2 and #3 anyway.

One more thing: https://www.photrio.com/forum/threads/diy-31-megapixel-enlarger.197305
As per this development, it would be useful if the exposure controller could interface with a computer of some sort for exposure sequencing. Basically, it would be very nice if the host computer that displays the digital image on the transmissive LCD could also signal the light source to do its job. This job would depend on the image; for instance, for color, you would have sequential red, blue and green exposures. And for B&W, there's the trick of expanding the dynamic range beyond the 8 bit greyscale depth of the LCD through sequential exposures as well.

I know this complicates the project considerably, but it seems relevant. I think we're going to see these digital LCD's being used a lot more for hybrid enlarging in the future and it would be very neat if there were interoperability with the light source.

 

[albada]

@koraks : I must admit that #1 is easier for most people.

@dkonigs : Here's a discovery that might affect you. A few postings ago, you included Heiland's grade-to-GB table. I just compared my cal-table with his, and although my ER values are close to his, my blue is consistently 1.5 stops weaker than his. Note that my blue has half the power of green. So at full power, it appears that Heiland's blue has 2.5 stops less power than green. Thus, I suspect that he designed his circuitry so that equal power-settings of G and B will mimic tungsten. In general, every DIY LED-head will have a different GB ratio at equal settings. Idea: Let the user enter that GB ratio into your controller. Using the log of that ratio as an offset for B, I think you could use one generic grade-table that would work okay with most papers (from Ilford anyway) and with all DIY LED-heads.

Mark

 

[dkonigs]

@koraks : I must admit that #1 is easier for most people.

Yeah, the trick is finding the right combinations of off-the-shelf parts that can do the job.

And when we're talking about PWM generation, being absolutely precise with the frequency is kinda irrelevant. All that matters is that the clock does not have significant jitter over a relatively short period, because what you really care about is just the ratio between "high" and "low" remaining constant during an exposure. The duration of the exposure itself is externally driven, and being off on responding to that by a few milliseconds is likely no big deal.

@dkonigs : Here's a discovery that might affect you. A few postings ago, you included Heiland's grade-to-GB table. I just compared my cal-table with his, and although my ER values are close to his, my blue is consistently 1.5 stops weaker than his. Note that my blue has half the power of green. So at full power, it appears that Heiland's blue has 2.5 stops less power than green. Thus, I suspect that he designed his circuitry so that equal power-settings of G and B will mimic tungsten. In general, every DIY LED-head will have a different GB ratio at equal settings. Idea: Let the user enter that GB ratio into your controller. Using the log of that ratio as an offset for B, I think you could use one generic grade-table that would work okay with most papers (from Ilford anyway) and with all DIY LED-heads.

The goal with all this is to come up with a set of "sensible defaults" while making things configurable enough to handle all these cases. I could do something like you suggest, or I could simply have a set of max brightness percentages for each channel, or something else.

So along these lines, all of my Heiland controllers have a sticker on the circuit board that reads: "R:80% G:56% B:80%". However, the actual PWM duty cycle it sends out to the LED drivers does not take these numbers into account.
With a max brightness setting on the controller ("-00"), at grade 00 it sends 75% to green and nothing to blue, whereas at grade 5 it sends nothing to green and 75% to blue. (And at every other grade, just multiply 0.75 by the ratios in that table, and that's the duty cycle you see.)

So that label might be simply a rough measurement of how their LEDs actually behave when given the same power, and then they tuned the table from there. But really, without individual LED measurements and/or datasheets, that's just guessing. They also have a series of tiny trim pots on the front of the unit, that you can use to make your own adjustments. I haven't touched them, so I'm just observing out-of-the-box behavior.

 

[albada]

In your UI, you will probably allow the user to set the brightness of R, G, and B. I found that the following are good units to use for this:

brightness = 10.0 + log2(dutyCycle), where dutyCycle is in min..1.0 (min=1/128 for me).​

Let's call these units, "stops below 10". Note that log2 is usually negative.
This is intuitive for users. 10 is max brightness, 9 is half, 8 is quarter, etc. I display them with one decimal point (eg, 8.2).
It's not confusing because higher numbers cause more exposure, which is how time behaves.
It's easy to adjust all channels by the same number of stops.
It's easy to interchange brightness and time.

I started with units of -log2(dutyCycle), but that often confused me because higher numbers caused less exposure, unlike time.
Units of duty-cycle makes it hard to shift GB or RGB by same number of stops, or to interchange with time.
So I found stops-below-10 to work best.

One idea I did not try: Display as duty-cyle (%), but have buttons/knob change them in steps of 1/10 or 1/12 or whatever fraction of a stop you use. Shifting multiple channels or interchanging with time would be possible, but riskier because it's not obvious from the display how many stops a brightness was changed.

Mark

 

[dkonigs]

So, as I'm planning for the next revision of the hardware, I finally decided to go ahead and do some basic temperature testing of the meter probe. It look a bit of work to rig this all up, because the easiest way to do the test involved running the meter probe from a computer (instead of my timer unit) and because I needed to illuminate the sensor via a fiber optic cable coming from a light source outside of the test rig.

In any case, I finally got all the pieces together this evening and collected some data.
I used a similar thermal ramp method as I used to test the densitometer's thermal performance, which involves a freezer and a heated 3D printer filament drying chamber. Its great for ramp testing, but I'd obviously want something fancier if I was trying to build an actual thermal profile. So the data is a bit noisy, given that the hardware doesn't heat evenly and never really reaches a steady state, but its still good for answering some basic questions.

Those questions being:

1. Does temperature affect the sensor's performance?
2. Does temperature affect the sensor's performance enough to actually matter?
3. Is it worth adding a temperature sensor, renting a proper thermal chamber, and building an actual thermal calibration profile?

For these tests, I had the sensor at a fairly high gain setting and the light source at its dimmest. All data is normalized around 25C. (The sensor gave readings that would have been in the ballpark of 0.15 lux if it had picked up the light under my enlarger in a normal meter probe configuration.)

Going all the way from 0-45C, this is what the graph looks like:

The graph is showing differences in reading in stops (log2), and the total range is about 1/4 stop. The jaggyness of the line is most likely due to the inconsistencies in the test method, and not sensor behavior. I'd expect a much smoother line with higher quality steady-state testing.

Someone here mentioned an expected usage temperature range of 17-30C, so I plotted that too:

In this case, we're only talking about a range under 1/10th of a stop.

While it might be a good idea, for the sake of completeness, to test a range of light levels and sensor settings, I think this particular test is likely to end up being close to the worst case scenario.

So I guess now the question becomes... Is it work going through all the trouble to build in temperature compensation to improve accuracy by an amount likely below the typical adjustment increment, for people who build their paper profiles during a summer heat wave and then print in the dead of winter, using a darkroom that's located in an uninsulated shack in their backyard?

Unless I'm missing something, which maybe I am, and you'll all be happy to fill me in.