Yahoo Groups archive

QTR-Quadtone RIP

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

Thread

QTR and GO

QTR and GO

2015-01-07 by sanking@...

Would someone explain the QTR/GO issue? I was unaware of this issue until someone mentioned a Level 255 > 254 correction that was applied in an application.

Is this something one should be concerned about in writing QTR profiles where there is no intention to apply a GO layer?

Sandy

Re: [QuadtoneRIP] QTR and GO

2015-01-07 by Paul Roark

I believe that at 255 all inks are off -- including the GO channel. So, files with GO to be applied to the paper white to cut the gloss differential need to have the white point be at 254; nothing in the file should be at 255. If you're not using GO or not using it for gloss differential, where you want it applied to the paper, use the full 0 - 255 range.

Paul
Show quoted textHide quoted text
On Wed, Jan 7, 2015 at 11:35 AM, sanking@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:

Would someone explain the QTR/GO issue? I was unaware of this issue until someone mentioned a Level 255 > 254 correction that was applied in an application.

Is this something one should be concerned about in writing QTR profiles where there is no intention to apply a GO layer?

Sandy


Re: [QuadtoneRIP] QTR and GO

2015-01-07 by Alan Vlach

I think the 255>254 issue is only a concern when creating a negative curve, that is a curve that inverts all the values. I have been experimenting with that with the chart throb curve creator in photoshop to create curves for alternative process negatives. When you create a reverse curve and plug it into a QTR profile it reverses all the values except 255. So where you would expect 100% black you get 100% clear in the transparency. Changing the output value from 255 to 254 in a levels adjustment corrects this. Paul Harrington explained this to me a while ago and it has something to do with the use of gloss optimizer, by piezography I suspect. Paul should probably chime in and clear this up.

Alan
Show quoted textHide quoted text
> On Jan 7, 2015, at 4:06 PM, Paul Roark roark.paul@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:
> 
> 
> I believe that at 255 all inks are off -- including the GO channel.  So, files with GO to be applied to the paper white to cut the gloss differential need to have the white point be at 254; nothing in the file should be at 255.  If you're not using GO or not using it for gloss differential, where you want it applied to the paper, use the full 0 - 255 range.
> 
> Paul
> www.PaulRoark.com <http://www.paulroark.com/> 
> 
> On Wed, Jan 7, 2015 at 11:35 AM, sanking@... <mailto:sanking@...> [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com <mailto:QuadtoneRIP@yahoogroups.com>> wrote:
>  
> Would someone explain the QTR/GO issue? I was unaware of this issue until someone mentioned a Level 255 > 254 correction that was applied in an application.
> 
> Is this something one should  be concerned about in writing QTR profiles where there is no  intention to apply a GO layer?
> 
> Sandy
> 
> 
> 
>

Re: QTR and GO

2015-01-08 by richard@...

In normal usage you want to keep 255 as pure white. I just tested a few ways of editing an ink descriptor file to cause an ink to fire at 255, but when looking at that channel in the .quad files its clear that anything in 255 gets converted to 0.

Alan, do you mean Roy Harrington? When you print with a gloss optimizer with piezography you are printing a white patch with a separate profile thats only value is the ink limit set to the 255 value. When I print digital negatives with the piezography system i don't even worry about the GO—Just pass and that is it. (although i did use it for printing on gold leaf backed transparencies using the full k7 inks)

If you do want an ink to fire at 255 you would need to go into the .quad file and change the first value below "# INK Curve" from 0 to what ever value you wanted between 0-65535 (that upper limit of 65535 is 100% of that channel firing. It is like printing the 100% patch of that ink's separation image calibration mode with the ink limit set to 100).

In any case, I wouldn't worry about it. If you are making digital negatives just invert in photoshop and send that to the printer and don'tworry about trying to embed an inverting curve into the QTR profile.

Richard Boutwell


Re: [QuadtoneRIP] QTR and GO

2015-01-08 by Alan Vlach

Richard,

Yes, I mean Roy Harrington and I am familiar with the Piezography method to print the GO in a separate pass. That was why I mentioned it as a possible reason for reserving the 255 value. Jon Cone seems to work closely with Roy.

The reason I got into this was because I was trying to find a simple way to teach students to calibrate digital negatives without the need for a densitometer. The Chartthrob automated plug-in in Photoshop seemed like a good alternative but, the way it works as originally written, you have to apply the adjustment curve in Photoshop to a positive image then invert the image to a negative before printing. I wanted to apply the adjustment curve in QTR. I spoke with the Charttrob developer and he provided a version that has an option to create a negative curve which can be used in QTR to print a positive image and wind up with a negative. The only problem was the 255 issue.  Roy explained the reasoning to me and the fix is to have no value higher than 254 in your positive.

I prefer to embed the correction curve in QTR rather than applying it to the image in Photoshop. I have no proof other than an intuition (and a hope) that doing it that way is less destructive to the image. Ron Reeder has suggested that it is better and it just seems like it should be better to control the ink distribution (which would be linear) rather than create gaps in your histogram.

I’m glad this subject has suddenly raised so much discussion after many months. I too hope Roy will provide a version of QTR that doesn’t reserve the 255 value. 

Alan
Show quoted textHide quoted text
> On Jan 7, 2015, at 7:29 PM, richard@richardboutwell.com [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:
> 
> In normal usage you want to keep 255 as pure white. I just tested a few ways of editing an ink descriptor file to cause an ink to fire at 255, but when looking at that channel in the .quad files its clear that anything in 255 gets converted to 0. 
> 
> 
> Alan, do you mean Roy Harrington? When you print with a gloss optimizer with piezography you are printing a white patch with a separate profile thats only value is the ink limit set to the 255 value. When I print digital negatives with the piezography system i don't even worry about the GO—Just pass and that is it.  (although i did use it for printing on gold leaf backed transparencies using the full k7 inks)
> 
> If you do want an ink to fire at 255 you would need to go into the .quad file and change the first value below "# INK Curve" from 0 to what ever value you wanted between 0-65535 (that upper limit of 65535 is 100% of that channel firing. It is like printing the 100% patch of that ink's separation image calibration mode with the ink limit set to 100).
> 
> In any case, I wouldn't worry about it. If you are making digital negatives just invert in photoshop and send that to the printer and don'tworry about trying to embed an inverting curve into the QTR profile. 
> 
> Richard Boutwell
> 
> 
>  
> 
>

Re: [QuadtoneRIP] QTR and GO

2015-01-08 by richard@...

I think this is a case of over complicating things.

The reason to "reserve" 255 as a value has nothing to do with piezography or the gloss optimizer. As far as I understand how the QTR curve creations algorithms work, it is simply that computers start counting at 0 so that is where the ink curve must begin. In terms of digital images and printing, pure white is 255 and equals 0 in the ink curve. With that in mind, what Roy says makes perfect sense.

I understand why it is better to embed the process correction curve in the QTR profile. What I question is the reason for embedding the inversion and correction curve in the gray curve step. If all you do is get the 0-100 steps to print linearly (or as close to it as possible) then it doesn't matter if you are sending a positive or a negative into the QTR driver. If you invert the image in photoshop, and then print with the process-corrected QTR profile the input/output values are still 0-100% or 255-0 and you are still not overly-stretching or compressing the original image data.

Of course, the easiest answer is to just invert the file in Photoshop before printing. The pure black 0 values will then be the 255 values and will print clear in the negative (base+fog)—if you don't want to print the shadows completely transparent and would rather put a little ink in the original pure black or 0 values you just need to add a levels adjustment with an black point output value of 1-5 before you invert, or 250-254 after you invert, in which case you are just adding a little more +fog. This levels adjustment is essentially what you are doing, just for a different reason than to hack around how the QTR curves engine works.

When I make digital negatives printing alt-process I prefer to leave room for interpretation in the exposure/contrast mix rather than trying to have a perfectly calibrated negative/positive. I'll usually print a smaller negative as a proof/test print and then re-adjust with an additional curves adjustment layer correction if it isn't working out in the printing stage. (although that is not the case when I am printing inkjet positives on paper). I put the invert adjustment layer above any additional curves adjustment and feed the whole caboodle to the printer. I've found that makes it much easier than trying to fight with any issues in the profiling steps.

Richard Boutwell

Re: [QuadtoneRIP] QTR and GO

2015-01-08 by Alan Vlach

We are obviously not on the same page and have different methods of working. I am sure yours works for you, but mine also works very well for me.
Show quoted textHide quoted text
> On Jan 7, 2015, at 10:54 PM, richard@... [QuadtoneRIP] <QuadtoneRIP@yahoogroups.com> wrote:
> 
> 
> I think this is a case of over complicating things.
> 
> The reason to "reserve" 255 as a value has nothing to do with piezography or the gloss optimizer. As far as I understand how the QTR curve creations algorithms work, it is simply that computers start counting at 0 so that is where the ink curve must begin. In terms of digital images and printing, pure white is 255 and equals 0 in the ink curve. With that in mind, what Roy says makes perfect sense. 
> 
> I understand why it is better to embed the process correction curve in the QTR profile. What I question is the reason for embedding the inversion and correction curve in the gray curve step. If all you do is get the 0-100 steps to print linearly (or as close to it as possible) then it doesn't matter if you are sending a positive or a negative into the QTR driver.  If you invert the image in photoshop, and then print with the process-corrected QTR profile the input/output values are still 0-100% or 255-0 and you are still not overly-stretching or compressing the original image data.  
> 
> Of course, the easiest answer is to just invert the file in Photoshop before printing. The pure black 0 values will then be the 255 values and will print clear in the negative (base+fog)—if you don't want to print the shadows completely transparent and would rather put a little ink in the original pure black or 0 values you just need to add a levels adjustment with an black point output value of 1-5 before you invert, or 250-254 after you invert, in which case you are just adding a little more +fog. This levels adjustment is essentially what you are doing, just for a different reason than to hack around how the QTR curves engine works. 
> 
> When I make digital negatives printing alt-process I prefer to leave room for interpretation in the exposure/contrast mix rather than trying to have a perfectly calibrated negative/positive. I'll usually print a smaller negative as a proof/test print and then re-adjust with an additional curves adjustment layer correction if it isn't working out in the printing stage. (although that is not the case when I am printing inkjet positives on paper). I put the invert adjustment layer above any additional curves adjustment and feed the whole caboodle to the printer. I've found that makes it much easier than trying to fight with any issues in the profiling steps.
> 
> Richard Boutwell
> 
>  
> 
>

Re: [QuadtoneRIP] QTR and GO

2015-01-10 by ctb@...

Another solution could be to adapt the charthrob code. If charthrob could output a curve that corrects a negative instead of a postive this curve could be used in QTR. Instead of correcting 255 to 254 the file needs only to be inverted before printing. This is the normal QTR workflow used by many people with the added convenience of a ready to use charthrob curve. Let's ask Kevin?

-kees

Re: [QuadtoneRIP] QTR and GO

2015-01-10 by Alan Vlach

I already suggested that but maybe a flurry of requests would move him to do it. 

Sent from my iPhone
Show quoted textHide quoted text
> On Jan 10, 2015, at 5:32 AM, "ctb@zeelandnet.nl [QuadtoneRIP]" <QuadtoneRIP@yahoogroups.com> wrote:
> 
> Another solution could be to adapt the charthrob code. If charthrob could output a curve that corrects a negative instead of a postive this curve could be used in QTR. Instead of correcting 255 to 254 the file needs only to be inverted before printing. This is the normal QTR workflow used by many people with the added convenience of a ready to use charthrob curve. Let's ask Kevin?
> 
> -kees
> 
>

Re: [QuadtoneRIP] QTR and GO

2015-01-10 by ctb@...

The function that negates the curve in Charthrob is:

(gNegate) {
for(i=0;i<curvePoints.length;i++) {
curvePoints[i][1] = 255 - curvePoints[i][1];
}

It simply subtrackts the values from 255 to get a negated curve. The math to get a curve that corrects a negative file is somewhat more complicated. Simply put it should be flipped (top/bottom and up/down) round the straight curve axis. Any javascript coders out here that know how to do this?

If so we might fork chartrob on github joker-b/ChartThrob.



-k

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.