QTR-Quadtone RIP

--- In QuadtoneRIP@yahoogroups.com, "Joost Horsten" <j.h.j.h@...> 

> You seem more knowledgeable in this then I am, so I hesitate to 
take 
> to strong position here. But I don't think this can work in a 
general 
> sense. You assume that a change of hue has no effect on luminance. 
In 
> reality, a different hue will be realised with a different "sub ink 
> set" (e.g. cool vs. warm toners). In general they will need a 
> different linearization profile. To me, if their physical 
properties 
> are exactly matched your assumption is true. If that is not the 
case 
> (which is in practice, or at least I don't want to rely on it), a 
> change of hue will effect luminance.
> 
> Having said the above, I can see how a modification of your 
proposed 
> workflow could work. If you make three curves, one for each 
primary, 
> I imagine one could build a host of different UIs/hue control 
> mechanisms on top of it. The ABW for one, the sliders as proposed 
by 
> Roy as another, a color-like workflow as proposed by David Tobie or 
> alpha-channels as proposed by Tom. And only three curves is already 
a 
> WORLD of difference, with the infinite amount of curves I would 
have 
> to make now in QTR to get all the hues and split-tones I would like 
> to try.
>

Ernst,

While cycling to work, a further argumentation came to my mind. In 
your approach, where you write: 

"In this case
it is a smaller gamut and it doesn't have to handle color just
luminance. The only difference is that we exchange one hue for
another to some degree and never extreme.", 

you seem to assume that hue (LAB a and b) axes can be assumed are 
orthogonal to the Luminance axis. That seems too coarse an assumption 
to me. I find proof in the fact that each of the UT3D hues (warm, 
cool, selenium) have slightly different linearization curves. They're 
similar, but different. The key point of QTR is to linearize the 
curves. And by doing so, the effect is that the hue axes on hand and 
the luminance axis on the other become orthogonal.

And on top that orthogonal framework one could build these different 
hue control mechanisms (changing hue without changing the luminance).

Joost


P.S. This brings another possbile work flow approach to my mind. I'm 
not sure how it would work in practice, just throwing it into the 
group...

In stead of working in an RGB space, as is currently discussed in the 
DB&WTP forum, on could think of working in LAB. In effect when 
working with QTR, we already do so, but restricted to a=b=0. So this 
seems much more natural for B&W. The "real B&W work" ;-) is done in 
the L-channel, adding the hues later happens in the a and b channels.

QTR (in an enhanced version) could take the a and b values per pixel 
and interpolate between the (a,b) values of the curves. Of course, 
QTR needs to have this information, but feeding that info would be 
very similar to entering the linearization data (which are actually 
L) values of a step wedge. Of course, this is starting to build some 
kind of color engine, but the big differences with the icc-approach 
is that it would be much more natural for B&W (the a and b channels 
are completely optional) and it does not put any restriction on the 
ink set (any wild combination remains possible, since QTR deals with 
the peculiarities).

In such a hypothetical workflow I would probably completely separate 
the luminance editing (the "real B&W part") and the hue editing, 
which is for me related to the printing process. In my current 
workflow I have basically three files: 
1) the original RAW/DNG file (no or very basic editing done, just for 
archival purposes
2) the "master" file in which I do all the editing (as much as 
possible in a non-destructive way with adjustment layers)
3) the "print" file, a flattened version of the master file, adjusted 
to the appropriate size and resolution, sharpening applied.

The hue editing would be done in the "print" file (or perhaps in an 
intermediate file between "master" and "print"

Does the above make any sense?