Printalyzer - Darkroom enlarging timer & exposure meter

[albada]

I've been thinking about features to put in an LED-controller, assuming it is controlled by a timer having a simple on/off interface.
- LED power-levels.
- Quick save/recall (using dedicated buttons) of multiple power-levels. Used for remembering grades and the levels for focusing/metering.
- "Pre-red" wherein the red LED turns on for 5 seconds before exposure begins, giving the user time to position dodge/burn tools. The user must add 5 seconds to the timer's time.

These are most or all of the features LEDs can provide, without cluttering the timer-analyzer.

 

[dkonigs]

Since the conversation has gotten very much side-tracked by this, I should probably mention that "making an LED enlarger controller" isn't actually a current goal of my project, especially since I do not even have an LED enlarger head. While I am open to tackling this in the future, right now my goals (in somewhat of a priority order) are:

1. Be a functional f-stop timer that attempts feature parity with the RH StopClock
2. Be a functional enlarger meter that attempts feature parity with the RH Analyser Pro
3. Experiment to see what I can do with sensing color, and whether I can tackle the color analyzer problem (with my current sensor or a different one)

Eventually building in additional options for the "enlarger connection" part is certainly something I'm open to doing, but I really want the base project to be solid and stable first.

Now when I say "feature parity", there are absolutely areas where I want my implementation to do better. My hardware base is a lot more modern, so I'm a lot less constrained in my potential. That means more processing capabilities, more memory, more buttons/controls, a more flexible display, and even a USB port.

 

[MattKing]

It may not be as pretty, but ...
It would help if the colours of the buttons alternated or differed in some way, to make them easier to differentiate under safelight.

 

[dkonigs]

It may not be as pretty, but ...
It would help if the colours of the buttons alternated or differed in some way, to make them easier to differentiate under safelight.

Its not really practical to do that, for two reasons: First, the physical buttons are hard enough to see as it is (and aren't available in many colors). Second, I can't really change the illumination color (the LEDs around the buttons) without risking "paper safety."

However, I do have a few other things to try and help with this exact problem:

• The buttons have a nice tactile feel, and its easy to run your fingers over them without accidentally pushing them. (And pushing them doesn't really bump the device/table either.)
  
• I picked a distinctive layout which puts the buttons in three uniquely-shaped groupings, so its easy to find them by feel
• All the buttons have "illumination" LEDs adjacent to them, marking their location. I can turn these on/off individually, but haven't yet found a good case for doing that.
• A few of the buttons (the quad on the right, used for mode changes and special functions) also have indicator LEDs embedded in the corner of the button surface. I'm not exactly sure how I should best use these yet, but I'm thinking perhaps to indicate that the device is in a particular mode (e.g. test strips, adding adjustments, etc).

 

[albada]

Out of curiosity, which sensor-chip are you using in the probe?
You mentioned the possibility of using it for the color-analyzer function, so it must be an RGB sensor (or CMY if such a thing exists).
What trade-offs do you face in the selection of this sensor-chip?
Mark Overton

 

[dkonigs]

Out of curiosity, which sensor-chip are you using in the probe?
You mentioned the possibility of using it for the color-analyzer function, so it must be an RGB sensor (or CMY if such a thing exists).
What trade-offs do you face in the selection of this sensor-chip?
Mark Overton

Right now I'm using an AMS TCS3472, which is an RGB sensor. I've tested several sensors in its class, and it seems to have the best sensitivity. The advantages of using a color sensor are that I can more easily get an accurate lux measurement, and I can determine the color temperature of the enlarger lamp. I may also be able to do color analyzer functions, but its going to take a lot more testing to be certain that it has sensitivity in the right parts of the spectrum to accurately detect the changes from my enlarger's dichroic filters. The disadvantage of using an RGB sensor is that it might be a bit less sensitive than a pure light-intensity sensor.

Another sensor I'm tempted to experiment with is the AMS AS73211, which is a much more sophisticated (and expensive) XYZ color space sensor. Its likely even more sensitive than what I'm using now, and will also probably work a lot better for color applications. I just need to do a lot of reading up on how to do the necessary color space transformations to get the data I want out of it.

All of these are modern light sensors, which means the analog-to-digital conversion and integration of readings is all done on-device. This means that I don't have to worry about noise on the cable causing problems, or doing any of my own 50/60Hz "flicker rejection." I just sent the gain and integration time parameters, and read out a bunch of numbers for the various channels.

Whatever I do, I really want to be able to transform the output of the sensor into standardized units (e.g. lux) and then do all of my exposure calculations in those units. This makes my data more "portable", and completely separates sensor choice and calibration from paper/enlarger/filter calibration.

 

[albada]

The disadvantage of using an RGB sensor is that it might be a bit less sensitive than a pure light-intensity sensor.

I just looked over the datasheet for the AMS TCS3472. Impressive! But I saw no spec for its sensitivity, except for the claim, "Very high sensitivity - ideally suited for operation behind dark glass". Anyway, it claims to be ESD-tolerant up to 2 kv, which helps your application.

I mentioned in the meter thread that the DA meter lacks sensitivity, meaning that under lighting for normal exposure, it can't meter dense highlights. But I work around that by switching to "metering lighting", which is running all LEDs at half-power. On a condenser enlarger, you would get metering lighting by removing the contrast filter. This work-around works for B&W, but for color? Maybe open up a couple stops to make the meter happy?

 

[dkonigs]

I just looked over the datasheet for the AMS TCS3472. Impressive! But I saw no spec for its sensitivity, except for the claim, "Very high sensitivity - ideally suited for operation behind dark glass". Anyway, it claims to be ESD-tolerant up to 2 kv, which helps your application.

I mentioned in the meter thread that the DA meter lacks sensitivity, meaning that under lighting for normal exposure, it can't meter dense highlights. But I work around that by switching to "metering lighting", which is running all LEDs at half-power. On a condenser enlarger, you would get metering lighting by removing the contrast filter. This work-around works for B&W, but for color? Maybe open up a couple stops to make the meter happy?

Even the RH Analyser instructions want you to measure without the contrast filter, so the meter does capture more light than you'd normally use for printing. When I was doing a lot of tests to characterize its behavior, and get a general feel of light readings, I noticed that your typical under-the-lens Ilford Multigrade filters reduce the light by about two stops. They also alter the spectrum, of course, so it makes sense to meter w/o filters and then process that data differently depending on which filter you plan to use for the print.

Its entirely possible that I may need to meter at a different aperture than I print at, for color. Given how sensitive color paper is, this is actually quite likely. Once I get further along in the development of my device, I'll need to do a lot more darkroom tests to figure this all out.
(My early tests involved a bunch of parts plugged into a breadboard, where I could get a rough feel for the sensor, but I really can't do as much useful testing as I can on a device with a full control panel of buttons.)

 

[ic-racer]

It has been almost 12 years since my last project in this area, but what I was trying to do was to get the meter to analyze the color of the filtration and correlate that via a look up table with the B&W multigrade paper's contrast range.

Therefore, for any probed location on the projected image, the analyzer would be able to estimate the resulting dry print density by taking into account the coloration (which it converts to contrast values), the baseboard light intensity, the exposure time and the paper's response curves. One thing I discovered was the math on the density numbers required to give the final result compounded the various small errors in the system. So the results were not all that good. Maybe there is some similar reason why commercially available devices don't use that system (ie. meter through the contrast filters).

 

[albada]

It has been almost 12 years since my last project in this area, but what I was trying to do was to get the meter to analyze the color of the filtration and correlate that via a look up table with the B&W multigrade paper's contrast range.
Therefore, for any probed location on the projected image, the analyzer would be able to estimate the resulting dry print density by taking into account the coloration (which it converts to contrast values), the baseboard light intensity, the exposure time and the paper's response curves. One thing I discovered was the math on the density numbers required to give the final result compounded the various small errors in the system. So the results were not all that good. Maybe there is some similar reason why commercially available devices don't use that system (ie. meter through the contrast filters).

Perhaps modern RGB sensors are good enough to do this now.
I've developed a simple method using the Darkroom Automation meter (mono, EV-only) that lets me make a probed location print at near-black, mid-gray, or skin-tone, at any grade. The method works fine, except that T-grain negatives from Kodak and especially Ilford have a slight blue cast in them which reduces green a little. And to reach the desired EV, blue is boosted slightly. The reduced green causes skin-tones to print too light, even though the Stouffer tablet step at the desired density prints correctly. An RGB meter that knows the paper's curves would automatically compensate for a such color cast in the negative. If that's too much for the meter, then it could at least tell the user what grade he'll get based on the green-blue ratio.
Mark Overton

 

[dkonigs]

Hey, so its probably time for a project update. I really should put some of this in a new blog post, but I'll give a brief recap here to just get my thoughts out for now.

My first attempt at getting actual "translucent graphic overlay" stickers for my metering probe appears to have been a success! I know it looks quite plain and simple, but this was really just a test to make sure I could order something with the right dimensions and specifications from JRPanel and to see how their materials performed optically. I've tested both their glossy and matte materials, with matte (shown below) being the preferred choice if it would work. Both are sufficiently achromatic, and matte only has a density of D=0.08 (glossy was D=0.06). So I'm going to go with this for now.

The next thing I did was to finish implementing burn/dodge adjustments (I'll probably detail that more another time, and finally also implement the ability to get actual screenshots off the device. This means whatever I share of its display going forward can look a lot better than me simply taking a photograph of it with my phone. Here are some examples:

Now on to the more important topic... paper profiling for print metering. Since I've completed the "required features of an f-stop timer" (aside from some polish), I'm now thinking very seriously about my next big step. The first thing I need to do is come up with a system for managing printing paper profiles. I've already done a lot of research and brainstorming, and figured I might as well share my ideas. I should also mention that I have a copy of ISO 6846:1992, which has helped enormously with coming up with the best way of quantifying the problem.

For starters, everything really focuses around this graph of the sensitometric curve for printing paper:

The goal of a paper profile is to be able to reproduce the graph from the "T" point up to the "S" point. To put these points in a more familiar context, the paper's "ISO(R)" (contrast range) is based on the difference between "T" and "S" and the paper's "ISO(P)" (speed/sensitivity) is based on the "Speed point". (Both the ISO(R) and ISO(P) are commonly published in a paper's datasheet.)

Whether this can be done with sufficient accuracy with two points or three points seems to vary. I was looking at some curves I measured from testing Ilford MGV RC, and this seemed to vary by contrast grade. At some grades this line was straight (matching the "average gradient" shown above) and at other grades it did bend a little bit. Whether or not this bend matters enough for my purposes remains to be seen, but I do want to be able to handle profiles with two or three points just to be safe.

From looking at the existing products, there appear to be two approaches to how others handle this:

• RH Designs - Enter the "T" point as an offset (in 1/12th stop units) to a baked in profile (that we're not sharing), alongside the ISO(R) value.
• Heiland Splitgrade - Pick a completely baked-in profile we gave you (and aren't sharing the numbers from), and maybe nudge it with a simple offset to make it more correct for your setup.

I personally really do not like any sort of profile that depends on baked-in magic numbers, because those numbers are now unchangeable and its harder to convert this profile between systems. Therefore, my system is going to do profiles in terms of absolute exposure numbers that are easy to process and convert between different representations.

The base unit for my profiles is something I'm going to most likely refer to as a "Paper Exposure Value" or simply PEV (I want to avoid confusing it with the "EV" we're all more familiar with. Its similar in what it represents, but the units/scale are different.) This value is defined as:

PEV = (log10 H) * 100
where H is the exposure in lux-seconds​

This works well because light sensor measurements are directly convertable to lux, and can be calibrated against calibrated lux meters. Furthermore, this is actually the unit a paper's ISO(R) is specified in terms of. It also gives nice round numbers that are easy to copy/enter. (I did attempt to quantify the RH "default" profile against my calibrated lux meter, and it gave numbers in the range of 14-95 for the lower "T" point in this unit.)

So my plan is to store actual paper profiles in terms of 3 entered values, which are all going to be represented in these units:

• "T" - exposure to achieve D=0.04 above Dmin
• "M" - exposure to achieve D=0.60 above Dmin
• "S" - exposure to achieve 90% of Dmax, based on the difference between Dmin and Dmax

Of course actually getting these numbers, in the right units, isn't something I can really expect a user to just "figure out". Nor do I really want them to have to whip out a calculator and do a bunch of logarithms. Therefore, I have some ideas for "easy" ways to actually enter them.

First, I'm going to make my device capable of actually displaying the "PEV" value for a meter reading (and subsequent test strip patches) so someone can write this down when doing calibration tests. (since the goal of calibration is to essentially find the "T", or D=0.04 point, and everything else is based on that).

Then, I can provide a couple different ways of actually building a profile based on this information:

• Enter the PEV for the "base exposure" (T point), alongside the paper's ISO(R) (from the datasheet or your own tests), and it calculates the rest
• Enter an RH-style offset which I convert to a PEV value, alongside the paper's ISO(R). (Not sure if I'll include this on the device, or just document it in the manual.)
• Enter the PEV for a "reference exposure", alongside a bunch of densitometer measurements from exposing a Stouffer-style step wedge, and let it internally do all the math to figure out the "T", "M", and "S" points.

To make the step-wedge/densitometer approach easier, I'm even considering making it possible to plug a densitometer directly into my device's USB port so you don't need to type the numbers in manually. (Heiland TRD-2 has a USB option, and the X-Rite 810 has a serial port for which you can get a USB-to-serial adapter.)

I may even find something user-facing to do with the ISO(P), such as using it to help recommend a starting point for doing exposure tests. It does appear to be approximately 30% of the way between "T" and "S", but that actual relationship is not specified or reported anywhere so I can only treat it as a suggestion.

I'll also likely come up with a way of adjusting an existing profile in more familiar units, to make fine tuning easier. (And this part is not that hard to even do manually. On the PEV scale, "1-stop" is approximately 30 units and a "half-stop" is approximately 15.)

I really hope this rambling made sense to someone I also hope I can explain it a bit better once its time to write a manual discussing how one builds a paper profile.

 

[albada]

I like your thoroughness. A few thoughts that will interest you:

I think "T" stands for "textural", meaning the lightest tone that can show texture. This is the lightest useful tone.

Your PEV scale (30 units/stop) is the same as the CMY filtration numbers used on enlarger color-heads produced by Durst and Kaiser. Kodak used 45 units/stop for their filters, and Agfa used 60.

I have noticed that some negatives have a slight blue cast, which reduces green. The magenta cast often seen in T-max also reduces green. Such a negative will steepen the paper's HD curve wrt what you have stored in the profile. Therefore, I suggest that your probe use an RGB photodiode or phototransistor so you can detect and compensate for such a color cast. As small as this color cast is, it has given me trouble when trying to match a tone based on metering.

Your Printalyzer needs a densitometer. With an integrated densitometer, you would have a very compelling product.
I think you can make a tiny inexpensive hand-held densitometer having a 3-conductor wire that will plug into the Printalyzer. You need two LEDs illuminating the paper at 45 degrees, with the sensor between them. The densitometer probe would be a plastic triangle about 30mm in both directions, and about 6mm thick. Drill three holes through it the long way, with all three holes converging and exiting at a corner. When that corner is placed on paper, with the middle hole vertical, the LEDs in the two angled holes would illuminate the paper, and the sensor in the vertical (middle) hole would see the paper's density without seeing a reflection. I can sketch this idea to clarify this description. The wires would be: Common, LEDs, phototransistor/diode. You would not need to calibrate this densitometer because you can have the user measure paper-white (Dmin) and Dmax on the test-strip, which is all you need.

Edit: You could integrate this densitometer into the tip of your present probe. But that tip would be crowded with nearby photodiodes and LEDs, so you would probably need to glue-in both photodiodes and LEDs by hand, and hand-solder them to the circuit board.
Mark Overton

 

[ic-racer]

A light source that can clamp on top of your sensor could turn it into a transmission densitometer.
This is a little crazy but I have used a transmission densitometer to test the transmission of a step wedge exposure on printing paper. If that would work (that is the transmission values of the paper similar to the reflection values curve shape), you customer could make their own paper curves with your device.

You can include a calibrated step wedge with your device. Supply an inexpensive non-calibrated step wedge and calibrate it yourself to your densitometer for the customer.

Another option is to have an "Expert" menu to tweak all the numbers, but a "Standard" interface with the very straight forward baked in profiles. I'll bet in beta-testing with average darkroom workers that will satisfy most conditions.
In other words, those that want to use the "Expert" menu would be expected to have their own reflection and transmission densitometers and a sensitometer already.

 

[dkonigs]

Your Printalyzer needs a densitometer. With an integrated densitometer, you would have a very compelling product.

Again, I really don't want to get side-tracked in that direction right now. Its not a bad idea for a future iteration, but for the time being I'm going to take advantage of densitometers that already exist. However, experimenting with a small reflection densitometer "puck" isn't a bad idea in and of itself.

The idea of actually making a reflection and transmission densitometer does keep occurring to me. A big motivator is the fact that "modern" color-capable densitometers simply don't seem to meaningfully exist. Thus, its kinda tempting to build something similar to the Heiland TRD-2 albeit with a color sensor. Of course even if I did build such a thing, calibration materials wouldn't be all that easy to come by. I'd basically need to make sure I had up-to-date and reliable calibration on an X-Rite 810, and use that to generate numbers for a Stouffer wedge of some sort. (The Heiland device seems to rely more on baked-in calibration, but it also is better for taking relative measurements. Meanwhile, the X-Rite does better with absolute measurements.)

Therefore, I suggest that your probe use an RGB photodiode or phototransistor so you can detect and compensate for such a color cast.

As I've mentioned in previous posts, I am planning to use a color sensor for this. All my research has told me that color sensors actually work better for measuring "lux" because of how it maps to the color spectrum. (Lux measurements are actually biased in favor of green, which is why the RH and Heiland meter probes have a green filter over their sensors.)

You need two LEDs illuminating the paper at 45 degrees, with the sensor between them. The densitometer probe would be a plastic triangle about 30mm in both directions, and about 6mm thick. Drill three holes through it the long way, with all three holes converging and exiting at a corner.

I took a close look at how the TRD-2 is designed. Its similar, but not identical, to this description. It basically has a plastic "triangle" shell with a vertical black tube that likely leads up to a sensor. It then has a single LED installed at a 45 degree angle to this. It also has a bottom illumination source behind an aperture, but that's only needed for transmission measurements. If I were to make an "accessory puck" for my device, I could skip that part and simply rely on a pre-calibrated step wedge (even an uncalibrated one might be close enough).

But again, maybe a side-project to experiment with using the same components I'm already becoming familiar with, but not what I really want to focus on until I'm basically "done" with the existing design and functionality.

 

[albada]

A light source that can clamp on top of your sensor could turn it into a transmission densitometer.
This is a little crazy but I have used a transmission densitometer to test the transmission of a step wedge exposure on printing paper. If that would work (that is the transmission values of the paper similar to the reflection values curve shape), you customer could make their own paper curves with your device.

I've done that as well. I used the enlarger as the light source, and measured the transmission of paper using my meter from Darkroom Automation. I've only used this method to match tones or interpolate between tones. I think the curves will be different from reflection-measurements, and I've also seen horizontal diffusion through the paper distort my measurements. If the steps in the strip are large enough that diffusion doesn't hurt, and if the user is required to measure Dmin and Dmax this way, then this approach might work in the Printalyzer.

 

[dkonigs]

A light source that can clamp on top of your sensor could turn it into a transmission densitometer.

Not a bad idea, but I wonder if this would get good enough data (versus the step wedge's specs) to be worthwhile. Especially since controlling stray light would be a concern, so I'd need to make a special fitting.

You can include a calibrated step wedge with your device. Supply an inexpensive non-calibrated step wedge and calibrate it yourself to your densitometer for the customer.

This is absolutely do-able, and may be sufficient to get the job done. (Its also unclear as to whether the difference between "spec values" and "calibrated values" for one of those Stouffer wedges is enough to make a difference in this application.)

Another option is to have an "Expert" menu to tweak all the numbers, but a "Standard" interface with the very straight forward baked in profiles. I'll bet in beta-testing with average darkroom workers that will satisfy most conditions.
In other words, those that want to use the "Expert" menu would be expected to have their own reflection and transmission densitometers and a sensitometer already.

The main purpose of these "PEV numbers" is simply to have something that's easy to type in and write down for reference. There are enough variables that I'm not sure I want to provide existing baked-in profiles (that would be a lot of work too, where my conditions may not match other peoples' conditions). However, there is an "easy" way to calibrate with this system:

• Put the device in "calibration mode"
• Take a meter reading
• Make a test strip, and write down the PEV numbers associated with each strip patch (it'll display those)
• Find the patch that most closely matches the tone on the D=0.04 "reference strip" (RH includes something like this)
• Enter that number, and the ISO(R) from the paper's datasheet

 

[dkonigs]

Anyways, I've been crunching more numbers (based on data I collected when doing past paper calibrations for my RH Analyser and when trying to characterize its "base" profile), and have come to an interesting discovery. Maybe this is something obvious to everyone, but I have not seen it explicitly written anywhere. Essentially, when Ilford (et al) say a paper has an ISO(P) of 500 unfiltered or 250 when filtered, I don't think they're claiming that the paper is less sensitive to filtered light than to unfiltered light. Rather, they're saying that the filter itself cuts the light in half. In other words, I think they're measuring the "speed point" light without the filter, then exposing the paper with the filter. Either that, or something else about the filtered measurement process is unsaid. Regardless, my takeaway from this is simply that I shouldn't ever show the user the "speed point" converted to an equivalent ISO(P) value, because it'll just be confusing.

So, while I still plan to represent a profile internally in terms of HT, HM, and HS, I think I'll just display them one (slightly different) way to the user:

• Base exposure (Dmin + 0.04)
• Speed point (Dmin + 0.60)
• ISO(R)

All three values will be in the "PEV" units I described previously, with the speed point being optional. The main change is simply showing the user ISO(R) directly, rather than having it be on a screen with a "simplified representation". This way I can have one screen for setting the calibration numbers, and only need additional menu options for "fancy" features (such as calculating them from step wedge measurements).

You can get the "Base exposure" from a simple comparison test (as described in my last post), and you can get the "ISO(R)" straight from the paper manufacturer's datasheet. (HS is just "HT + ISO(R)" )

And speaking of ISO(R), here's something interesting I did find when I tested Ilford MG V RC for my RH Analyser... The ISO(R) numbers I got from measuring step wedge exposures (as described in the RH calibration manual) were actually very close to what Ilford published. So while doing your own tests to get this number will certainly give a more "refined" profile, simply using the datasheet value* will be fairly close to the mark.

(* Assuming, of course, you're using a diffusion enlarger with a tungsten light source, which is what those numbers are based on.)

 

[albada]

Here's an idea to future-proof the Printalyzer by making it easy to add the densitometer function to it:

1. Mechanically, design the probe so that a triangular densitometer adapter could be attached to the top of it.
2. Electronically, make it easy to accommodate the LED(s) in the adapter, perhaps by having a 3.3v or 5v plug on the probe. This adapter would contain LED(s) but no sensor because it would use the probe's photodiode.​

With this approach, you can work on the adapter later (if at all). But at least you won't regret being locked out of this option later.

 

[dkonigs]

Here's an idea to future-proof the Printalyzer by making it easy to add the densitometer function to it:

Technically speaking, there's absolutely no reason why I couldn't just make a densitometer probe that plugged into the exact same port I'm currently using for the meter probe. I designed that interface to be flexible and somewhat future-proof.

The parts you'd avoid duplicating with an "add-on accessory" really aren't as expensive as you think they are, and it would make the meter probe a fair bit more mechanically complex (and more annoying to use as a densitometer than a dedicated densitometer widget).

 

[dkonigs]

Anyways... Since I'm doing all the work on this project "in public," I decided it was finally time to start more officially typing up my to-do list and put it on Github alongside all the other project schematics/code/data:
https://github.com/dkonigsberg/printalyzer/issues

This includes things part of my current plans, as well as "wishlist" items suggested in places like this forum. Both hardware and software items are tracked, hopefully labeled well enough.

 

[albada]

I looked over your list of issues on github, and am pleased to see a high level of detail, worrying about even what kind of bypass cap to use in the probe.

BTW, I keep posting suggestions to this thread because I value what you are doing.

 

[dkonigs]

I looked over your list of issues on github, and am pleased to see a high level of detail, worrying about even what kind of bypass cap to use in the probe.

I like to get paranoid with the little things, especially when changing the design is actually not much harder than simply making more of the old design. (At this stage, its not like I have a surplus of unpopulated boards, so changing the design when I make more isn't a big deal.)

A lot of these items came from my list of notes that I took while assembling the hardware, so I simply wanted to capture them in a spot (other than my notebook) where I wouldn't forget.

Suggestions are always welcome. Even if I don't really want to act on them anytime soon, they're still usually worth writing down as future ideas.

 

[dkonigs]

So, this week I feel like I've been perpetually on the verge of actually implementing the print metering part of the project. (First I built the first round of actually inputting and storing paper profiles, then I added some helper modes to the device's home screen for assisting with making those profiles.)

In any case, as I continue to characterize how my RH Analyser behaves (versus measurements I've taken with other instruments), I think 3 possible approaches towards print metering have emerged. Fundamentally, all 3 approaches involve taking a series of readings, finding the "center" (mean, median, geometric mean, something like that), finding the ideal exposure for that center point, and plotting all the readings on a user-visible tone scale. Where these approaches differ, is in how I quantify that scale and what exposure I use for that center point.

These 3 approaches are based on what profile data I have to work from, and they are:

• Base exposure + ISO(R)
  • Center on the midpoint of the contrast range
  • Place tones on an exposure (PEV) based scale
  • Maybe have some extra headroom on the dense end
  • (I think this is how the RH Analyser is behaving, and it is the simplest approach)
• Base exposure + Speed point + ISO(R)
  • Center on the speed point
  • Otherwise the same as the previous approach, and may give similar (but not identical) results
• Base exposure + Speed point + ISO(R) + Dmax
  • Center on the speed point
  • Place tones on a density scale (from D=0.04 to 90% of net density)
  • Starting exposure may look similar to the previous approach, but the tone graph could look different

I would not be the least bit surprised if all 3 approaches yield very similar results, but that will vary depending on where the "speed point" is located on a particular paper curve, and how linear the important part of that curve happens to be.

Of course once a "center exposure" is chosen, the process of adjusting it will likely always be done in time-stops to keep things simple and consistent.

 

[polka]

I simply use my Gossen lightmeter with a 45° little mirror, that I calibrated experimentally for the job.
POLKa

 

[albada]

These 3 approaches are based on what profile data I have to work from, and they are:

It appears to me that you are determining the initial exposure (time) based on measurements of one or more points on the image. Here's an idea: Have the user specify both grade and exposure-time. Then, knowing the paper profile for that grade, you can simply plot the resulting tones on the horizontal scale and let the user slide them left or right using the encoder knob, changing exposure-time until the tones are what he wants. Or did I misunderstand something?

likely always be done in time-stops to keep things simple and consistent

Would you offer the user the option of entering exposure-time in seconds? I am building an LED controller based on an Arduino, and I put a simple timer function in it. Time is set (using the encoder knob) in tenths of stops, ranging from 0 (1 sec) to 9.9 (955 sec). I display the resulting seconds, but they are seldom nice integers (such as 15 or 20) that most folks are accustomed to. You and I are engineers, so we like this design, but I wonder whether it will repel most people. So you might consider letting the user enter seconds.

Suggestion: Add a "Process" button which merely causes the display to count up seconds (and minutes), starting from 0, displayed in large characters on your 64-row OLED module. This would be trivial to add, and would let your unit function as a process timer for developing/stopping/fixing/etc. I know you don't want to make this a process timer, but the function would be useful if you use large characters to make them readable from the wet side of a large darkroom.

Suggestion: Put three buttons above and three buttons below the OLED display to function as soft keys. That's what I did on my LED controller, and they are great! I'm using them to select things (such as which LEDs to change) and to set modes. Your device is more sophisticated than my controller, so I think it would benefit even more from this soft-key approach.
Mark Overton