Yahoo Groups archive

QTR-Quadtone RIP

Index last updated: 2026-04-28 23:12 UTC

Thread

QIDF versus ICC

QIDF versus ICC

2016-07-27 by info@...

Hi I’m new to this, I’ve done my home work but I’m confused about somethings.


I’m using a PC but I also have a MAC and could switch to it if the fact that I’m using a PC is contributing to my confusion. In some of the on line literature, as well as here in this forum it appears as though the qidf curves are being referred to as profiles. My intuition tells me that these curves are more like media type settings since they control ink levels. The profile would be the ICC profile being created using the Eye one and the Create ICC RGB droplet. If my intuition is correct than the curves (media types) and profiles should be working in tandem. Yet I have never encountered, in the any of the manuals or tutorials an indication that the curves are used in conjunction with the profile. In fact on a PC it is not clear how one might use the QTR rip with the ICC profile (unless of course the files are previously converted in Photoshop)


Are the ICC profiles simply for soft proofing and if so does this mean that results sent from the RGB ( or Greyscale ) work space through the QTR rip using the ink level curve are identical to a virtual colour conversion to the ICC profile (created using the quid curve) ?


Thanks for any clarification you can provide me


Eugene


Re: [QuadtoneRIP] QIDF versus ICC

2016-07-27 by Paul Roark

I'm not going to attempt to answer all the questions, but just thought a few notes might be helpful.

I work in Windows and find the GUI for the Curve Creator (as well as main QTR interface) to be a great asset.

Among other workflows, I make image adjustment curves in Photoshop that, through the Epson driver, can control my inksets. However, I prefer to embed these curves in an ICC. I do that with QTR9;s Create ICC-RGB. Then I simply print from PS, through the Epson driver, pull up the ICC, and I have a "color managed" workflow. In this case "color managed" means that the Lab L values -- the gray ramp -- are printed such that they should what you see on a properly profiled monitor. The ICC workflow is easy and fast. (Be aware that most monitors are not very well profiled, however. You may need to attend to that also to get a good match.)

Usually I print through QTR, which acts as a stand-alone driver in Windows. To make a QTR profile, I use curves that are very much like the Photoshop curves, except I have much better control. QTR in Windows is not a "color managed" workflow that reads the file's workspace and prints to match it. For my work (and I post all the curves and profiles) I use a Photoghop curve to make the adjustment between my file's Gray Gamma 2.2 and QTR's straight line Lab L response curve ("characteristic curve" for the old film guys).

So, from my perspective, "profiles" for printing have curves within them. We often use the terms generically to refer to the software that controls the printer and how the inks are laid down.

It's a long learning curve but worth it.

FWIW

Paul
Show quoted textHide quoted text
On Wed, Jul 27, 2016 at 7:34 AM, info@moisdelaphoto.ca [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:

Hi I’m new to this, I’ve done my home work but I’m confused about somethings.


I’m using a PC but I also have a MAC and could switch to it if the fact that I’m using a PC is contributing to my confusion. In some of the on line literature, as well as here in this forum it appears as though the qidf curves are being referred to as profiles. My intuition tells me that these curves are more like media type settings since they control ink levels. The profile would be the ICC profile being created using the Eye one and the Create ICC RGB droplet. If my intuition is correct than the curves (media types) and profiles should be working in tandem. Yet I have never encountered, in the any of the manuals or tutorials an indication that the curves are used in conjunction with the profile. In fact on a PC it is not clear how one might use the QTR rip with the ICC profile (unless of course the files are previously converted in Photoshop)


Are the ICC profiles simply for soft proofing and if so does this mean that results sent from the RGB ( or Greyscale ) work space through the QTR rip using the ink level curve are identical to a virtual colour conversion to the ICC profile (created using the quid curve) ?


Thanks for any clarification you can provide me


Eugene



Re: QIDF versus ICC

2016-07-27 by richard@...

I think Paul might have confused this for you even more by mentioning his ink sets and the epson driver and ICC profiles.

To answer your first question about qidf/profiles/curves: Think of QTR curves as very accurate media settings for the exact paper and ink and printer used to make them. You can then make an ICC profile using those media settings for soft proofing in Photoshop (which is not as helpful as you think it might be). Printing with color management and QTR is easier through OS X either through Photoshop or PrintTool, but isn't really advised, at least not my me personally. It is a little more complicated with the QTRgui in that you need to convert the file to the ICC profile in Photoshop, then save and print through the QTRgui.

About the need to print with ICC profiles and application managed color matching: In many cases printing with color management will block the shadows up too severely, and I tend to like the linear tonal distribution on gloss papers. But, I do need to introduce a little shadow compression with matte papers so I use a combination of the color picker/info pallet and a printed step wedge to create a final printing adjustment curve on an image by image basis. That is similar to what Paul does with his QTR to GG2.2 curve, but I customize mine to each image based on the actual printed step wedge and the K% values in the file.


Hope that helps,
Richard Boutwell

http://www.richardboutwell.com/

Re: QIDF versus ICC

2016-07-27 by richard@...

I just reread the part where you would you could do all this on a Mac instead of Windows. I know Paul likes the QTRgui, but once you get used to entering the inputs into a text file you will wonder why you ever used the windows version. The biggest advantage is being able to use PrintTool on OS X/macOS.

RB

RE: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-27 by Le Mois de la Photo à Uqbar

Thank you for your help, I’m starting to feel like I’m on familiar ground.  I think I will install QTR on my MAC and see if it doesn’t help clear up the questions I have.





I’d like to pick up on a term both of you are using « adjustment curve ».  I’m still a little confused about distinguishing ink level adjustments from target adjustments,  both « image to image » as Richard says , and systemic, ( that can be applied blindly to all images being sent from the same work space).





In my targeting process the objective of systemic curves is, firstly, mapping the black point to maximum shadow (I don’t usually use perceptual rendering) and secondly, linearization, that is,  trying to realign the L* values  on a shorter axis. The objective of image to image targeting curves is to de-linearize the reproduction curve where certain shapes and contours of the image have been disadvantaged by a uniform compression.





Is it possible that the QTR workflow attempts to combine what I am calling systemic target adjustments with media curves?


 



Also, given what Richard said about colour managed work flows blocking up the shadows, which would be the fault of the perceptual rendering table, (the recommended rendering intent with QTR profiles).  It sounds like the QIDF is not vulnerable to this problem, at least not when used in a « same as source » work flow that avoids colour management. I’m still unclear as to how an ICC workflow with a colorimetric conversion using perceptual rendering (which, AFAIK cannot be neutral, it must remap black and compress all grey values even if there is no black in the file.)  can produce the same results as a « same as source » work flow even if that curve was used in the production of the ICC profile.





How does it escape the perceptual rendering table moving tones around after they have been perfectly aligned?





Eugene








De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com]
Envoyé : July-27-16 1:31 PM
À : QuadtoneRIP@yahoogroups.com
Objet : [QuadtoneRIP] Re: QIDF versus ICC









I just reread the part where you would you could do all this on a Mac instead of Windows. I know Paul likes the QTRgui, but once you get used to entering the inputs into a text file you will wonder why you ever used the windows version. The biggest advantage is being able to use PrintTool on OS X/macOS.





RB

RE: [QuadtoneRIP] QIDF versus ICC

2016-07-27 by Le Mois de la Photo à Uqbar

Oh and I forgot to ask , Paul could you explain  how I can import a curve into my Epson printer driver   I have a P800.





Thanks





Eugene











De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com]
Envoyé : July-27-16 12:19 PM
À : QTR-Forum
Objet : Re: [QuadtoneRIP] QIDF versus ICC








I'm not going to attempt to answer all the questions, but just thought a few notes might be helpful.





I work in Windows and find the GUI for the Curve Creator (as well as main QTR interface) to be a great asset.





Among other workflows, I make image adjustment curves in Photoshop that, through the Epson driver, can control my inksets.  However, I prefer to embed these curves in an ICC.  I do that with QTR's Create ICC-RGB.  Then I simply print from PS, through the Epson driver, pull up the ICC, and I have a "color managed" workflow.  In this case "color managed" means that the Lab L values -- the gray ramp -- are printed such that they should what you see on a properly profiled monitor. The ICC workflow is easy and fast.  (Be aware that most monitors are not very well profiled, however.  You may need to attend to that also to get a good match.)





Usually I print through QTR, which acts as a stand-alone driver in Windows.  To make a QTR profile, I use curves that are very much like the Photoshop curves, except I have much better control.  QTR in Windows is not a "color managed" workflow that reads the file's workspace and prints to match it.  For my work (and I post all the curves and profiles) I use a Photoghop curve to make the adjustment between my file's Gray Gamma 2.2 and QTR's straight line Lab L response curve ("characteristic curve" for the old film guys).





So, from my perspective, "profiles" for printing have curves within them.  We often use the terms generically to refer to the software that controls the printer and how the inks are laid down.





It's a long learning curve but worth it.





FWIW





Paul


www.PaulRoark.com





On Wed, Jul 27, 2016 at 7:34 AM, info@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:





Hi I’m new to this,  I’ve done my home work but I’m confused about somethings.





 I’m using a PC but I also have a MAC and could switch to it if the fact that I’m using a PC is contributing to my confusion.  In some of the on line literature, as well as here in this forum  it appears as though the qidf curves are being referred to as profiles.  My intuition tells me that these curves are more like media type settings since they control ink levels. The profile would be the ICC profile being created using the Eye one and the Create ICC RGB droplet.  If my intuition is correct than the curves (media types) and profiles should be working in tandem.  Yet I have never encountered, in the any of the manuals or tutorials an indication that the curves are used in conjunction with the profile. In fact on a PC it is not clear how one might use the QTR rip with the ICC profile (unless of course the files are previously converted in Photoshop)





Are the ICC profiles simply for soft proofing  and if so does this mean that results sent from the RGB ( or Greyscale ) work space  through the QTR rip using the ink level curve are identical to a virtual colour conversion to the ICC profile (created using the quid curve) ?





Thanks for any clarification you can provide me





Eugene

Re: [QuadtoneRIP] QIDF versus ICC

2016-07-27 by Paul Roark

The issues seem to be multiplying here. So, again, let me just give my perspective on a couple of points.

First, I like to keep my files in Gray Gamma 2.2. It's, in effect, a subset of Adobe RGB, which is what I shoot in. The fewer transformations, the better. I think it's the best standard there is.

I used to think the compressed shadow valued of Gray Gamma 2.2 were a waste of our (then 8 bit) grayscales. I no longer think that. The compressed shadows make the print much more tolerant of major lighting differences. In particular, with my glossy gallery brochures, they look good inside as well as outside. Inside the 95% and 100% look the same -- totally black. However, when I take a brochure outside into the sun, I can "see into" that 95 - 100% compressed area.

So, for me, the compressed shadows make sense and work.

Second, regarding image adjustment curves, these are Photoshop curves. I use these all the time as part of my basic working-up of an image. I usually do not use them directly for printing, but they can be. At least with my inksets I can have a warm and a cool area within the same image via selecting different areas and applying different curves. This is a trick ICCs, ABW, and QTR cannot do. See for example http://www.paulroark.com/Whalers.html .

Usually, however, I use these curves to make an ICC that controls the print tone. The ICC is pulled into the Photoshop Print screen, not the Epson driver.

As to the Epson driver, I virtually always have that on "no color adjustment." (I think this is something Mac no longer allows, but I'm Windows, probably more due to history -- former day job necessity, etc. -- than anything else.) The Epson driver has to be set to the paper type (sets the ink limit, among other things), quality, etc. that was used when I made the ICC.

Paul

Re: QIDF versus ICC

2016-07-28 by brian_downunda@...

Quite a lot has been written in response, some of it quite advanced, and I don't want to add too much more. I have a lot of sympathy for the views in Eugene's initial post. When people coming to QTR read of QTR curves being referred to as profiles they get understandably confused, a point I've made before. That said, you seem to have a good understanding. I agree with you and Richard that the media type setting in the Epson driver seems to be the closest analogy, except that you can't add new ones or adjust the existing ones as you can in QTR.

The issue of whether to use an ICC - produced by the Create ICC (RGB) droplet - just for soft-proofing or to convert to it for printing has been a vexed issue. In my view, a lot of it has to do with what style of print you want and perhaps what sort of images you print. Clearly Richard and I and in a different camp to Paul.

There was a heated debate with Jon Cone some (seven) years ago on another Yahoo forum. Partly in light of that exchange, I wrote a post outlining some of the issues for new users, esp those coming from a colour workflow:
http://www.cyberhalides.com/piezography-printing/the-piezography-heretic-to-convert-or-not-to-convert/


I don't pretend that this is a sophisticated analysis, since it's aimed at new users with less technical knowledge that you seem to have, but you may find it helpful all the same. It was written in the context of Piezography, but it applies to any B&W inkset including OEM-K3. Bear in mind that it's also a little tongue-in-cheek.


I know that Richard loves his Macs, but both OS X and Windows have their advantages and disadvantages. They both work. Use what you know are are most comfortable. Print Tool is a great program, but QTRGui is quite useable, esp the curve creator. In either case, you can't print direct from PS anymore, so I don't see a huge difference in the workflows, and I have tried the OS X one. I may have switched to OS X some years ago for printing, but the combined antics of Apple and Adobe to break things, accidentally or intentionally, removed most of the potential advantages for me.


---In QuadtoneRIP@yahoogroups.com, <info@...> wrote :

My intuition tells me that these curves are more like media type settings since they control ink levels. The profile would be the ICC profile being created using the Eye one and the Create ICC RGB droplet. If my intuition is correct than the curves (media types) and profiles should be working in tandem.

Re: QIDF versus ICC

2016-07-28 by info@...

Ok thank you, it’s clear. Now I understand how people are soft proofing with a profile they’re not using to print.

Cheers

Re: QIDF versus ICC

2016-07-28 by info@...

Ok thank you, that’s makes it clear. Now I understand how people are soft proofing with profiles they’re not printing through.

I’ll have a go at these ink level curves and post any question as I go along, as I see others are doing.

Thanks for your help

Eugene


RE: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-28 by Le Mois de la Photo à Uqbar

Ok thank you explanations and references, that makes it clear. Now I understand how people are soft proofing with profiles they’re not printing through.





Sorry if this message is a repeat I seem to be having trouble posting.





Eugene











De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com]
Envoyé : July-27-16 8:38 PM
À : QuadtoneRIP@yahoogroups.com
Objet : [QuadtoneRIP] Re: QIDF versus ICC








Quite a lot has been written in response, some of it quite advanced, and I don't want to add too much more.  I have a lot of sympathy for the views in Eugene's initial post.  When people coming to QTR read of QTR curves being referred to as profiles they get understandably confused, a point I've made before.  That said, you seem to have a good understanding.  I agree with you and Richard that the media type setting in the Epson driver seems to be the closest analogy, except that you can't add new ones or adjust the existing ones as you can in QTR.


The issue of whether to use an ICC - produced by the Create ICC (RGB) droplet - just for soft-proofing or to convert to it for printing has been a vexed issue.  In my view, a lot of it has to do with what style of print you want and perhaps what sort of images you print.  Clearly Richard and I and in a different camp to Paul.


There was a heated debate with Jon Cone some (seven) years ago on another Yahoo forum.  Partly in light of that exchange, I wrote a post outlining some of the issues for new users, esp those coming from a colour workflow:
http://www.cyberhalides.com/piezography-printing/the-piezography-heretic-to-convert-or-not-to-convert/





I don't pretend that this is a sophisticated analysis, since it's aimed at new users with less technical knowledge that you seem to have, but you may find it helpful all the same.  It was written in the context of Piezography, but it applies to any B&W inkset including OEM-K3.  Bear in mind that it's also a little tongue-in-cheek.




I know that Richard loves his Macs, but both OS X and Windows have their advantages and disadvantages.  They both work.  Use what you know are are most comfortable.  Print Tool is a great program, but QTRGui is quite useable, esp the curve creator.  In either case, you can't print direct from PS anymore, so I don't see a huge difference in the workflows, and I have tried the OS X one.  I may have switched to OS X some years ago for printing, but the combined antics of Apple and Adobe to break things, accidentally or intentionally, removed most of the potential advantages for me.






---In QuadtoneRIP@yahoogroups.com, <info@...> wrote :


My intuition tells me that these curves are more like media type settings since they control ink levels. The profile would be the ICC profile being created using the Eye one and the Create ICC RGB droplet.  If my intuition is correct than the curves (media types) and profiles should be working in tandem.

Re: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-29 by Roy Harrington

I was curious about the various workflows to get what you want on the paper.

Here's where I am: I'm on a Mac so the ICC approach is very convenient. So this is
what I use all the time these days. I mostly do photo paper these days but did the
same thing with matte for a long time.

With matte papers the dMax is relatively weak so its always been an issue of how to
map an image (on screen) with wider Dynamic Range (DR) onto a paper with smaller DR.
The matte paper loss of DR is almost entirely on the dark end so this is where the
mapping is most notable and potentially controversial. Anyway you slice it you
have to lose DR somewhere -- all over or more some places. The QTR linearization
from early days has always been a straightforward straight-line or basically DR loss is
spread out across the whole range. With this approach a DR of L=96 to L=16 has
a midpoint of L=56 which a fair bit lighter than a middle gray of L=50. (in actuality
it is even more complicated because editing spaces are all different so middle will
have lots of different values). But the bottom line is that most people noticed that
their prints were almost always lighter and weaker than they expected. (if you were
from the darkroom days you were used to just editing till you got what you wanted).

But the beauty of digital photography is reducing the trial and fix cycles. Screen to
print matching to me seems like the ultimate goal. Its never going to be perfect,
first a light emitting screen is never identical to a reflecting piece of paper, and
second a smaller DR paper will never be as contrasty as a high DR screen. You will
always need to use your experience to "see" what you will get and will need a minimum
trial/fix cycle. So lets do the best we can.

I think the workflows fall into two categories -- dumb down the screen somehow
so you edit in the reduced DR that matches the paper, or -- do a correction curve
at print time that gives the best you can do mapping (i.e. something you can
easily learn to pre-visualize). I prefer the later since the former ties the image
file to the specific paper -- what happens when you want a different paper?

The ICC folks have done lots of this with color so I figured it ought to apply to
grayscale too -- actually lots simpler because it's one dimension instead of three.
Learning how it all worked (for gray at least) was a bear because everyone just
treats it like a mysterious black box that no one needs to know how it works.
All-in-all for grayscale it's all just curves that maps input values to output values
according to math calculations. I got all this to work on Macs but its a bit more
cumbersome on PCs.

So given that the PC workflow w/ICC is a bit more awkward there have been a number
of workflows to accomplish something similar.

I've know Paul Roark for a long time and he's certainly someone who knows
what he is doing. He's got a Photoshop curves (.acv file) that he just puts on a
layer above everything else. Turn it on for printing and off for editing. In a sense
it works very much like a printing ICC profile -- just applied for printing.
So I decided to compare his .acv method to my ICC method. With Photoshop
this turns out to be very easy. Just take a 21step file assigned to GG 2.2. We're
going to see that actual data values would be sent to QTR driver with the 2 methods.
So for Paul's I just apply the .acv and flatten the image, for mine/ICC I just do a
Convert to Profile with my generic Gray-Matte-Paper. These give files that
would go to QTR without any more changes. I just used Photoshop to calculate
the difference function for these. Even to my surprise they are just about identical.
The maximum difference was just 2 (8-bit values) or less that 1%, the average
difference was less than 1/2 a bit-value or less that 0.2% -- amazing.
Paul -- how did you make this .acv ?? Just by eye?
I think this gives a lot more credence to the simple mathematic correction curves.

I also read Brian's paper quite a few times to get it all (maybe). I can't so far
think of an as easy test as Paul's but it does seem to depend on the standard
ICC methodology so I'm inclined to think it'll yield similar results. But I think
it's more of an edit-in-the reduced-DR workflow.
BTW, Brian had a link to an earlier discussion that had more info -- thanks Brian:

Another comment I have: both Paul's .acv and Brian's second graph show
fairly pronounced flattening/compression of shadow area. What I think is not
obvious is that there are two components to this. There's the compression due
to a weak dMax -- i.e. the basis of most of this whole discussion, but also there's
the Gamma 2.2 curve of the source file. Both of these corrections are trying
to mimic the L-values of the G2.2 curve NOT the K-values that are being
graphed. So the severe compression of shadows in G2.2 are also being
shown in these curves.

Roy

-- a little aside to those feeling like the regular ICC workflow with Gray-Matte-Paper
is a bit strong in its compression of shadows. There generic ICCs are super
simple, you can easily make your own with different parameters.
The input for Matte-Paper is simply two L-values-- 96 16
Those were chosen as typical matte dMin and dMax. If you'd like a weaker
correction just use 96 12 say. All you need in a .txt file is those 2 numbers
and Create-ICC will create a new generic ICC for you. Try pairs till you like it.

Roy

Show quoted textHide quoted text
On Wed, Jul 27, 2016 at 5:38 PM, brian_downunda@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:


Quite a lot has been written in response, some of it quite advanced, and I don't want to add too much more. I have a lot of sympathy for the views in Eugene's initial post. When people coming to QTR read of QTR curves being referred to as profiles they get understandably confused, a point I've made before. That said, you seem to have a good understanding. I agree with you and Richard that the media type setting in the Epson driver seems to be the closest analogy, except that you can't add new ones or adjust the existing ones as you can in QTR.

The issue of whether to use an ICC - produced by the Create ICC (RGB) droplet - just for soft-proofing or to convert to it for printing has been a vexed issue. In my view, a lot of it has to do with what style of print you want and perhaps what sort of images you print. Clearly Richard and I and in a different camp to Paul.

There was a heated debate with Jon Cone some (seven) years ago on another Yahoo forum. Partly in light of that exchange, I wrote a post outlining some of the issues for new users, esp those coming from a colour workflow:
http://www.cyberhalides.com/piezography-printing/the-piezography-heretic-to-convert-or-not-to-convert/


I don't pretend that this is a sophisticated analysis, since it's aimed at new users with less technical knowledge that you seem to have, but you may find it helpful all the same. It was written in the context of Piezography, but it applies to any B&W inkset including OEM-K3. Bear in mind that it's also a little tongue-in-cheek.


I know that Richard loves his Macs, but both OS X and Windows have their advantages and disadvantages. They both work. Use what you know are are most comfortable. Print Tool is a great program, but QTRGui is quite useable, esp the curve creator. In either case, you can't print direct from PS anymore, so I don't see a huge difference in the workflows, and I have tried the OS X one. I may have switched to OS X some years ago for printing, but the combined antics of Apple and Adobe to break things, accidentally or intentionally, removed most of the potential advantages for me.


---In QuadtoneRIP@yahoogroups.com, wrote :

My intuition tells me that these curves are more like media type settings since they control ink levels. The profile would be the ICC profile being created using the Eye one and the Create ICC RGB droplet. If my intuition is correct than the curves (media types) and profiles should be working in tandem.





--

RE: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-29 by Le Mois de la Photo à Uqbar

I am coming at QTR from an ICC world. I started, I think as most of us did coming out of the darkroom in the 90’s in a « same as source » environment, and I swore by it. Dark rooms were like Spitfires they only had one seat. I was looking for the kind of direct and absolute control that I got with MY kodak thermometer and MY Saunders timer, etc.  I established a perfect working relationship with my printer and my paper by sending raw control signals and charting the results. Most people moved to colour management when, for any reason, they had to work with other human beings or other media, or simply got tired of rebuilding their universes every time they changed printers.  But I moved to colour management to obtain a greater control over translating data to ink.  For me colour management is digital sensitometry.  My understanding of the ICC workflow is that the only possible explanation for prints that are lighter or darker or greener or in any way producing an unexpected result is if perceptual rendering is being used.





Because the perceptual table does not lock ingamut colours (including grey values) as relative does things can move around. But using relative rendering automatically assumes that the out of gamut values  are being manually targeted, which for me means there is no ICC without ACV.


So making target adjustments and using the perceptual table would be like driving a car inside a car. In fact if the black ink level were manually targeted and then perceptual rendering used, the absence of any L*0 value would not prevent the perceptual table from compressing the curve anyway because it’s just a blind look up table, each time and time after time L*X gets mapped to L*Y.  That’s why when I use the QTR profile I do not remap black instead I make a slight « linearisation curve » that pulls values out of whatever plateau the perceptual table creates that disadvantages the particular image I’m targeting.





So , for my money it sounds like ICC workflow is being confused with perceptual rendering table. For some reason I won’t go into it here (I posted about this a short while ago) the QTR relative table does seem to lock the ingamut values in place, making target adjustments difficult.





However, this is how I explain to my students why QTR uses a perceptual table. You have to understand that when we get to QTR they have come through a an ICC workflow that allows them absolute control over every tone in their image which they can isolate and place where ever they want. They are used to marking the deepest edge of shadow detail emerging out of black with sample points then placing it at on the print at  the very edge of perception. So you can see how they scratch their heads a bit when I say we’ll be using the perceptual rendering intent.  This is what I tell them, « The perceptual table when made by an ICC technician who works for a company whose criteria is most likely best possible results for consumers who probably don’t know that much about what they’re doing is like the automatic mode on your camera. But a perceptual table made by a photographer who was most likely a master printer and also by the grace of god understands computer programming would be like having Emmet Gowin print your negative ».





But it would be nice if the relative table was more stable. Ideally, and this is why I have decided to learn to make the QIDF curves. QTR would allow us to make media type settings for papers that Epson doesn’t make and not have to use Premium Luster for Museo Rag or Enhanced Matte for Entrada. Then we could make an ICC profile and if the relative table locked ingamut lightnesses, target adjust our images to perfection.





Eugene











De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com]
Envoyé : July-28-16 11:15 PM
À : QuadtoneRIP@yahoogroups.com

Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC








I was curious about the various workflows to get what you want on the paper.





Here's where I am:  I'm on a Mac so the ICC approach is very convenient.  So this is


what I use all the time these days. I mostly do photo paper these days but did the


same thing with matte for a long time.





With matte papers the dMax is relatively weak so its always been an issue of how to


map an image (on screen) with wider Dynamic Range (DR) onto a paper with smaller DR.


The matte paper loss of DR is almost entirely on the dark end so this is where the


mapping is most notable and potentially controversial.  Anyway you slice it you


have to lose DR somewhere -- all over or more some places.  The QTR linearization


from early days has always been a straightforward straight-line or basically DR loss is


spread out across the whole range.  With this approach a DR of L=96 to L=16 has


a midpoint of L=56 which a fair bit lighter than a middle gray of L=50.  (in actuality


it is even more complicated because editing spaces are all different so middle will


have lots of different values).  But the bottom line is that most people noticed that


their prints were almost always lighter and weaker than they expected.  (if you were


from the darkroom days you were used to just editing till you got what you wanted).





But the beauty of digital photography is reducing the trial and fix cycles.  Screen to


print matching to me seems like the ultimate goal.  Its never going to be perfect,


first a light emitting screen is never identical to a reflecting piece of paper, and


second a smaller DR paper will never be as contrasty as a high DR screen.  You will


always need to use your experience to "see" what you will get and will need a minimum


trial/fix cycle.  So lets do the best we can.





I think the workflows fall into two categories -- dumb down the screen somehow


so you edit in the reduced DR that matches the paper, or --  do a correction curve


at print time that gives the best you can do mapping (i.e. something you can


easily learn to pre-visualize).   I prefer the later since the former ties the image


file to the specific paper -- what happens when you want a different paper?





The ICC folks have done lots of this with color so I figured it ought to apply to


grayscale too -- actually lots simpler because it's one dimension instead of three.


Learning how it all worked (for gray at least) was a bear because everyone just


treats it like a mysterious black box that no one needs to know how it works.


All-in-all for grayscale it's all just curves that maps input values to output values


according to math calculations.  I got all this to work on Macs but its a bit more


cumbersome on PCs.





So given that the PC workflow w/ICC is a bit more awkward there have been a number


of workflows to accomplish something similar.


 



I've know Paul Roark for a long time and he's certainly someone who knows


what he is doing. He's got a Photoshop curves (.acv file) that he just puts on a


layer above everything else.  Turn it on for printing and off for editing.  In a sense


it works very much like a printing ICC profile -- just applied for printing.


So I decided to compare his .acv method to my ICC method.  With Photoshop


this turns out to be very easy.  Just take a 21step file assigned to GG 2.2.   We're


going to see that actual data values would be sent to QTR driver with the 2 methods.


So for Paul's I just apply the .acv and flatten the image, for mine/ICC I just do a


Convert to Profile with my generic Gray-Matte-Paper.  These give files that


would go to QTR without any more changes.  I just used Photoshop to calculate


the difference function for these.  Even to my surprise they are just about identical.



The maximum difference was just 2 (8-bit values) or less that 1%, the average


difference was less than 1/2 a bit-value or less that 0.2%  -- amazing.


Paul -- how did you make this .acv ?? Just by eye?


I think this gives a lot more credence to the simple mathematic correction curves.





I also read Brian's paper quite a few times to get it all (maybe).  I can't so far


think of an as easy test as Paul's but it does seem to depend on the standard


ICC methodology so I'm inclined to think it'll yield similar results.  But I think


it's more of an edit-in-the reduced-DR workflow.


BTW, Brian had a link to an earlier discussion that had more info -- thanks Brian:


https://groups.yahoo.com/neo/groups/QuadtoneRIP/conversations/messages/12538





Another comment I have:  both Paul's .acv and Brian's second graph show


fairly pronounced flattening/compression of shadow area.  What I think is not


obvious is that there are two components to this.  There's the compression due


to a weak dMax -- i.e. the basis of most of this whole discussion, but also there's


 the Gamma 2.2 curve of the source file.  Both of these corrections are trying


to mimic the L-values of the G2.2 curve NOT the K-values that are being


graphed.  So the severe compression of shadows in G2.2 are also being


shown in these curves.





Roy





-- a little aside to those feeling like the regular ICC workflow with Gray-Matte-Paper


is a bit strong in its compression of shadows.  There generic ICCs are super


simple, you can easily make your own with different parameters.


The input for Matte-Paper is simply two L-values--   96 16


Those were chosen as typical matte dMin and dMax.   If you'd like a weaker


correction just use 96 12 say.  All you need in a .txt file is those 2 numbers


and Create-ICC will create a new generic ICC for you.  Try pairs till you like it.





Roy








On Wed, Jul 27, 2016 at 5:38 PM, brian_downunda@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:






Quite a lot has been written in response, some of it quite advanced, and I don't want to add too much more.  I have a lot of sympathy for the views in Eugene's initial post.  When people coming to QTR read of QTR curves being referred to as profiles they get understandably confused, a point I've made before.  That said, you seem to have a good understanding.  I agree with you and Richard that the media type setting in the Epson driver seems to be the closest analogy, except that you can't add new ones or adjust the existing ones as you can in QTR.


The issue of whether to use an ICC - produced by the Create ICC (RGB) droplet - just for soft-proofing or to convert to it for printing has been a vexed issue.  In my view, a lot of it has to do with what style of print you want and perhaps what sort of images you print.  Clearly Richard and I and in a different camp to Paul.


There was a heated debate with Jon Cone some (seven) years ago on another Yahoo forum.  Partly in light of that exchange, I wrote a post outlining some of the issues for new users, esp those coming from a colour workflow:
http://www.cyberhalides.com/piezography-printing/the-piezography-heretic-to-convert-or-not-to-convert/





I don't pretend that this is a sophisticated analysis, since it's aimed at new users with less technical knowledge that you seem to have, but you may find it helpful all the same.  It was written in the context of Piezography, but it applies to any B&W inkset including OEM-K3.  Bear in mind that it's also a little tongue-in-cheek.




I know that Richard loves his Macs, but both OS X and Windows have their advantages and disadvantages.  They both work.  Use what you know are are most comfortable.  Print Tool is a great program, but QTRGui is quite useable, esp the curve creator.  In either case, you can't print direct from PS anymore, so I don't see a huge difference in the workflows, and I have tried the OS X one.  I may have switched to OS X some years ago for printing, but the combined antics of Apple and Adobe to break things, accidentally or intentionally, removed most of the potential advantages for me.






---In QuadtoneRIP@yahoogroups.com, <info@...> wrote :


My intuition tells me that these curves are more like media type settings since they control ink levels. The profile would be the ICC profile being created using the Eye one and the Create ICC RGB droplet.  If my intuition is correct than the curves (media types) and profiles should be working in tandem.


 














--


Roy Harrington
roy@...
www.harrington.com

Re: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-29 by Roy Harrington

Eugene,

I'm not sure what to make of your comments. QTR is really simple in concept.
All it does is let you control exactly how much ink goes on the paper for each
of the gray pixel values. It just goes from no ink (paper white) to some
controlable max amount of ink (dMax). There are no perceptual tables in
QTR, no intents, no ICC anything. White dMin maps to paper, black dMax maps
to max level. Everything in between can be mapped how you like.

ICC support was added on top, separately to help control the mapping curves
between white and black. White mapping is built into ICC standard, black
mapping concept was added by Adobe in Black Point Compensation.
The intent tables for QTR ICCs were made to match those standards.
Maybe you can make use of this but it's certainly not something you have to use.
What you see on a screen always goes through a color management stage,
so I prefer using the same idea on the print but it is not at all mandatory.

Hope the QTR curves give you whatever control you need and want. YMMV.
Roy





Show quoted textHide quoted text
On Fri, Jul 29, 2016 at 7:20 AM, Le Mois de la Photo à Uqbar info@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:


I am coming at QTR from an ICC world. I started, I think as most of us did coming out of the darkroom in the 90’s in a « same as source » environment, and I swore by it. Dark rooms were like Spitfires they only had one seat. I was looking for the kind of direct and absolute control that I got with MY kodak thermometer and MY Saunders timer, etc. I established a perfect working relationship with my printer and my paper by sending raw control signals and charting the results. Most people moved to colour management when, for any reason, they had to work with other human beings or other media, or simply got tired of rebuilding their universes every time they changed printers. But I moved to colour management to obtain a greater control over translating data to ink. For me colour management is digital sensitometry. My understanding of the ICC workflow is that the only possible explanation for prints that are lighter or darker or greener or in any way producing an unexpected result is if perceptual rendering is being used.

Because the perceptual table does not lock ingamut colours (including grey values) as relative does things can move around. But using relative rendering automatically assumes that the out of gamut values are being manually targeted, which for me means there is no ICC without ACV.

So making target adjustments and using the perceptual table would be like driving a car inside a car. In fact if the black ink level were manually targeted and then perceptual rendering used, the absence of any L*0 value would not prevent the perceptual table from compressing the curve anyway because it’s just a blind look up table, each time and time after time L*X gets mapped to L*Y. That’s why when I use the QTR profile I do not remap black instead I make a slight « linearisation curve » that pulls values out of whatever plateau the perceptual table creates that disadvantages the particular image I’m targeting.

So , for my money it sounds like ICC workflow is being confused with perceptual rendering table. For some reason I won’t go into it here (I posted about this a short while ago) the QTR relative table does seem to lock the ingamut values in place, making target adjustments difficult.

However, this is how I explain to my students why QTR uses a perceptual table. You have to understand that when we get to QTR they have come through a an ICC workflow that allows them absolute control over every tone in their image which they can isolate and place where ever they want. They are used to marking the deepest edge of shadow detail emerging out of black with sample points then placing it at on the print at the very edge of perception. So you can see how they scratch their heads a bit when I say we’ll be using the perceptual rendering intent. This is what I tell them, « The perceptual table when made by an ICC technician who works for a company whose criteria is most likely best possible results for consumers who probably don’t know that much about what they’re doing is like the automatic mode on your camera. But a perceptual table made by a photographer who was most likely a master printer and also by the grace of god understands computer programming would be like having Emmet Gowin print your negative ».

But it would be nice if the relative table was more stable. Ideally, and this is why I have decided to learn to make the QIDF curves. QTR would allow us to make media type settings for papers that Epson doesn’t make and not have to use Premium Luster for Museo Rag or Enhanced Matte for Entrada. Then we could make an ICC profile and if the relative table locked ingamut lightnesses, target adjust our images to perfection.

Eugene

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com]
Envoyé : July-28-16 11:15 PM
À : QuadtoneRIP@yahoogroups.com
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC

I was curious about the various workflows to get what you want on the paper.

Here's where I am: I'm on a Mac so the ICC approach is very convenient. So this is

what I use all the time these days. I mostly do photo paper these days but did the

same thing with matte for a long time.

With matte papers the dMax is relatively weak so its always been an issue of how to

map an image (on screen) with wider Dynamic Range (DR) onto a paper with smaller DR.

The matte paper loss of DR is almost entirely on the dark end so this is where the

mapping is most notable and potentially controversial. Anyway you slice it you

have to lose DR somewhere -- all over or more some places. The QTR linearization

from early days has always been a straightforward straight-line or basically DR loss is

spread out across the whole range. With this approach a DR of L=96 to L=16 has

a midpoint of L=56 which a fair bit lighter than a middle gray of L=50. (in actuality

it is even more complicated because editing spaces are all different so middle will

have lots of different values). But the bottom line is that most people noticed that

their prints were almost always lighter and weaker than they expected. (if you were

from the darkroom days you were used to just editing till you got what you wanted).

But the beauty of digital photography is reducing the trial and fix cycles. Screen to

print matching to me seems like the ultimate goal. Its never going to be perfect,

first a light emitting screen is never identical to a reflecting piece of paper, and

second a smaller DR paper will never be as contrasty as a high DR screen. You will

always need to use your experience to "see" what you will get and will need a minimum

trial/fix cycle. So lets do the best we can.

I think the workflows fall into two categories -- dumb down the screen somehow

so you edit in the reduced DR that matches the paper, or -- do a correction curve

at print time that gives the best you can do mapping (i.e. something you can

easily learn to pre-visualize). I prefer the later since the former ties the image

file to the specific paper -- what happens when you want a different paper?

The ICC folks have done lots of this with color so I figured it ought to apply to

grayscale too -- actually lots simpler because it's one dimension instead of three.

Learning how it all worked (for gray at least) was a bear because everyone just

treats it like a mysterious black box that no one needs to know how it works.

All-in-all for grayscale it's all just curves that maps input values to output values

according to math calculations. I got all this to work on Macs but its a bit more

cumbersome on PCs.

So given that the PC workflow w/ICC is a bit more awkward there have been a number

of workflows to accomplish something similar.

I've know Paul Roark for a long time and he';s certainly someone who knows

what he is doing. He's got a Photoshop curves (.acv file) that he just puts on a

layer above everything else. Turn it on for printing and off for editing. In a sense

it works very much like a printing ICC profile -- just applied for printing.

So I decided to compare his .acv method to my ICC method. With Photoshop

this turns out to be very easy. Just take a 21step file assigned to GG 2.2. We're

going to see that actual data values would be sent to QTR driver with the 2 methods.

So for Paul's I just apply the .acv and flatten the image, for mine/ICC I just do a

Convert to Profile with my generic Gray-Matte-Paper. These give files that

would go to QTR without any more changes. I just used Photoshop to calculate

the difference function for these. Even to my surprise they are just about identical.

The maximum difference was just 2 (8-bit values) or less that 1%, the average

difference was less than 1/2 a bit-value or less that 0.2% -- amazing.

Paul -- how did you make this .acv ?? Just by eye?

I think this gives a lot more credence to the simple mathematic correction curves.

I also read Brian's paper quite a few times to get it all (maybe). I can't so far

think of an as easy test as Paul's but it does seem to depend on the standard

ICC methodology so I'm inclined to think it'll yield similar results. But I think

it's more of an edit-in-the reduced-DR workflow.

BTW, Brian had a link to an earlier discussion that had more info -- thanks Brian:

Another comment I have: both Paul's .acv and Brian's second graph show

fairly pronounced flattening/compression of shadow area. What I think is not

obvious is that there are two components to this. There's the compression due

to a weak dMax -- i.e. the basis of most of this whole discussion, but also there's

the Gamma 2.2 curve of the source file. Both of these corrections are trying

to mimic the L-values of the G2.2 curve NOT the K-values that are being

graphed. So the severe compression of shadows in G2.2 are also being

shown in these curves.

Roy

-- a little aside to those feeling like the regular ICC workflow with Gray-Matte-Paper

is a bit strong in its compression of shadows. There generic ICCs are super

simple, you can easily make your own with different parameters.

The input for Matte-Paper is simply two L-values-- 96 16

Those were chosen as typical matte dMin and dMax. If you'd like a weaker

correction just use 96 12 say. All you need in a .txt file is those 2 numbers

and Create-ICC will create a new generic ICC for you. Try pairs till you like it.

Roy

On Wed, Jul 27, 2016 at 5:38 PM, brian_downunda@... [QuadtoneRIP] <QuadtoneRIP@...m> wrote:



Quite a lot has been written in response, some of it quite advanced, and I don't want to add too much more. I have a lot of sympathy for the views in Eugene's initial post. When people coming to QTR read of QTR curves being referred to as profiles they get understandably confused, a point I've made before. That said, you seem to have a good understanding. I agree with you and Richard that the media type setting in the Epson driver seems to be the closest analogy, except that you can't add new ones or adjust the existing ones as you can in QTR.

The issue of whether to use an ICC - produced by the Create ICC (RGB) droplet - just for soft-proofing or to convert to it for printing has been a vexed issue. In my view, a lot of it has to do with what style of print you want and perhaps what sort of images you print. Clearly Richard and I and in a different camp to Paul.

There was a heated debate with Jon Cone some (seven) years ago on another Yahoo forum. Partly in light of that exchange, I wrote a post outlining some of the issues for new users, esp those coming from a colour workflow:
http://www.cyberhalides.com/piezography-printing/the-piezography-heretic-to-convert-or-not-to-convert/

I don't pretend that this is a sophisticated analysis, since it's aimed at new users with less technical knowledge that you seem to have, but you may find it helpful all the same. It was written in the context of Piezography, but it applies to any B&W inkset including OEM-K3. Bear in mind that it's also a little tongue-in-cheek.


I know that Richard loves his Macs, but both OS X and Windows have their advantages and disadvantages. They both work. Use what you know are are most comfortable. Print Tool is a great program, but QTRGui is quite useable, esp the curve creator. In either case, you can't print direct from PS anymore, so I don't see a huge difference in the workflows, and I have tried the OS X one. I may have switched to OS X some years ago for printing, but the combined antics of Apple and Adobe to break things, accidentally or intentionally, removed most of the potential advantages for me.



---In QuadtoneRIP@yahoogroups.com, <info@...> wrote :

My intuition tells me that these curves are more like media type settings since they control ink levels. The profile would be the ICC profile being created using the Eye one and the Create ICC RGB droplet. If my intuition is correct than the curves (media types) and profiles should be working in tandem.



--






--

RE: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-29 by Le Mois de la Photo à Uqbar

Roy,

 

I think it is possible that I am part of a subset of QTR users who are using your software in a way that you did not intend. Some literature exists for this (see Amadou Diallo and I think Eric Chan). Quad Tone Rip is the only ICC grey profile-making software that I know of.   B&W photographers wanting to use only the ultrachrome grey inks in an ICC workflow are able to use QTR to generate ICC profiles; this process bypasses QTR gui completely, and by all means it is not a perfect system.

 

If you print and measure an L* chart via the Epson Advanced B&W Dark mode, on a surprising number of papers the response is as linear as one might expect, factoring in the compression that has to occur to compensate for differing black points. The ABW dark mode is used as a foundation upon which the profile is built. The 21x4 target is printed using ABW dark, measured and a profile is created with the create ICC droplet.  Later the profile is used to print through from Photoshop selecting “Photoshop manages colour” the QTR profile is selected, as well as the rendering intent and then in the Epson driver ABW dark is also selected. This is no longer possible on a MAC but the workaround is simple, the file is converted beforehand and colour management deactivated. 

 

It is clear that Epson ABW is NOT a colour management workflow. Yet for the same reason that, as he wrote in his article, Brian is able to soft-proof a file using an ICC profile that he does not intend to print through by checking “preserve the numbers”, a converted file (that is, converted to the control signals of the printer that produce real world densities) which is sent outside of colour management should produce exactly the same results. 

 

My comments about the relative table have to do with this use of the profile, which as you have indicated is not what it was conceived for.  According to Colorthink the QTR profiles have four tables (perceptual, relative, absolute and saturation) each displaying  a different graph. 

 

I am sorry if this is a bastardisation of your creation and you didn’t mean it to be used this way, but I am grateful for your software and happy to have the chance to thank you personally. 

 

I honestly believe your software is the only way to generate grey profiles. I would love to be corrected if I’m wrong

 

Eugene

 

 

 

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com] 
Envoyé : July-29-16 1:27 PM
À : QuadtoneRIP@yahoogroups.com
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC

 

  

Eugene,

 

I'm not sure what to make of your comments.  QTR is really simple in concept.

All it does is let you control exactly how much ink goes on the paper for each

of the gray pixel values.  It just goes from no ink (paper white) to some

controlable max amount of ink (dMax).  There are no perceptual tables in

QTR, no intents, no ICC anything.  White dMin maps to paper, black dMax maps

to max level. Everything in between can be mapped how you like.

 

ICC support was added on top, separately to help control the mapping curves

between white and black.  White mapping is built into ICC standard, black

mapping concept was added by Adobe in Black Point Compensation.

The intent tables for QTR ICCs were made to match those standards.

Maybe you can make use of this but it's certainly not something you have to use.

What you see on a screen always goes through a color management stage,

so I prefer using the same idea on the print but it is not at all mandatory.

 

Hope the QTR curves give you whatever control you need and want. YMMV.

Roy

 

 

 

 

 

 

On Fri, Jul 29, 2016 at 7:20 AM, Le Mois de la Photo à Uqbar info@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:

 

I am coming at QTR from an ICC world. I started, I think as most of us did coming out of the darkroom in the 90’s in a « same as source » environment, and I swore by it. Dark rooms were like Spitfires they only had one seat. I was looking for the kind of direct and absolute control that I got with MY kodak thermometer and MY Saunders timer, etc.  I established a perfect working relationship with my printer and my paper by sending raw control signals and charting the results. Most people moved to colour management when, for any reason, they had to work with other human beings or other media, or simply got tired of rebuilding their universes every time they changed printers.  But I moved to colour management to obtain a greater control over translating data to ink.  For me colour management is digital sensitometry.  My understanding of the ICC workflow is that the only possible explanation for prints that are lighter or darker or greener or in any way producing an unexpected result is if perceptual rendering is being used. 

 

Because the perceptual table does not lock ingamut colours (including grey values) as relative does things can move around. But using relative rendering automatically assumes that the out of gamut values  are being manually targeted, which for me means there is no ICC without ACV. 

So making target adjustments and using the perceptual table would be like driving a car inside a car. In fact if the black ink level were manually targeted and then perceptual rendering used, the absence of any L*0 value would not prevent the perceptual table from compressing the curve anyway because it’s just a blind look up table, each time and time after time L*X gets mapped to L*Y.  That’s why when I use the QTR profile I do not remap black instead I make a slight « linearisation curve » that pulls values out of whatever plateau the perceptual table creates that disadvantages the particular image I’m targeting. 

 

So , for my money it sounds like ICC workflow is being confused with perceptual rendering table. For some reason I won’t go into it here (I posted about this a short while ago) the QTR relative table does seem to lock the ingamut values in place, making target adjustments difficult.  

 

However, this is how I explain to my students why QTR uses a perceptual table. You have to understand that when we get to QTR they have come through a an ICC workflow that allows them absolute control over every tone in their image which they can isolate and place where ever they want. They are used to marking the deepest edge of shadow detail emerging out of black with sample points then placing it at on the print at  the very edge of perception. So you can see how they scratch their heads a bit when I say we’ll be using the perceptual rendering intent.  This is what I tell them, « The perceptual table when made by an ICC technician who works for a company whose criteria is most likely best possible results for consumers who probably don’t know that much about what they’re doing is like the automatic mode on your camera. But a perceptual table made by a photographer who was most likely a master printer and also by the grace of god understands computer programming would be like having Emmet Gowin print your negative ».

 

But it would be nice if the relative table was more stable. Ideally, and this is why I have decided to learn to make the QIDF curves. QTR would allow us to make media type settings for papers that Epson doesn’t make and not have to use Premium Luster for Museo Rag or Enhanced Matte for Entrada. Then we could make an ICC profile and if the relative table locked ingamut lightnesses, target adjust our images to perfection.

 

Eugene

 

 

 

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com] 
Envoyé : July-28-16 11:15 PM
À : QuadtoneRIP@yahoogroups.com
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC

 

  

I was curious about the various workflows to get what you want on the paper.

 

Here's where I am:  I'm on a Mac so the ICC approach is very convenient.  So this is 

what I use all the time these days. I mostly do photo paper these days but did the 

same thing with matte for a long time.

 

With matte papers the dMax is relatively weak so its always been an issue of how to

map an image (on screen) with wider Dynamic Range (DR) onto a paper with smaller DR.

The matte paper loss of DR is almost entirely on the dark end so this is where the

mapping is most notable and potentially controversial.  Anyway you slice it you

have to lose DR somewhere -- all over or more some places.  The QTR linearization

from early days has always been a straightforward straight-line or basically DR loss is

spread out across the whole range.  With this approach a DR of L=96 to L=16 has

a midpoint of L=56 which a fair bit lighter than a middle gray of L=50.  (in actuality

it is even more complicated because editing spaces are all different so middle will

have lots of different values).  But the bottom line is that most people noticed that

their prints were almost always lighter and weaker than they expected.  (if you were

from the darkroom days you were used to just editing till you got what you wanted).

 

But the beauty of digital photography is reducing the trial and fix cycles.  Screen to

print matching to me seems like the ultimate goal.  Its never going to be perfect,

first a light emitting screen is never identical to a reflecting piece of paper, and

second a smaller DR paper will never be as contrasty as a high DR screen.  You will

always need to use your experience to "see" what you will get and will need a minimum

trial/fix cycle.  So lets do the best we can.

 

I think the workflows fall into two categories -- dumb down the screen somehow

so you edit in the reduced DR that matches the paper, or --  do a correction curve

at print time that gives the best you can do mapping (i.e. something you can 

easily learn to pre-visualize).   I prefer the later since the former ties the image

file to the specific paper -- what happens when you want a different paper?

 

The ICC folks have done lots of this with color so I figured it ought to apply to

grayscale too -- actually lots simpler because it's one dimension instead of three.

Learning how it all worked (for gray at least) was a bear because everyone just

treats it like a mysterious black box that no one needs to know how it works.

All-in-all for grayscale it's all just curves that maps input values to output values

according to math calculations.  I got all this to work on Macs but its a bit more

cumbersome on PCs.

 

So given that the PC workflow w/ICC is a bit more awkward there have been a number

of workflows to accomplish something similar.

 

I've know Paul Roark for a long time and he's certainly someone who knows 

what he is doing. He's got a Photoshop curves (.acv file) that he just puts on a

layer above everything else.  Turn it on for printing and off for editing.  In a sense

it works very much like a printing ICC profile -- just applied for printing.

So I decided to compare his .acv method to my ICC method.  With Photoshop

this turns out to be very easy.  Just take a 21step file assigned to GG 2.2.   We're

going to see that actual data values would be sent to QTR driver with the 2 methods.

So for Paul's I just apply the .acv and flatten the image, for mine/ICC I just do a

Convert to Profile with my generic Gray-Matte-Paper.  These give files that

would go to QTR without any more changes.  I just used Photoshop to calculate

the difference function for these.  Even to my surprise they are just about identical.

The maximum difference was just 2 (8-bit values) or less that 1%, the average

difference was less than 1/2 a bit-value or less that 0.2%  -- amazing.

Paul -- how did you make this .acv ?? Just by eye?

I think this gives a lot more credence to the simple mathematic correction curves.

 

I also read Brian's paper quite a few times to get it all (maybe).  I can't so far 

think of an as easy test as Paul's but it does seem to depend on the standard

ICC methodology so I'm inclined to think it'll yield similar results.  But I think 

it's more of an edit-in-the reduced-DR workflow.   

BTW, Brian had a link to an earlier discussion that had more info -- thanks Brian:

https://groups.yahoo.com/neo/groups/QuadtoneRIP/conversations/messages/12538

 

Another comment I have:  both Paul's .acv and Brian's second graph show 

fairly pronounced flattening/compression of shadow area.  What I think is not

obvious is that there are two components to this.  There's the compression due

to a weak dMax -- i.e. the basis of most of this whole discussion, but also there's 

 the Gamma 2.2 curve of the source file.  Both of these corrections are trying

to mimic the L-values of the G2.2 curve NOT the K-values that are being

graphed.  So the severe compression of shadows in G2.2 are also being 

shown in these curves.  

 

Roy

 

-- a little aside to those feeling like the regular ICC workflow with Gray-Matte-Paper

is a bit strong in its compression of shadows.  There generic ICCs are super

simple, you can easily make your own with different parameters.

The input for Matte-Paper is simply two L-values--   96 16

Those were chosen as typical matte dMin and dMax.   If you'd like a weaker

correction just use 96 12 say.  All you need in a .txt file is those 2 numbers

and Create-ICC will create a new generic ICC for you.  Try pairs till you like it.

 

Roy

 

 

On Wed, Jul 27, 2016 at 5:38 PM, brian_downunda@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:



Quite a lot has been written in response, some of it quite advanced, and I don't want to add too much more.  I have a lot of sympathy for the views in Eugene's initial post.  When people coming to QTR read of QTR curves being referred to as profiles they get understandably confused, a point I've made before.  That said, you seem to have a good understanding.  I agree with you and Richard that the media type setting in the Epson driver seems to be the closest analogy, except that you can't add new ones or adjust the existing ones as you can in QTR.

The issue of whether to use an ICC - produced by the Create ICC (RGB) droplet - just for soft-proofing or to convert to it for printing has been a vexed issue.  In my view, a lot of it has to do with what style of print you want and perhaps what sort of images you print.  Clearly Richard and I and in a different camp to Paul.  

There was a heated debate with Jon Cone some (seven) years ago on another Yahoo forum.  Partly in light of that exchange, I wrote a post outlining some of the issues for new users, esp those coming from a colour workflow:
http://www.cyberhalides.com/piezography-printing/the-piezography-heretic-to-convert-or-not-to-convert/

 

I don't pretend that this is a sophisticated analysis, since it's aimed at new users with less technical knowledge that you seem to have, but you may find it helpful all the same.  It was written in the context of Piezography, but it applies to any B&W inkset including OEM-K3.  Bear in mind that it's also a little tongue-in-cheek.


I know that Richard loves his Macs, but both OS X and Windows have their advantages and disadvantages.  They both work.  Use what you know are are most comfortable.  Print Tool is a great program, but QTRGui is quite useable, esp the curve creator.  In either case, you can't print direct from PS anymore, so I don't see a huge difference in the workflows, and I have tried the OS X one.  I may have switched to OS X some years ago for printing, but the combined antics of Apple and Adobe to break things, accidentally or intentionally, removed most of the potential advantages for me.



---In QuadtoneRIP@yahoogroups.com, <info@...> wrote :

My intuition tells me that these curves are more like media type settings since they control ink levels. The profile would be the ICC profile being created using the Eye one and the Create ICC RGB droplet.  If my intuition is correct than the curves (media types) and profiles should be working in tandem.

 





 

-- 

Roy Harrington
roy@...
www.harrington.com

 





 

-- 

Roy Harrington
roy@...
www.harrington.com

Re: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-29 by Roy Harrington

Eugene,

I think you are right that it is the only grayscale ICC program around. I'm quite
aware of Amadou and Eric (he created gray ICCs for a while but did not share
the method publicly as far as I know).

Anyway using this with ABW is perfectly fine and one of the intended uses.
My intent on all my tools is to make them as general purpose and open as possible.

Grayscale color management worked great back in the days of Photoshop CS3 -
worked with QTR driver as well as Epson ABW driver. But Apple, Adobe, and
Epson in the interest of "protecting" people from hurting themselves, gradually
put in interlocks and restrictions that essentially broke grayscale CM. I spent
quite a while with Apple developer support finally convincing them of the
problems and that they were their's -- that's when they lost interest.

That led to me writing Print-Tool -- to bring back all the capabilities lost and
add a bunch of new ones. You haven't mentioned Print-Tool (on quadtonerip.com)
but if you really want to try CM with ABW or QTR -- this again is the only way.
There's a special checkbox to disable the interlocks with ABW.
(yes, it is possible to workaround in PS but it's complicated and dependent on
the OS X version -- just plain error prone)

BTW, about the ICC tables. There are actually just 3 -- absolute & relative
share the same one -- according to ICC standards. The main difference is that
perceptual has BPC builtin whereas relative&saturation (the same) do not
have the BPC builtin. How these tables are actually used is up to the CM
Engine being used -- it is not defined by ICC. With grayscale I'd expect the
perceptual and relative w/BPC to be the same but they tend to vary slightly.

Roy

Show quoted textHide quoted text
On Fri, Jul 29, 2016 at 1:56 PM, Le Mois de la Photo à Uqbar info@moisdelaphoto.ca [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:


Roy,

I think it is possible that I am part of a subset of QTR users who are using your software in a way that you did not intend. Some literature exists for this (see Amadou Diallo and I think Eric Chan). Quad Tone Rip is the only ICC grey profile-making software that I know of. B&W photographers wanting to use only the ultrachrome grey inks in an ICC workflow are able to use QTR to generate ICC profiles; this process bypasses QTR gui completely, and by all means it is not a perfect system.

If you print and measure an L* chart via the Epson Advanced B&W Dark mode, on a surprising number of papers the response is as linear as one might expect, factoring in the compression that has to occur to compensate for differing black points. The ABW dark mode is used as a foundation upon which the profile is built. The 21x4 target is printed using ABW dark, measured and a profile is created with the create ICC droplet. Later the profile is used to print through from Photoshop selecting “Photoshop manages colour” the QTR profile is selected, as well as the rendering intent and then in the Epson driver ABW dark is also selected. This is no longer possible on a MAC but the workaround is simple, the file is converted beforehand and colour management deactivated.

It is clear that Epson ABW is NOT a colour management workflow. Yet for the same reason that, as he wrote in his article, Brian is able to soft-proof a file using an ICC profile that he does not intend to print through by checking “preserve the numbers”, a converted file (that is, converted to the control signals of the printer that produce real world densities) which is sent outside of colour management should produce exactly the same results.

My comments about the relative table have to do with this use of the profile, which as you have indicated is not what it was conceived for. According to Colorthink the QTR profiles have four tables (perceptual, relative, absolute and saturation) each displaying a different graph.

I am sorry if this is a bastardisation of your creation and you didn’t mean it to be used this way, but I am grateful for your software and happy to have the chance to thank you personally.

I honestly believe your software is the only way to generate grey profiles. I would love to be corrected if I’m wrong

Eugene

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com]
Envoyé : July-29-16 1:27 PM


À : QuadtoneRIP@yahoogroups.com
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC

Eugene,

I'm not sure what to make of your comments. QTR is really simple in concept.

All it does is let you control exactly how much ink goes on the paper for each

of the gray pixel values. It just goes from no ink (paper white) to some

controlable max amount of ink (dMax). There are no perceptual tables in

QTR, no intents, no ICC anything. White dMin maps to paper, black dMax maps

to max level. Everything in between can be mapped how you like.

ICC support was added on top, separately to help control the mapping curves

between white and black. White mapping is built into ICC standard, black

mapping concept was added by Adobe in Black Point Compensation.

The intent tables for QTR ICCs were made to match those standards.

Maybe you can make use of this but it's certainly not something you have to use.

What you see on a screen always goes through a color management stage,

so I prefer using the same idea on the print but it is not at all mandatory.

Hope the QTR curves give you whatever control you need and want. YMMV.

Roy

On Fri, Jul 29, 2016 at 7:20 AM, Le Mois de la Photo à Uqbar info@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:

I am coming at QTR from an ICC world. I started, I think as most of us did coming out of the darkroom in the 90’s in a « same as source » environment, and I swore by it. Dark rooms were like Spitfires they only had one seat. I was looking for the kind of direct and absolute control that I got with MY kodak thermometer and MY Saunders timer, etc. I established a perfect working relationship with my printer and my paper by sending raw control signals and charting the results. Most people moved to colour management when, for any reason, they had to work with other human beings or other media, or simply got tired of rebuilding their universes every time they changed printers. But I moved to colour management to obtain a greater control over translating data to ink. For me colour management is digital sensitometry. My understanding of the ICC workflow is that the only possible explanation for prints that are lighter or darker or greener or in any way producing an unexpected result is if perceptual rendering is being used.

Because the perceptual table does not lock ingamut colours (including grey values) as relative does things can move around. But using relative rendering automatically assumes that the out of gamut values are being manually targeted, which for me means there is no ICC without ACV.

So making target adjustments and using the perceptual table would be like driving a car inside a car. In fact if the black ink level were manually targeted and then perceptual rendering used, the absence of any L*0 value would not prevent the perceptual table from compressing the curve anyway because it’s just a blind look up table, each time and time after time L*X gets mapped to L*Y. That’s why when I use the QTR profile I do not remap black instead I make a slight « linearisation curve » that pulls values out of whatever plateau the perceptual table creates that disadvantages the particular image I’m targeting.

So , for my money it sounds like ICC workflow is being confused with perceptual rendering table. For some reason I won’t go into it here (I posted about this a short while ago) the QTR relative table does seem to lock the ingamut values in place, making target adjustments difficult.

However, this is how I explain to my students why QTR uses a perceptual table. You have to understand that when we get to QTR they have come through a an ICC workflow that allows them absolute control over every tone in their image which they can isolate and place where ever they want. They are used to marking the deepest edge of shadow detail emerging out of black with sample points then placing it at on the print at the very edge of perception. So you can see how they scratch their heads a bit when I say we’ll be using the perceptual rendering intent. This is what I tell them, « The perceptual table when made by an ICC technician who works for a company whose criteria is most likely best possible results for consumers who probably don’t know that much about what they’re doing is like the automatic mode on your camera. But a perceptual table made by a photographer who was most likely a master printer and also by the grace of god understands computer programming would be like having Emmet Gowin print your negative ».

But it would be nice if the relative table was more stable. Ideally, and this is why I have decided to learn to make the QIDF curves. QTR would allow us to make media type settings for papers that Epson doesn’t make and not have to use Premium Luster for Museo Rag or Enhanced Matte for Entrada. Then we could make an ICC profile and if the relative table locked ingamut lightnesses, target adjust our images to perfection.

Eugene

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com]
Envoyé : July-28-16 11:15 PM
À : QuadtoneRIP@yahoogroups.com
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC

I was curious about the various workflows to get what you want on the paper.

Here's where I am: I'm on a Mac so the ICC approach is very convenient. So this is

what I use all the time these days. I mostly do photo paper these days but did the

same thing with matte for a long time.

With matte papers the dMax is relatively weak so its always been an issue of how to

map an image (on screen) with wider Dynamic Range (DR) onto a paper with smaller DR.

The matte paper loss of DR is almost entirely on the dark end so this is where the

mapping is most notable and potentially controversial. Anyway you slice it you

have to lose DR somewhere -- all over or more some places. The QTR linearization

from early days has always been a straightforward straight-line or basically DR loss is

spread out across the whole range. With this approach a DR of L=96 to L=16 has

a midpoint of L=56 which a fair bit lighter than a middle gray of L=50. (in actuality

it is even more complicated because editing spaces are all different so middle will

have lots of different values). But the bottom line is that most people noticed that

their prints were almost always lighter and weaker than they expected. (if you were

from the darkroom days you were used to just editing till you got what you wanted).

But the beauty of digital photography is reducing the trial and fix cycles. Screen to

print matching to me seems like the ultimate goal. Its never going to be perfect,

first a light emitting screen is never identical to a reflecting piece of paper, and

second a smaller DR paper will never be as contrasty as a high DR screen. You will

always need to use your experience to "see" what you will get and will need a minimum

trial/fix cycle. So lets do the best we can.

I think the workflows fall into two categories -- dumb down the screen somehow

so you edit in the reduced DR that matches the paper, or -- do a correction curve

at print time that gives the best you can do mapping (i.e. something you can

easily learn to pre-visualize). I prefer the later since the former ties the image

file to the specific paper -- what happens when you want a different paper?

The ICC folks have done lots of this with color so I figured it ought to apply to

grayscale too -- actually lots simpler because it's one dimension instead of three.

Learning how it all worked (for gray at least) was a bear because everyone just

treats it like a mysterious black box that no one needs to know how it works.

All-in-all for grayscale it's all just curves that maps input values to output values

according to math calculations. I got all this to work on Macs but its a bit more

cumbersome on PCs.

So given that the PC workflow w/ICC is a bit more awkward there have been a number

of workflows to accomplish something similar.

I've know Paul Roark for a long time and he's certainly someone who knows

what he is doing. He9;s got a Photoshop curves (.acv file) that he just puts on a

layer above everything else. Turn it on for printing and off for editing. In a sense

it works very much like a printing ICC profile -- just applied for printing.

So I decided to compare his .acv method to my ICC method. With Photoshop

this turns out to be very easy. Just take a 21step file assigned to GG 2.2. We're

going to see that actual data values would be sent to QTR driver with the 2 methods.

So for Paul's I just apply the .acv and flatten the image, for mine/ICC I just do a

Convert to Profile with my generic Gray-Matte-Paper. These give files that

would go to QTR without any more changes. I just used Photoshop to calculate

the difference function for these. Even to my surprise they are just about identical.

The maximum difference was just 2 (8-bit values) or less that 1%, the average

difference was less than 1/2 a bit-value or less that 0.2% -- amazing.

Paul -- how did you make this .acv ?? Just by eye?

I think this gives a lot more credence to the simple mathematic correction curves.

I also read Brian's paper quite a few times to get it all (maybe). I can't so far

think of an as easy test as Paul's but it does seem to depend on the standard

ICC methodology so I'm inclined to think it'll yield similar results. But I think

it's more of an edit-in-the reduced-DR workflow.

BTW, Brian had a link to an earlier discussion that had more info -- thanks Brian:

Another comment I have: both Paul's .acv and Brian's second graph show

fairly pronounced flattening/compression of shadow area. What I think is not

obvious is that there are two components to this. There's the compression due

to a weak dMax -- i.e. the basis of most of this whole discussion, but also there's

the Gamma 2.2 curve of the source file. Both of these corrections are trying

to mimic the L-values of the G2.2 curve NOT the K-values that are being

graphed. So the severe compression of shadows in G2.2 are also being

shown in these curves.

Roy

-- a little aside to those feeling like the regular ICC workflow with Gray-Matte-Paper

is a bit strong in its compression of shadows. There generic ICCs are super

simple, you can easily make your own with different parameters.

The input for Matte-Paper is simply two L-values-- 96 16

Those were chosen as typical matte dMin and dMax. If you'd like a weaker

correction just use 96 12 say. All you need in a .txt file is those 2 numbers

and Create-ICC will create a new generic ICC for you. Try pairs till you like it.

Roy

On Wed, Jul 27, 2016 at 5:38 PM, brian_downunda@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:



Quite a lot has been written in response, some of it quite advanced, and I don't want to add too much more. I have a lot of sympathy for the views in Eugene's initial post. When people coming to QTR read of QTR curves being referred to as profiles they get understandably confused, a point I've made before. That said, you seem to have a good understanding. I agree with you and Richard that the media type setting in the Epson driver seems to be the closest analogy, except that you can't add new ones or adjust the existing ones as you can in QTR.

The issue of whether to use an ICC - produced by the Create ICC (RGB) droplet - just for soft-proofing or to convert to it for printing has been a vexed issue. In my view, a lot of it has to do with what style of print you want and perhaps what sort of images you print. Clearly Richard and I and in a different camp to Paul.

There was a heated debate with Jon Cone some (seven) years ago on another Yahoo forum. Partly in light of that exchange, I wrote a post outlining some of the issues for new users, esp those coming from a colour workflow:
http://www.cyberhalides.com/piezography-printing/the-piezography-heretic-to-convert-or-not-to-convert/

I don't pretend that this is a sophisticated analysis, since it's aimed at new users with less technical knowledge that you seem to have, but you may find it helpful all the same. It was written in the context of Piezography, but it applies to any B&W inkset including OEM-K3. Bear in mind that it's also a little tongue-in-cheek.


I know that Richard loves his Macs, but both OS X and Windows have their advantages and disadvantages. They both work. Use what you know are are most comfortable. Print Tool is a great program, but QTRGui is quite useable, esp the curve creator. In either case, you can't print direct from PS anymore, so I don't see a huge difference in the workflows, and I have tried the OS X one. I may have switched to OS X some years ago for printing, but the combined antics of Apple and Adobe to break things, accidentally or intentionally, removed most of the potential advantages for me.



---In QuadtoneRIP@yahoogroups.com, <info@...> wrote :

My intuition tells me that these curves are more like media type settings since they control ink levels. The profile would be the ICC profile being created using the Eye one and the Create ICC RGB droplet. If my intuition is correct than the curves (media types) and profiles should be working in tandem.



--



--






--

Re: QIDF versus ICC

2016-07-30 by brian_downunda@...

I hesitate to add another reply, as much of what has just been posted is way over my pay grade. For me, it's about getting enough control to get the print I want. But there are a few points that I wanted to comment on.

When Roy says "what happens when you want a different paper?", I think he is referring to what happens when you switch papers if you don't convert to the ICC. This used to trouble me too, and was one reason that I was initially attracted to ICC conversion. You can switch papers and get roughly the same image, allowing for differences between papers. However, if you can manage to print in GG22 without ICC conversion with curves that are perfectly linear for each paper, then you get pretty much the same effect. As a Piezography user, this was only possible before the relinearisation droplet by paying IJM $US99 for each custom curve. The relinearisation droplet solves all that and makes changing papers without ICC conversion a snap. Thank you, thank you, thank you.

I understand only too well the benefits of a good screen to print match as a good starting point - to minimise the iterations. But as I tried to explain in that blog post, there's more than one way to skin a cat. The preserve numbers soft-proof gives a good screen-to-print match, as does assigning the ICC rather than converting. I resisted this Cone-esque workflow for some time. but gradually I came to realise what I was missing in the shadows. Once you've converted it's hard to get the detail back in the deep shadows by editing. Better to stick to GG22, preserve numbers soft-proof, and edit the shadows down to where you want them than to convert and try to recover them. So it's not whether you use the ICC, it's how you use it to best effect.

I mention Paul's .acv in that article, although only really to to contrast it to the GG22 work - it's an easy way of doing the exact opposite. In fact I make a lot of use of that ICC. If you find the preserve numbers soft proof too light and the ICC conversion too dark, you can put that PS curve on a layer and have the opacity in the 40-60% range and use it to edit down the shadows to where you want them, with the preserve numbers soft proof as your guide. It allows me to dial in an intermediate rendering. So it's a useful tool no matter which workflow you use. That's probably worth adding to the article.

The idea of doing the same thing by creating a custom ICC with custom dMax and dMin numbers is intriguing, but I think .acv on a layer is more flexible.

I often read the statement that the convert to ICC workflow is more awkward in Windows, but I can't really see it. You just convert to the ICC in PS and save a duplicate then print in QTRGui. Given that neither Mac nor Win allows you to print from PS any more, I just can't see that the workflow is all that much different. Mac allows you to avoid creating a duplicate, but it's still a two program workflow, isn't it?

It troubles me a little that Roy had to read my article multiple times to understand it. I tried to make it accessible to all levels of knowledge. I'm open to comments about what isn't clear.


---In QuadtoneRIP@yahoogroups.com, <roy@...> wrote [relevant excerpts only]:

I think the workflows fall into two categories -- dumb down the screen somehow
so you edit in the reduced DR that matches the paper, or -- do a correction curve
at print time that gives the best you can do mapping (i.e. something you can
easily learn to pre-visualize). I prefer the later since the former ties the image
file to the specific paper -- what happens when you want a different paper?

But the beauty of digital photography is reducing the trial and fix cycles. Screen to
print matching to me seems like the ultimate goal. ... You will
always need to use your experience to "see" what you will get and will need a minimum
trial/fix cycle. So lets do the best we can.

I've know Paul Roark for a long time and he's certainly someone who knows
what he is doing. He's got a Photoshop curves (.acv file) that he just puts on a
layer above everything else. Turn it on for printing and off for editing. In a sense
it works very much like a printing ICC profile -- just applied for printing.

There generic ICCs are super simple, you can easily make your own with different parameters.

So given that the PC workflow w/ICC is a bit more awkward there have been a number
of workflows to accomplish something similar.

I also read Brian's paper quite a few times to get it all (maybe).

Re: [QuadtoneRIP] QIDF versus ICC

2016-07-30 by forums@walkerblackwell.com

A note about ICC printing related to Piezo. While it’s not official here in the R&D lab at InkjetMall, I certainly see a potential for it when you want to have contrast matches between different media with the same image file. We at IJM just think that linear printing is a way more stable way of editing and proofing an image (for a given paper) in order to maintain full shadow depth and detail.

Our upcoming Piezography Professional Edition toolset will give Piezography customers the ability to make manual and semi-manual Grayscale ICCs directly from a Photoshop curve using Roy’s Create-ICC. We’ve been doing this to make null-transform ICCs, as well as the “half-way” translation ICCs (ICCs that take into account the dMax and also a tune suggestion) that do screen-to-print match without making everything too dark in the print (mainly this is for PiezoDN platinum printing because it has such a light dMax, but this can certainly be applied to prints). (Alternatively, this adjustment can also be applied directly into a linearized piezo .quad.)

We’ve also perfected a workflow that exploits the full potential of the QTR-Linearize-Quad droplet using an old StudioPrint iterative technique: start with 51steps and then go to 129steps correcting the measurement data with a unique formula. This will enable complete DIY linearization of the Piezo .quad to eliminate banding transitions that, while not showing up in prints, can appear in the circle-gradient acid tests. The toolset for this lin technique will be available as a private google drive spreadsheet for each user.

//

Whenever contrast is equalized between papers of different black depth, one tonal region suffers. Usually this is right in the dark mid-shadow tones (they get compressed flat). So this is always a consideration to think about when dealing with ICC printing vs linear printing. Ironically, a good monitor that is set at a low contrast point will not soft-proof correctly and will show too little contrast with that method. This is a goldilocks problem. The solution is to forget a little about the monitor and do everything to the proof. 

regards.
Walker
Show quoted textHide quoted text
> On Jul 29, 2016, at 9:20 PM, brian_downunda@yahoo.com [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:
> 
> I hesitate to add another reply, as much of what has just been posted is way over my pay grade.  For me, it's about getting enough control to get the print I want.  But there are a few points that I wanted to comment on.
> 
> When Roy says "what happens when you want a different paper?", I think he is referring to what happens when you switch papers if you don't convert to the ICC.  This used to trouble me too, and was one reason that I was initially attracted to ICC conversion.  You can switch papers and get roughly the same image, allowing for differences between papers.  However, if you can manage to print in GG22 without ICC conversion with curves that are perfectly linear for each paper, then you get pretty much the same effect.  As a Piezography user, this was only possible before the relinearisation droplet by paying IJM $US99 for each custom curve.  The relinearisation droplet solves all that and makes changing papers without ICC conversion a snap.  Thank you, thank you, thank you.  
> 
> 
> I understand only too well the benefits of a good screen to print match as a good starting point - to minimise the iterations.  But as I tried to explain in that blog post, there's more than one way to skin a cat.  The preserve numbers soft-proof gives a good screen-to-print match, as does assigning the ICC rather than converting.  I resisted this Cone-esque workflow for some time. but gradually I came to realise what I was missing in the shadows.  Once you've converted it's hard to get the detail back in the deep shadows by editing.  Better to stick to GG22, preserve numbers soft-proof, and edit the shadows down to where you want them than to convert and try to recover them.  So it's not whether you use the ICC, it's how you use it to best effect.
> 
> I mention Paul's .acv in that article, although only really to to contrast it to the GG22 work - it's an easy way of doing the exact opposite.  In fact I make a lot of use of that ICC.  If you find the preserve numbers soft proof too light and the ICC conversion too dark, you can put that PS curve on a layer and have the opacity in the 40-60% range and use it to edit down the shadows to where you want them, with the preserve numbers soft proof as your guide.  It allows me to dial in an intermediate rendering.  So it's a useful tool no matter which workflow you use.  That's probably worth adding to the article.
> 
> The idea of doing the same thing by creating a custom ICC with custom dMax and dMin numbers is intriguing, but I think .acv on a layer is more flexible.
> 
> I often read the statement that the convert to ICC workflow is more awkward in Windows, but I can't really see it.  You just convert to the ICC in PS and save a duplicate then print in QTRGui.  Given that neither Mac nor Win allows you to print from PS any more, I just can't see that the workflow is all that much different.  Mac allows you to avoid creating a duplicate, but it's still a two program workflow, isn't it?
> 
> It troubles me a little that Roy had to read my article multiple times to understand it.  I tried to make it accessible to all levels of knowledge.  I'm open to comments about what isn't clear.
> 
> 
> ---In QuadtoneRIP@yahoogroups.com <mailto:QuadtoneRIP@yahoogroups.com>, <roy@...> wrote [relevant excerpts only]:
> 
> I think the workflows fall into two categories -- dumb down the screen somehow
> so you edit in the reduced DR that matches the paper, or --  do a correction curve
> at print time that gives the best you can do mapping (i.e. something you can 
> easily learn to pre-visualize).   I prefer the later since the former ties the image
> file to the specific paper -- what happens when you want a different paper?
> 
> But the beauty of digital photography is reducing the trial and fix cycles.  Screen to
> print matching to me seems like the ultimate goal. ... You will
> always need to use your experience to "see" what you will get and will need a minimum
> trial/fix cycle.  So lets do the best we can.
> 
> I've know Paul Roark for a long time and he's certainly someone who knows 
> what he is doing. He's got a Photoshop curves (.acv file) that he just puts on a
> layer above everything else.  Turn it on for printing and off for editing.  In a sense
> it works very much like a printing ICC profile -- just applied for printing.
> 
> There generic ICCs are super simple, you can easily make your own with different parameters.
> 
> So given that the PC workflow w/ICC is a bit more awkward there have been a number
> of workflows to accomplish something similar.
> 
> I also read Brian's paper quite a few times to get it all (maybe).
> 
> 
>

RE: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-30 by Le Mois de la Photo à Uqbar

I have never used the print tool, but thank you for that tip I’ll investigate. Perhaps naively I wasn’t aware of any ICC QTR problems. 

 

Is it possible that windows users did not experience these Epson / Adobe / Apple changes since CS3, or could these changes be unapparent to windows users? I’m still using QTR profiles much as I did in CS3 with seemingly no difference.  

 

Given what you say that the QTR relative table does not include BPC, Is it conceivable that converting to the QTR profiles in an ICC work flow using the relative table would allow printers to use a target adjustment to manually remap DMAX and threshold values? I ask this question because here and elsewhere when I have inquired about QTR with relative rendering, I am simply told the QTR profiles must be used with the perpetual table. 

 

I think I‘m starting to get an inkling of the paradigm shift between what we are calling ICC workflow and QTR linearization curves. If my inkling is correct then these curves are meant to be far more than media type (ink level) settings which attempt simply to even out the distribution of ink on various papers. If I understand the discussion here, these curves seem to play a role in translating data to those levels.  In which case, they would be replacing colour management on a data to specific paper/printer combination basis, as long as the same source space was always being used.

 

Is that a fair appraisal? 

 

Eugene

 

 

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com] 
Envoyé : July-29-16 6:16 PM
À : QuadtoneRIP@yahoogroups.com
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC

 

  

Eugene,

 

I think you are right that it is the only grayscale ICC program around.  I'm quite

aware of Amadou and Eric (he created gray ICCs for a while but did not share

the method publicly as far as I know).

 

Anyway using this with ABW is perfectly fine and one of the intended uses.

My intent on all my tools is to make them as general purpose and open as possible.

 

Grayscale color management worked great back in the days of Photoshop CS3 -

worked with QTR driver as well as Epson ABW driver.  But Apple, Adobe, and 

Epson in the interest of "protecting" people from hurting themselves, gradually

put in interlocks and restrictions that essentially broke grayscale CM.  I spent

quite a while with Apple developer support finally convincing them of the 

problems and that they were their's -- that's when they lost interest.

 

That led to me writing Print-Tool -- to bring back all the capabilities lost and

add a bunch of new ones.  You haven't mentioned Print-Tool (on quadtonerip.com)

but if you really want to try CM with ABW or QTR -- this again is the only way.

There's a special checkbox to disable the interlocks with ABW.

(yes, it is possible to workaround in PS but it's complicated and dependent on

the OS X version -- just plain error prone)

 

BTW, about the ICC tables.  There are actually just 3 -- absolute & relative 

share the same one -- according to ICC standards.  The main difference is that

perceptual has BPC builtin whereas relative&saturation (the same) do not

have the BPC builtin.  How these tables are actually used is up to the CM

Engine being used -- it is not defined by ICC.  With grayscale I'd expect the

perceptual and relative w/BPC to be the same but they tend to vary slightly.

 

Roy

 

 

On Fri, Jul 29, 2016 at 1:56 PM, Le Mois de la Photo à Uqbar info@moisdelaphoto.ca [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:

 

Roy,

 

I think it is possible that I am part of a subset of QTR users who are using your software in a way that you did not intend. Some literature exists for this (see Amadou Diallo and I think Eric Chan). Quad Tone Rip is the only ICC grey profile-making software that I know of.   B&W photographers wanting to use only the ultrachrome grey inks in an ICC workflow are able to use QTR to generate ICC profiles; this process bypasses QTR gui completely, and by all means it is not a perfect system.

 

If you print and measure an L* chart via the Epson Advanced B&W Dark mode, on a surprising number of papers the response is as linear as one might expect, factoring in the compression that has to occur to compensate for differing black points. The ABW dark mode is used as a foundation upon which the profile is built. The 21x4 target is printed using ABW dark, measured and a profile is created with the create ICC droplet.  Later the profile is used to print through from Photoshop selecting “Photoshop manages colour” the QTR profile is selected, as well as the rendering intent and then in the Epson driver ABW dark is also selected. This is no longer possible on a MAC but the workaround is simple, the file is converted beforehand and colour management deactivated. 

 

It is clear that Epson ABW is NOT a colour management workflow. Yet for the same reason that, as he wrote in his article, Brian is able to soft-proof a file using an ICC profile that he does not intend to print through by checking “preserve the numbers”, a converted file (that is, converted to the control signals of the printer that produce real world densities) which is sent outside of colour management should produce exactly the same results. 

 

My comments about the relative table have to do with this use of the profile, which as you have indicated is not what it was conceived for.  According to Colorthink the QTR profiles have four tables (perceptual, relative, absolute and saturation) each displaying  a different graph. 

 

I am sorry if this is a bastardisation of your creation and you didn’t mean it to be used this way, but I am grateful for your software and happy to have the chance to thank you personally. 

 

I honestly believe your software is the only way to generate grey profiles. I would love to be corrected if I’m wrong

 

Eugene

 

 

 

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com] 
Envoyé : July-29-16 1:27 PM


À : QuadtoneRIP@yahoogroups.com
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC

 

  

Eugene,

 

I'm not sure what to make of your comments.  QTR is really simple in concept.

All it does is let you control exactly how much ink goes on the paper for each

of the gray pixel values.  It just goes from no ink (paper white) to some

controlable max amount of ink (dMax).  There are no perceptual tables in

QTR, no intents, no ICC anything.  White dMin maps to paper, black dMax maps

to max level. Everything in between can be mapped how you like.

 

ICC support was added on top, separately to help control the mapping curves

between white and black.  White mapping is built into ICC standard, black

mapping concept was added by Adobe in Black Point Compensation.

The intent tables for QTR ICCs were made to match those standards.

Maybe you can make use of this but it's certainly not something you have to use.

What you see on a screen always goes through a color management stage,

so I prefer using the same idea on the print but it is not at all mandatory.

 

Hope the QTR curves give you whatever control you need and want. YMMV.

Roy

 

 

 

 

 

 

On Fri, Jul 29, 2016 at 7:20 AM, Le Mois de la Photo à Uqbar info@moisdelaphoto.ca [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:

 

I am coming at QTR from an ICC world. I started, I think as most of us did coming out of the darkroom in the 90’s in a « same as source » environment, and I swore by it. Dark rooms were like Spitfires they only had one seat. I was looking for the kind of direct and absolute control that I got with MY kodak thermometer and MY Saunders timer, etc.  I established a perfect working relationship with my printer and my paper by sending raw control signals and charting the results. Most people moved to colour management when, for any reason, they had to work with other human beings or other media, or simply got tired of rebuilding their universes every time they changed printers.  But I moved to colour management to obtain a greater control over translating data to ink.  For me colour management is digital sensitometry.  My understanding of the ICC workflow is that the only possible explanation for prints that are lighter or darker or greener or in any way producing an unexpected result is if perceptual rendering is being used. 

 

Because the perceptual table does not lock ingamut colours (including grey values) as relative does things can move around. But using relative rendering automatically assumes that the out of gamut values  are being manually targeted, which for me means there is no ICC without ACV. 

So making target adjustments and using the perceptual table would be like driving a car inside a car. In fact if the black ink level were manually targeted and then perceptual rendering used, the absence of any L*0 value would not prevent the perceptual table from compressing the curve anyway because it’s just a blind look up table, each time and time after time L*X gets mapped to L*Y.  That’s why when I use the QTR profile I do not remap black instead I make a slight « linearisation curve » that pulls values out of whatever plateau the perceptual table creates that disadvantages the particular image I’m targeting. 

 

So , for my money it sounds like ICC workflow is being confused with perceptual rendering table. For some reason I won’t go into it here (I posted about this a short while ago) the QTR relative table does seem to lock the ingamut values in place, making target adjustments difficult.  

 

However, this is how I explain to my students why QTR uses a perceptual table. You have to understand that when we get to QTR they have come through a an ICC workflow that allows them absolute control over every tone in their image which they can isolate and place where ever they want. They are used to marking the deepest edge of shadow detail emerging out of black with sample points then placing it at on the print at  the very edge of perception. So you can see how they scratch their heads a bit when I say we’ll be using the perceptual rendering intent.  This is what I tell them, « The perceptual table when made by an ICC technician who works for a company whose criteria is most likely best possible results for consumers who probably don’t know that much about what they’re doing is like the automatic mode on your camera. But a perceptual table made by a photographer who was most likely a master printer and also by the grace of god understands computer programming would be like having Emmet Gowin print your negative ».

 

But it would be nice if the relative table was more stable. Ideally, and this is why I have decided to learn to make the QIDF curves. QTR would allow us to make media type settings for papers that Epson doesn’t make and not have to use Premium Luster for Museo Rag or Enhanced Matte for Entrada. Then we could make an ICC profile and if the relative table locked ingamut lightnesses, target adjust our images to perfection.

 

Eugene

 

 

 

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com] 
Envoyé : July-28-16 11:15 PM
À : QuadtoneRIP@yahoogroups.com
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC

 

  

I was curious about the various workflows to get what you want on the paper.

 

Here's where I am:  I'm on a Mac so the ICC approach is very convenient.  So this is 

what I use all the time these days. I mostly do photo paper these days but did the 

same thing with matte for a long time.

 

With matte papers the dMax is relatively weak so its always been an issue of how to

map an image (on screen) with wider Dynamic Range (DR) onto a paper with smaller DR.

The matte paper loss of DR is almost entirely on the dark end so this is where the

mapping is most notable and potentially controversial.  Anyway you slice it you

have to lose DR somewhere -- all over or more some places.  The QTR linearization

from early days has always been a straightforward straight-line or basically DR loss is

spread out across the whole range.  With this approach a DR of L=96 to L=16 has

a midpoint of L=56 which a fair bit lighter than a middle gray of L=50.  (in actuality

it is even more complicated because editing spaces are all different so middle will

have lots of different values).  But the bottom line is that most people noticed that

their prints were almost always lighter and weaker than they expected.  (if you were

from the darkroom days you were used to just editing till you got what you wanted).

 

But the beauty of digital photography is reducing the trial and fix cycles.  Screen to

print matching to me seems like the ultimate goal.  Its never going to be perfect,

first a light emitting screen is never identical to a reflecting piece of paper, and

second a smaller DR paper will never be as contrasty as a high DR screen.  You will

always need to use your experience to "see" what you will get and will need a minimum

trial/fix cycle.  So lets do the best we can.

 

I think the workflows fall into two categories -- dumb down the screen somehow

so you edit in the reduced DR that matches the paper, or --  do a correction curve

at print time that gives the best you can do mapping (i.e. something you can 

easily learn to pre-visualize).   I prefer the later since the former ties the image

file to the specific paper -- what happens when you want a different paper?

 

The ICC folks have done lots of this with color so I figured it ought to apply to

grayscale too -- actually lots simpler because it's one dimension instead of three.

Learning how it all worked (for gray at least) was a bear because everyone just

treats it like a mysterious black box that no one needs to know how it works.

All-in-all for grayscale it's all just curves that maps input values to output values

according to math calculations.  I got all this to work on Macs but its a bit more

cumbersome on PCs.

 

So given that the PC workflow w/ICC is a bit more awkward there have been a number

of workflows to accomplish something similar.

 

I've know Paul Roark for a long time and he's certainly someone who knows 

what he is doing. He's got a Photoshop curves (.acv file) that he just puts on a

layer above everything else.  Turn it on for printing and off for editing.  In a sense

it works very much like a printing ICC profile -- just applied for printing.

So I decided to compare his .acv method to my ICC method.  With Photoshop

this turns out to be very easy.  Just take a 21step file assigned to GG 2.2.   We're

going to see that actual data values would be sent to QTR driver with the 2 methods.

So for Paul's I just apply the .acv and flatten the image, for mine/ICC I just do a

Convert to Profile with my generic Gray-Matte-Paper.  These give files that

would go to QTR without any more changes.  I just used Photoshop to calculate

the difference function for these.  Even to my surprise they are just about identical.

The maximum difference was just 2 (8-bit values) or less that 1%, the average

difference was less than 1/2 a bit-value or less that 0.2%  -- amazing.

Paul -- how did you make this .acv ?? Just by eye?

I think this gives a lot more credence to the simple mathematic correction curves.

 

I also read Brian's paper quite a few times to get it all (maybe).  I can't so far 

think of an as easy test as Paul's but it does seem to depend on the standard

ICC methodology so I'm inclined to think it'll yield similar results.  But I think 

it's more of an edit-in-the reduced-DR workflow.   

BTW, Brian had a link to an earlier discussion that had more info -- thanks Brian:

https://groups.yahoo.com/neo/groups/QuadtoneRIP/conversations/messages/12538

 

Another comment I have:  both Paul's .acv and Brian's second graph show 

fairly pronounced flattening/compression of shadow area.  What I think is not

obvious is that there are two components to this.  There's the compression due

to a weak dMax -- i.e. the basis of most of this whole discussion, but also there's 

 the Gamma 2.2 curve of the source file.  Both of these corrections are trying

to mimic the L-values of the G2.2 curve NOT the K-values that are being

graphed.  So the severe compression of shadows in G2.2 are also being 

shown in these curves.  

 

Roy

 

-- a little aside to those feeling like the regular ICC workflow with Gray-Matte-Paper

is a bit strong in its compression of shadows.  There generic ICCs are super

simple, you can easily make your own with different parameters.

The input for Matte-Paper is simply two L-values--   96 16

Those were chosen as typical matte dMin and dMax.   If you'd like a weaker

correction just use 96 12 say.  All you need in a .txt file is those 2 numbers

and Create-ICC will create a new generic ICC for you.  Try pairs till you like it.

 

Roy

 

 

On Wed, Jul 27, 2016 at 5:38 PM, brian_downunda@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:



Quite a lot has been written in response, some of it quite advanced, and I don't want to add too much more.  I have a lot of sympathy for the views in Eugene's initial post.  When people coming to QTR read of QTR curves being referred to as profiles they get understandably confused, a point I've made before.  That said, you seem to have a good understanding.  I agree with you and Richard that the media type setting in the Epson driver seems to be the closest analogy, except that you can't add new ones or adjust the existing ones as you can in QTR.

The issue of whether to use an ICC - produced by the Create ICC (RGB) droplet - just for soft-proofing or to convert to it for printing has been a vexed issue.  In my view, a lot of it has to do with what style of print you want and perhaps what sort of images you print.  Clearly Richard and I and in a different camp to Paul.  

There was a heated debate with Jon Cone some (seven) years ago on another Yahoo forum.  Partly in light of that exchange, I wrote a post outlining some of the issues for new users, esp those coming from a colour workflow:
http://www.cyberhalides.com/piezography-printing/the-piezography-heretic-to-convert-or-not-to-convert/

 

I don't pretend that this is a sophisticated analysis, since it's aimed at new users with less technical knowledge that you seem to have, but you may find it helpful all the same.  It was written in the context of Piezography, but it applies to any B&W inkset including OEM-K3.  Bear in mind that it's also a little tongue-in-cheek.


I know that Richard loves his Macs, but both OS X and Windows have their advantages and disadvantages.  They both work.  Use what you know are are most comfortable.  Print Tool is a great program, but QTRGui is quite useable, esp the curve creator.  In either case, you can't print direct from PS anymore, so I don't see a huge difference in the workflows, and I have tried the OS X one.  I may have switched to OS X some years ago for printing, but the combined antics of Apple and Adobe to break things, accidentally or intentionally, removed most of the potential advantages for me.



---In QuadtoneRIP@yahoogroups.com, <info@...> wrote :

My intuition tells me that these curves are more like media type settings since they control ink levels. The profile would be the ICC profile being created using the Eye one and the Create ICC RGB droplet.  If my intuition is correct than the curves (media types) and profiles should be working in tandem.

 





 

-- 

Roy Harrington
roy@...
www.harrington.com

 





 

-- 

Roy Harrington
roy@...
www.harrington.com

 





 

-- 

Roy Harrington
roy@...
www.harrington.com

Re: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-30 by Paul Roark

>;... Is it possible that windows users did not experience these Epson / Adobe / Apple changes since CS3, or could these changes be unapparent to windows users?

In Windows 7 I can print from Photoshop CC using "No Color Adjustment" in the Epson driver and inserting an ICC in the Photoshop Print screen. See, for example, page 3 of http://www.paulroark.com/BW-Info/Glossy-Carbon-Variable-Tone.pdf.

Likewise, I can use an ICC with ABW printing from PS CC in Windows 7.

I believe there was a past PS and/or Windows version that did impose constraints, but my current Windows 7, PS CC setup has the settings that I need for making and using ICCs without any work-around.

Paul
Show quoted textHide quoted text

RE: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-30 by Le Mois de la Photo à Uqbar

Paul 

 

Thanks for the reference. 

 

SO I will assume that if the problems associated to the Epson / Adobe / Apple changes since CS3, are limited to the ability to select “photoshop manages colour” in the PS printer interface and still keep the ABW mode active in the Epson driver, that windows users are unaffected. Though I’m pretty sure MAC users  can work around this by converting the file to the QTR profile in PS and selecting “printer manages colour” in the printer interface.

 

Eugene

 

 

 

 

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com] 
Envoyé : July-30-16 1:04 PM
À : QTR-Forum
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC

 

  

>... Is it possible that windows users did not experience these Epson / Adobe / Apple changes since CS3, or could these changes be unapparent to windows users? 

 

In Windows 7 I can print from Photoshop CC using "No Color Adjustment" in the Epson driver and inserting an ICC in the Photoshop Print screen.  See, for example, page 3 of http://www.paulroark.com/BW-Info/Glossy-Carbon-Variable-Tone.pdf.  

 

Likewise, I can use an ICC with ABW printing from PS CC in Windows 7.

 

I believe there was a past PS and/or Windows version that did impose constraints, but my current Windows 7, PS CC setup has the settings that I need for making and using ICCs without any work-around.

 

Paul

www.PaulRoark.com

Re: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-31 by Roy Harrington

Paul & Eugene

First, I have to say I don't do much work on Windows so I don't have experience
on how everything works there. But I've looked a whole lot on Mac operations.
Admittedly Apple is a big factor there but of course is not involved with Windows.
But Adobe & Epson have also been heavily involved with a lot of the issues too.
I.e. driver interlocks, photoshop No CM interact/interfere up and down in lots of ways.
Epson has worked really hard on the Mac to keep you from doing ICC with ABW
so I'd be really surprised that that was not true on Windows. Even when it
appears to let you in, you really can't tell what it's really doing.

-- a couple of points:
"printer manages color" does not mean no color management
(on Mac it means convert to sRGB then send to driver, unless its an older
version of OS X when it did convert to AdobeRGB then send it)
"no color adjustment" isn't the same either.

Though I’m pretty sure MAC users can work around this by converting the file to the QTR profile in PS and selecting “printer manages colour” in the printer interface.
Show quoted textHide quoted text

This also required assigning to sRGB. Also needed for printing target.

A lot of this is really messy.
Roy

On Sat, Jul 30, 2016 at 3:18 PM, Le Mois de la Photo à Uqbar info@moisdelaphoto.ca [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:


Paul

Thanks for the reference.

SO I will assume that if the problems associated to the Epson / Adobe / Apple changes since CS3, are limited to the ability to select “photoshop manages colour” in the PS printer interface and still keep the ABW mode active in the Epson driver, that windows users are unaffected. Though I’m pretty sure MAC users can work around this by converting the file to the QTR profile in PS and selecting “printer manages colour” in the printer interface.

Eugene

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com]
Envoyé : July-30-16 1:04 PM
À : QTR-Forum
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC

>... Is it possible that windows users did not experience these Epson / Adobe / Apple changes since CS3, or could these changes be unapparent to windows users?

In Windows 7 I can print from Photoshop CC using "No Color Adjustment" in the Epson driver and inserting an ICC in the Photoshop Print screen. See, for example, page 3 of http://www.paulroark.com/BW-Info/Glossy-Carbon-Variable-Tone.pdf.

Likewise, I can use an ICC with ABW printing from PS CC in Windows 7.

I believe there was a past PS and/or Windows version that did impose constraints, but my current Windows 7, PS CC setup has the settings that I need for making and using ICCs without any work-around.

Paul







--

Re: QIDF versus ICC

2016-07-31 by brian_downunda@...

It is my understanding that Adobe has changed the colour management in recent versions of Photoshop in a way that also affects Windows users. This change is not that well known, and fortunately for this forum, it doesn't affect QTR printing on Windows.

If you print direct from PS and select "printer manages colour" in the PS print dialog, then you will get a silent profile conversion to sRGB en route to the printer driver. This behaviour is spelt out and defended by Adobe engineer Dave Polaschek in the comments section of this article on TOP:
http://theonlinephotographer.typepad.com/the_online_photographer/2015/10/photoshop-vs-printer-managed-color-printing.html

He also discusses the behaviour in OS X. This is the only place I know where an Adobe engineer has discussed this issue publicly, although be warned you will need to read his comments (there are several comment blocks from him) many times to understand fully.


So on Windows, the people who are particularly affected are ABW users, and the users of certain RIPs that install as a printer driver, e.g. PrintFab, as these workflows use the "printer manages colour" setting. The workarounds are either to assign to sRGB before printing, a clumsy workflow, or to do a null profile conversion in the print dialog, e.g. from AdobeRGB to AdobeRGB. Photoshop shows a warning about this, but it still works on Windows. Dave Polaschek warns that it may stop working one day.


I've tested this. I ABW printed and measured the 21x4 twice - once as it is supplied as an untagged greyscale image, and once after converting it to AdobeRGB and then assigning to sRGB. They weren't the same. The measurements of the untagged greyscale print were decidedly odd.



---In QuadtoneRIP@yahoogroups.com, <info@...> wrote :

Paul

Thanks for the reference.

SO I will assume that ... windows users are unaffected.

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com]
Envoyé : July-30-16 1:04 PM
À : QTR-Forum
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC

In Windows 7 I can print from Photoshop CC using "No Color Adjustment" in the Epson driver and inserting an ICC in the Photoshop Print screen. See, for example, page 3 of http://www.paulroark.com/BW-Info/Glossy-Carbon-Variable-Tone.pdf.

Likewise, I can use an ICC with ABW printing from PS CC in Windows 7.

I believe there was a past PS and/or Windows version that did impose constraints, but my current Windows 7, PS CC setup has the settings that I need for making and using ICCs without any work-around.


Re: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-31 by Roy Harrington


On Sat, Jul 30, 2016 at 9:06 AM, Le Mois de la Photo à Uqbar info@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:


I have never used the print tool, but thank you for that tip I’ll investigate. Perhaps naively I wasn’t aware of any ICC QTR problems.

Is it possible that windows users did not experience these Epson / Adobe / Apple changes since CS3, or could these changes be unapparent to windows users? I’m still using QTR profiles much as I did in CS3 with seemingly no difference.


The matrix of all the combinations of OS's, OS versions, PS versions, etc etc is too large to
make any clear statement of what happens in a specific case.

Given what you say that the QTR relative table does not include BPC, Is it conceivable that converting to the QTR profiles in an ICC work flow using the relative table would allow printers to use a target adjustment to manually remap DMAX and threshold values? I ask this question because here and elsewhere when I have inquired about QTR with relative rendering, I am simply told the QTR profiles must be used with the perpetual table.


You need to try it. I don't know what you are really trying to accomplish.

I think I‘m starting to get an inkling of the paradigm shift between what we are calling ICC workflow and QTR linearization curves. If my inkling is correct then these curves are meant to be far more than media type (ink level) settings which attempt simply to even out the distribution of ink on various papers. If I understand the discussion here, these curves seem to play a role in translating data to those levels. In which case, they would be replacing colour management on a data to specific paper/printer combination basis, as long as the same source space was always being used.


QTR is a very low level driver. All it does is take Gray values (0-255) that it is fed for each
pixel, it translates that to a specific number of ink drops of each ink based on the .quad
tables which are the QTR curves. Except for the usage of QTR linearization (straight line
graph of gray values vs Lab patches) nothing at this level knows a thing about anything else.

All ICC stuff is a much higher level bunch of code. It's all about translating Lab values in
source files to gray values to be sent to driver. In Windows the QTR level is entirely in
QTRgui so windows issues do not show up at all. On Mac sending data from any printing
app to the driver goes through the system and potentially hidden conversions are being done.

Roy

Is that a fair appraisal?

Eugene


RE: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-31 by Le Mois de la Photo à Uqbar

Roy and Brian,

 

You’re freaking me out! I think I’m getting answers here to questions I didn’t even realise I should be asking. That would explain perfectly what I have been describing as strange relative table behaviour.

 

It all pivots on one very important question. 

 

Does selecting “printer manages colour” automatically assign sRGB to the file data (GG2.2 numbers) or initiate a conversion to sRGB?

 

Eugene

 

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com] 
Envoyé : July-30-16 10:36 PM
À : QuadtoneRIP@yahoogroups.com
Objet : [QuadtoneRIP] Re: QIDF versus ICC

 

  

It is my understanding that Adobe has changed the colour management in recent versions of Photoshop in a way that also affects Windows users.  This change is not that well known, and fortunately for this forum, it doesn't affect QTR printing on Windows.  

If you print direct from PS and select "printer manages colour" in the PS print dialog, then you will get a silent profile conversion to sRGB en route to the printer driver.  This behaviour is spelt out and defended by Adobe engineer Dave Polaschek in the comments section of this article on TOP:
http://theonlinephotographer.typepad.com/the_online_photographer/2015/10/photoshop-vs-printer-managed-color-printing.html

He also discusses the behaviour in OS X.  This is the only place I know where an Adobe engineer has discussed this issue publicly, although be warned you will need to read his comments (there are several comment blocks from him) many times to understand fully.

 

So on Windows, the people who are particularly affected are ABW users, and the users of certain RIPs that install as a printer driver, e.g. PrintFab, as these workflows use the "printer manages colour" setting.  The workarounds are either to assign to sRGB before printing, a clumsy workflow, or to do a null profile conversion in the print dialog, e.g. from AdobeRGB to AdobeRGB.  Photoshop shows a warning about this, but it still works on Windows.  Dave Polaschek warns that it may stop working one day.  

 

I've tested this.  I ABW printed and measured the 21x4 twice - once as it is supplied as an untagged greyscale image, and once after converting it to AdobeRGB and then assigning to sRGB.  They weren't the same.  The measurements of the untagged greyscale print were decidedly odd.  



---In QuadtoneRIP@yahoogroups.com, <info@...> wrote :

Paul 

 

Thanks for the reference. 

 

SO I will assume that ... windows users are unaffected. 

 

 

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com] 
Envoyé : July-30-16 1:04 PM
À : QTR-Forum
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC

 

  

In Windows 7 I can print from Photoshop CC using "No Color Adjustment" in the Epson driver and inserting an ICC in the Photoshop Print screen.  See, for example, page 3 of http://www.paulroark.com/BW-Info/Glossy-Carbon-Variable-Tone.pdf.  

 

Likewise, I can use an ICC with ABW printing from PS CC in Windows 7.

 

I believe there was a past PS and/or Windows version that did impose constraints, but my current Windows 7, PS CC setup has the settings that I need for making and using ICCs without any work-around.

RE: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-31 by Le Mois de la Photo à Uqbar

Roy,

 

“You need to try it.  I don't know what you are really trying to accomplish”.

 

This surprises me , it makes me feel like I’m from another planet. But maybe I am in some respects  I’m getting the feeling that my perception of the  ICC workflow is actually a completely different school of thought to the  QTR workflow .

In the ICC workflow that I am familiar with the media type settings ( ink level curves) do not remap file data to maximum black, colour management does.  

 

So in that light this is what I mean to accomplish is

 

Obviously The L*0 to ( roughly  L*3 -8 for glossy papers or L*17- L*22 for Matte papers)  values of the image file have to be moved to the maximum ink level of the paper /printer combination. In the dark room we made test strips to determine precisely where Dmax yielded to the first visible tone. In the ICC work flow I only know of 3 ways to accomplish this,  either;  a conversion using perceptual rendering to the output profile, a conversion using relative rendering in conjunction with Adobe Black Point Compensation or a conversion using relative with no BPC where the black point has been manually targeted beforehand. Perceptual rendering and BPC are like automatic modes. I have never fully understood the behaviour of BPC especially where colour data is concerned, and since I’m a control freak, I prefer to do it myself. 

 

When I print a chart of the 100 L* values in an ICC workflow with relative intent and no BPC I can verify ( under lighting conditions the final print will be displayed in)  exactly where DMAX is lost and the length of the toe,( the distance between the first appearance of visible line and a usable threshold density). This allows me to see which paper/ printer combinations take as much as 5 L* to move from the first visible line to usable threshold density, and which paper/ printer combinations can make clean and clear tonal distinction rapidly.  The elasticity of this dmax to usefull threshold zone allows me to place whatever deep shadow detail I do not want to be printed with anything less than useful threshold density, precisely there.  Then once I’ve compressed the curve by  targeting the black point and threshold I can use a target curve with soft proofing to realign the  L* axis should I feel the uniform compression fused contours, or simply to readjust local contrast,  especially if  vital vibrations from tonal juxtapositions were diminished by the uniform compression.  

 

As a said previously I have the feeling the QTR workflow attempts to do this with ink level curves. 

 

I can’t believe that this approach is alien to you I have to believe I’m not expressing myself properly. I hope this detailed description helps.

 

Eugene

 

 

De :  <mailto:QuadtoneRIP@yahoogroups.com> QuadtoneRIP@yahoogroups.com [ <mailto:QuadtoneRIP@yahoogroups.com> mailto:QuadtoneRIP@yahoogroups.com] 
Envoyé : July-31-16 12:29 AM
À :  <mailto:QuadtoneRIP@yahoogroups.com> QuadtoneRIP@yahoogroups.com
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC

 

  

 

On Sat, Jul 30, 2016 at 9:06 AM, Le Mois de la Photo à Uqbar  <mailto:info@moisdelaphoto.ca> info@... [QuadtoneRIP] < <mailto:QuadtoneRIP@yahoogroups.com> QuadtoneRIP@yahoogroups.com> wrote:

 

I have never used the print tool, but thank you for that tip I’ll investigate. Perhaps naively I wasn’t aware of any ICC QTR problems. 

 

Is it possible that windows users did not experience these Epson / Adobe / Apple changes since CS3, or could these changes be unapparent to windows users? I’m still using QTR profiles much as I did in CS3 with seemingly no difference. 

 

The matrix of all the combinations of OS's, OS versions, PS versions, etc etc is too large to

make any clear statement of what happens in a specific case.

 

 

Given what you say that the QTR relative table does not include BPC, Is it conceivable that converting to the QTR profiles in an ICC work flow using the relative table would allow printers to use a target adjustment to manually remap DMAX and threshold values? I ask this question because here and elsewhere when I have inquired about QTR with relative rendering, I am simply told the QTR profiles must be used with the perpetual table.

 

You need to try it.  I don't know what you are really trying to accomplish.

 

 

I think I‘m starting to get an inkling of the paradigm shift between what we are calling ICC workflow and QTR linearization curves. If my inkling is correct then these curves are meant to be far more than media type (ink level) settings which attempt simply to even out the distribution of ink on various papers. If I understand the discussion here, these curves seem to play a role in translating data to those levels.  In which case, they would be replacing colour management on a data to specific paper/printer combination basis, as long as the same source space was always being used.

 

QTR is a very low level driver.  All it does is take Gray values (0-255) that it is fed for each

pixel, it translates that to a specific number of ink drops of each ink based on the .quad

tables which are the QTR curves.  Except for the usage of QTR linearization (straight line

graph of gray values vs Lab patches) nothing at this level knows a thing about anything else.

 

All ICC stuff is a much higher level bunch of code.  It's all about translating Lab values in

source files to gray values to be sent to driver.  In Windows the QTR level is entirely in

QTRgui so windows issues do not show up at all.  On Mac sending data from any printing

app to the driver goes through the system and potentially hidden conversions are being done.

 

Roy

 

 

Is that a fair appraisal? 

 

Eugene

 

 

 





[Non-text portions of this message have been removed]

RE: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-31 by Le Mois de la Photo à Uqbar

Ok I just read the reference you sited (sorry should have done that first), 

 

The article says that if the file has a colour profile it will be CONVERTED to sRGB. If the file does not have a colour profile it will be assumed to be in sRGB (otherwise assigned). It’s not clear in the Dave Polaschek comments when he says “files with attached colour profiles” if he means to exclude greyscale profiles.  I use Adobe 1998 as a workspace so I expect that my files are being converted to sRGB and not assigned. 

 

I can see why colour printers are concerned about this, but I’m not sure we should be. Assigning a profile can change values but converting ( using relative rendering which I’m pretty sure is the default rendering for Photoshop ) cannot,  unless the values are out of gamut and since both spaces go from L*0 to L*100 my feeling is values can’t change ( you can test this in Photoshop by bouncing back and forth from Adobe to sRGB you shouldn’t see a change in lightness values , but if you assign sRGB you will).

 

It’s true that the reproduction curve of sRGB is weird to say the least, I think it’s a hybrid of 1.8 and 2.2 but if the file is being converted and not assigned, I beleive the L*values are being translated accurately , ( this would mean the 2.2 contrast curve is being translated into the sRGB curve respecting their original values. As long as we don’t adjust the file in sRGB we should be ok. 

 

However in light of this information I’ll be spending the next few days testing. 

 

Eugene

 

 

 

 

 

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com] 
Envoyé : July-30-16 10:36 PM
À : QuadtoneRIP@yahoogroups.com
Objet : [QuadtoneRIP] Re: QIDF versus ICC

 

  

It is my understanding that Adobe has changed the colour management in recent versions of Photoshop in a way that also affects Windows users.  This change is not that well known, and fortunately for this forum, it doesn't affect QTR printing on Windows.  

If you print direct from PS and select "printer manages colour" in the PS print dialog, then you will get a silent profile conversion to sRGB en route to the printer driver.  This behaviour is spelt out and defended by Adobe engineer Dave Polaschek in the comments section of this article on TOP:
http://theonlinephotographer.typepad.com/the_online_photographer/2015/10/photoshop-vs-printer-managed-color-printing.html

He also discusses the behaviour in OS X.  This is the only place I know where an Adobe engineer has discussed this issue publicly, although be warned you will need to read his comments (there are several comment blocks from him) many times to understand fully.

 

So on Windows, the people who are particularly affected are ABW users, and the users of certain RIPs that install as a printer driver, e.g. PrintFab, as these workflows use the "printer manages colour" setting.  The workarounds are either to assign to sRGB before printing, a clumsy workflow, or to do a null profile conversion in the print dialog, e.g. from AdobeRGB to AdobeRGB.  Photoshop shows a warning about this, but it still works on Windows.  Dave Polaschek warns that it may stop working one day.  

 

I've tested this.  I ABW printed and measured the 21x4 twice - once as it is supplied as an untagged greyscale image, and once after converting it to AdobeRGB and then assigning to sRGB.  They weren't the same.  The measurements of the untagged greyscale print were decidedly odd.  



---In QuadtoneRIP@yahoogroups.com, <info@...> wrote :

Paul 

 

Thanks for the reference. 

 

SO I will assume that ... windows users are unaffected. 

 

 

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com] 
Envoyé : July-30-16 1:04 PM
À : QTR-Forum
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC

 

  

In Windows 7 I can print from Photoshop CC using "No Color Adjustment" in the Epson driver and inserting an ICC in the Photoshop Print screen.  See, for example, page 3 of http://www.paulroark.com/BW-Info/Glossy-Carbon-Variable-Tone.pdf.  

 

Likewise, I can use an ICC with ABW printing from PS CC in Windows 7.

 

I believe there was a past PS and/or Windows version that did impose constraints, but my current Windows 7, PS CC setup has the settings that I need for making and using ICCs without any work-around.

RE: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-31 by <info@...>

Greetings, I’m a new member





I’ve been following this post with interest. But I just got lost.





Eugene can you help me understand why you are concerned about this secret conversion to srgb when “printer manages color is selected” if, as you say you are working in the Windows environment which allows you to select “Photoshop manages color “and initiate an on the fly conversion to the QTR profile, and then select the ABW mode in the Epson driver.





Did I miss something?





Paul Lowry











De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com]
Envoyé : July-31-16 12:39 PM
À : QuadtoneRIP@yahoogroups.com
Objet : RE: [QuadtoneRIP] Re: QIDF versus ICC





 


Ok I just read the reference you sited (sorry should have done that first),





The article says that if the file has a colour profile it will be CONVERTED to sRGB. If the file does not have a colour profile it will be assumed to be in sRGB (otherwise assigned). It’s not clear in the Dave Polaschek comments when he says “files with attached colour profiles” if he means to exclude greyscale profiles.  I use Adobe 1998 as a workspace so I expect that my files are being converted to sRGB and not assigned.





I can see why colour printers are concerned about this, but I’m not sure we should be. Assigning a profile can change values but converting ( using relative rendering which I’m pretty sure is the default rendering for Photoshop ) cannot,  unless the values are out of gamut and since both spaces go from L*0 to L*100 my feeling is values can’t change ( you can test this in Photoshop by bouncing back and forth from Adobe to sRGB you shouldn’t see a change in lightness values , but if you assign sRGB you will).





It’s true that the reproduction curve of sRGB is weird to say the least, I think it’s a hybrid of 1.8 and 2.2 but if the file is being converted and not assigned, I beleive the L*values are being translated accurately , ( this would mean the 2.2 contrast curve is being translated into the sRGB curve respecting their original values. As long as we don’t adjust the file in sRGB we should be ok.





However in light of this information I’ll be spending the next few days testing.





Eugene

















De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com]
Envoyé : July-30-16 10:36 PM
À : QuadtoneRIP@yahoogroups.com
Objet : [QuadtoneRIP] Re: QIDF versus ICC








It is my understanding that Adobe has changed the colour management in recent versions of Photoshop in a way that also affects Windows users.  This change is not that well known, and fortunately for this forum, it doesn't affect QTR printing on Windows.


If you print direct from PS and select "printer manages colour" in the PS print dialog, then you will get a silent profile conversion to sRGB en route to the printer driver.  This behaviour is spelt out and defended by Adobe engineer Dave Polaschek in the comments section of this article on TOP:
http://theonlinephotographer.typepad.com/the_online_photographer/2015/10/photoshop-vs-printer-managed-color-printing.html


He also discusses the behaviour in OS X.  This is the only place I know where an Adobe engineer has discussed this issue publicly, although be warned you will need to read his comments (there are several comment blocks from him) many times to understand fully.





So on Windows, the people who are particularly affected are ABW users, and the users of certain RIPs that install as a printer driver, e.g. PrintFab, as these workflows use the "printer manages colour" setting.  The workarounds are either to assign to sRGB before printing, a clumsy workflow, or to do a null profile conversion in the print dialog, e.g. from AdobeRGB to AdobeRGB.  Photoshop shows a warning about this, but it still works on Windows.  Dave Polaschek warns that it may stop working one day.





I've tested this.  I ABW printed and measured the 21x4 twice - once as it is supplied as an untagged greyscale image, and once after converting it to AdobeRGB and then assigning to sRGB.  They weren't the same.  The measurements of the untagged greyscale print were decidedly odd.






---In QuadtoneRIP@yahoogroups.com, <info@...> wrote :


Paul





Thanks for the reference.





SO I will assume that ... windows users are unaffected.








De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com]
Envoyé : July-30-16 1:04 PM
À : QTR-Forum
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC








In Windows 7 I can print from Photoshop CC using "No Color Adjustment" in the Epson driver and inserting an ICC in the Photoshop Print screen.  See, for example, page 3 of http://www.paulroark.com/BW-Info/Glossy-Carbon-Variable-Tone.pdf.





Likewise, I can use an ICC with ABW printing from PS CC in Windows 7.





I believe there was a past PS and/or Windows version that did impose constraints, but my current Windows 7, PS CC setup has the settings that I need for making and using ICCs without any work-around.

Re: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-31 by Roy Harrington

I'm beginning to think this whole thread has been meandering too long and too widely and too vaguely to
really help people understand what's happening with CM and what to do.

But ICC color management is an important and interesting subject. You have to understand a fair amount
of the background and general idea of it all though before you can "get it". Treating it as a magic black box
is fine for most people, but not good enough if you get into the nitty-gritty and want to understand all the
underlying processing going on.

On Sat, Jul 30, 2016 at 7:36 PM, brian_downunda@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:

It is my understanding that Adobe has changed the colour management in recent versions of Photoshop in a way that also affects Windows users. This change is not that well known, and fortunately for this forum, it doesn't affect QTR printing on Windows.

If you print direct from PS and select "printer manages colour" in the PS print dialog, then you will get a silent profile conversion to sRGB en route to the printer driver. This behaviour is spelt out and defended by Adobe engineer Dave Polaschek in the comments section of this article on TOP:
http://theonlinephotographer.typepad.com/the_online_photographer/2015/10/photoshop-vs-printer-managed-color-printing.html

Interesting article plus the Luminous Landscape article that is linked to in one of the comments. Trouble is: it's more
indicative of mis-information and confusion there is trying to talk about it than helpful information. Yes, there's a lot
of factual stuff in it but it's continuously interspersed with vagueness that makes it very hard to decide what9;s what.

My first impression about article itself: it's by a guy Ctein who is a long time photo expert from way back. Sometimes
highly respected but sometimes controversial at least in some peoples' opinions -- I don't really know. But he has
done lots in the analog world and now in the digital world. He's explicit right up front that he's talking about
printing in OS X with Photoshop and Printer Manages Color. Quote -- "What I'm recommending only works under Mac OS"
Strange thing is that with Photoshop and Printer Manages Color a very important dialog page Color Matching is
never mentioned in article or in any of the numerous comments. Neither are selections in Epson dialog settings. ??
I'm interested but skeptical about his finding -- but without more explicit info I'm not sure what can be said.

The comments wander all over -- Mac to Windows, sRGB to AdobeRGB to ProPhoto, conversions & assignments,
and particularly No Color Management (LULA article is especially about that). So it's hard to tell which
assumptions each commenter is making.

He also discusses the behaviour in OS X. This is the only place I know where an Adobe engineer has discussed this issue publicly, although be warned you will need to read his comments (there are several comment blocks from him) many times to understand fully.

My reading of his post seemed all about Windows not Mac but there's a lot of other product jargon that I'm
not familiar with. I think his most revealing quote was (his bold emphasis!):
But if you want no color management at all, you really should be printing from Photoshop CS3
or earlier where that option is explicitly available ...
I did a lot of recommending CS3 in the past but for an Adobe guy to actually saying that less than a year ago
about 6 versions of Photoshop later says a lot about how messy most of this is.
(btw, Adobe has a program called ACPU for both Mac & Windows
that is recommended for printing targets etc with No Color Management. But it's very limited in flexibility.)


On Sun, Jul 31, 2016 at 7:57 AM, Le Mois de la Photo à Uqbar info@moisdelaphoto.ca [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:

Roy and Brian,

You’re freaking me out! I think I’m getting answers here to questions I didn’t even realise I should be asking. That would explain perfectly what I have been describing as strange relative table behaviour.

Freaking out is not that unusual with this :)


Show quoted textHide quoted text
On Sun, Jul 31, 2016 at 9:38 AM, Le Mois de la Photo à Uqbar info@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:

...

I can see why colour printers are concerned about this, but I’m not sure we should be. Assigning a profile can change values but converting ( using relative rendering which I’m pretty sure is the default rendering for Photoshop ) cannot, unless the values are out of gamut and since both spaces go from L*0 to L*100 my feeling is values can’t change ( you can test this in Photoshop by bouncing back and forth from Adobe to sRGB you shouldn’t see a change in lightness values , but if you assign sRGB you will).

So, I started reading the above paragraph -- "Assigning a profile can change values but converting ... cannot".
My first reaction was -- Wow, you got this all backwards! I'm guessing you do know what you are
talking about, but what about a reader?. The issue is just saying "values" -- all image files have two
kind of values -- first, the numbers in the file i.e K or RGB values, and second, the meanings of those numbers i.e.
the L* or LAB values which are derived from numbers (K or RGB) with the ICC profile attached or assumed.

This is like taking a ruler and measuring the length of something. If I tell you it 6 long you have the number but
the meaning doesn't show up until I tell whether it's inches or cm or miles. So 6 is like the RGB value, inches
is like GG2.2, and together you know the actual length which is like L-value.

Assign Profile always preserves the numbers (K or RGB) at the expense of changing L-values.
Convert Profile always tries to preserve L-values by changing the K or RGB values.
This ought to be totally ingrained in anyone trying to talk about CM but any hint that it's vague
in someone's mind throws off the whole discussion.

So my point is that any comment, question, statement that is vague about "values";, vague about OS type,
vague about converting what to what, vague about anything in a workflow, becomes mostly meaningless.
Sure people will answer but you never know what assumptions they are making either.

Eugene, this is just an illustration, not you. This issue is everywhere. The link articles with all the ";experts" are
riddled with vagueness. To me it just becomes impossible to get anywhere.

Roy

--

Re: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-31 by Paul Roark

>; ... Adobe has a program called ACPU for both Mac & Windows
that is recommended for printing targets etc with No Color Management.
​ ...

I use it to check that what I'm doing from PS results in the same test print.

Paul
Show quoted textHide quoted text
On Sun, Jul 31, 2016 at 12:40 PM, Roy Harrington roy@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:

I'm beginning to think this whole thread has been meandering too long and too widely and too vaguely to
really help people understand what's happening with CM and what to do.

But ICC color management is an important and interesting subject. You have to understand a fair amount
of the background and general idea of it all though before you can "get it". Treating it as a magic black box
is fine for most people, but not good enough if you get into the nitty-gritty and want to understand all the
underlying processing going on.

On Sat, Jul 30, 2016 at 7:36 PM, brian_downunda@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:

It is my understanding that Adobe has changed the colour management in recent versions of Photoshop in a way that also affects Windows users. This change is not that well known, and fortunately for this forum, it doesn't affect QTR printing on Windows.

If you print direct from PS and select "printer manages colour" in the PS print dialog, then you will get a silent profile conversion to sRGB en route to the printer driver. This behaviour is spelt out and defended by Adobe engineer Dave Polaschek in the comments section of this article on TOP:
http://theonlinephotographer.typepad.com/the_online_photographer/2015/10/photoshop-vs-printer-managed-color-printing.html

Interesting article plus the Luminous Landscape article that is linked to in one of the comments. Trouble is: it's more
indicative of mis-information and confusion there is trying to talk about it than helpful information. Yes, there's a lot
of factual stuff in it but it's continuously interspersed with vagueness that makes it very hard to decide what's what.

My first impression about article itself: it's by a guy Ctein who is a long time photo expert from way back. Sometimes
highly respected but sometimes controversial at least in some peoples' opinions -- I don't really know. But he has
done lots in the analog world and now in the digital world. He's explicit right up front that he's talking about
printing in OS X with Photoshop and Printer Manages Color. Quote -- "What I'm recommending only works under Mac OS"
Strange thing is that with Photoshop and Printer Manages Color a very important dialog page Color Matching is
never mentioned in article or in any of the numerous comments. Neither are selections in Epson dialog settings. ??
I'm interested but skeptical about his finding -- but without more explicit info I'm not sure what can be said.

The comments wander all over -- Mac to Windows, sRGB to AdobeRGB to ProPhoto, conversions & assignments,
and particularly No Color Management (LULA article is especially about that). So it's hard to tell which
assumptions each commenter is making.

He also discusses the behaviour in OS X. This is the only place I know where an Adobe engineer has discussed this issue publicly, although be warned you will need to read his comments (there are several comment blocks from him) many times to understand fully.

My reading of his post seemed all about Windows not Mac but there's a lot of other product jargon that I'm
not familiar with. I think his most revealing quote was (his bold emphasis!):
But if you want no color management at all, you really should be printing from Photoshop CS3
or earlier where that option is explicitly available ...
I did a lot of recommending CS3 in the past but for an Adobe guy to actually saying that less than a year ago
about 6 versions of Photoshop later says a lot about how messy most of this is.
(btw, Adobe has a program called ACPU for both Mac & Windows
that is recommended for printing targets etc with No Color Management. But it9;s very limited in flexibility.)


On Sun, Jul 31, 2016 at 7:57 AM, Le Mois de la Photo à Uqbar info@moisdelaphoto.ca [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:

Roy and Brian,

You’re freaking me out! I think I’m getting answers here to questions I didn’t even realise I should be asking. That would explain perfectly what I have been describing as strange relative table behaviour.

Freaking out is not that unusual with this :)


On Sun, Jul 31, 2016 at 9:38 AM, Le Mois de la Photo à Uqbar info@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:

...

I can see why colour printers are concerned about this, but I’m not sure we should be. Assigning a profile can change values but converting ( using relative rendering which I’m pretty sure is the default rendering for Photoshop ) cannot, unless the values are out of gamut and since both spaces go from L*0 to L*100 my feeling is values can’t change ( you can test this in Photoshop by bouncing back and forth from Adobe to sRGB you shouldn’t see a change in lightness values , but if you assign sRGB you will).

So, I started reading the above paragraph -- "Assigning a profile can change values but converting ... cannot".
My first reaction was -- Wow, you got this all backwards! I'm guessing you do know what you are
talking about, but what about a reader?. The issue is just saying "values" -- all image files have two
kind of values -- first, the numbers in the file i.e K or RGB values, and second, the meanings of those numbers i.e.
the L* or LAB values which are derived from numbers (K or RGB) with the ICC profile attached or assumed.

This is like taking a ruler and measuring the length of something. If I tell you it 6 long you have the number but
the meaning doesn't show up until I tell whether it's inches or cm or miles. So 6 is like the RGB value, inches
is like GG2.2, and together you know the actual length which is like L-value.

Assign Profile always preserves the numbers (K or RGB) at the expense of changing L-values.
Convert Profile always tries to preserve L-values by changing the K or RGB values.
This ought to be totally ingrained in anyone trying to talk about CM but any hint that it's vague
in someone's mind throws off the whole discussion.

So my point is that any comment, question, statement that is vague about "values", vague about OS type,
vague about converting what to what, vague about anything in a workflow, becomes mostly meaningless.
Sure people will answer but you never know what assumptions they are making either.

Eugene, this is just an illustration, not you. This issue is everywhere. The link articles with all the "experts" are
riddled with vagueness. To me it just becomes impossible to get anywhere.

Roy

--


RE: [QuadtoneRIP] Re: QIDF versus ICC

2016-07-31 by Le Mois de la Photo à Uqbar

Paul (Lowry) 

 

You did not get lost, I did, sorry. 

 

You are right, everything concerning this secret conversion would only apply to MAC users who must select “printer manages colour” in order to have access to the ABW mode. 

 

I’m sorry to confuse the forum readers, It seems to be a matter of language when I use words like “value” “colour”, “contrast” “lightness” or anything visible I am referring to colorimetric phenomena, that which is perceivable to the human eye and represented  as L* a* b* values.  When I refer to RGB levels, Greyscale %, or CMJN % I use the word data. Data is what’s written in 0’s and 1’s on the hard drive. Data is what is rewritten during colorimetric conversions in order to preserve colour. Assignment preserves the data and modifies the colour; conversion preserves the colour by modifying the data. 

 

Eugene

 

 

 

 

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com] 
Envoyé : July-31-16 3:41 PM
À : QuadtoneRIP@yahoogroups.com
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC

 

  

I'm beginning to think this whole thread has been meandering too long and too widely and too vaguely to

really help people understand what's happening with CM and what to do.

 

But ICC color management is an important and interesting subject.  You have to understand a fair amount

of the background and general idea of it all though before you can "get it".  Treating it as a magic black box

is fine for most people, but not good enough if you get into the nitty-gritty and want to understand all the

underlying processing going on.  

 

On Sat, Jul 30, 2016 at 7:36 PM, brian_downunda@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:


It is my understanding that Adobe has changed the colour management in recent versions of Photoshop in a way that also affects Windows users.  This change is not that well known, and fortunately for this forum, it doesn't affect QTR printing on Windows.  

If you print direct from PS and select "printer manages colour" in the PS print dialog, then you will get a silent profile conversion to sRGB en route to the printer driver.  This behaviour is spelt out and defended by Adobe engineer Dave Polaschek in the comments section of this article on TOP:
http://theonlinephotographer.typepad.com/the_online_photographer/2015/10/photoshop-vs-printer-managed-color-printing.html

 

Interesting article plus the Luminous Landscape article that is linked to in one of the comments.  Trouble is: it's more

indicative of mis-information and confusion there is trying to talk about it than helpful information.  Yes, there's a lot

of factual stuff in it but it's continuously interspersed with vagueness that makes it very hard to decide what's what.

 

My first impression about article itself:  it's by a guy Ctein who is a long time photo expert from way back.  Sometimes

highly respected but sometimes controversial at least in some peoples' opinions -- I don't really know.  But he has

done lots in the analog world and now in the digital world.  He's explicit right up front that he's talking about 

printing in OS X with Photoshop and Printer Manages Color.  Quote -- "What I'm recommending only works under Mac OS"
Strange thing is that with Photoshop and Printer Manages Color a very important dialog page Color Matching is 

never mentioned in article or in any of the numerous comments.  Neither are selections in Epson dialog settings.  ??

I'm interested but skeptical about his finding -- but without more explicit info I'm not sure what can be said.

 

The comments wander all over -- Mac to Windows, sRGB to AdobeRGB to ProPhoto,  conversions & assignments,

and particularly No Color Management (LULA article is especially about that).  So it's hard to tell which

assumptions each commenter is making.

 

He also discusses the behaviour in OS X.  This is the only place I know where an Adobe engineer has discussed this issue publicly, although be warned you will need to read his comments (there are several comment blocks from him) many times to understand fully.

My reading of his post seemed all about Windows not Mac but there's a lot of other product jargon that I'm

not familiar with.  I think his most revealing quote was (his bold emphasis!):

But if you want no color management at all, you really should be printing from Photoshop CS3 

or earlier where that option is explicitly available ... 

I did a lot of recommending CS3 in the past but for an Adobe guy to actually saying that less than a year ago

about 6 versions of Photoshop later says a lot about how messy most of this is.  

(btw, Adobe has a program called ACPU for both Mac & Windows

that is recommended for printing targets etc with No Color Management.  But it's very limited in flexibility.)

 

 

On Sun, Jul 31, 2016 at 7:57 AM, Le Mois de la Photo à Uqbar info@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:

 

Roy and Brian,

You’re freaking me out! I think I’m getting answers here to questions I didn’t even realise I should be asking. That would explain perfectly what I have been describing as strange relative table behaviour.

Freaking out is not that unusual with this :)

 

 

On Sun, Jul 31, 2016 at 9:38 AM, Le Mois de la Photo à Uqbar info@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:

 

...

I can see why colour printers are concerned about this, but I’m not sure we should be. Assigning a profile can change values but converting ( using relative rendering which I’m pretty sure is the default rendering for Photoshop ) cannot,  unless the values are out of gamut and since both spaces go from L*0 to L*100 my feeling is values can’t change ( you can test this in Photoshop by bouncing back and forth from Adobe to sRGB you shouldn’t see a change in lightness values , but if you assign sRGB you will).

So, I started reading the above paragraph --  "Assigning a profile can change values but converting ... cannot".

My first reaction was -- Wow, you got this all backwards!    I'm guessing you do know what you are

talking about, but what about a reader?.   The issue is just saying "values" -- all image files have two

kind of values -- first, the numbers in the file i.e K or RGB values, and second, the meanings of those numbers i.e.

the L* or LAB values which are derived from numbers (K or RGB) with the ICC profile attached or assumed.

 

This is like taking a ruler and measuring the length of something.  If I tell you it 6 long you have the number but

the meaning doesn't show up until I tell whether it's inches or cm or miles.  So 6 is like the RGB value,  inches

is like GG2.2, and together you know the actual length which is like L-value.

 

Assign Profile always preserves the numbers (K or RGB) at the expense of changing L-values.

Convert Profile always tries to preserve L-values by changing the K or RGB values.

This ought to be totally ingrained in anyone trying to talk about CM but any hint that it's vague

in someone's mind throws off the whole discussion.

 

So my point is that any comment, question, statement that is vague about "values", vague about OS type,

vague about converting what to what, vague about anything in a workflow, becomes mostly meaningless.

Sure people will answer but you never know what assumptions they are making either.

 

Eugene, this is just an illustration, not you.  This issue is everywhere.  The link articles with all the "experts" are

riddled with vagueness.  To me it just becomes impossible to get anywhere.

 

Roy

 

-- 

Roy Harrington
roy@harrington.com
www.harrington.com

Re: QIDF versus ICC

2016-07-31 by brian_downunda@...

I agree that this thread increasingly requires a Ph.D. in forensic analysis in order to understand it. So I hesitate to add any more, but I made a small error in my post yesterday. I was a bit too hasty in including that link from TOP. In fact the discussion of the behaviour of "Printer Manages Colour" in recent versions of PS was spread over the comments sections to a series of TOP articles by C'Tein and Andrew Rodney. In order, they are:

26 July 2015: http://theonlinephotographer.typepad.com/the_online_photographer/2015/07/are-profiles-obsolete.html

27 July 2015: http://theoinephotographer.typepad.com/the_online_photographer/2015/07/andrew-rodney-on-the-importance-of-custom-printer-profiles.html

23 Sep 2015: http://theonlinephotographer.typepad.com/the_online_photographer/2015/09/product-review-epson-surecolor-p800-printer.html

01 Oct 2015: http://theonlinephotographer.typepad.com/the_online_photographer/2015/10/photoshop-vs-printer-managed-color-printing.html

As you will observe, the articles were principally about colour printing, but the comments raise issues relevant to B&W. Dave Polaschek from Adobe made comments on three of these articles. The comments on OS X that I was recalling were mostly in the second article from 27 July - note the featured comment from Dave Polaschek at the top of the comments section.

Although this is a B&W forum, those interested in understanding whether C'tien's recommendation to use printer managed colour makes any sense for colour printing may wish to read this LuLa post by Mark from Aardenburg:

http://forum.luminous-landscape.com/index.php?topic=104202.msg856130#msg856130

Re: [QuadtoneRIP] QIDF versus ICC

2016-08-01 by John Labovitz

On Jul 31, 2016, at 12:28 AM, Roy Harrington roy@... wrote:

> On Mac sending data from any printing
> app to the driver goes through the system and potentially hidden conversions are being done.

Perhaps it's academic or far too technical at this point, but I have had luck on OS X sending image data to the QTR driver without the higher-level print systems mucking with it. Basically, I send TIFF files directly to the CUPS printer queue via CUPS's programming interface [1], with the appropriate options specified for the QTR curves, etc. This isn't a GUI program, but rather something I do with some scripting (in Ruby) at the command line (e.g., Terminal).

I don't recommend this method for most people -- Roy's Print-Tool is wonderful and definitely does the job, and I use it myself -- but I wanted to state for the record that Print-Tool is not the *only* way to do it. It is not easy to escape the clutches of OS X's forced color management, but it is possible.

--John

[1] https://www.cups.org/documentation.php/doc-2.0/api-cups.html#cupsPrintFile

Re: QIDF versus ICC

2016-08-01 by brian_downunda@...

This secret conversion issue also applies to Windows. It's true that you don't have to select "Printer Manages Colours" on Windows to get access to ABW in the Epson Driver, but I suspect that most ABW users will do that anyway and thus get the secret conversion.

Because if they instead select Photoshop manages colours then they also have to select a profile, and what would the average user then do? A QTR user may have created an ICC for ABW that they could use, but that's not typical, and not all QTR users would want to do that anyway. You can select the null conversion trick (e.g. AdobeRGB -> AdobeRGB), but Photoshop then gives you this scary warning that would put the typical user off, even though the null conversion still works, last I tried it. Or you can fool PS by assigning sRGB, but that's not something the average user would do either.

So although there are little known workarounds to this little known problem, because they're all little known it remains an issue in Windows.

Re ACPU, the Windows version is broken, in that no matter what margins you use, it always prints with zero top and left margins. So it's useless for image printing, unless you happen to want zero margins. Does anyone have a working version in Windows or are they all broken like this?

[The relevance of all this to a QTR forum is that there is some mention of QTR-generated ICCs.]


---In QuadtoneRIP@yahoogroups.com, <info@...> wrote :

Paul (Lowry) You did not get lost, I did, sorry.

You are right, everything concerning this secret conversion would only apply to MAC users who must select “printer manages colour” in order to have access to the ABW mode.

RE: [QuadtoneRIP] Re: QIDF versus ICC

2016-08-01 by <info@...>

A QTR user may have created an ICC for ABW that they could use, but that's not typical, and not all QTR users would want to do that anyway.


Brian,


Could you help me understand what a Windows QTR user would be doing printing from Photoshop if he didn’t have a QTR profile. I’m having trouble seeing the «QTR » part of the QTR user. Is there a way of importing a QIDF curve into the Epson ABW driver on Windows or some other point of entry after sending the file from Photoshop? I can’t see why a windows QTR user without a QTR profile wouldn’t just be printing through the GUI.


Paul








De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com]
Envoyé : July-31-16 9:46 PM
À : QuadtoneRIP@yahoogroups.com
Objet : [QuadtoneRIP] Re: QIDF versus ICC








This secret conversion issue also applies to Windows.  It's true that you don't have to select "Printer Manages Colours" on Windows to get access to ABW in the Epson Driver, but I suspect that most ABW users will do that anyway and thus get the secret conversion.


Because if they instead select Photoshop manages colours then they also have to select a profile, and what would the average user then do?  A QTR user may have created an ICC for ABW that they could use, but that's not typical, and not all QTR users would want to do that anyway.  You can select the null conversion trick (e.g. AdobeRGB -> AdobeRGB), but Photoshop then gives you this scary warning that would put the typical user off, even though the null conversion still works, last I tried it.  Or you can fool PS by assigning sRGB, but that's not something the average user would do either.


So although there are little known workarounds to this little known problem, because they're all little known it remains an issue in Windows.


Re ACPU, the Windows version is broken, in that no matter what margins you use, it always prints with zero top and left margins.  So it's useless for image printing, unless you happen to want zero margins.  Does anyone have a working version in Windows or are they all broken like this?


[The relevance of all this to a QTR forum is that there is some mention of QTR-generated ICCs.]






---In QuadtoneRIP@yahoogroups.com, <info@...> wrote :


Paul (Lowry)   You did not get lost, I did, sorry.





You are right, everything concerning this secret conversion would only apply to MAC users who must select “printer manages colour” in order to have access to the ABW mode.

Re: QIDF versus ICC

2016-08-01 by Tracy Valleau

I'll toss this in as an aside, since a lot of people are not aware of 
it:

On a Mac, there IS a built-in way to send a file directly to your 
printer, ala PrintTool or Adode's CPU.

Open ColorSync Utility. Choose file/open and open the target file. 
Choose print, and from the Color: popup menu choose print as color 
target.



Tracy
www.valleau.gallery

Re: QIDF versus ICC

2016-08-01 by brian_downunda@...

Paul, in trying to be brief (something I don't often achieve), I wrote that sentence in a way that is cryptic and confusing. A "QTR user" is unlikely to print using ABW, and certainly not this little black duck, except occasionally out of idle curiosity. A Windows QTR user is not going to be printing from Photoshop. There's no way to specify an ICC or anything else in the ABW driver. I gather there used to be, but Epson in their infinite wisdom removed it.

Rather what I meant was ... someone who wanted to print using ABW could use QTR-Create-ICC-RGB to create an ICC profile for ABW. They'd need to avoid the silent conversion problem in doing so. But having done so they could then use the ICC to soft-proof, and then in the PS print dialog they select PS manages colours and select the QTR-generated ICC profile, and in the printer settings select ABW. You can do this on Windows easily enough. I don't have access to an OS X copy of PS to check whether it's possible there too - there were earlier suggestions that it's not.

I *think* there was an earlier comment in this thread from Eugene to the effect that ABW wasn't that far from linear. That's not what I found when I've measured it, not by a very long shot. I don't understand what Epson were trying to achieve when they designed its behaviour. But there are a lot of people out there who think it's wonderful. I guess you can adapt to anything.

What the QTR-generated ICCs can do is give an ABW user is some predictability and control. You can either adopt a workflow like the one I described in the second para, although converting to the ICC raises the same issues of crushing shadow detail as you get when convert and print via QTR. Or you can adopt the preserve numbers soft-proof approach and not convert when printing via ABW, but then you still have to avoid the silent conversion problem at print time.


---In QuadtoneRIP@yahoogroups.com, <info@...> wrote :

A QTR user may have created an ICC for ABW that they could use, but that's not typical, and not all QTR users would want to do that anyway.

Brian,

Could you help me understand what a Windows QTR user would be doing printing from Photoshop if he didn’t have a QTR profile. I’m having trouble seeing the «QTR » part of the QTR user. Is there a way of importing a QIDF curve into the Epson ABW driver on Windows or some other point of entry after sending the file from Photoshop? I can’t see why a windows QTR user without a QTR profile wouldn’t just be printing through the GUI.

Paul


Re: [QuadtoneRIP] Re: QIDF versus ICC

2016-08-02 by Roy Harrington

Eugene,

I think I get what you are saying -- see if this is what you mean.

You have a printer/ink/paper combo that goes from L*16 to L*100.
For editing you are using GG2.2 so L*16 is about K=83.
So while editing you are using and seeing K=0 through K=83 thus
seeing specifically the L* range of the paper. Then when you print
you expect L=100 to map to white paper (no inks) and K=83 to
map to the L=16 dMax -- and probably all the L 's in the middle match.
Sounds kind of nice in general -- but I guess I've never heard anyone
doing it this way. I think people in general use generic workspaces
like GG2.2 -- edit as they like on the screen. Then that's a "master"
image file that you can print to matte paper, photo paper or web sites.
The mappings are always K=100 to K=100 even if K=100 on the
paper is L=16 or L=4. ICC CM is the tool that does this mapping in
a way that hopefully does a "best" job given that compression.

In your way you give up 17% of the range in GG2.2 -- 8-bit that would
be an issue but with 16-bit its probably not serious. (there still are 8-bit
places in workflow though). More of an issue though is that now you
have to have separate masters for different targets -- i.e. matte master
and photo master, and maybe for different individual papers.
Essentially you are editing in a "print" space rather that a generic
space that you can convert as needed for any print space. I see the
whole ICC profiling purpose is to get away from that.

This is my impression about how most people do things. I'm certainly
more in the B&W world than color, and I don't do ad's that have to
match specific colors, nor try to make exact L-value targets or something.
Of course, I don't profess any absolute of how you should do a workflow.

Roy
Show quoted textHide quoted text
On Sun, Jul 31, 2016 at 7:58 AM, Le Mois de la Photo à Uqbar info@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:
Roy,



“You need to try it. I don';t know what you are really trying to accomplish”.



This surprises me , it makes me feel like I’m from another planet. But maybe I am in some respects I’m getting the feeling that my perception of the ICC workflow is actually a completely different school of thought to the QTR workflow .

In the ICC workflow that I am familiar with the media type settings ( ink level curves) do not remap file data to maximum black, colour management does.



So in that light this is what I mean to accomplish is



Obviously The L*0 to ( roughly L*3 -8 for glossy papers or L*17- L*22 for Matte papers) values of the image file have to be moved to the maximum ink level of the paper /printer combination. In the dark room we made test strips to determine precisely where Dmax yielded to the first visible tone. In the ICC work flow I only know of 3 ways to accomplish this, either; a conversion using perceptual rendering to the output profile, a conversion using relative rendering in conjunction with Adobe Black Point Compensation or a conversion using relative with no BPC where the black point has been manually targeted beforehand. Perceptual rendering and BPC are like automatic modes. I have never fully understood the behaviour of BPC especially where colour data is concerned, and since I’m a control freak, I prefer to do it myself.



When I print a chart of the 100 L* values in an ICC workflow with relative intent and no BPC I can verify ( under lighting conditions the final print will be displayed in) exactly where DMAX is lost and the length of the toe,( the distance between the first appearance of visible line and a usable threshold density). This allows me to see which paper/ printer combinations take as much as 5 L* to move from the first visible line to usable threshold density, and which paper/ printer combinations can make clean and clear tonal distinction rapidly. The elasticity of this dmax to usefull threshold zone allows me to place whatever deep shadow detail I do not want to be printed with anything less than useful threshold density, precisely there. Then once I’ve compressed the curve by targeting the black point and threshold I can use a target curve with soft proofing to realign the L* axis should I feel the uniform compression fused contours, or simply to readjust local contrast, especially if vital vibrations from tonal juxtapositions were diminished by the uniform compression.



As a said previously I have the feeling the QTR workflow attempts to do this with ink level curves.



I can’t believe that this approach is alien to you I have to believe I’m not expressing myself properly. I hope this detailed description helps.



Eugene


--

RE: [QuadtoneRIP] Re: QIDF versus ICC

2016-08-02 by Le Mois de la Photo à Uqbar

Roy, we are almost on the same page.

 

I edit in GG2.2 or Adobe 1998 using all 100 L*(or K=100 to K=100 as you wrote) with no consideration of output profile. I am in complete agreement with you; there is no other way to edit. If the darkest pixel is not already at L*0 and the lightest at L*100 after Raw conversion, I make a black point and white point adjustment that places them there. When I’m finished editing the image, it is beautiful in the full dynamic range of the workspace and the screen. 

 

The target adjustments are only applied just prior to printing. 

 

Only after completing the editing stage do I flatten the file and save it as a Master. Back in the 8 bit days I did not flatten the Master preferring instead to apply all adjustments simultaneously, but in a 16 bit file I am not afraid of data loss, since I have 32,768 levels of grey and humans can only perceive 100.  

 

Then I begin the targeting stage. I make groups for every separate output (glossy paper, matte paper or web site). Each group bears the name of its output profile. Inside each group I make a series of target adjustments. In B&W these are essentially, black point target adjustment and reproduction curve target adjustment. The black point target adjustment can be applied blindly; once a paper / printer combination has been tested it will never change. To continue your example of a matte paper with Dmax of L*16 (which as you say is 83% in a workspace with a gamma of 2.2), the black point adjustment (usually levels) uses the output slider to make an L*0 = L*16 adjustment. This compresses the curve. The second target adjustment (which is purely aesthetic) is done using soft proofing on an image to image basis.  I create a temporary duplicate of the file and compare the workspace view to the soft proof view (configured with relative rendering & no BPC) with the black point target adjustment active, (and therefore the simulate black ink off).  Should I think certain forms or contours of the image were particularly disadvantaged by the uniform compression of the curve after the BP adjustment I rectify the curve accordingly. 

 

Then I make a workprint and… for me (and I know this is controversial), I never look back at the screen again, after the first print the only viable reference is the print.  

 

Then, should I want to print the master file on glossy paper I just deactivate the matt paper group and begin a new set of target adjustments for the glossy paper. If the glossy paper is Museo Silver Rag, on the P800 this black point target adjustment is L*0 = L*2, and as you can imagine the target reproduction curve adjustment is minimal if needed at all.

 

Before I discovered QTR I was operating in a “same as source” work flow in B&W. I had to develop a working relationship between ink densities and file data for each paper/ printer combination. My only other option was to print B&W with colour inks and I’m sure everyone on this list understands why I didn’t want to do that. 

 

Eugene

 

 

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com] 
Envoyé : August-01-16 9:51 PM
À : QuadtoneRIP@yahoogroups.com
Objet : Re: [QuadtoneRIP] Re: QIDF versus ICC

 

  

Eugene,

 

I think I get what you are saying -- see if this is what you mean.

 

You have a printer/ink/paper combo that goes from L*16 to L*100.

For editing you are using GG2.2 so L*16 is about K=83.

So while editing you are using and seeing K=0 through K=83 thus

seeing specifically the L* range of the paper.  Then when you print

you expect L=100 to map to white paper (no inks) and K=83 to

map to the L=16 dMax -- and probably all the L 's in the middle match.

Sounds kind of nice in general -- but I guess I've never heard anyone

doing it this way.  I think people in general use generic workspaces

like GG2.2 -- edit as they like on the screen.  Then that's a "master"

image file that you can print to matte paper, photo paper or web sites.

The mappings are always K=100 to K=100 even if K=100 on the

paper is L=16 or L=4.  ICC CM is the tool that does this mapping in

a way that hopefully does a "best" job given that compression.

 

In your way you give up 17% of the range in GG2.2 -- 8-bit that would

be an issue but with 16-bit its probably not serious.  (there still are 8-bit

places in workflow though).   More of an issue though is that now you

have to have separate masters for different targets -- i.e. matte master

and photo master, and maybe for different individual papers.

Essentially you are editing in a "print" space rather that a generic

space that you can convert as needed for any print space.  I see the

whole ICC profiling purpose is to get away from that.

 

This is my impression about how most people do things.  I'm certainly

more in the B&W world than color, and I don't do ad's that have to

match specific colors, nor try to make exact L-value targets or something.

Of course, I don't profess any absolute of how you should do a workflow.

 

Roy

 

On Sun, Jul 31, 2016 at 7:58 AM, Le Mois de la Photo à Uqbar  <mailto:info@...> info@... [QuadtoneRIP] < <mailto:QuadtoneRIP@yahoogroups.com> QuadtoneRIP@yahoogroups.com> wrote:

Roy,



“You need to try it.  I don't know what you are really trying to accomplish”.



This surprises me , it makes me feel like I’m from another planet. But maybe I am in some respects  I’m getting the feeling that my perception of the  ICC workflow is actually a completely different school of thought to the  QTR workflow .

In the ICC workflow that I am familiar with the media type settings ( ink level curves) do not remap file data to maximum black, colour management does.



So in that light this is what I mean to accomplish is



Obviously The L*0 to ( roughly  L*3 -8 for glossy papers or L*17- L*22 for Matte papers)  values of the image file have to be moved to the maximum ink level of the paper /printer combination. In the dark room we made test strips to determine precisely where Dmax yielded to the first visible tone. In the ICC work flow I only know of 3 ways to accomplish this,  either;  a conversion using perceptual rendering to the output profile, a conversion using relative rendering in conjunction with Adobe Black Point Compensation or a conversion using relative with no BPC where the black point has been manually targeted beforehand. Perceptual rendering and BPC are like automatic modes. I have never fully understood the behaviour of BPC especially where colour data is concerned, and since I’m a control freak, I prefer to do it myself.



When I print a chart of the 100 L* values in an ICC workflow with relative intent and no BPC I can verify ( under lighting conditions the final print will be displayed in)  exactly where DMAX is lost and the length of the toe,( the distance between the first appearance of visible line and a usable threshold density). This allows me to see which paper/ printer combinations take as much as 5 L* to move from the first visible line to usable threshold density, and which paper/ printer combinations can make clean and clear tonal distinction rapidly.  The elasticity of this dmax to usefull threshold zone allows me to place whatever deep shadow detail I do not want to be printed with anything less than useful threshold density, precisely there.  Then once I’ve compressed the curve by  targeting the black point and threshold I can use a target curve with soft proofing to realign the  L* axis should I feel the uniform compression fused contours, or simply to readjust local contrast,  especially if  vital vibrations from tonal juxtapositions were diminished by the uniform compression.



As a said previously I have the feeling the QTR workflow attempts to do this with ink level curves.



I can’t believe that this approach is alien to you I have to believe I’m not expressing myself properly. I hope this detailed description helps.



Eugene

 

 

-- 

Roy Harrington
roy@...
www.harrington.com





[Non-text portions of this message have been removed]

RE: [QuadtoneRIP] Re: QIDF versus ICC

2016-08-03 by donsbryant@...

---In QuadtoneRIP@yahoogroups.com, <info@...> wrote :

@Eugene:

If you are a Windows user why aren't you printing with QTRGui? Convert your files to gray gamma 2.2 and then print.

If you are editing in PS in color first use Adobe1998 color space which uses gamma 2.2, then convert.

I'm just saying ...

As for Andrew Rodney's vs Ctein's discussion if you use a color managed workflow for color printing then follow Rodney's suggestion.

Don Bryant

Re: QIDF versus ICC

2016-08-07 by sanking@...

I *think* there was an earlier comment in this thread from Eugene to the effect that ABW wasn't that far from linear. That's not what I found when I've measured it, not by a very long shot. I don't understand what Epson were trying to achieve when they designed its behaviour. But there are a lot of people out there who think it's wonderful. I guess you can adapt to anything.


I am a bit late in replying, but my experience in comparing ABW with QTR is the same as that of Brian, i.e. ABS is far from linear.

I compared step wedges printed with the Epson 7880 using ABW and QTR on Epson Enhanced matte, both with Warm tone selected. I then scanned the step wedges with an iOne and ran the data through QTR Linearize Data. As you can see, the QTR print is almost perfectly linear and requires no correction, whereas the ABW print needs a significant curve to make the output completely linear.

The A and B values are so similar it looks to me that both ABC-Warm and QTR-Warm are using only all gray inks, MK, LK and LLK.

I posted the QTR Linearize .out data in the zzMisc folder in the Files section if anyone is interested in looking at them.

Sandy

Re: QIDF versus ICC

2016-08-08 by info@...

I think I said ABW “dark mode” was as linear as one might expect.


In my testing context I am sending a wedge with L* patches, directly to the ABW driver via Photoshop, then reading the patches with an Eye One. Of the 5 modes available (light, normal, dark, darker, darkest) I found “dark” was the most linear and, (factoring in the realignment of grey values due to the differences in DMAX,) acceptably linear to build a profile on.


Without establishing parameters we may be all saying the same thing with different tolerances for variation. It goes without saying that no matt paper will ever be linear, unless we are not using the definition in the same way. If linear means all the input L* produce their real world coefficients in ink density that would be impossible. A paper with a DMAX of L*22 will never be able to redistribute the missing 20L* and regain perfect alignment. You can’t make 100 input grey values be the same as 78 output grey values.


I don’t think perfect alignment is the goal, intelligent realignment is.


Eugene

Re: [QuadtoneRIP] Re: QIDF versus ICC

2016-08-08 by Roy Harrington

Hi Sandy

I'm reluctant to keep this thread going but I think it worth pointing out a couple things.

ABW has two issues that are important:

1) the obvious one -- there are multiple "dark/light" options -- darkest,darker,dark,normal,light
so you can pick different "curve" targets when printing. Darker is the default.

2) the hidden one -- in general the printing is trying to match the L-values of the target --
using either the real embedded profile or the assumed one -- its pretty likely to be matching
GG2.2 or sRGB both of which are darker in the shadow area compared to linear.
(this is true unless App you are using to print happens to have No CM with ABW)
I also think ABW is designed to match these popular editing spaces.

Roy

Show quoted textHide quoted text
On Sun, Aug 7, 2016 at 4:45 PM, sanking@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:


I *think* there was an earlier comment in this thread from Eugene to the effect that ABW wasn't that far from linear. That's not what I found when I've measured it, not by a very long shot. I don't understand what Epson were trying to achieve when they designed its behaviour. But there are a lot of people out there who think it's wonderful. I guess you can adapt to anything.


I am a bit late in replying, but my experience in comparing ABW with QTR is the same as that of Brian, i.e. ABS is far from linear.

I compared step wedges printed with the Epson 7880 using ABW and QTR on Epson Enhanced matte, both with Warm tone selected. I then scanned the step wedges with an iOne and ran the data through QTR Linearize Data. As you can see, the QTR print is almost perfectly linear and requires no correction, whereas the ABW print needs a significant curve to make the output completely linear.

The A and B values are so similar it looks to me that both ABC-Warm and QTR-Warm are using only all gray inks, MK, LK and LLK.

I posted the QTR Linearize .out data in the zzMisc folder in the Files section if anyone is interested in looking at them.

Sandy






--

Re: [QuadtoneRIP] Re: QIDF versus ICC

2016-08-08 by Roy Harrington

Eugene,

When you say "sending a wedge with L* patches, directly to the ABW driver via Photoshop",
do you mean a target that you have specifically designed as evenly spaced L* patches or
is it the target with the more usual evenly spaced K-value patches.
All the targets are mostly available are even K-values with no embedded profile and
therefore are assigned your working space in Photoshop when you read them in.
Note also printing to ABW with Photoshop will involve some color conversions as was talked
about earlier in this thread.

Roy
Show quoted textHide quoted text
On Mon, Aug 8, 2016 at 9:52 AM, info@moisdelaphoto.ca [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:


I think I said ABW “dark mode” was as linear as one might expect.


In my testing context I am sending a wedge with L* patches, directly to the ABW driver via Photoshop, then reading the patches with an Eye One. Of the 5 modes available (light, normal, dark, darker, darkest) I found “dark” was the most linear and, (factoring in the realignment of grey values due to the differences in DMAX,) acceptably linear to build a profile on.


Without establishing parameters we may be all saying the same thing with different tolerances for variation. It goes without saying that no matt paper will ever be linear, unless we are not using the definition in the same way. If linear means all the input L* produce their real world coefficients in ink density that would be impossible. A paper with a DMAX of L*22 will never be able to redistribute the missing 20L* and regain perfect alignment. You can’t make 100 input grey values be the same as 78 output grey values.


I don’t think perfect alignment is the goal, intelligent realignment is.


Eugene






--

Re: QIDF versus ICC

2016-08-09 by brian_downunda@...

Like Roy, I hesitate to keep this going, but thought that it may help to see some charts of what I described earlier. Using EEM, I printed and measured the 21x4 using each of the five ABW modes and plotted the results. Note that in doing this I was careful to avoid the silent profile conversion issue.

http://www.inkjetmall.com/tech/attachment.php?attachmentid=1197&d=1470700983


Why was ABW designed like this? Roy's comment about the assumed editing space is the best explanation that I've heard. What really puzzled me was that it's different on gloss. This is the middle ABW setting on Ilford Smooth Pearl:


http://www.inkjetmall.com/tech/attachment.php?attachmentid=1158&d=1461312224


[I hope these image links work.]


Re: QIDF versus ICC

2016-08-09 by brian_downunda@...

My attempt to get smart and link just to the images didn't entirely work I gather, so here are the images as they appeared in the relevant IJM forum posts:

Matte (EEM): http://www.inkjetmall.com/tech/showthread.php?2173-Piezography-in-Vancouver-BC&p=10349&viewfull=1#post10349

Gloss (ISP): http://www.inkjetmall.com/tech/showthread.php?2288-Epson-3800-P2-Setup-Apparent-Linearization-Issue&p=10998&viewfull=1#post10998



---In QuadtoneRIP@yahoogroups.com, <brian_downunda@...> wrote :

Like Roy, I hesitate to keep this going, but thought that it may help to see some charts of what I described earlier. Using EEM, I printed and measured the 21x4 using each of the five ABW modes and plotted the results. Note that in doing this I was careful to avoid the silent profile conversion issue.

http://www.inkjetmall.com/tech/attachment.php?attachmentid=1197&d=1470700983


Why was ABW designed like this? Roy's comment about the assumed editing space is the best explanation that I've heard. What really puzzled me was that it's different on gloss. This is the middle ABW setting on Ilford Smooth Pearl:


http://www.inkjetmall.com/tech/attachment.php?attachmentid=1158&d=1461312224


[I hope these image links work.]


Re: QIDF versus ICC

2016-08-09 by richard@...

I've been busy the last week and have just been watching this from afar and somewhat puzzled.

Eugene, after these 40 some-odd posts I am still not sure what you are trying to get at here, but I think there is misunderstanding of some of the fundamental principles of custom QTR Curves (or media settings). The whole point is to see what the deepest Dmax you can have with a printer/ink/paper combination and then map your 100%K in the image to that print density and then have perfectly even spaces between each of L\* measurements for however many steps you want to measure. There are all sorts of arguments that can be made for how to best alter that linear density distribution to better match what you see on the display or match your working space or some combination of the two, but the first step is always getting the printer to behave in a predictable and measurable way.

Here is the point that I really wanted to make though: I think you are confusing trying to get a print to match the CIELAB color space and the printer’s linear L*a*b* L* measurements for a set of custom QTR curves (media settings). I might not have this exactly right, but CIELAB is more of a theoretical space that is an approximation of human visual scale and we just use it to measure print values against. There isn’t anything that can actually match it. Furthermore, actually trying to match it can actually lead to other problems.

Printing on Glossy papers, where you can reach a L*a*b* L* of 2-3 results in something that almost parallels the CIELAB space with little loss on the high and low end, but does result in something that *appears* slightly darker in the midtones and slightly lighter in the shadows than you would expect to see on the display (based on printing with no CM). One thing I have found helpful is to*apply* the QTR RGBLAB profile to the image (not converting) and then edit the image so that it looks correct through the midtones and shadows. That is really only helpful for glossy prints because it is fairly close to CIELAB and needs minor tweaking. BUT, I generally don’t like to have a Dmax that high because it can cause problems in other ways, like showing inkjet prints and gelatin silver prints in the same show, or just not being able to see the details in the deepest shadows (even if they are in the image file, like between 95%-98%K).

Matte papers are more problematic because of the much lower Dmax when compared to glossy prints. If you were to try to parallel CIELAB as long as possible before reaching the Dmax and leveling off, you would get a print that appears MUCH too dark through get midtones. I’ve done a lot of testing to see what gives the best appearing matte prints without losing detail in the shadows while still not being as open as what you would get with a Linear L* and a Dmax of 15-17, and I’ve come up with something that works for me personally, and I modify it for each paper I work with.

Which gets me to the final point. What is with this overall concern for matching CIELAB, GG2.2? The print is never going to match it perfectly, and the screen is in no way going to give you exactly what you will see in the print. Why not just get the printer to behave predictably (like you can with custom QTR curves) and then PRINT. You will learn exactly what each tone in the image will look like with that printer/ink/paper and will be able to edit the image accordingly. There used to be a thing people did in the darkroom that tends to get lost with some of this digital stuff. They would get to know and master the materials and then make intuitively adjustments based on experience.


Richard Boutwell

RE: [QuadtoneRIP] Re: QIDF versus ICC

2016-08-09 by Le Mois de la Photo à Uqbar

Richard

 

I’m not going to labour this.  I afraid that I began this post with a small question but spent far too much time trying to explain the context within which I was asking the question.  

 

There is obviously a disconnect between the QTR environment, at least those who are responding to this thread, and the standard colour management work flow. This colour managed workflow is not my invention it is the Universal production standard (UPDIG) for colour ink printing.  The goal of colour management is not to match CIE lab, which as a derivative model of the original Standard Observer is a graphic representation of the human perception of light.  As you wrote, nothing material could. The coordinates of the (L*a*b*) define colour unambiguously. The goal of colour management is to translate colour from one space to another, like a dictionary translates words from one language to another. 

 

I guess what I am trying to accomplish, in fact what I do accomplish, is to apply the colour management workflow to B&W printing. This is only possible because of the QTR ICC profile. 

 

If you are working in digital imagery and you are making prints there are only two options “same as source” or “colour managed”. Outside of colour management all files are untagged even if you think you are in a greyscale space. In a “same as source” workflow the file data is not converted, so you are sending untagged digital data (file data that will eventually become electronic control signals that communicate directly to the print heads) and through trial and error matching data to ink densities.  If you are in a colour managed workflow you are using a chain of look up tables (that serve as dictionaries) through a series of colour space conversions that translate the colour associated to the source file data to its respective place in the destination file data. Discrepancies in colour spaces are either dealt with systemically (perceptual rendering or Adobe BPC) or manually through targeting curves for out of gamut values or colours.  

 

I’ve already sent a “sign off” or conclusion of sorts to this post, apparently the message has not arrived yet, if it does not please accept this message as a final conclusion to this thread. 

 

I’m sorry to have stirred the waters and perhaps muddied them for some. 

 

Eugene

 

 

De : QuadtoneRIP@yahoogroups.com [mailto:QuadtoneRIP@yahoogroups.com] 
Envoyé : August-09-16 10:33 AM
À : QuadtoneRIP@yahoogroups.com
Objet : [QuadtoneRIP] Re: QIDF versus ICC

 

  

I've been busy the last week and have just been watching this from afar and somewhat puzzled.

 

Eugene, after these 40 some-odd posts I am still not sure what you are trying to get at here, but I think there is misunderstanding of some of the fundamental principles of custom QTR Curves (or media settings).  The whole point is to see what the deepest Dmax you can have with a printer/ink/paper combination and then map your 100%K in the image to that print density and then have perfectly even spaces between each of L\* measurements for however many steps you want to measure. There are all sorts of arguments that can be made for how to best alter that linear density distribution to better match what you see on the display or match your working space or some combination of the two, but the first step is always getting the printer to behave in a predictable and measurable way. 

 

Here is the point that I really wanted to make though: I think you are confusing trying to get a print to match the CIELAB color space and the printer’s linear L*a*b* L* measurements for a set of custom QTR curves (media settings). I might not have this exactly right, but CIELAB is more of a theoretical space that is an approximation of human visual scale and we just use it to measure print values against. There isn’t anything that can actually match it. Furthermore, actually trying to match it can actually lead to other problems.

 

Printing on Glossy papers, where you can reach a L*a*b* L* of 2-3 results in something that almost parallels the CIELAB space with little loss on the high and low end, but does result in something that *appears* slightly darker in the midtones and slightly lighter in the shadows than you would expect to see on the display (based on printing with no CM). One thing I have found helpful is to*apply* the QTR RGBLAB profile to the image (not converting) and then edit the image so that it looks correct through the midtones and shadows. That is really only helpful for glossy prints because it is fairly close to CIELAB and needs minor tweaking. BUT, I generally don’t like to have a Dmax that high because it can cause problems in other ways, like showing inkjet prints and gelatin silver prints in the same show, or just not being able to see the details in the deepest shadows (even if they are in the image file, like between 95%-98%K).

 

Matte papers are more problematic because of the much lower Dmax when compared to glossy prints. If you were to try to parallel CIELAB as long as possible before reaching the Dmax and leveling off, you would get a print that appears MUCH too dark through get midtones. I’ve done a lot of testing to see what gives the best appearing matte prints without losing detail in the shadows while still not being as open as what you would get with a Linear L* and a Dmax of 15-17, and I’ve come up with something that works for me personally, and I modify it for each paper I work with. 

 

Which gets me to the final point. What is with this overall concern for matching CIELAB, GG2.2? The print is never going to match it perfectly, and the screen is in no way going to give you exactly what you will see in the print. Why not just get the printer to behave predictably (like you can with custom QTR curves) and then PRINT. You will learn exactly what each tone in the image will look like with that printer/ink/paper and will be able to edit the image accordingly. There used to be a thing people did in the darkroom that tends to get lost with some of this digital stuff. They would get to know and master the materials and then make intuitively adjustments based on experience.

 

 

Richard Boutwell

Re: [QuadtoneRIP] QIDF versus ICC

2016-08-09 by forums@walkerblackwell.com

I think it important to “de-confuse” people about what gamma is.

Gamma was created only as a compensation for tube screens that (by default) compressed shadow tones extremely and needed a very heavy ramp-up in power to show a linear image. The industry fluttered for awhile and then settled on gamma 2.2 and the encoding algorithm to compensate for an image to then be fired analogue through a monitor that has no tone translation abilities of its own. That is the short story. Look it up on the googles for the long version.

It’s only a theoretical number that is a standard just to be a standard (or just to be backwards compatible). In short, it’s a dinosaur. Linearizing can be done for a gamma 1.0 image as it could be done for a gamma 3.2 (just picked a number out of a hat) image. A gamma 3.2 image in photoshop will be translated in photoshop internally and then be translated in the system/video-cart and then in the monitor to show exactly the same tones as 2.2. Go ahead and try it.

Encode a target in gamma 1.0 and print it and linearize that target. Then print an image in gamma 1.0. It will print the same as a 2.2 image with a curve calibrated for 2.2. These are all just bla bla numbers that are there as intellectual anchor-points so Joe's image that he creates on his system system will print the same on Jane’s system because everyone has just agreed that 2.2 is the way. It’s like the US currency. It’s the GAMMA DOLLAR.

The problem comes from the fact we generally don’t like how flat things look when the dMax is light. That linear line is no longer at a 45 degree angle so it makes the print look LIGHT slightly. We soft-proof and get expensive monitors to flatten the monitor-image out to look like matte papers but it’s not perfect. Sometimes we need a small curve applied to the image at-print that brings the contrast up a bit. This seems to make people happy.

Printing like this all comes at the cost of tonal fidelity (specifically in the shadows). 

None of it has ANYTHING to do with GAMMA. It’s not about matching gamma 2.2 on your monitor. That is not what it is. It’s about matching the contrast of your monitor which tends to be higher than what a matte print can produce.

best,
Walker

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.