U of S | Mailing List Archive | alt-photo-process-l | Re: Why?

Re: Why?



Kees,

you see when you do as  you suggest for #3 this as the unfortunate effect of
reducing the actual print contrast relative to the original image. Say for
the sake of discussion that your scanner is well calibrated, that the
darkest printed value is 5% and that the white is 95% or vice-versa if you
prefer, if we do as you suggest, this range is strech to 0% - 100% and you
linearise to these values right? But, the actual print values don't change,
they are still 5% to 95% and this not only implies but is a reduction in
overall contrast.

If one would do as most gamut or tone mapping algorithm suggest, you could
do something like the following:

1: You bring the original white to the print "white"
2: You bring the original black to the print "black"

Up to here, this would produce the exact same result as implied by your #3

3: You add a new point near the "white" value, say about 90% and you bring
that point such that it's on the diagonal from 0% to 100%
4: You add a new point near the "black" value, say about 10% and you bring
that point such that it's on the diagonal from 0% to 100%

Now you would have 80% of the print tonal values that are an exact match to
the original tonal values and contrast instead of a single tone value
implied by #3. The 10% on each end of the tonal range can and could be map
differently base on one preference but the "curve" Photoshop does provide a
smooth transition to the end point on each side.

For processes that provide a relatively "long" tonal range, the reduction in
contrast implied by #3 may be insignificant but for processes with a
relatively "medium" or "short" tonal range the difference will probably be
quite significant.

This is still an imperfect solution though, just think of cyanotype for
example, depending on how the scanner software translate color to greyscale,
this can have a significant impact on the resulting greyscale values and
thus on the mapping from original to the print tonal range. At the expense
of a major increase in complexity and cost, there are ways to deal with this
kind of mapping problems I wont get into here.

The basic idea of all this is that original tones that are outside the print
tonal range should be handled or map to print tonal values in such a way as
to preserve as much as possible the "perceptual" intent of the original and
that the original tones that fall in the print tonal range be mapped to the
exact same tones as much as possible.

The method proposed in #3 doesn't do that and while what I suggest here
isn't perfect, it does a better job of preserving the original
caracteristics and yet it is still quite easy to implement.

Thanks,
Yves



----- Original Message -----
From: "Kees Brandenburg" <ctb@zeelandnet.nl>
To: <alt-photo-process-l@usask.ca>
Sent: Monday, June 16, 2008 9:20 AM
Subject: Re: Why?


> Hello Yves,
>
> When you calibrate your workflow for digital negatives you do three
> things:
>
> 1. find your maximum black - it's your standard printing time - lets
> call this 100%. No need to use a longer exposure time, it never gets
> blacker!
> 2. find the right color (or a combination of ink laydown % and color)
> to get minimum white - lets call this 0% No need to block more than
> needed to get paper white.
> 3. linearize between these fixed  0 and 100% bij making a correction
> curve
>
> As 1 never can get darker and 2 never gets whiter and they correspond
> with the 0 and 100% patches in your original greyscale you can safely
> set them to 0 and 100 after scanning. Take care to scan all image
> information and prevent clipping or curve changing. Set white and
> black points just outside the histogram in your scan preview and scan
> linear (no whitebalance or other curve correction by the scansoftware).
>
> regards
>
> -kees
>
>
>
>
> On 16 jun 2008, at 13:56, Yves Gauvreau wrote:
>
> > Hi all,
> >
> > I'm intrigue, I've been reading about color management for a while
> > now and I
> > can't help myself asking why most method of creating digital negs
> > suggest to
> > strech the scan of the 101 stepwedge print or equivalent from 0 to
> > 255 while
> > every mapping algorithm I've seen so far basically say that the
> > opposite is
> > the norm?
> >
> > Have a nice day,
> > Yves
> >
>