Digital BW, The Print

Hi Steve,

There are quite a few different units floating around and many mathematical
formulas.  Just saying "linearize" is very ambiguous until you define exactly
what you are linearizing.  Nobody wants to linearize "density" values.  That 
would put the 50 step at about 0.86 midway between 0.04 and 1.68.   

I think we'd all agree that there has to be some sort of up sweeping curve
when you plot density.  But there are numerous mathematical functions that
exhibit this look but in fact are different when you get to the details of the shape.

I can think of three main physical values from color theory that are relevant:
Density,  the Y of XYZ which is luminance, and L of Lab called luminosity or
sometimes lightness.  The names sometimes get confused but the letters are
always consistently defined.

Mathematically they are related:
density = -log(Y)
Y = ((L+16)/116)^3   for L >=8
Y = L/903                  for L < 8

Gamma is a purely mathematical function:
output = input ^ gamma

Dot Gain is a physical property of putting ink onto paper which
typically gives a curved shape because the middle values are affected
more that the end points.

A finally the pixel values of 0-255 are totally arbitrary -- they may be derived
in any way we like.

All the functions above have a sweeping curve character.  When you start
combining them you have a unlimited number of possible shapes.
So any spec that quotes a particular shape really needs a lot of qualification
about what they really mean.

What QTR does and I advocate is linearizing in Lab values.  Lab was defined way
back in the early 1900's using large studies of human perception and our eye's
response to light intensities.  The weird function was designed to mimic the
way we see.  So when QTR linearizes to Lab values it just uses the dynamic range
of dMin to dMax to the "best" curve.

What has been the weak part is that we've been using the gray space of gamma
2.2 which has a different shape.  I'm always been a little surprised or annoyed that
I calibrate my monitor with the best gear but when I look at a 21step wedge the
dark shadows from 100 to 95 seem much more compressed that the rest of the
wedge.  Getting the soft proofing working has "fixed" this in the sense that I
can now get reasonable separation throught the 21step.

This whole thread has gotten me to figure out more of this.  The problem with our
scheme so far is the gamma 2.2 working space.  It just isn't geared to our perception.
It's close and if you look at Lindbloom's site about comparing Lab to gamma 2.2
you can see what's going on.  Lab doesn't have a "gamma" -- it has that cubic
equation.  Bruce has just shown that gamma 2.2 is pretty close.   But if you look at
the comparision though you'll notice a strange wiggle in the curve in the bottom
left corner.  This is the source of the compressed 100-95 levels.

This is why I've introduced the new gray space.  Whatever the gray space is, is
what gets converted to the monitor display space.  Now we have all the parts talking
the same language.  I've still got some tweaking to do since this was done more by
trial and error than mathematically.  But I think this may be a significant "new"
way to deal with B&W printing.

Roy


--- In DigitalBlackandWhiteThePrint@yahoogroups.com, Steve Kale <stevekale@b...> 
wrote:
> 
> One other perspective which ought to make you stop and think a little about
> the current methodology.  Tyler has nicely espoused the current way of doing
> things:  a desire for a nice linear (straight line) progression of density
> from dMin to dMax across the full range of pixel values, 0-255 in 8 bit, 0-1
> normalised.  So, for EEM for example, this would mean 0 maps to a density of
> 1.68 and 1 maps to a density of 0.04 and all other points in between sit on
> the straight line between the two.  (If I am wrong on this please correct
> me.)  In so doing you are defining (or calibrating) the colour space of the
> printer.
> 
> NO COLOUR SPACE IN GENERAL USE TODAY HAS THIS SORT OF PROFILE. Not Apple
> RGB, not Gray Gamma 1.8, not Adobe RGB, not Gray Gamma 2.2, not sRGB, not
> LAB.  NONE of these are linear when we plot density vs pixel value.  ALL are
> curved in this dimension, such curvature representing their gamma (a fancy
> word for rate of change or contrast).  Plot them out.  You have all the
> formulas.  Most have been covered in this thread and many are in general use
> (eg we typically read LAB with our photospectrometers to then calculate the
> density figures which are linearised above).  Those that aren't are covered
> on Bruce's site and he even has calculators to make the job easier.
> 
> From what I can see (excuse the pun), making pixel value vs density plot as
> a straight line has absolutely no basis in "colour" theory.  The only thing
> that I have come across in photography that is linear in this dimension is
> the measuring of light intensity by a photosensitive cell (a camera "pixel"
> for example) and what is the first thing we do with this type of data?  We
> apply a gamma, we curve the data.  Why?  Because the eye doesn't work in a
> linear fashion in this dimension.  So I find it rather peculiar that people
> on the one hand get obsessed with "how the eye sees" and yet, on the other,
> ignore this when they make pixel value vs density linear.
> 
> The plot that more often than not is linear is log10(pixel value) vs
> density!  ALL (with perhaps the exception of LAB, see my note below) the
> colour spaces mentioned above ARE linear when we plot log10(pixel value) vs
> density.  (As an aside, note that when Kodak plots the response curve of
> photo paper it plots log10(exposure) vs density!) If you have a straight
> line with pixel value vs density it is NOT linear when you then plot
> log10(pixel value) vs density.
> 
> A note on LAB:  the LAB space may not provide a perfectly linear plot of
> log10(pixel value) to density but it is very close.  If it did Bruce
> Lindbloom would have known the gamma embedded in the LAB model.  Instead he
> had to undertake an exercise to find which gamma best fit the LAB model.  He
> came up with 2.2.