*Toe Twiddling For BTZS Film Testers
by Phil Davis
I’ve received a few questions recently referring to my recent article about
the “Personal Speed Point” and how one goes about establishing it. I haven’t
heard of any serious problems, in fact most folks seem to be making good
progress. But, as usual, there are reports of some minor irregularities in
the test files, especially in the contours of the Chart lines.
These lumpy lines may look a lot more serious than they are because, in the
case of the EFS charts in particular, the errant data points are rounded up
or down, in use, to coincide with the standard film speed numbers. For
example, any chart value between 90 and 112 will automatically become 100,
when applied to a meter.
At least that’s the way we used to think about it until the ExpoDev
program came along. Now, however, EFS and G-bar (average gradient) numbers
are exported to the ExpoDev without being rounded; in other words, the
program interpolates intermediate numbers, and delays rounding until the
computation is finished. Given the uncertain nature of the whole
photographic process, we can’t really make a case for the greater “accuracy”
of this calculation method, but it does recognize the fact that a minor
change in exposure doesn’t result in an erratic, disproportionately abrupt
change in the negative’s image density; nor does contrast increase in
spasmodic leaps as development time advances, second by second.
Recognizing this smooth progression of exposure and development effects
is an especially important concern now that the ExpoDev program displays
actual development times. These times are discovered by a magical function
that tracks the Dev Chart lines and reads off their time and density
coordinates, not just at the 21 data points, but at any selected point along
the line’s length. If these lines are irregular or lumpy, the development
times read from them will be similarly irregular.
The G-bar and Dev Chart lines are plotted directly from the data points
of the Family curves, so it’s obvious that any irregularity in the Family
display — especially in the critical toe region — will deform the Chart
lines and distort their information.
We can’t correct erratic Chart lines directly but we can (and should)
edit them indirectly by cleaning up the Family curves. In the Family Tab,
select the arrowhead pointer from the tool bar and the data points on all of
the curves will be identified by small circles. Click on a circle to select
it and you will then be able to step along the curve in either direction by
using the right and left arrow keys. You can jump from curve to curve with
the up and down arrow keys; and you can move any point up or down, one pixel
at a time, by holding down the shift key as you use the up or down arrow
keys. Moving the data points will also change their density values in the
Data Tab just as if you had edited the numbers directly.
Of course you should use this powerful editing feature discreetly because
it’s quite possible to create fictitious curve contours this way. But when
applied sensibly, these point adjustments can actually improve the accuracy
of your test data. Point density errors of 0.01 or 0.02 are entirely
possible because the density of any film sample can sometimes vary by that
much if the readings are taken from slightly different areas. Also,
densitometers’ accuracy is generally no better than +/- 0.01 and their zero
settings can drift by a similar amount. In other words, you can expect to
discover a few points out of place no matter how carefully you work. In the
interest of good craftsmanship — and good data — you should correct them as
well as you can.
First, check the curves visually to discover random displaced points, and
if the correct location of a point is obvious, nudge it into place with the
arrow keys. Then pay particular attention to the toe region of the curve
family because even slight irregularities there can skew the chart lines
significantly. In other words, if you see a bent or jagged chart line, check
the curve toes first because that’s where you’re likely to find the cause of
the problem.
Analyze the situation before you begin to shift data points around; the
first editing principle is “do no harm.” At first glance there may appear to
be several ways to correct toe deformities, but the scheme that requires the
fewest moves is probably the best one. It’s also a good idea to assume, at
first, that unless these are obvious displacements, the extreme curves, 1
and 5, are probably OK. Then look for abnormal variations in the spacing
between curves; the spaces should converge smoothly as they approach the toe
region and the curves should never touch each other, at least not until they
level out at the B+F density level.
For an example of successful “toe twiddling” look at the “Raw Curves”
illustration which shows the original toe configuration of a test file, as
well as its G/Dev and G/EFS charts. Superficially it appears that curve 2
needs adjusting to fix the G/Dev chart, but curve 3 seems to be the cause of
the break in the G/EFS chart. Actually curve 2 had a different problem that
I’ll explain later.
 |
Raw Curves
|
At first glance at the curve family I could see that there was a single
point out of place on curve 1 and also on curve 2 (the errant points are
shown in black). Moving each of them up by one pixel improved the chart
lines a little, but the break in the G/EFS chart line was unaffected. Taking
a longer look at the toes, I decided that curve 4, not curve 3, was the
troublesome one because of the uneven spaces between it and the adjacent
curves. Curves 4 and 5 were almost parallel for a little distance, while the
space between 3 and 4 converged sharply. In other words, three points on
curve 4 needed to be raised up by only one pixel each. Making that
adjustment produced the result shown in the “Fixed Curves” illustration.
Interestingly, it turned out that points 3 and 5 were the valid ones; the
point adjustment I made affected the other three points to produce the
smooth EFS chart line.
 |
Fixed Curves
|
These adjustments are largely cosmetic and they have relatively little
practical affect on the accuracy of the working data exported to the Palm
and iPaq hand-held devices. But the corrected lines are theoretically more
accurate, and as long as we have the option of doing things right, we might
as well make the effort.
The initial hump in the G chart line (point 2) turned out to be a data entry
error. The developing time for that point had been entered as “5mins 40s”
and that entry baffled the WinPlotter; it assumed that the “5” was the last
significant number, and ignored the following “mins 40s.” When that labeling
error was corrected the final G/Dev chart line was commendably smooth. To
avoid this sort of error, enter these times either as decimals (5.6mins) or
in the conventional minute:second format (5:40). The Plotter stops paying
attention to these numbers as soon as it encounters an alphabetic character.
*Title suggested by Bill Waldron; he dared me to use it. Heck, I don’t have
any pride.
|
