I went further in my PiezoDN experience and followed the manual’s instruction to limit the 1430-PiezoDN-Master.quad and made it to the 1430-PiezoDN-Master-lin.quad. I actually used the very same limit number as the manual’s exemple, that correspond to my need.
The “Photoshop curve to apply to the final print” makes sense to me, limiting the highlights.
But looking at the files with QTR-CurveView, I just can’t understand how the lin.quad will make a thinner negative. It seems to me that the changes at the end and middle of the curves will make darker shadows and middtones when the lighter tones of the final print will remain unchanged.
I know curves are reversed because PiezoDN uses positives, and yes that confuses me.
Are you using the regular (negative) Master, or the Pos-Master? You are doing this for Carbon, right? And need a positive transparency?
I’ve never really used Curve-View, but the -lin side of your screen shot looks like it would make a slightly thinner transparency whether positive or negative.
I used the regular 1430-PiezoDN-Master.quad, has shown in the QTR-CurveView window.
QTR-CurveView shows ink load with a 0-100% scale, not L values. Since the original .TIFF file is a positive, the 0% input correspond to the 255 whithe patch of the target that I need to print thinner in the negative (less ink). I don’t see a change here. I see a change further in the curve and mostly at the end, which make the negative thinner in the shadows.
Maybe the limiting process applied to my mind! If no one confirms my doubts, I’ll just print and see…
The limiting procedure does not effect the total amount of ink. (You can do that with the ink limit slider in the QuadtoneRIP driver).
The limiting procedure is there to decrease the optical density of the near-densest tones of the negative (aka the printed highlights) while keeping the most-dense tone the same.
“The limiting procedure is there to decrease the optical density of the near-densest tones of the negative”.
Am I right to believe that when a negative made with the LIMITER target shows paper white “at 223” in the darkroom, the role of the limiting procedure is to make a negative with less density in the highlights that will print something in the darkroom just “beyond 255” with the same exposure? That is adapting (limiting) the Density Range of the negative to the process? I understand it can be done by changing the curves, not the ink limits.
I reprinted a LIMITER.tif target with the 1430-PiezoDN-Master curve, then with the 1430-PiezoDN-Master-lin I got using the limiting procedure described in the manual (again, very same values as in the exemple, I don’t think I messed building the correction curve).
15 mn between both negatives, checking the nozzles before each neg and after. Drying overnight.
I made some optical density readings, using my old X-rite 341 transmission densitometer (for the printing industry) and reported in a spreadsheet. No cheating.
The curves show what I expected looking at the lin.quad curve in QTR-CurveView: the “near-densest tones of the negative” have not changed, only slightly at 223. Main changes are in the less dense tones…
Pardon me, I’m asking again if I’m getting what I’m supposed to get?
You should be limiting from printed data, not data from the negative. Are you doing this?
Looking at the curve screenshots and this density graph shows me that you are limiting the shadow area (least dense part) and not the highlights area (most dense part).
Please upload a screenshot of your curve adjustment tool with the limiting curve applied. It should look nearly identical to the screenshot in the limiting instructions.
My curve adjustment tool looks identical to the screenshot in the limiting instructions, logically.
So I re-did the following steps, copying and pasting the CGATS. I recall I had to do this several times until I selected the datas properly and the droplet would accept them.
Guess what, I have very different curves today (-lin2), that at last seem to go in the right direction! (see attachment)
I’m inkjet-printing a corrected negative now and will carbon-print it tomorrow.
I don’t know what went wrong the first time and how the droplet could accept something from the same CGATS that made such a different .quad; sorry about this.