Profile/curve for ABW - fundamental question

[keithcooper]

I note a few comments about my B&W test image being in GG2.2 - this was always because I work in 16 bit GG2.2 for my B&W and the test image makes it easy to check ABW/Canon B&W modes.

Building QTR profiles from the test image was for linearisation purposes - something that has worked very well with some paper/ink combinations, but I find less and less need for (soft proofing never entered my considerations in this area)

Given the improvements in Printer B&W performance, I'm minded to note that measuring the linearity of ABW or Colour ICC profile based prints on the P5000 (using the 21 or 51 step patterns on the test image) and then creating a simple PS adjustment curve seems to be working rather well... Whilst the curve is 'by eye' it's based on the measured numbers from the test chart.

I tried out a P20000 yesterday and the ABW performance looked very good (Mk/Pk +3 greys) - I don't have detailed measurements for this, just a few -very- big nice looking prints (on TPP and CPN)

[texshooter]

I note a few comments about my B&W test image being in GG2.2 - this was always because I work in 16 bit GG2.2 for my B&W and the test image makes it easy to check ABW/Canon B&W modes.

Building QTR profiles from the test image was for linearisation purposes - something that has worked very well with some paper/ink combinations, but I find less and less need for (soft proofing never entered my considerations in this area)

Given the improvements in Printer B&W performance, I'm minded to note that measuring the linearity of ABW or Colour ICC profile based prints on the P5000 (using the 21 or 51 step patterns on the test image) and then creating a simple PS adjustment curve seems to be working rather well... Whilst the curve is 'by eye' it's based on the measured numbers from the test chart.

I tried out a P20000 yesterday and the ABW performance looked very good (Mk/Pk +3 greys) - I don't have detailed measurements for this, just a few -very- big nice looking prints (on TPP and CPN)

The Ultrachrome PRO ink (P10000/20000) costs 3x that of Ultrachrome HD (P5000-P9000).  Let us know if the PRO ink B&W prints look 3x better, as well

If I open your 2.2 gray gamma chart inside the aRGB 2.2G working space and print it from there, nothing bad will happen, correct?  I work in aRGB and would like to stay there if no trouble.

 Also, if I upsize  your chart to fit on 13x19 paper (so that the 51 step patches are big enough for my Colormunki to read),  will that cause any problems? And should I print your chart at my Pro 3800 printer's native 360ppi, or should I print it at 300ppi?   Generally, I print at either 360ppi or 720ppi because that's what the experts say to do. But your chart comes as-is 300ppi.

[keithcooper]

>> The Ultrachrome PRO ink (P10000/20000) costs 3x that of Ultrachrome HD (P5000-P9000).  Let us know if the PRO ink B&W prints look 3x better, as well

If you can define "3x better"  ;-)

>> If I open your 2.2 gray gamma chart inside the aRGB 2.2G working space and print it from there, nothing bad will happen, correct?  I work in aRGB and would like to stay there if no trouble.

Sure, I use images in A98 sometimes

>> Also, if I upsize  your chart to fit on 13x9 paper (so that the 51 step patches are big enough for my Colormunki to read),  will that cause any problems?

No - I did have a colormunki specific version of the 21 step, with chevrons (from back when the CM first came out)

>>And should I print your chart at my Pro 3800 printer's native 360ppi, or should I print it at 300ppi?   Generally, I print at either 360ppi or 720ppi because that's what the experts say to do. But your chart comes as-is 300ppi.

Ah - beware experts ;-) This is in the try it and see if you can genuinely see any difference category - I will push up the print ppi if there is 'real' detail.

The chart works fine at 300 - if you want to use the checkerboard pattern for testing fine detail then you can print it a 'better' resolution.  The question of 'optimal' ppi settings is often debated and I'll admit to comfortably printing some larger images at 240.

Interestingly, such resolutions were one of the areas I was chatting about yesterday wrt the P20000 - IIRC Epson have changed to multiples of 300 (like Canon and HP) - I need to check the details of this though (the specs point to native 600x600 as compared to 720x720 for the P7000)

[Doug Gray]

Stranger and stranger.

I just ran a Photoshop print test on my Canon 9500II and Win 10 x64.

I created a chart with Lab values from Lab(50,0,0) to Lab(50,-99,0). I also converted the chart to Adobe RGB and sRGB to see how images in those spaces printed. I would note that Adobe RGB clipped the image starting at a=-64 and sRGB clipped starting at a=-36.  Then printed them on glossy in the following modes:

Lab -> Photoshop manages              Measured print colors clipped at a=-83
Lab -> Printer manages (ICC sel)      Measured print colors clipped at a=-67

Image was converted to Adobe RGB then
aRGB -> Printer manages (ICC sel)    Measured print colors clipped at a=-67 (same as Lab)

Image was converted to sRGB then
sRGB -> Printer manages (ICC sel)    Measured print colors clipped at a=-39

I then changed the driver to select "driver managed (default)" instead of "ICC"
sRGB -> Printer manages (ICC sel)    Measured print colors clipped at a=-47

Observations:

This is a Canon 9500 II on a Win x64. Results may differ on other configs.

As expected (my usual workflow) printing with color management disabled and "Photoshop manages color" provides colors to the edge of the printer's gamut at a=-83

Printing Lab images using "printer manages color" results in essentially the same print as first converting the Lab to Adobe RGB then printing with a clipping at a=-67

Adobe RGB is not transformed to sRGB when printing using "printer manages color"

Both sRGB images and Adobe RGB images print roughly correctly using the driver's ICC mode.

sRGB's colors are printed significantly more saturated when using "driver manages" in the device driver reaching a=-47 instead of starting clipping at a=-36 (sRGB gamut edge)

I'm not sure what to make of this except to note that I have noticed sometimes just printing quick cell phone snapshots (sRGB) often look better (love the greens) using the printer color management. Now I see why. They just increase the color saturation.

No idea how this would affect Epson ABW but it appears things are a bit complicated.

[unesco]

I note a few comments about my B&W test image being in GG2.2 - this was always because I work in 16 bit GG2.2 for my B&W and the test image makes it easy to check ABW/Canon B&W modes.

The core of the idea of my question in the initial post and then the following discussion is: how to generate that GG2.2 patch set (in PS). So, how have you done it?

[Ferp]

As long as the monitor matches the print, I'm good to go. I can soft proof 'till I'm happy.

That's a very good point. Ultimately the objective is to get a print that we're satisfied with, and generally that means one that matches the monitor. With B&W there's more than one way to do that. Whatever works for you. My experience is that an approach based on measurement is easier and more robust.

Here is one link to the discussion several years ago about ABW, PS, and the OS:   http://forum.luminous-landscape.com/index.php?topic=62900.0  I think my first post also has a link to the first discussion.  Enjoy reading "old" history. 

It is true that there have been a number of long and confusing Lula threads about printing with ABW and profiles, particularly on Mac, when it works, when it doesn't, and who is to blame. There was a lot of talking at cross-purposes,  which we've repeated here to some extent.

The problem I've got with those threads is they don't address the issues of concern in this thread. Yes, you can print ABW from Photoshop using an ICC on Windows (and you print ABW from Print Tool using an ICC on Mac), but what if don't want to use an ICC on Windows? If you want to print from Photoshop, you have to be aware of the silent conversion problem under the printer manages colors setting and how to avoid it.

[Ferp]

Adobe RGB is not transformed to sRGB when printing using "printer manages color"  .... I'm not sure what to make of this ....

Me neither, partly because I don't fully understand the methodology or the results.  For my part, I printed the standard 21x4 tagged as gray gamma 2.2 using printer manages colors, and again by converting to AdobeRGB and then assigning sRGB (thereby avoiding the silent conversion), and the results were quite different, mostly in the shadows.

[Doug Gray]

Me neither, partly because I don't fully understand the methodology or the results.  For my part, I printed the standard 21x4 tagged as gray gamma 2.2 using printer manages colors, and again by converting to AdobeRGB and then assigning sRGB (thereby avoiding the silent conversion), and the results were quite different, mostly in the shadows.

That is consistent with what I observed. The device driver, or some part of the Win 10 OS after Photoshop, is converting the RGB data it is receiving to the device RGB space and not just ignoring the source colorspace and not simplistically assuming incoming data is in sRGB.

The same B&W image in gamma=2.2 (Adobe RGB is also gamma=2.2), when assigned sRGB, will result in lighter patches in the darkest end of the 21x4 set if the different colorspaces are correctly converted. If the source colorspace was ignored the prints would match.

But what fascinated me is that the tests with the green patches indicates that the gamut of Adobe RGB is not truncated which it would be if converted to sRGB by the driver.

[keithcooper]

The core of the idea of my question in the initial post and then the following discussion is: how to generate that GG2.2 patch set (in PS). So, how have you done it?

The targets in the newer versions of the test image were created as CMYK targets in i1Profiler (for i1Pro and i1iO) simple K only targets.

If you wanted to make an arbitrary one in PS, you can create a new GG2.2 document, make a gradient block from black to white, then posterise to the number of steps needed.

The reasons for using i1Profiler was that it makes targets of just the right size to easily scan - it's also easy to specify targets numerically from a simple text file.

[unesco]

If you wanted to make an arbitrary one in PS, you can create a new GG2.2 document, make a gradient block from black to white, then posterise to the number of steps needed.

this is how I was going to do it today, thank you for confirmation

[texshooter]

The core of the idea of my question in the initial post and then the following discussion is: how to generate that GG2.2 patch set (in PS). So, how have you done it?

ChartThrob?  http://www.botzilla.com/blog/archives/000544.html

[unesco]

I have made some tests today. Now I know more - but less...

Windows 7 x64, PS CC (updated), blank new image in: sRGB, AdobeRGB, GrayGamma2.2, all 16 bit, neutral gradient generated from pure white to pure black. Posterised to 21 steps.

Then, as for reference, I have measured in PS: RGB values and L values. sRGB patch set was identical to AdobeRGB (measurement using 8-bit numbers). GrayGamma2.2 very different to sRGB. Difference visible in the 1st and the 2nd figure.

Expressed in RGB values, source sRGB patch set is purely linear, but GrayGamma is partially linear, with strange artifacts especialy in shadows.

Expressed in L* values, source sRGB patch set is a bit convex with slight compression in shadows, GrayGamma similar but with severe shadow compression.

Then, I have printed sRGB 21 patch set in ABW (Neutral, Darker, Dark, 2880 dpi bi-directional, Printer manages color). Then measured with ColorMunkiPhoto. Results are in the 3rd figure (measured results have been normalised to 0-100 range).

Conclusion:
1) ABW Darker measurement results follows synthetic L* values from sRGB patch set. Differences are on L*=1 level, max=1.4, (for error discussion: only one print was measured, PS read 8-bit quantisation values with rounding errors from 16 to 8 bit conversion + ColorMunki imperfection). I would assume ABW Darker is linear in L* sense - it mimics L* source data.

2) ABW Dark differs from Darker, max difference L*= 3.4 - just checking in what direction the curve goes.

3) GrayGamma2.2 patch set generation attempt is strange, is it a bug in PS or I am silly and miss something?

Any more advanced comments then mine and interpretation is greatly welcome since I am a bit confused with some of the results.

[edit: Epson SC-P800, Ilford Smooth Pearl paper printed with PSPP settings]

[unesco]

ChartThrob?  http://www.botzilla.com/blog/archives/000544.html

thank you, I will read it carefully

[Alan Goldhammer]

I was looking at Scott Martin's site for another post earlier today and came across this article:  http://www.on-sight.com/using-i1profiler-for-qtr-grayscale-measurement-and-profiling/

[Ferp]

I was looking at Scott Martin's site for another post earlier today and came across this article:  http://www.on-sight.com/using-i1profiler-for-qtr-grayscale-measurement-and-profiling/

Which aspects of it do you think are relevant for this thread?

[Ferp]

I have made some tests today. Now I know more - but less... 

I hesitate to comment on the test results posted so far, because I'm struggling to follow them.  I'm not sure if that's just me, or whether ambiguities remain despite the best efforts of the posters to explain what they have done.

I don't understand this desire to generate new test charts.  Perfectly good charts are available, particularly those that ship with QTR. They give equally spaced luminosity steps from 0 to 100 in a variety of patterns. They're untagged, which is fine.  If you assign any grayscale profile you like, and measure, the data isn't going to change because you've only assigned the profile, not converted.  The appearance of the chart on your monitor will change.  If you convert to another profile, then with the exception of AdobeRGB (which has a gamma of 2.2), the measured data will change. but the appearance won't.

The general principle when creating an ICC - color or B&W - is you print with color management off.  So as long as you do this then it shouldn't matter what space the test chart is tagged in.  Your test charts generated from first steps should all work, since they should have 21 equally spaced steps from 0 to 100.  The profile shouldn't affect the print, since color management should be off.  The fact that the gray gamma 2.2 chart doesn't measure as having 21 equally spaced steps, if I interpret your results correctly, suggests to me that something has gone wrong with the generation of this chart.  I honestly don't see the point of generating test charts from first principles, other than as an academic exercise.

Regarding your measurement of ABW Dark and Darker, a number of people of people posted comparative measurements of the five ABW tone settings.  I went searching on the Digital B&W forum and found these:

http://forum.luminous-landscape.com/index.php?topic=104907.0

If you search more widely on the internet you'll find others.  They vary with paper and printer.

The measurements I was suggesting on Windows to validate mine were these.  Take an existing test QTR test chart.  It's untagged.  Assign it to gray gamma 2.2 and save a copy.  Assign it to qtr-gray-lab and save a copy.  Print these three files via ABW, using ACPU, since that's going to be the simplest way to ensure that color management is off, although the placement on the page is going to be inconvenient.  Measure them.  They should all be the same.  That will demonstrate that the approach in the cameratico article doesn't work, if it ever did.  So long as color management is off, the tagged profile will be ignored.

Now print them as is from Photoshop using printer manages colors and the same ABW settings.  They will measure as different to the first three.  I suspect that the gray-lab one will also be different to the other two. This will demonstrate that something has happened to them.  (Based on the statements by Adobe software engineer Dave Polaschek I believe that this is caused by a silent conversion to sRGB by Photoshop.  For reasons I don't understand, Doug Gray seems to conclude that it's happening elsewhere in the printing pipeline.) 

If you want to print any of those charts correctly via Photoshop, rather than ACPU, you would have to convert them to the equivalent RGB ICC (AdobeRGB for gray gamma 2.2, rgb-lab for gay-lab), then assign sRGB, then print.  If you compare these measurements, they will be the same as the ACPU prints.  This will demonstrate that if you wish to print ABW from Photoshop using printer manages colors (and not using the ICC to print), then you'll have to use this trick to fool Photoshop into thinking that the image is in sRGB.  Alternatively, you'll can use the null transform method in the print dialog - set the printer profile to be the document profile and ignore the scary Adobe warning.

(Edited for spelling)

[unesco]

I hesitate to comment on the test results posted so far, because I'm struggling to follow them.  I'm not sure if that's just me, or whether ambiguities remain despite the best efforts of the posters to explain what they have done.

I don't understand this desire to generate new test charts.  Perfectly good charts are available, particularly those that ship with QTR. [...]

Thank you Frep for your patience in all your replies.

I have made dozens of tests in the past week - generating from the scratch my own 21 and 51 patch sets directly in the PS CC (gradient posterisation, Windows7 as I intended and Keith recommended) in the following color spaces: AdobveRGB, sRGB, Gray Gamma 2.2, QTR Gray Lab (linear L*) and untagged files from QTR catalogue. Prints have been made in ABW Darker, Neutral mode (2880 dpi, bi-directional), Epson SC-P800 on Ilford Smooth Pearl paper. Color Munki spectro.

Conclusions:
1) All above mentioned variants gave the same results, shape of the curves were virtually identical (as presented a few posts before in the figure "L values - measurement.png"), max of differences is about 1.5 L*, but prints have been made in different conditions, different measurement modes - spot and strip, in different page orientation etc. Most of differences are within +-0.5 L* margin

2) Therefore, for Epson ABW test patch measurement under PS, untagged patch set can be used.

3) As a side effect, measuring a* and b* shows that 1440 dpi mode gives some more neutral print than 2880 dpi mode (Darker).

This week I am going to measure different options of ABW and parametrise them e.g. to be able to achieve linear print later on without measuring, using QTR scripts and struggling with PS color management options - I will share results here once they are ready.

[texshooter]

This week I am going to measure different options of ABW and parametrise them e.g. to be able to achieve linear print later on without measuring, using QTR scripts and struggling with PS color management options - I will share results here once they are ready.

What working color space have you decided to use from here on out?  I ask because the author of the aforementioned Cameratico.com article recommends using QTR-Lab working color space (I'm not talking printer profile, but rather working space PS>Edit>Color Settings).  If your answer is QTR-Lab, then I must ask you this.   Does the QTR printing GUI (module, pipeline, driver, thingamajig, whatever you call it) bypass the Epson ABW printer driver (like PrintImage and QImage RIPs do)  and print with a 1.0 gamma response curve?  If no, then what does the QTR printing GUI actually do that the printer ABW driver does not do? My experience with QTR was limited to building an ICC profile and nothing more--I've never printed directly from QTR itself.

[Doug Gray]

Many years ago I needed to create specialized charts with superimposed sine functions of differing frequencies for studying system MTF. Linearity was important. It was a B&W image. I used the conventional approach using a custom profile and it worked reasonably well but I was able to refine it by creating an RGB target with all 256, 8 bit values. This was printed w/o color management then read with an I1. After loading it into Matlab, I smoothed it with a low pass filter as each step wasn't perfectly monatomic. Then created a reverse interpolation table. This was used in a function that read in a tiff file, applied the reverse table, and wrote out a modified tiff file. This worked even better. All I had to do was run the Matlab function to create a B&W image that was significantly more accurate than the best I got from a conventional profile using standard tools. It would be quite easy to create a command line program that could do something similar to get rid of the Matlab requirement.  I suspect the open source Octave might be another route. I used standard color mode w color management disabled but it should apply to Adv. B&W just as well. Anyone tried something like that?

In retrospect I think that approach could be improved by grouping 4 pixels (at 720PPI on Epson) and adjusting them to improve the smoothness of each RGB step.

[Ferp]

@unesco:  #1 surprises me a little, because depending on how you printed these various test charts, I'd have expected some differences, but perhaps you printed them in a way to prevent this.  #2 is what I would have expected.  #3 is an interesting observation that I hadn't noticed before.

Does the QTR printing GUI (module, pipeline, driver, thingamajig, whatever you call it) bypass the Epson ABW printer driver (like PrintImage and QImage RIPs do)  and print with a 1.0 gamma response curve?  If no, then what does the QTR printing GUI actually do that the printer ABW driver does not do?

Qimage is not a RIP - it prints via the OEM printer driver.  QTR is a RIP and as such it bypasses the printer driver entirely, including the ABW component of it.  It just prints the luminosity numbers in the image file using the selected QTR curve.  It's that curve that determines the response, because it specifies how much of each ink to use at each luminosity level.  That's one of the attractions of QTR - you can get in under the hood and change its behavior using these curves in ways you can't with ABW.  Most curves have been created to be linear in luminosity.  In practice that varies from printer to printer, but QTR provides the capacity to linearize a curve for your printer.  However converting to an ICC generated by QTR-Create-ICC before sending the image to QTRGUi, as recommended by some people, will change the overall response of your printing pipeline to something closer to a perceptual rendering intent.

@Doug: No idea.  Out of my league.