QTR-Quadtone RIP

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