Digital BW, The Print

Hi Tyler


> From: Tyler Boley <tyler@...>


> Requirements of an optimum working/editing space are complex and
> differ from "good" output linearization, or say, a monitor space. This
> is one reason we have color management.
> There is a great deal of sense
> in selecting LAB as a standard for output, it's based on years of
> stufy on how humans see.
> In some ways that decision makes more sense than why one may select a
> particular working space, they just happened to be the ones that come
> with Photoshop.

OK.  In the past when you guys debated or asked the question re to which
space you linearized I didn't understand the question let alone the answer
and so I didn't really follow the subject matter.  I guess I am still a
little puzzled though.  Everything I have read about CIELAB is that it is a
very broad colour space, encompassing Adobe RGB, SRGB et al, but that it is
not very "useful" for editing, principally because it is not as intuitive as
RGB and its broader gamut doesn't offer much incremental value. I am sure
this is contended!  It is useful of course as an intermediate space, used in
the background by PS when switching colour spaces but about the only widely
used use of LAB in editing that I have encountered is when sharpening, ie
sharpening the L channel because it has no colour info and hence can't
induce colour change when sharpening.

One can see the difference between LAB and gamma 2.2 on a step wedge by
assigning the two profiles to two step wedges and looking at the difference
and the differences can be expressed in density terms by converting the
figures shown in the info palette to their density equivalents.

For example, if Paul (or anyone else) wants to target a LAB mid point for
his curves then 50% needs to be LAB=50 or a density of 0.73, rather than
0.66 for gamma 2.2 or the current 0.61.  This would also match a grey card's
18% reflectance.

Your other post provided a link to Bruce Lindbloom's Beta RGB.  This is the
result of his search for an optimal working space.  It is interesting that
he chose a gamma of 2.2 for Beta RGB and for grey scale:

"I have previously analyzed the optimal gamma for the grayscale only (you
can  see this analysis [here]). This result was about 2.2 (actually either
2.1723 or 2.3243 depending  upon the error metric used).

For Beta RGB, I additionally performed a three-dimensional
analysis....[which] resulted in a gamma of 2.12. This was sufficiently close
to 2.2 that I did not feel a deviation from a "standard" 2.2 value was
warranted."

One can take this one of two ways: (A) working in 2.2 gamma is a good
compromise for visualizing LAB output or (B) there is not much to be gained
from linearizing to 2.2 gamma versus LAB.

EITHER way, the question still begs over WHAT RANGE the linearization
calculation should take place.  Note Bruce's charts all have an x-axis range
from 0 to 1 that he calls Input Value ie this is what I have been calling
(from Norman's nomenclature) normalised pixel value.  When we linearize (to
LAB) with QTR we do so from dMin to dMax over the full range of 0 to 1.  Yet
for, say EEM, the printer can only reproduce pixel values from 0.18 to 0.95.
As a result, the linearization does not follow the LAB curve shown on
Bruce's site but rather takes on a completely different curvature and mid
point.  If instead we linearized to LAB over the range of pixel values that
the printer can reproduce, ie from dMin (paper white/ink=0) @ 0.95 to dMax
(ink black) @ 0.18, then we would get linearization that meets what we
wanted - the LAB curve between the values at which the printer can register
tonal change (can I call this "dynamic range"?).

(Also note that we would still need to fill the slots for the missing values
on either side of the range. If these were left at no ink and full ink
respectively then the curve would take on the form of a curve for film or
photographic paper.  A printer loaded with ink is directly comparable to
these two other mediums.)

> If you wanted to carry your ideas forward, it would be very easy to
> make a custom gray space with the same gamma as LAB, or, for a Roarke
> RGB workflow, use a custom gamma RGB space that matches that output's
> gamma.

Or I could choose B above and linearize to gamma 2.2.  The question is how
much is gained from LAB.

In any case, I think the PRIMARY issue is the one that I outline above
(beginning "EITHER way").

> 
> 
> 
>> ...QTR does not go so
>> far as to allow a user to define the type of linearization though - that
>> really would be quite a masterpiece.
> 
> Well, it's just going to cost you more. If I recall, OPM/IJC
> linearizes to a user selectable choice of gammas 1.8 or 2.2 (someone
> correct me). A user would have to report to you regarding whether or
> not there is a good monitor match using the corresponding gray working
> spaces.
> StudioPrint is linearized to whatever the user selects. We linearize
> to 20% dot gain, and use a 20% dot gain gray working space. While
> monitor match is pretty good, soft proof is still much better.

With reference to my point above, do you linearize over 0 to 1 or over the
dynamic range for that curve?

> Other users select a gamma based space, and adjust the target output
> dot gain to suit, visually I assume.
> The only way to properly display (to the degree you may be seeking),
> on a monitor, a device/workflow/whatever is to characterize it and use
> soft proof. 

Or define it in curve format so that the transformation curve can be saved
and the transformed image can be saved.  Not I have been making a very big
simplifying assumption that we are primarily interested, when editing, in
tonal rendition and not hue (largely because I think this is practice and
secondly we can only edit hue by writing a different curve).

> I can even find fault with that, but it's miles ahead of
> where we were before softproof.
> Lastly, I have to come back to monitor calibration. If you would
> prefer developers linearize their processes to the look of a generally
> accepted working space on monitor....
> ...whose monitor?

It is not linearizing to monitor per se, eg if linearization to LAB is
deemed critical and 2.2 is considered a satisfactory compromise for editing
then I could perhaps live with the difference (because it is so small) only
if my primary issue is suitably resolved.  It is getting the linearization
intended: a linearization to x (LAB, 2.2 or whatever) over the range of
values within which the printer can record changes tonal change, ie
linearization over the dynamic range of the printer.

Cheers

Steve