QTR-Quadtone RIP

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]