New user, dark prints, Mac OS 10.11.4, poor linearization

InkjetMall Customer Support Piezography Inks & Printing
1

This is my first post, and I am a new Piezography user. I read the manual. I really, really did. Several times! I am getting dark prints. I have K7 Neutral inks in an Epson 3880. The printer was working fine using mostly ABW (and some color) before I converted to piezography inks a couple of weeks ago. The printer is 2 years old, and I am the only owner. Nozzle checks are good and always have been. Here is where my inks are:
[
]

I am using a NEC PA272W monitor calibrated with SpectraView to 85 cd/m2, D50, contrast ratio 250:1, Gamma 2.20.
I am printing on JCSType5, using curve 3880-WN-SEL-NU-JCStype5, 2880 dpi, uni-directional. I use front feed exclusively to avoid pizza wheel marks.
I use a Mac, OS 10.11.4 (El Capitan), and PS/LR CC2015. I use Print-Tool 1.1.0 to print.
I have a Colormunki Photo, and I have measured the L* values for the ‘21steps-Eye1.tif’ both (a) printing directly in Print-Tool using the unadulterated RGB untagged [it shows up in Print Tool as having an Embedded profile sRGB IEC61966-2.1], and (b) converting it in PS to Grey Gamma 2.20, saving and then printing in PrintTool. I get the same results either way (this is after drying, applying GO using the curve 3800-3880-30000GO, using a leading strip, drying again).

So I realize I must be doing something wrong here but I am out of ideas. The linearity profile does match the darkness of my prints, so at least that appears consistent. So here I am, and hoping I can get help. Thanks, Wayne

2

please post you L values here (the actual numbers)

3

Thank you, Walker
96.9
91.6
86.4
81.1
74.5
68.6
64
60
55.8
51.5
46.6
39
31.6
25
20.2
15.2
12.1
9.3
7
5.2
3.9

4

I tried a couple of things. I ran PS CS3 on an older MacBook running 10.4.9 and printed directly from PS without color management. I got exactly the same non-linear results. As interesting as it was to configure a retro system, it did not help.

I also used Roy Harrington’s Droplet to relinearize the output of the 3880-WN-SEL-NU-JCStype5.quad curve, and while it helped it did not fully fix the issue. If anyone has any help, I would be most appreciative. Not being able to print is frustrating, but you knew that! Thank, you.
Wayne

5

Please try this .quad.

I linearized with your values using Roy’s QTR-Quad-Linearizer droplet. You can too if you export the values as Lab* in cgats.

I’m currently building a 129 patch and how-too video for this.

http://inkjetmall.com/tech/uploads/3880-WN-SEL-NU-JCStype5-lin.quad.zip

Please let me know how it goes.

Sorry for the delay,
Walker

6

Thanks, Walker. This worked well:

It solved the issue. I still do not know why I get a different (worse) result when I use the QTR-Linearize-Quad.app, but that is why you work there and I don’t! Looking forward to your video.
Thanks again, Wayne

7

FYI, the newly measured *L values were
96.8
92.2
87.4
82.9
78.7
74.3
69.9
64.9
60.3
55.6
51.2
46.4
41.8
37.8
33.4
28.4
23
18.6
14.8
9.6
3.9

8

This is a still not super linear but is work-able. (21 steps isn’t always enough)

I’m coming out with 21,51,129patch step targets + ColorPort/i1Profiler/ColorMunki workflows . . . .

The trick to getting this to work is to build a proper CGATs file.

best,
W

9

And Measure Tool (still works on Windows)???

I’ll be interested to see this workflow, as I am not convinced about 51 steps and the droplet. I’ve tried it and I think it results in spurious accuracy.

10

There is no reason to use measuretool when colorport works better (on both Mac and PC) and even i1Profiler can be used at this point . . .

regards,
Walker

11

If you open a cgats file you will see the column headers for L* a* and b* axis. These have to be directly above the first measurement numbers for the lin droplet to work (and this is not always the case when exported from a measurement application). If these column headers are not in the right place, the tool can miss-represent the last few numbers of the (shadow values) of the measurements. It will also default to sampling only 16 of the patches so you won’t be utilizing all of your available data.

best,
Walker

12

Any reason not to use it? It works. It works quite well for me. Why change if it works?

This is an advantage of Windows. Legacy software still works, unlike in another OS that comes to mind.

13

If it works for you then go-fer-it. (We at IJM believe firmly in saying "If it ain’t broke than don’t fix it.)

But it uses USB1 protocol and can f’up the single-patch readings on i1s and i1v2s with newer firmware. just saying

Walker

14

Attached is a measurement file from Measure Tool. This is from the x880 P2 Spec Edition Curve for HPR. (Actually the curve was remapped for the R1900, but for these purposes that’s not really relevant - you could also use these numbers to relinearise the original curve.)

What’s wrong with the measurement file? If I use these numbers to relinearise the curve, I get a beautiful straight line. Where’s the problem? Do you really think that the droplet is using only a subset of the measurement data?

15

3 PROBLEMS.

  1. The Lab_L is not directly above first measurement number (71.91)
  2. These measurements need to actually be re-organized for the qtr quad linearizer *important in order to find falses.
  3. The patch set has to be either 21, 51, 129, or 151. Can’t be higher that 151 and can’t be 84 (in this case).

Best,
Walker

16

This is a tab delimited file, so the Lab_L numbers are in the same tab delimited column as the header label.

There are two reasons why I have difficulty in accepting that these three are problems - (i) Roy hasn’t said any such thing that I’ve read anywhere (his initial post says that “… and a measurement file i.e. .txt file like the usual QTR-Linearize-Data takes …”, and back in the day when all we had was Measure Tool, this was the measurement format used); and (ii) the droplet works and produces consistent results for me.

17

Why don’t you post a CGATS file that you consider to be correctly formatted, and then we can test whether or not using that format makes any difference.

You do realise that this is the measurement of a 21x4 chart, hence the 84 readings?

18

Ok. Here is a set of grayscale GG2.2 targets. These targets are not all tested with QTR Quad Linearizer:
https://drive.google.com/folderview?id=0B4gHbc7Tg9-SOWhsS01BVFJmUGs&usp#list

There are known bugs in how QTR Quad Linearizer handles Lab_L column header and data from i1Profiler Lab* CGATS exports. (please read above comments about that)

This is beta but please use this and get back to me on the results.

(The i1Profiler i1Pro2 targets will work with the Spyder and single-patch reads FYI.)

ColorMunki 21,51,129 random targets are coming (with added “de-randomizer” spreadsheet) but these are real manual targets that require hand-crafting. We do them at 720dpi.

Please read the instructions/disclaimer included in the link above. No support yet until it’s validated.

best,
Walker

19

“I’ll be interested to see this workflow, as I am not convinced about 51 steps and the droplet. I’ve tried it and I think it results in spurious accuracy.” You should try it. We do up to 129 right now and also 256 (with some error correction of the measurements).

If 21x4 is working for you then good. Sorry, I was thinking for some reason you were working off a different set. 21x4 are supported by his organizing code inside the droplet.

I’ve directly observed bugs with start of measurement data not correctly identified by the droplet but identified by create-icc.

W

20

I included the bare-bones example cgats in the google drive folder above. Note the position of Lab_L etc.

The sample measurements are from a Palladium print so don’t mind the weak dMax.

best,
Walker