The graphs are interesting info about several different aspects. So I have a few comments.
First, I've used similar graphs a lot over the years in making QTR curves. It's the best info about
how well you are doing with the linearity for both tones and neutrality.
Hello Roy,
it's very nice to have your comments here,
many thanks for this.
As you perfectly know, the plot I do are nothing new, in fact they are only a slightly rearranged looking versions of the ones you still provide in text mode as output of your QTR-tool
1) about the initial data and methods. I have to agree with I think Mark A. the Epson STD being done without
an ICC profile shows just the response of the the driver and really isn't a good comparison of what you should
get printing normally. The ABWs however are supposed to be tuned from the get-go so they are indicative
of what you will actually get.
Maybe Alan (who made the test) could help to better clarify what exact settings were used in the labeled "Epson std" data set.
Assuming the strip was kept untagged and the ACPU set to no color management, what need to be confirmed is whether in the Epson driver panel,
under the "mode" menu it was selected "Epson std" or "Off (no color management)" before printing (they are mutually exclusive).
Only in the second case we could tell that the measured data are related to a raw fully unmanaged workflow, but labeling it as "Epson std" was confusing, if the case.
Having read "Epson std" as label in the provided data I have interpreted it as the above menu option was set to "Epson std" and not "Off (no color management)", but a final confirmation from Alan could be useful to finally clarify the issue.
(I wonder about the ABW-D3 data in both cases because it seems to go to L=100
rather than paper white of about L=96, but not too big a deal).
You are right, this is strange in fact, it seems that the 5-6 readings near L* 100 in the ABW-D3 data set are abnormally lifted, this is something I forgot to ask to Alan about, and I'm still not easily able to figure out how it could happens. In any case it affects only the ABW-D3 plots, so we can even decide to keep these plots out of our thoughts without big impact.
I am surprised at how cool the darks are (b=-2.5) in all the ABW cases. I don't think you've mentioned the ABW paper that was selected in printing but it may
have different characteristics than the Silver Rag paper you actually used.
I was surprised too, for this reason I have remarked that the results should be considered tied to the given printer/paper/settings combination.
Maybe Alan could specify what media setting was used, it could be nice to know.
2) the difference shapes of the curves in the dark shadows illustrate the difference between the different embedded
profiles. AdobeRGB and Gamma 2.2 are true gamma curves -- pure exponentials. sRGB and Mac's special
Generic Gamma 2.2 are pretty close for most of the range but you can see they are pretty different in the very
darkest range. These two have the same tonal curve which is mathematically more complicated but suffice to say its
similar to gamma 2.2 until the dark shadows. If you look at the L values for a step in the dark range you'll see that
all compress the shadows a bit more than linear L values.
(aside: in QTR I made a special ICC profile that is exactly linear in L -- called QTR-GrayLab and QTR-RGBLab -- this
essentially makes K (or RGB) values line up directly with L values).
If you print in Photoshop with Printer Manages Color and ABW in driver what I believe the system does is convert
your data to sRGB before sending to the driver. So what you see in the two sets of data is this conversion of
AdobeRGB (or Gamma2.2) to sRGB (or Generic Gamma 2.2).
During the development of my linearization tool I have written some math script in Octave, based on LindBloom and Adobe tech info, in order to precisely calculate the RGB to Lab (and inverse) transformations for different colorspaces (currently sRGB, Adobe RGB and ProPhoto RGB). I have exactly implemented the ideal 2.2 gamma curve, the sRGB gamma curve (with their linear part in the deep shadows and a 2.4 exponent) and even the Adobe adopted gamma slope limit of 32 used in all ACE engines conversions when pure gamma curves colorspaces are involved.
I perfectly know that you are well aware of all of this stuff
I have written something regarding these arguments in my linearization thread here (Reply #18):
http://www.luminous-landscape.com/forum/index.php?topic=78142.0That said, I tend to agree with you regarding the fact that the shape of the extra dark zone in the gamma 2.2 plots is probably the result of an untagged K strip, being plotted as a gamma 2.2 L* x axis, but being printed assuming to be in sRGB-gamma format from the Epson driver (not only in ABW but even in the so labeled "Epson std" mode).
This was the reason why I decided to plot again all the data using a sRGB-gamma conversion for L* x axis.
What I find interesting is that if this is true, this could be considered a big proof of the fact that by default Epson driver expect all the inages to be encoded in sRGB and this is valid for ABW mode too.
Since there was a long time debate on the net if this was the case or not, with different opinions, and due to the fact that in my (limited) test I rarely, if ever, have seen this effect in my gamma 2.2 (Adobe RGB) assigned strips, I was one of the people starting to believe that the default expectations of Epson driver was gamma 2.2.
Now I'm much less sure, and it could really be that Epson driver, as you correctly point out (and matching Eric Chan opinion for example), by default, is expecting a sRGB encoded image in all their modes (ABW included).
3) Mark mentioned the "perfect system for L* tone reproduction". Ideally a straight-line from L=0 to L=100 would be
the goal. But since neither pure black not pure white is achievable we need to connect L(dmax) to L(dmin) somehow.
The simple straight-line seems like the obvious compromise (and in fact this is what linearization in QTR curves does).
But as I discovered with help from others is that what's more important is that the prints that come out match the
screen better. You have to have the mid tones match -- in other words the ideal curve has to go through (50,50).
With the examples given here that happens pretty close because dmin and dmax of photo paper is very close to the
white and black. The L=4 to L=96 line does go through (50,50). But with matte paper the much lower dMax
illustrates this better. A L=16 to L=96 line would go through (50,56) -- resulting in a noticeably lighter print.
I agree with you, this is something we have already covered in my Linearization thread.
Currently my approach is to match the linear line between real ink black and paper white readings as general target because I considered it a good starting point for my early development.
It could be absolutely possible to implement a second options, by adopting an "S" shape target, instead of the pure line, still anchored to real black and white readings, which could mimic the ideal 45 degree 0-100 L* linear in the midtones zone with good match, at the expense of shadows and highlights compression.
As you rightly highlight this "S" target could produce better perceptive results in matte papers more suffering from limited Dmax. In this case the shadows compression should be carefully monitored to avoid excessive "crushing" potentially occurring, in my opinion.
Scaling for various dMax's is where Black Point Compensation (BPC) came about. Adobe has a paper about it in all
the gory mathematical detail. Bottom line is you should scale in the Luminance Y values rather than Luminosity L values.
See http://www.brucelindbloom.com if you want more detail about the math.
This is the main reason for using the CM of the system to match L values from source file to L values of the print
in such a way to give the best perceptual match given dmax/dmin limitations.
I agree with you, and, as already told, I am often using the wonderful Bruce website as one of my most important technical information source.
I will look for the Adobe paper you mentioned for sure.
Many thanks again for sharing you precious thoughts, it is very appreciated.
Ciao
Andrea