Piezography-256step-i1Pro2.tif - bad patches?

Piezography Professional Tools
1

While trying to debug some weird repeating evenly-spaced ripple I’m seeing in my i1Pro2 measurements from the 256 step i1Profiler target (I’ll provide more in a separate thread once I’ve isolated what is going on), I went in to Photoshop just to verify the patches in the TIF file. I’ve found 6 patches that don’t give me correct RGB (R=G=B) values as read by the Eyedropper tool. This has nothing to do with the ripple I’m trying to diagnose, but it seems possible that “false” Falses could result. In any case, I’d want all the patches to be correct before using the target for any kind of calibration.

Here’s what I read from the file in Photoshop:

Patch ID 256 = 0,0,0 (OK)
Patch ID 255 = 0,0,0 (should read 1,1,1)
Patch ID 254 = 1,1,1 (should read 2,2,2)
Patch ID 253 = 1,1,1 (should read 3,3,3)
Patch ID 252 = 3,3,3 (should read 4,4,4)
Patch ID 251 = 4,4,4 (should read 5,5,5)
…
Patch ID 242 = 13,13,13 (should read 14,14,14)

I checked randomly over the rest of the target and did not find any other anomalies. It seems odd that five of these patches are clustered right below DMax and the sixth is an outlier at Patch ID 242.

I notice that the target is set for 720ppi, presumably to match QTR’s processing. Was the target subjected to any resizing or other interpolation? Just wondering how these errors would have been introduced, assuming that at some point all the patches were correct.

Your i1Profiler Workflow file is fine: If I load your workflow, then save the target to a new TIF file from i1Profiler, that new TIF file reads as expected (though i1Profiler outputs an 8-bit Untagged RGB file with lower resolution vs. your 16-bit Untagged Gray file @ 720ppi).

Dave

2

This target is a 16bit hard-coded gamma 2.2 file. So you need to set your info pallet to 16bit in order to actually see the correct values. This has zero bearing on the jagged readings.

FWIW, there was a lot of time and research and actual printing and validation that went into making the decision to create a hard-coded (converted but untagged) grayscale gamma 2.2 target vs just leaving it untagged in RGB. Also, we’ve always done a hard-coded target (really, for over 13 yrs this has been the target we give to people when we linearize their systems for them) so I opted to keep the same workflow.

//

Your jagged readings are from the left/right of the target and they correspond to your specific printer model (3880 correct?) that sloshes ink in the dampers and puts down a different amount of ink on the left and the right of the page. This happens with 38xx and P800 printers more than any other printer but is one BIG reason why all good profiling software has error correcting (smoother) algorithms in place. In our case we also have manual falses correction.

best,
Walker

3

Ahh, yes. Sorry I overlooked that. With Info panel set for 16-bit display, it looks fine.

Yes I know (as previously stated).

I’m printing with a 7900, not a 3880. I don’t have the left-to-right problem. My problem is more “top-to-bottom.” So as not to confuse this thread about the target, I will post separately with more details.

Back to discussion about the target:

Other than the empirical evidence and testing done in the past, is there something specifically inherent in an untagged hard-coded gamma 2.2 target that makes it better than an untagged RGB target that is also gamma 2.2? I can see that hard-coding may help prevent people from screwing things up, but is there something more than that? Just trying to understand.

And last question relating to the target: I’m on Windows which (last time I checked) is still limited to an 8-bit printing pipeline, even with QTR. Would it make any sense to be using 8-bit targets vs. 16-bit targets when printing on Windows? Seems like the conversion to 8-bit in the pipeline could just be re-introducing the same kind of rounding or quantization errors I thought I was seeing above.

4

Windows supported 16bit.

See release notes on 2.7.0:http://www.quadtonerip.com/html/ReleaseNotes2.7.0.txt

5

Maybe I’m reading it wrong, but those release notes do not state that the Windows pipeline is now 16 bit.

The release note says “The Windows implementation does not pass the data through the print system like the Mac version does. So 16-bit data changes noted above do not apply to the Windows version. However QTR continues to use all 16-bits of a TIFF data file for creating a print.” (Underline emphasis mine.)

It’s clear that QTR itself fully handles 16-bit image data on both Windows and Mac. But I believe the Windows pipeline (as used by QTR) will at some point convert that 16-bit image data to 8-bit on its way to the printer, hence my previous question regarding using an 8-bit target.

6

No. It does not convert it to 8bit. It creates a raw print file and then just sends this off to the driver to send it to the printer. The driver (Epson driver) does not touch the file.

“QTR continues to use all 16-bits of a TIFF data file for creating a print.” does not mean “QTR somehow randomly switches back to 8bit even though we just said it works in 16-bits”

You can validate this if you want. Print a 16bit 256 step target and measure the last three patches. They will/should be different from each other. If 8bit they won’t be.

-Walker