Luminous Landscape Forum
Raw & Post Processing, Printing => Printing: Printers, Papers and Inks => Topic started by: Brad P on December 02, 2017, 07:12:34 pm
-
I need to print files from my mac to a Z3200ps with no color management at all. I believe the right procedure is to go to the HP Utility, hit Submit Job>Start, set up the file for print, but in Color>ICC Color Management>RGB Source Profile, select "None (Native)" for an RGB based file, then select absolute colorimetric as the rendering intent. Is that correct or is there a better way?
For rendering intent, the only other choices are default, relative colorimetric, perceptual or saturation which I imagine might cause problems.
The reason I'm asking is that I had an external file profiler create a profile (they said it would be better but it didn't work) and I have started creating my own color profiles using Argyll with larger samples than the spectrophotometer natively processes with its software (which seem to work fine).
Adobe's Color Print Utility is not updated properly to work with my Mac computer so I can't use that option.
-
You can make larger target profiles directly from the Z3200.
Check out this page:
Make 1728 patch targets for ICC Profiles (http://z3200.com/Making_Profiles_For_HP-Z3200_Printers.htm)
Then you can use Argylle with Terminal or ICC Gen
Always use Relative Colormetric with ICC Gen.
You can use Apple Color Center to print a non-color managed print if you need to.
But printing a 1728 patch target internally from the Z3200 is a huge improvement over the normal target used by the Z natively.
Mark
-
That is very cool Mark,
Thanks for sharing, as always.
Do you know if I can drop this file into my X-Rite i1 Pro 2 software to create the icc profile?
John
You can make larger target profiles directly from the Z3200.
Check out this page:
Make 1728 patch targets for ICC Profiles (http://z3200.com/Making_Profiles_For_HP-Z3200_Printers.htm)
Then you can use Argylle with Terminal or ICC Gen
Always use Relative Colormetric with ICC Gen.
You can use Apple Color Center to print a non-color managed print if you need to.
But printing a 1728 patch target internally from the Z3200 is a huge improvement over the normal target used by the Z natively.
Mark
-
...
But printing a 1728 patch target internally from the Z3200 is a huge improvement over the normal target used by the Z natively.
Mark
Mark, i just made some profiles for a paper with the 'HP advanced profiling solution' (APS) that i bought with the z3100
I have a 1728 reference so it can do that too.
i made a 220, a 918 and a 1728 profile with the APS and a 440 patch profile that came with the printers software.
Result ... and for me a trending result:
1728 and 918 has some banding in places with gradients in areas with strong colors were the 440 and 220 have not.
the 440 profile was the better one in this case. ( the 220 profile was not accurate enough )
On the other hand the 918 and 1728 had more extreme colour.
so my basic idea is : more patches- more accurate colour, but also a greater chance for banding issues
What are your experiences?
I know this is a difficult subject ( can of worms) for a straightforward answer.
-
I'm not Mark but I do know from experience with other profiling systems that the more patches the hardware has to read the greater the potential for mistakes in the reading process itself. This is most likely why Hp has standardized on using less patches to read as well as the fact that it takes less time to produce the profile.
Mark, i just made some profiles for a paper with the 'HP advanced profiling solution' (APS) that i bought with the z3100
I have a 1728 reference so it can do that too.
i made a 220, a 918 and a 1728 profile with the APS and a 440 patch profile that came with the printers software.
Result ... and for me a a trending result:
1728 and 918 has some banding in places with gradients in places with strong colors were the 440 and 220 have not.
the 440 profile was the better one in this case. ( the 220 profile was not accurate enough )
On the other hand the 918 and 1728 had more extreme colour.
so my basic idea is : more patches- more accurate colour, but also a greater chance for banding issues
What are your experiences?
I know this is a difficult subject ( can of worms) for a straightforward answer.
-
You can use Apple Color Center to print a non-color managed print if you need to.
ColorSync Utility (or even Preview).
Not all patch sets are created equally so when someone states a 1728 patch target, they differ. You really want Bill Atkinson's patch set, based on my testing.
-
so my basic idea is : more patches- more accurate colour, but also a greater chance for banding issues
In a near prefect world, you'd make a 16.7 million patch target that represents every possible RGB value. But that would take forever to measure and the profile would be larger than many images.
In a prefect world, you'd make a target that only contains device values that define colors so you'd have far less than 16.7 million patches. Still probably a few million and the same issues as above.
So we need to use a vastly smaller set of patches and the software has to extrapolate a lot. Some do this better than others. Some products create better sets of patches than others. With a good set of patches from someone who knows how to define them, 1728 can do a good job. However, the product I use to create profiles offers an POST optimization process where another set of patches, generated from the data in the first profile, can in some cased improve the original profile. I'm working on a video now to show what that provides when used (it's subtle but it's visible).
Not all profiles are created equally and just one reason is, not all targets and the patches used are created equally:
Not all ICC profiles are created equally
In this 23 minute video, I'll cover:
The basic anatomy of ICC Profiles
Why there are differences in profile quality and color rendering
How to evaluate an ICC output profile
Examples of good and not so good canned profiles and custom profiles on actual printed output.
High resolution: http://digitaldog.net/files/Not_All_Profiles_are_created_equally.mp4 (http://digitaldog.net/files/Not_All_Profiles_are_created_equally.mp4)
Low resolution (YouTube): https://www.youtube.com/watch?v=TNdR_tIFMME&feature=youtu.be (https://www.youtube.com/watch?v=TNdR_tIFMME&feature=youtu.be)
-
Not all profiles are created equally and just one reason is, not all targets and the patches used are created equally:
Not all ICC profiles are created equally
In this 23 minute video, I'll cover:
The basic anatomy of ICC Profiles
Why there are differences in profile quality and color rendering
How to evaluate an ICC output profile
Examples of good and not so good canned profiles and custom profiles on actual printed output.
High resolution: http://digitaldog.net/files/Not_All_Profiles_are_created_equally.mp4 (http://digitaldog.net/files/Not_All_Profiles_are_created_equally.mp4)
Low resolution (YouTube): https://www.youtube.com/watch?v=TNdR_tIFMME&feature=youtu.be (https://www.youtube.com/watch?v=TNdR_tIFMME&feature=youtu.be)
That is an awesome video. Thanks. I’m actually shocked to see the differences in the canned and custom profiles at the end. It proves a good part of the time and money we allocate to lenses and camera gear would better allocated to color profiling if we want good prints.
-
That is an awesome video. Thanks. I’m actually shocked to see the differences in the canned and custom profiles at the end.
Actually, it's the differences in the two canned profiles quality, from the SAME company that's rather shocking to me.
-
Hi Mark - thanks for this. I've been doing about the same thing for a few months but manually without ICC Gen.
I noticed you wrote to use RelCol with ICC Gen. Is that an ICC Gen restraint or your preferred profile? From memory, in Geraldo's original post somewhere someone noted that one could produce both RelCol or Perceptual ICC profiles using Argyll, but it was either one or the other with each icc file. I've only made a perceptual profile to date but was about to reprint a 1728 sample today and make both perceptual and relative profiles (setting eachup different paper names in the printer, like "IGFGRelCol1728RGEon" and "IGFGPerc1728GEon"). Interested in your experiences so far.
You can make larger target profiles directly from the Z3200.
Check out this page:
Make 1728 patch targets for ICC Profiles (http://z3200.com/Making_Profiles_For_HP-Z3200_Printers.htm)
Then you can use Argylle with Terminal or ICC Gen
Always use Relative Colormetric with ICC Gen.
Mark
-
ColorSync Utility (or even Preview).
Not all patch sets are created equally so when someone states a 1728 patch target, they differ. You really want Bill Atkinson's patch set, based on my testing.
Hello Andrew, thanks for joining,
I got the 1728 from Bill Atkinson- the software however maybe does not match with the target...
I will watch your video, have a closer look at what is going on and come back...
-
Hello Andrew, thanks for joining,
I got the 1728 from Bill Atkinson- the software however maybe does not match with the target...
I will watch your video, have a closer look at what is going on and come back...
IF you have a standard CGATs text file, virtually any software worth it's salt should import that to build a target.
Remind me again what product you're using to build a profile?
-
Actually, it's the differences in the two canned profiles quality, from the SAME company that's rather shocking to me.
I'm less shocked. Unfortunately, only the Colorimetric Intents are well spec'ed by the ICC. And only those colors that are in gamut. How out of gamut colors are mapped, as well as virtually all of Perceptual is left to the implementer. But for the same vendor to have such large differences in OOG rendering is rather odd. Any idea how well in gamut colors are rendered by the two profiles? It may be the OOG ugly one does a better job rendering in gamut colors.
-
That is very cool Mark,
Thanks for sharing, as always.
Do you know if I can drop this file into my X-Rite i1 Pro 2 software to create the icc profile?
John
Hi John,
Yes you can. Should be no problem.
EDIT:
It looks like it is doable John, but we have to determine how to make a minor modification to the Z series cgats header to enable x-rite to accept the files. Working on it. Will keep you posted.
Mark
-
Mark, i just made some profiles for a paper with the 'HP advanced profiling solution' (APS) that i bought with the z3100
I have a 1728 reference so it can do that too.
i made a 220, a 918 and a 1728 profile with the APS and a 440 patch profile that came with the printers software.
Result ... and for me a trending result:
1728 and 918 has some banding in places with gradients in areas with strong colors were the 440 and 220 have not.
the 440 profile was the better one in this case. ( the 220 profile was not accurate enough )
On the other hand the 918 and 1728 had more extreme colour.
so my basic idea is : more patches- more accurate colour, but also a greater chance for banding issues
What are your experiences?
I know this is a difficult subject ( can of worms) for a straightforward answer.
I’ve never had banding with 1728 patch target profiles using the Z. I know that everything must be followed to the letter, (including advance paper calibration) and one must use the correct preset for the paper being profiled, and one must overwrite the original created paper not changing any names during install. Also, it is an experiment to find the right combinations which can be time consuming and costly. In using Argyll, rel col works the best IMO. It takes a lot of trial and error to work it out, but once you get it it is pretty good. MHMG and I did some testing and he came up with excellent results.
Mark
-
Hi Mark - thanks for this. I've been doing about the same thing for a few months but manually without ICC Gen.
I noticed you wrote to use RelCol with ICC Gen. Is that an ICC Gen restraint or your preferred profile? From memory, in Geraldo's original post somewhere someone noted that one could produce both RelCol or Perceptual ICC profiles using Argyll, but it was either one or the other with each icc file. I've only made a perceptual profile to date but was about to reprint a 1728 sample today and make both perceptual and relative profiles (setting eachup different paper names in the printer, like "IGFGRelCol1728RGEon" and "IGFGPerc1728GEon"). Interested in your experiences so far.
I find very little difference in the two, and yes, do prefer relcol. Argyl is what it is, other programs like RGB Drop do a very similar thing, in tests conducted with MHMG. In looking at comparitive graphs - very similar results.
Mark
-
ColorSync Utility (or even Preview).
Not all patch sets are created equally so when someone states a 1728 patch target, they differ. You really want Bill Atkinson's patch set, based on my testing.
Thank you for correcting that Andrew - I did mean to say ColorSync Utility.
The target that the Z produces is the target the Z can and will read. If it is possible to convert the Atkinson target to one readable by the Z, then that would be cool. I think it can be done but I have yet to play with that. I know that the Z is really picky about what it will and won’t read, however. The 1728 patch target is much better than the standard one the Z produces automatically. Not too bad considering it is all automated and in house as part of the actual cost of the printer. Move away from that and it becomes money on an entirely new level for stand alone machines.
-Mark
-
The target that the Z produces is the target the Z can and will read. If it is possible to convert the Atkinson target to one readable by the Z, then that would be cool.
That's kind of true everywhere. So if you get a CGATs file defining the reference colors for the 1728 patches of Bills selection, the software needs the ability to create a custom target from that data. Very easy to do in a number of products like i1Profiler etc. No idea what your Z software can do. If it's worth it's salt and not some crippled product, it should allow you to create a custom target from the CGATs file. That custom target has all the colors values (device values) desired and formatted for whatever Spectrophotometer you need to use.
-
That's kind of true everywhere. So if you get a CGATs file defining the reference colors for the 1728 patches of Bills selection, the software needs the ability to create a custom target from that data. Very easy to do in a number of products like i1Profiler etc. No idea what your Z software can do. If it's worth it's salt and not some crippled product, it should allow you to create a custom target from the CGATs file. That custom target has all the colors values (device values) desired and formatted for whatever Spectrophotometer you need to use.
Andrew, can you send me the Atkinson file? I’ll check it out.
Mark
-
Andrew, can you send me the Atkinson file? I’ll check it out.
Mark
Shoot me a PM with an email address. I have a CGATs file, formatted for ProfileMaker Pro but can format differently.
-
Shoot me a PM with an email address. I have a CGATs file, formatted for ProfileMaker Pro but can format differently.
Thanks Andrew, PM sent.
Mark
-
High resolution: http://digitaldog.net/files/Not_All_Profiles_are_created_equally.mp4 (http://digitaldog.net/files/Not_All_Profiles_are_created_equally.mp4)
Low resolution (YouTube): https://www.youtube.com/watch?v=TNdR_tIFMME&feature=youtu.be (https://www.youtube.com/watch?v=TNdR_tIFMME&feature=youtu.be)[/i]
One more thank you Andrew - I hadn't ever tested my profiles with Bill's Balls, linked in your video, and I used that to test it later today. That is a super test that revealed a problem that other tests haven't. Backstory - when printing out my 1728 profile a few months ago (which is a lot of ink and paper on the HPZ3200), I noticed a couple white spots on two patches where some flecks of something prevented the green ink from hitting the paper. Slyly I thought, I filled them in with a green pen trying to match. Till now, I thought I had gotten away with it. But nope, big time thick banding in the green balls. Anyway, I'll redo the patch and won't be doing that again.
Just a real world note of thanks and hopefully a bit of levity.
-
Mark, i just made some profiles for a paper with the 'HP advanced profiling solution' (APS) that i bought with the z3100
I have a 1728 reference so it can do that too.
i made a 220, a 918 and a 1728 profile with the APS and a 440 patch profile that came with the printers software.
Result ... and for me a trending result:
1728 and 918 has some banding in places with gradients in areas with strong colors were the 440 and 220 have not.
the 440 profile was the better one in this case. ( the 220 profile was not accurate enough )
On the other hand the 918 and 1728 had more extreme colour.
so my basic idea is : more patches- more accurate colour, but also a greater chance for banding issues
What are your experiences?
I know this is a difficult subject ( can of worms) for a straightforward answer.
Kers,
Another thought about this. Consider that the APS you are using is now about a 15-20 year old technology, meaning that the HP Puck, the profile target,etc, is made from a Z3100 machine technology and Gretag MacBeth era technology. Fast forward and today’s Spectrophotometer is i1, with presumably many innovations and considerable evolution involved. It was well known information that the Z3200ps with its standard small patch target outperformed the outdated APS profiling system, and that the APS would have required a significant upgrade to work with the new spectrophotometers and all that entailed, so HP dropped it. The ability to make 1728 patch targets and generate standard cgats files is in part a hold-over from that technology previously called APS, yet as we know, we are required to use third party software such as Argyll or RGB Drop, (et al), etc., in order to generate the actual ICC profiles. As it is, however, the machine is entirely adept at producing standard cgats in the form of .csv files that can be changed to standard .TXT files as well. So in essence, the APS has been rendered obsolete, which may explain your issues with banding, yet I suspect there are other issues related to printheads/settings/and controls that are potentially contributing to that effect. This is my opinion, of course, your mileage may vary.
Best,
Mark
-
That is very cool Mark,
Thanks for sharing, as always.
Do you know if I can drop this file into my X-Rite i1 Pro 2 software to create the icc profile?
John
Hi John, I recently went through that whole exercise with Mark L.'s help and the results were very interesting. First some background information for new owners of Z3200PS printers. HP marketing literature still claims one is getting the APS "advanced profiling" solution with the PS version of the Z3200, but in fact, the display calibrator hardware became obsolete a number of years ago, so HP just quit including the APS hardware/software kit with the machine. However, some of the target generation capability still lies within the current color utilities, and it allows the user to print the 1728 target, measure it, and save a CGATs configured .CSV file. I am able to successfully read that file with BasicColor RGB profiling software, and Argyll CMS (using Mark's iCCGen GUI app to give it a nice and simple GUI for profile generation), but Xrite's i1Profiler software rejected it. I suspect that with a little more exploration of the header file information there may be a simple "cut and paste" workaround with Microsoft Excel or a text editor to trick i1Profiler into reading the HP generated CGATs file, but I haven't had time to do that experiment. Anyway, I have attached a png screenshot of some curves I quickly plotted in Excel to show the tone reproduction response of the ICC profiles I built using the Z's 1728 auto printed and measured output. The graphs could use a little more cleaned up text in the titles. One graph is the tone plot from the Argyll/ICCGen produced profile (title in the graph begins with "iGen". It was made with Relcol/BPC rendering. The second graph is from the profile built with BasicColor RGB drop software (reads "BcC" in the title) using Relcol/BPC as well. Third graph has a very subtle tonal difference because it was made with the BcC profiling engine using perceptual rendering. The midtones are ever so slightly higher in L value to coax a little better shadow detail linearity out of the tone curve with the perceptual rendering intent. The roll off in the curve as Lmin (Dmax) is approached is typical tone reproduction output on fine art matte papers (this one was Moab Entrada Natural).
Both the Argyll and BasicColor profiles built from the Z3200's measured 1728 patch output are quite good, IMHO. Since HP's 1728 patch layout is the standard 12x12x12 uniform grid arrangement, I don't see anything to gain from Bill Atkinson's 1728 patch target other than if you want to use less paper and print smaller patch sizes, but then you will need another spectrophotometer to measure the final printed target as well.
In the meantime, it's fair to conclude that the Z3200 printed and measured the 1728 patches in perfectly satisfactory manner. That leaves new Z3200 printer owners just having to find some profiling app to crunch the numbers since HP's APS software that used to handle the task is no longer being delivered with the new machines. Argyll using Mark L's iCCGen helper applet is an essentially straightforward and "free" approach to crunch the data (but please consider a donation to the Graeme Gill's Argyll website http://www.argyllcms.com/index.html). BasicColor RGB drop is as sweet as as it gets with respect to ease and quality of profile generation (but you pay for that ease of use)!
cheers,
Mark
http://www.aardenburg-imaging.com
-
Mark,
I'm willing to take a crack at converting the spectral file to a CGATs that I1Profiler recognizes. I regularly munge data and write out CGATS files I1Profiler reads. If successful, which is highly likely, I will then post instructions or possibly open a github repo where people can download code.
-
Mark,
I'm willing to take a crack at converting the spectral file to a CGATs that I1Profiler recognizes. I regularly munge data and write out CGATS files I1Profiler reads. If successful, which is highly likely, I will then post instructions or possibly open a github repo where people can download code.
Doug,
If you like, I can publish your code on z3200.com if you like (unless you’re planning to sell it). If you’ll be giving it away for free, please consider it, because it would be a good place to keep this info in the same place. I have to tune up the installation instructions for ICC Gen as it has a bug in the instructions. As for the x-rite/ z series issue, MHMG is thinking that it’s a simple cut and paste of the x-rite header to replace the Z3200 header, so hopefully it should be easy. Please consider doing a simple GUI for folks who don’t use terminal. That’s all ICC Gen is, a shell that uses terminal to utilize Argyll, yet enables users to bypass using terminal themselves.
I’d be happy to publish any work around you come-up with and make a graphic for it and give full credit to you and anyone else involved in making it if you’re up for it.
I’m interested in providing free work arounds for the .csv and .TXT files generated through the Z Series utility so everyone so inclined can have a total solution for using the Z Series automated ICC profile capabilities.
Mark McCormick is super busy with Aardenburg, but I’m confident he will collaborate, as he and I have already started to investigate this. Any involvement you could contribute would be more than welcome.
Thanks-
Mark L.
-
Mark,
I'm willing to take a crack at converting the spectral file to a CGATs that I1Profiler recognizes. I regularly munge data and write out CGATS files I1Profiler reads. If successful, which is highly likely, I will then post instructions or possibly open a github repo where people can download code.
Hi Doug, see attached file. Have at it :) As I noted earlier the BasicColor and Argyll profiling apps had no trouble reading this HPZ3200 spectrophotometer-generated CGATS file and building a proper ICC profile using the data. However, when I tried to load the file into i1Profiler, it says it's an "invalid" CGATS file. Probably something simple I'm overlooking about how to load a measurement file into i1Profiler or perhaps a case of needing to tweak some of header row formatting to get i1Profiler to accept it. Good luck.
Mark
http://www.aardenburg-imaging.com
-
Hi Doug, see attached file. Have at it :) As I noted earlier the BasicColor and Argyll profiling apps had no trouble reading this HPZ3200 spectrophotometer-generated CGATS file and building a proper ICC profile using the data. However, when I tried to load the file into i1Profiler, it says it's an "invalid" CGATS file. Probably something simple I'm overlooking about how to load a measurement file into i1Profiler or perhaps a case of needing to tweak some of header row formatting to get i1Profiler to accept it. Good luck.
Mark
http://www.aardenburg-imaging.com (http://www.aardenburg-imaging.com)
Will it load in ProfileMaker Pro? Re-save, i1P should (should but may not) open it.
-
Will it load in ProfileMaker Pro? Re-save, i1P should (should but may not) open it.
Good solution Andrew!
And, yes, you can make profiles with PM5 if you have a license. But if you don't and want to use I1Profiler do this:
1. Load the file in PM5's Measure Tool, then save as a txt file.
2. Load the new, CGATS file in I1Profiler in the "Measurements" section skipping "Patch Set" and "Test Chart." It will then ask for data type. The latest X-rite is XRGA but it's probably better to select one of the older standards like the GMB. I1Profiler will next request the uV mode (M0, M1, or M2). Select M2. Spectral data is stripped so this can only be used for standard D50 profiles.
A few notes:
The file is a uV cut file using a white LED source (no uV from those). Spectral data from 380nm through 400nm is zero as is everything above 710nm
You don't need a license to load and save the file with PM5's Measurement Tool. While it will state it is in "demo" mode, the necessary functions are enabled to load the HP file and save an I1Profiler compatible CGATS file.
-
I was thinking of using PMP (actually MeasureTool*) just to attempt a CGATs conversion that i1P might like.
* no dongle needed with MeasureTool to do this as you point out.
And when, WHEN will X-rite give us all that functionality we don't have any more from MeasureTool or ColorPort in their high end expensive package?
-
I was thinking of using PMP (actually MeasureTool*) just to attempt a CGATs conversion that i1P might like.
* no dongle needed with MeasureTool to do this as you point out.
And when, WHEN will X-rite give us all that functionality we don't have any more from MeasureTool or ColorPort in their high end expensive package?
Just followed Andrew's suggestion to try PM5's measure tool app to resave the HP.csv file as a text file, and then Doug's tips on where/how to insert into the i1Profiler workflow. I had earlier just tried to trick i1Profiler by replacing the .csv extension with a .txt extension but had not been successful with that simple method. However, the Measuretool-resaved text file did come into i1Profiler, and I successfully build a profile. Gamut is identical to the BasicColor RGB result. Looking at a softproof of a corlorful test image, the perceptual tag is a little more aggressive on tone curve than the one built by BcC RGB Drop, but relcol with BPC looks like a dead ringer for both profiling Apps.
One problem with this approach is not only do you have to download Measuretool, but one has to have a Mac machine running OS10.6 or older (I do indeed have all this old legacy hardware/software), because Measuretool needs Rosetta code to run on a Mac. Nonetheless, this workflow did succeed. I still think that once these different text files are inspected more carefully in Excel, one will be able to make the changes directly in Excel and not need to resort to Measuretool, but more eperimenting needed!
Although this effort may seem somewhat arcane to folks who don't own a Z3200, it does show that HP's built in Spectro along with its printer driver utility can indeed generate reasonably CGATs compatible files that can further be used in conjunction with numerous other ICC profiling packages. With a 44 inch roll loaded into my Z3200, the Z's printer utility automatically laid out and printed the 1728 patch target set using just 14 inches of paper from the leading edge of the roll. Letting the Z then measure unattended was a real treat compared to printing an i1Pro2 compatible target with a "no color adjust" utility and then hand measuring. For those lucky folks with more automated spectros like i1iSIS, this HP spectro workflow might not appeal, but for those of us having to resort to more manually generated ICC profiles, the HP Z3200's Spectro adds a welcome relief to the fatigue of measuring high patch counts by hand :)
All the best,
Mark
http://www.aardenburg-imaging.com
-
Just followed Andrew's suggestion to try PM5's measure tool app to resave the HP.csv file as a text file, and then Doug's tips on where/how to insert into the i1Profiler workflow. I had earlier just tried to trick i1Profiler by replacing the .csv extension with a .txt extension but had not been successful with that simple method. However, the Measuretool-resaved text file did come into i1Profiler, and I successfully build a profile. Gamut is identical to the BasicColor RGB result.
FWIW, while I'm happy that worked, my suggestion was to help the OP get a patch file I sent (CGATs) into whatever he's using to make a new 1728 target.
-
FWIW, while I'm happy that worked, my suggestion was to help the OP get a patch file I sent (CGATs) into whatever he's using to make a new 1728 target.
Andrew, Thanks for your comments and for sending the CGATS file. Frankly I don't know how to import or convert the data you sent me into a file that the Z3200 can read. I'm not the OP, but am interested in importing other targets that the Z3200ps can read that are greater than 1728 - specifically, a 2371 Patch Target. The Z accomplishes this by printing a target for later use, then it reads it and creates a .CSV file (Mac) or a .TXT file (Windows). I'm not sure how to import a target patch larger than 1728 that is in the same format as what the i1 profiler in the Z3200 spectrophotometer uses in its final form as illustrated below:
(http://z3200.com/images/page-1/4698-long%20target-.jpg)
The Z3200 is finicky about reading these targets - any idea how to convert large patch targets into this specific target formation?
BTW - you were partially correct, that the Z is somewhat crippled because it doesn't have a program anymore to be able to create an ICC profile from a .csv or .txt file. However, as demonstrated and with one of your solutions, it's entirely possible to use third party software. As I stated earlier, this use of the ESP and free third party software is a long ways away from a $3K plus machine that is automated. As it applies to specifically Z3200 owners, it's of vital importance for anyone trying to get the most out of the spectrophotometer keeping relatively sophisticated profiles in-house. The CGATS files generated by the Z3200 are equivalent to what is coming out of other systems. Agree or disagree, it's what we have to use. And thanks again for your work around. As MHMG just showed, it works. Getting a simple header change to make it work directly would be significant for us.
Best,
Mark
-
Mark, I was hoping a similar technique the other Mark tried would work for you.
You've got an exported PMP CGATs 'patch file' for all of Bill's 1728 colors. I don't know anything about the software you use with the Z. The idea is, if (big if) it supports custom targets, it should import that text file and allow you to now define the Spectrophotometer, size of patches and number of pages etc. It would create a target you could print, measure and that original CGATs would be used as the 'reference' for creation of the profile. But again, I have no idea how this works with your product.
-
Thanks Andrew - I'm looking into it. Appreciate your help and input. Will see if I can get it working. Others here may jump in as well.
Best -
Mark
-
Thanks Mark and Andrew,
It's interesting that I can generate an icc fron the hp expanded patch file on the Z3200 and install it .
For the time being I'll just use my X-Rite 2033 patch target like I do with my Canon and my Z3100 - that's a whole lot easier and faster, since I'm familiar with that, but it is good to have a backup.
John
Hi Doug, see attached file. Have at it :) As I noted earlier the BasicColor and Argyll profiling apps had no trouble reading this HPZ3200 spectrophotometer-generated CGATS file and building a proper ICC profile using the data. However, when I tried to load the file into i1Profiler, it says it's an "invalid" CGATS file. Probably something simple I'm overlooking about how to load a measurement file into i1Profiler or perhaps a case of needing to tweak some of header row formatting to get i1Profiler to accept it. Good luck.
Mark
http://www.aardenburg-imaging.com
-
Mark, I was hoping a similar technique the other Mark tried would work for you.
You've got an exported PMP CGATs 'patch file' for all of Bill's 1728 colors. I don't know anything about the software you use with the Z. The idea is, if (big if) it supports custom targets, it should import that text file and allow you to now define the Spectrophotometer, size of patches and number of pages etc. It would create a target you could print, measure and that original CGATs would be used as the 'reference' for creation of the profile. But again, I have no idea how this works with your product.
Hot Dang. I got it. It worked. Very cool. Thanks Andrew. Cha-ching.
Mark
-
Another way to fix it without running Measure Tool:
Just change the .csv file to .txt (it isn't really a csv file).
Then open the file with a text editor and change this line in the header:
NUMBER_OF_FIELDS 49
to
NUMBER_OF_FIELDS 44
This also preserves the spectral data which means you have the ability to create custom profiles that can be made so that a print will look great under even the worst lighting such as some office fluorescents.
The problem is that the HP saves fields from 380nm to 780nm. I1Profiler expects only from 380nm to 730nm. Making this change causes the extra data, which is zero anyway, to be ignored.
Then load it in to I1Profiler as a CGATS file, select M2, and GMB as before.
-
Another way to fix it without running Measure Tool:
Just change the .csv file to .txt (it isn't really a csv file).
Then open the file with a text editor and change this line in the header:
NUMBER_OF_FIELDS 49
to
NUMBER_OF_FIELDS 44
This also preserves the spectral data which means you have the ability to create custom profiles that can be made so that a print will look great under even the worst lighting such as some office fluorescents.
The problem is that the HP saves fields from 380nm to 780nm. I1Profiler expects only from 380nm to 730nm. Making this change causes the extra data, which is zero anyway, to be ignored.
Then load it in to I1Profiler as a CGATS file, select M2, and GMB as before.
Thanks Doug, for that! A quick fix with Text editor on my Mac, and i1Profiler loaded the HPZ3200-measured CGATS file with no problem. I didn't even need to drag the file into Excel!
kind regards,
Mark
http://www.aardenburg-imaging.com
-
Thanks Doug, for that! A quick fix with Text editor on my Mac, and i1Profiler loaded the HPZ3200-measured CGATS file with no problem. I didn't even need to drag the file into Excel!
kind regards,
Mark
http://www.aardenburg-imaging.com
Thanks for your changes Doug - very interesting. Excellent.
Mark
-
Thanks Andrew. Cha-ching.
Send checks or money orders to..... ;D Glad it worked out. Curious if you end up seeing any differences with the newer 1728 target (the older may have been Bills?)
-
Send checks or money orders to..... ;D Glad it worked out. Curious if you end up seeing any differences with the newer 1728 target (the older may have been Bills?)
Andrew - thanks - just got your email. Have been working with MHMG (Mark) on several issues relating to the HP Z3200ps and making advanced profiles. Appreciate your sending me those files. Will get back to you at some point.
Mark
-
Looking at the profile created from the 1728 patch set there are a few things of note:
1. The profile is quite "lumpy." I believe this is a side effect of transitions from magenta and cyan to the additional, strong colors the printer has. This increases the gamut in places compared to the more limited set of inks my 9800 and 9500 have but it also will make the gamut more lumpy. It may also require more patches to achieve the same level of accuracy in colorimetric rendering.
2. Reviewing a histogram of the RGB device space dE76 examining a large set of colors and looking at adjacent (1 bit) colors shows a very nice distribution with the average dE76 being about .4 and a max of .9. 99% fall under .5. So the driver mapping of device RGB values to the inks is really good. Especially considering the large ink set.
However, profile accuracy is best determined from a set of colors distinct from those used to generate the target. What I do is create a set of Lab values, evenly spaced (5, 10, or 20 grid points) which are in gamut. Then I save them as a CGATs file where the RGB values have been converted to device space. After printing a "target" I scan them with a spectro and gather the statistics of the deviation of scanned Lab values from what the CGATs file should yield.
It's a simple (5 minute) process for me to do and I'd be happy to provide a CGATs file that, when printed as a "target" and scanned yield the requested color Lab values.
That would work like this:
1. You post the scanned CGATs file from which the profile was derived and either attach the generated profile or I can make an identical profile using I1Profiler if the settings are stated. (ie, XRGA, Quality -which should bet set at highest, default for others)
2. I will then create a new CGATs RGB file that can be printed as a "target" When scanned, post the CGATs file and I will process it and provide the statistics as well as the Reqested Lab/Actual Lab txt file.
It's a good way to evaluate a profile. The problem with evaluating a profile using the target patch set is that everything is self referential. One uses the same values to determine the requested Lab values that were used to create the values from which the table was created.
-
Looking at the profile created from the 1728 patch set there are a few things of note:
1. The profile is quite "lumpy." I believe this is a side effect of transitions from magenta and cyan to the additional, strong colors the printer has. This increases the gamut in places compared to the more limited set of inks my 9800 and 9500 have but it also will make the gamut more lumpy. It may also require more patches to achieve the same level of accuracy in colorimetric rendering.
2. Reviewing a histogram of the RGB device space dE76 examining a large set of colors and looking at adjacent (1 bit) colors shows a very nice distribution with the average dE76 being about .4 and a max of .9. 99% fall under .5. So the driver mapping of device RGB values to the inks is really good. Especially considering the large ink set.
However, profile accuracy is best determined from a set of colors distinct from those used to generate the target. What I do is create a set of Lab values, evenly spaced (5, 10, or 20 grid points) which are in gamut. Then I save them as a CGATs file where the RGB values have been converted to device space. After printing a "target" I scan them with a spectro and gather the statistics of the deviation of scanned Lab values from what the CGATs file should yield.
It's a simple (5 minute) process for me to do and I'd be happy to provide a CGATs file that, when printed as a "target" and scanned yield the requested color Lab values.
That would work like this:
1. You post the scanned CGATs file from which the profile was derived and either attach the generated profile or I can make an identical profile using I1Profiler if the settings are stated. (ie, XRGA, Quality -which should bet set at highest, default for others)
2. I will then create a new CGATs RGB file that can be printed as a "target" When scanned, post the CGATs file and I will process it and provide the statistics as well as the Reqested Lab/Actual Lab txt file.
It's a good way to evaluate a profile. The problem with evaluating a profile using the target patch set is that everything is self referential. One uses the same values to determine the requested Lab values that were used to create the values from which the table was created.
PM Sent Doug - thanks -
Mark L
-
PM Sent Doug - thanks -
Mark L
If you run into any difficulty printing super large targets I have tools to merge to create and/or merge a set of smaller ones.
-
Another way to fix it without running Measure Tool:
Just change the .csv file to .txt (it isn't really a csv file).
Then open the file with a text editor and change this line in the header:
NUMBER_OF_FIELDS 49
to
NUMBER_OF_FIELDS 44
This also preserves the spectral data which means you have the ability to create custom profiles that can be made so that a print will look great under even the worst lighting such as some office fluorescents.
The problem is that the HP saves fields from 380nm to 780nm. I1Profiler expects only from 380nm to 730nm. Making this change causes the extra data, which is zero anyway, to be ignored.
Then load it in to I1Profiler as a CGATS file, select M2, and GMB as before.
Just catching up. I'm attempting to do this now too. But for whatever reason my original CSV file states "NUMBER_OF_FIELDS 55" -- 55 rather than Mark L's 49. Should I change 55 to 44? Here's my header info
CGATS.5
FILE_DESCRIPTOR "RGB 1728 Patches (12x12x12)"
CREATED "December 04, 2017"
ORIGINATOR "HP Printer Utility"
SERIAL "90504F2E-D33C-4A7D-8766-BBC7B42F221E"
INSTRUMENTATION "Hewlett-Packard, HP Designjet Z3200ps 44in Photo (Q6721B), SN CN28R1H01V"
MEASUREMENT_GEOMETRY 45/0
MEASUREMENT_SOURCE "white LED"
FILTER "uv"
POLARIZATION "no"
SAMPLE_BACKING "black"
PRINT_CONDITIONS "Print Quality: Best_Graphics, Gloss Enhancer: EconoMode"
MANUFACTURER ""
MATERIAL "GFGloss1728GE40"
TARGET_TYPE "RGB 1728 Patches (12x12x12)"
NUMBER_OF_SETS 1728
NUMBER_OF_FIELDS 55
BEGIN_DATA_FORMAT
SAMPLE_ID SAMPLE_NAME RGB_R RGB_G RGB_B D_RED D_GREEN D_BLUE LAB_L LAB_A LAB_B XYZ_X XYZ_Y XYZ_Z SPECTRAL_380 SPECTRAL_390 SPECTRAL_400 SPECTRAL_410 SPECTRAL_420 SPECTRAL_430 SPECTRAL_440 SPECTRAL_450 SPECTRAL_460 SPECTRAL_470 SPECTRAL_480 SPECTRAL_490 SPECTRAL_500 SPECTRAL_510 SPECTRAL_520 SPECTRAL_530 SPECTRAL_540 SPECTRAL_550 SPECTRAL_560 SPECTRAL_570 SPECTRAL_580 SPECTRAL_590 SPECTRAL_600 SPECTRAL_610 SPECTRAL_620 SPECTRAL_630 SPECTRAL_640 SPECTRAL_650 SPECTRAL_660 SPECTRAL_670 SPECTRAL_680 SPECTRAL_690 SPECTRAL_700 SPECTRAL_710 SPECTRAL_720 SPECTRAL_730 SPECTRAL_740 SPECTRAL_750 SPECTRAL_760 SPECTRAL_770 SPECTRAL_780
END_DATA_FORMAT
-
Just catching up. I'm attempting to do this now too. But for whatever reason my original CSV file states "NUMBER_OF_FIELDS 55" -- 55 rather than Mark L's 49. Should I change 55 to 44? Here's my header info
CGATS.5
FILE_DESCRIPTOR "RGB 1728 Patches (12x12x12)"
CREATED "December 04, 2017"
ORIGINATOR "HP Printer Utility"
SERIAL "90504F2E-D33C-4A7D-8766-BBC7B42F221E"
INSTRUMENTATION "Hewlett-Packard, HP Designjet Z3200ps 44in Photo (Q6721B), SN CN28R1H01V"
MEASUREMENT_GEOMETRY 45/0
MEASUREMENT_SOURCE "white LED"
FILTER "uv"
POLARIZATION "no"
SAMPLE_BACKING "black"
PRINT_CONDITIONS "Print Quality: Best_Graphics, Gloss Enhancer: EconoMode"
MANUFACTURER ""
MATERIAL "GFGloss1728GE40"
TARGET_TYPE "RGB 1728 Patches (12x12x12)"
NUMBER_OF_SETS 1728
NUMBER_OF_FIELDS 55
BEGIN_DATA_FORMAT
SAMPLE_ID SAMPLE_NAME RGB_R RGB_G RGB_B D_RED D_GREEN D_BLUE LAB_L LAB_A LAB_B XYZ_X XYZ_Y XYZ_Z SPECTRAL_380 SPECTRAL_390 SPECTRAL_400 SPECTRAL_410 SPECTRAL_420 SPECTRAL_430 SPECTRAL_440 SPECTRAL_450 SPECTRAL_460 SPECTRAL_470 SPECTRAL_480 SPECTRAL_490 SPECTRAL_500 SPECTRAL_510 SPECTRAL_520 SPECTRAL_530 SPECTRAL_540 SPECTRAL_550 SPECTRAL_560 SPECTRAL_570 SPECTRAL_580 SPECTRAL_590 SPECTRAL_600 SPECTRAL_610 SPECTRAL_620 SPECTRAL_630 SPECTRAL_640 SPECTRAL_650 SPECTRAL_660 SPECTRAL_670 SPECTRAL_680 SPECTRAL_690 SPECTRAL_700 SPECTRAL_710 SPECTRAL_720 SPECTRAL_730 SPECTRAL_740 SPECTRAL_750 SPECTRAL_760 SPECTRAL_770 SPECTRAL_780
END_DATA_FORMAT
Interesting difference. It has several additional fields, XYZ's and D_RED, D_GREEN, D_BLUE. No idea what the last 3 are.
However, if you change "NUMBER_OF_FIELDS 55" to "NUMBER_OF_FIELDS 50" that may work as it's the elongated spectral data that I1Profiler doesn't like.
-
Just catching up. I'm attempting to do this now too. But for whatever reason my original CSV file states "NUMBER_OF_FIELDS 55" -- 55 rather than Mark L's 49. Should I change 55 to 44? Here's my header info
Mark L. and I just went through this problem ourselves today when we attempted to repeat the work with another custom patch count target, Here's the skinny on this workflow. The HP utility allows you to save various attributes into the text file along with the spectral data, e.g, lab values, XYZ values, even RGB density values. When you check all the boxes in the HP menu at the point where you want to save the text file, you end up with the 55 fields, whereas, apparently with the original text file I posted and which Doug Grey analyzed, not all those boxes had been checked. So, your 55 field number indicate you have extra RGB density values and XYZ values included in the file that the 49 field text file I let Doug evaluate didn't have. To bring things to the 44 count final requirement you need to strip away both the RGB density fields and the XYZ fields in your 55 field text file. leaving just the extra LAB value fields and spectral data fields. This can be done by importing this text file into Excel, deleting the extra columns, and resaving the file as a text file that matches the fields I had when I posted the file that Doug evaluated. A PITA I know, but these are teething pains that Mark L. and I will soon get worked out so that we can give better step-by-step instructions on how to get the HPZ3200 to make text files which the I!Profiler software can load correctly. The real fault is with i1Profiler, because both Argyll and Basicolor RGB drop profiling apps have no trouble figuring out which fields are which. The HP Z is not making an invalid CGats file. It conforms, IMHO, just fine to the CGATs specifications. Only Xrite's i1Profiler seems to be expecting a limited subset of fields in the CGATS file it is attempting to load. Anyway, once I figure out what boxes should be checked and which ones shouldn't be checked in the HP utility menu, we will get to the same text file that Doug had evaluated, and the 49 goes to 44 text change using a text editor along with the extension change from .csv to txt in the filename will enable i1Profiler to read the file correctly.
I hope that explanation helps.
best,
Mark
http://www.aardenburg-imaging.com
-
Interesting difference. It has several additional fields, XYZ's and D_RED, D_GREEN, D_BLUE. No idea what the last 3 are.
However, if you change "NUMBER_OF_FIELDS 55" to "NUMBER_OF_FIELDS 50" that may work as it's the elongated spectral data that I1Profiler doesn't like.
Hi Doug, I tried this approach first after seeing I had later generated a text file with 55 fields (see my prior post in this thread) However, i1Profiler got confused by the RGB density fields, so it accepted the file, but the profile generation was pure garbage because it thought the RGB density fields were part of the spectral data, as far as I can tell. So, to get this all to work right we just need to limit the HP's text file to only the spectral data plus the three LAB value column at most in order get i1Profiler software to play Nice with the text file. We could probably create another field count where only spectral data and not Lab values are included, but I think the practical answer is just to determine which checkboxes in the HP menu need to be checked to produce the text file just like the one you first evaluated. This isn't a tough problem, just a little attention being paid to the particular details to make it all work right. Your observation on the extra spectral fields that HP includes but i1Profiler needs to ignore was the fundamental key to the puzzle! Thanks. all the extra junk to make it work consistently is relatively trivial, IMHO. By deleting the RGB density and XYZ columns in the 55 field count file using Excel, then once again assigning 44 as the field count value, I got i1Profiler to load the file and build a proper profile. Hence, we should be able to get this little wrinkle in the workflow sorted ASAP by figuring out what checkboxes should be checked in the HP menu and which one should be left unchecked.
I'm looking forward to sending 2371 patch count to the HP printer and letting the HP print the target, read it, then let i1Profiler crunch a decent profile from the HP saved CGATs text file (this odd patch count request just so happens to optimize i1Profiler's neutral gray patch generation in the target set)!
best,
Mark
http://www.aardenburg-imaging.com
-
Hi Doug, I tried this approach first after seeing I had later generated a text file with 55 fields (see my prior post in this thread) However, i1Profiler got confused by the RGB density fields, so it accepted the file, but the profile generation was pure garbage because it thought the RGB density fields were part of the spectral data, as far as I can tell. So, to get this all to work right we just need to limit the HP's text file to only the spectral data plus the three LAB value column at most in order get i1Profiler software to play Nice with the text file. We could probably create another field count where only spectral data and not Lab values are included, but I think the practical answer is just to determine which checkboxes in the HP menu need to be checked to produce the text file just like the one you first evaluated. This isn't a tough problem, just a little attention being paid to the particular details to make it all work right. Your observation on the extra spectral fields that HP includes but i1Profiler needs to ignore was the fundamental key to the puzzle! Thanks. all the extra junk to make it work consistently is relatively trivial, IMHO. By deleting the RGB density and XYZ columns in the 55 field count file using Excel, then once again assigning 44 as the field count value, I got i1Profiler to load the file and build a proper profile. Hence, we should be able to get this little wrinkle in the workflow sorted ASAP by figuring out what checkboxes should be checked in the HP menu and which one should be left unchecked.
I'm looking forward to sending 2371 patch count to the HP printer and letting the HP print the target, read it, then let i1Profiler crunch a decent profile from the HP saved CGATs text file (this odd patch count request just so happens to optimize i1Profiler's neutral gray patch generation in the target set)!
best,
Mark
http://www.aardenburg-imaging.com
Hi Mark,
I also played a bit deleting various columns and found the only ones needed for I1Profiler are the ID, RGB, and Spectrum data. The rest are ignored. I'm not even sure the ID is needed. Didn't try that.
-
Hi Mark,
I also played a bit deleting various columns and found the only ones needed for I1Profiler are the ID, RGB, and Spectrum data. The rest are ignored. I'm not even sure the ID is needed. Didn't try that.
Sounds totally logical, but for some reason, i1Profiler crashed and burned on me with the profile generation step after accepting the file I loaded with appropriate field count number but still containing the RGD denisty fields. Yeah, it even led me to believe it had successfully built a profile, but the profile was total junk, not even close to quasi-functional. My negative result certainly bears repeating to confirm, but based on this first attempt, and the fact that I succeeded in building a proper profile after deleting the density fields, I suspect the RGB density fields must not be present or else i1Profiler gets confused over where to locate and read the corresponding spectral fields. Again, I find it interesting that Argyll and BasicColor seem to have no trouble parsing the data. Only i1Profiler seems to be looking for a more exacting string of numbers.
-
The HP utility allows you to save various attributes into the text file along with the spectral data, e.g, lab values, XYZ values, even RGB density values. When you check all the boxes in the HP menu at the point where you want to save the text file, you end up with the 55 fields, whereas, apparently with the original text file I posted and which Doug Grey analyzed, not all those boxes had been checked. So, your 55 field number indicate you have extra RGB density values and XYZ values included in the file that the 49 field text file I let Doug evaluate didn't have.
That's exactly right. In the original instructions posted in this forum, Geraldo stated to check all the boxes beneath "Save as CGATS measurements file", which I have done since and that works with Argyll. I'm attaching a screenshot of that dialogue box for illustration. By default, the CIE XYZ, CIE Lab and Status E measurements are NOT selected. I bet that's where the differences in my and Mark L's arise, and to avoid having to do the spreadsheet exercise when prepping a file for i1Profiler those boxes should not be selected.
I'm completely out of my league here on the programming details or the data needed to calculate a good profile, but I wonder for the moment if any of that info might be important and have something to do with the lumpiness of the profile created with Mark L's file.
-
That's exactly right. In the original instructions posted in this forum, Geraldo stated to check all the boxes beneath "Save as CGATS measurements file", which I have done since and that works with Argyll. I'm attaching a screenshot of that dialogue box for illustration. By default, the CIE XYZ, CIE Lab and Status E measurements are NOT selected. I bet that's where the differences in my and Mark L's arise, and to avoid having to do the spreadsheet exercise when prepping a file for i1Profiler those boxes should not be selected....
yes, I think your screenshot show what should and shouldn't be selected, but Mark L. and I had indeed checked all the boxes in our most recent custom patch count effort when the 55 field count came up, and inspection of the file showed LAB, XYZ, and RGB density fields had been included. So, we probably just want it to get down to the spectral data only, although i1Profiler didn't seem to mind the LAB data fields included and these fields were part of what led to the 44 field count correction value Doug found did the trick. Argyll and Basicolor RGB drop both appear to have more sophisticated programming than i1Profiler, ie., in the sense of being able to correctly parse which fields are which, and thus more forgiving to what boxes we check in the HP menu.
cheers,
Mark
http://www.aardenburg-imaging.com
-
Sounds totally logical, but for some reason, i1Profiler crashed and burned on me with the profile generation step after accepting the file I loaded with appropriate field count number but still containing the RGD denisty fields.
I poorly stated what I tried. It was that leaving off the other fields, in addition to leaving off the RGD fields, works fine. Don't need anything other than the id field, RGB fields, and Spectrum with the length reduced by 5 so I1Profier ignores the extra spectrum data.
-
Good work everyone. Brad, yesterday Mark M and I came to the conclusion that checking only certain boxes in the color measurement dialog should be able to streamline the resulting file, so we’ve all got consensus there. Doug, what both Mark M and I found troubling, is how to determine the exact fields required (from 49 to 44 in the case of the 1728 target) which changes depending on the size of the target being built. So when that last step of reducing the number of fields comes up, how exactly are you determining that number? Apparently you are suggesting leaving the dialog boxes unchecked as discussed by Brad and MHMG AND then reducing the fields in addition. If the number of fields generated is 55, are you saying we then use 5 as the number to reduce all field numbers by? Please clarify this if you would, OK?
Also, I have found that oddly, if I try to bring a CGATS file into the Z, such as a file which is an Atkinson target presumably created by i1profiler, sent for example by Andrew Rodney (thanks again Andrew), that file will not open in the Z dialog box - it will not accept it, instead saying it is invalid.
However... if opening the file, copying the data, then simply pasting in Notepad, not changing anything, but then just saving that file, oddly, the Z will then accept it.
So that’s bizarre.
So let’s get this all ironed out so we can finally have a perfect work flow. if you wil, and get the process distilled down to a workable essence. I have a most generous comittment from Mark M-G to do an article including tutorial and targets (the prize in the bottom of the Cracker Jack box) that I will publish on Z3200 for anyone to use.
I must say, this forum is awesome. I originally asked Geraldo’s help, and he came through in a huge way. Now we have many other players in this story which will lead us to a workable solution putting the automation capabilities of target creation and reading by the Z3200ps printer with ESP on a par with cutting edge technology.
I remarked to MHMG: “consider the momentous decision, when HP engineers, in their wisdom, decided to leave the internal workings and ability to create and read advanced scale targets in the machine once the decision was made to end APS. Kudos to them for leaving the framework so that we are still able to figure a solution out. Yet another thing that makes the Z a rockin’ machine, now capable, it seems of making any size profile we want. I remember there have been others who have mentioned they successfully created larger targets (can’t remember who [* Edit - Aaron Chan]), but hopefully now, we’ll have the processes and flavors /special sauces, etc., available as a unified workflow settled and documented, soon, for all to use.
I hereby claim the Z Series printer,
“THE UNCOMMON PRINTER FOR THE COMMON MAN”
Mark L / 12/06/2017
https://m.youtube.com/watch?feature=youtu.be&v=4NjssV8UuVA
*Edit - Added Aaron Chan as an individual who has previously made i! Profiler Targets to be read by the Z3200ps printer’s ESP. He, among others have done this before, yet I think it is more difficult without the APS Software as we are currently discovering.
*Note: The Aaron Copland music “Fanfare for the Common Man” is an awesome piece and the photos in the youtube video are also very cool...except the end, cheesy alien, stuff. Look past that and enjoy the music - it’s truly a great American Treasure by one of America’s great composers. This, brought to you in the spirit of fun, only, and a tonque in cheek, albeit serious recognition of HP Z Series printers. -M
-
However... if opening the file, copying the data, then simply pasting in Notepad, not changing anything, but then just saving that file, oddly, the Z will then accept it.
Some text editors make invisible changes such as converting tabs to spaces... just a possibility.
-
Some text editors make invisible changes such as converting tabs to spaces... just a possibility.
Thanks Graham, I think you’re onto something with that.
M
-
Couple things.
The reduction by 5 in the "NUMBER_OF_FIELDS" entry causes I1Profiler to ignore the trailing 5 fields in the subsequent list of field names, which are the unwanted spectrum wavelengths from 740nm to 770nm. These are then skipped in the DATA segment.
The major file format issues are from the different way end of lines are marked in Linux/Unix type OS's and Windows/DOS. The latter ends lines with CRLF, (bytes in hex: 0xd, 0xa), while the former uses only LF (0xa). Tab (0x9) handling is the same for both systems. As Graham noted, tabs can sometimes be replaced with spaces or, less often, spaces converted to tabs in either set of OS's. Usually details are changeable in the settings.
Most code editors for languages common to both OS's will handle files from either system. I use Visual Studio and open the file as a "text file." The VS editor has a nice feature where you can select a block of text offset horizontally and strip it out which is what I did to test removing various fields. For instance when removing the RGD labels it is also necessary to remove the following DATA or it will skew everything causing the wrong spectral data to be read.
I1Profiler ignores the LAB, XYZ fields if included but doesn't require them to be included. The RGB and Spectral data are required because they both are required to create profiles. It calculates them from the spectral data whether they are there or not. This is done based on the instrument generation selected when loading the CGATS measurement file from the HP Z3200ps in I1Profiler.
-
I just changed the title of this post to something that better reflects the discussion, which is going in a slightly different but more interesting direction from my original simple question that triggered all this off.
I'm VERY interested to see what type of i!Profiler solution Doug, and Mark L and Mark M-G come up with. There appears to be different processing functionality with that profile maker that will be interesting to see play out. And it will be interesting to see how automated and more simple those profiles can be than the current process some of us have been using.
But since there's a slow period at the moment, I'll fill it in with hopefully a worthwhile diversion.
I just downloaded basICColor DropRGB for a free 14 day demo and generated an ICC profile with a recently scanned 1728 patch Ilford Gold Fiber Gloss sample (which I hope Mark M-G is testing - I really like this paper).
I ran ColorThink on the ICC profile I built with basICColor (I selected the smoothing option). That appears as the wireframe here. The solid frame gamut is an earlier profile I processed using Argyll using a different print sample printed about a month ago. The patches on the earlier print were not as clean as I'd have liked (some of the dark greens had white spots of unknown origin), and printing a Bills Balls test I could see that the greens had banding, so I reprinted it and just reprocessed the new sample just now. Immediately I loaded it up into ColorThink (which I refer to when managing out of gamut colors when printing) just to see how different the two profile makers operate.
I am pretty amazed by the differences. Others more familiar with different color profiling engines probably are not surprised, but this is quite meaningful to me. When we think of small differences in lenses and all he money and time we spend on them, this really proves just a little attention to printer profiles might pay off a lot more.
I haven't printed with this new profile yet, but I have noticed my reds, oranges, yellows and greens have been somewhat compressed and color detail lacking. That's where the greater differences are between the two profiles, so I'm looking forward to seeing that in print.
Addendum #2: I just repeated this test with Canson Rag, my other go to paper. In that case I ran exactly the same color patch data through both Argyll and DropRGB. If you can say here there was about a 4% mapping difference (probably a little less if fact, but close), with Canson Rag it was probably about 3% difference. The differences in the set of charts below is primarily in the reds and yellows. In the Rag it was mostly in the blues and reds. Hmmm.
-
Hi Brad -
So you keep referring to my 1728 "lumpy" target - Not sure where you're getting that from?
So far, nothing of mine has been used - the only ones are in graphs that Mark (MGHG) made on previous pages.
The only 1728 patch Targets we've been discussing are the resident 1728 that the Z generates and the Atkinson 1728.
I have not yet played with the Atkinson 1728 -only smaller and the largest - 5,028 - all 5 feet of it.
Also, I have not used RGB Drop - only Argyll through ICC GEN which is:
CLICK HERE TO SEE ICC GEN (http://z3200.com/ICC_GEN_For_WIN-MAC-for_%20use_%20with_%20HP-Z3200_Printers.htm)
I've had "others" who have used RGB Drop to make Test Profiles for me for the express purposes of testing but haven't used it myself yet.
My goal (and MHMG) is to find several alternatives that will enable the data from the ESP generated from the Z Series printers to be read. I know RGB Drop works well - most of them do, including Argyll.
Your post and the illustrations are interesting.
Mark L
-
Apologies Mark. I incorrectly thought you had supplied the files Doug was working with. I withdraw all insinuations of lumpiness vis a vis you!
I did like the music earlier this morning BTW. Thanks for that.
-
Apologies Mark. I incorrectly thought you had supplied the files Doug was working with. I withdraw all insinuations of lumpiness vis a vis you!
I did like the music earlier this morning BTW. Thanks for that.
Brad,
I was the one referring to the profile's gamut surface with the adjective "lumpy". It undulates around the hue angles gamut boundary more than other profiles I've looked at. This does not have anything to do with whether a printer has banding. and is in no way an indication the profile is defective. It's a side effect of the addition of extra saturated inks the Z3200ps has. It simply has the gamut pushed out in places where the more saturated ink can be used instead of mixing CYM inks. It is harder to create printing drivers for these but HP is a highly technically competent company.
-
Thanks for that detailed explanation Doug. Makes sense now.
-
I should check it this weekend again but I got the impression that when HP APS does not recognize the puck correctly it still allows profile creation from already measured data files. If that is correct it might be possible to use Color Center for the measurement and bring the file to APS with some text changes .
I had computer issues and tried to reinstall HP APS (I kept the registration key etc) but it gave issues on the puck recognition.
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
March 2017 update, 750+ inkjet media white spectral plots
-
Kers has APS and has used it to make profiles. I wonder though, Ernst, the APS uses Gretag MacBeth logarithms which are not the same as i1 that is in the current Z3200ps machines, yes?
Kers remarked he saw banding coming from the custom profiles made with APS. There could be other causes for that as well, but curious to know your view on how the APS from Z3100 days relates to the current i1 spectrophtometer in the current Z3200ps machines?
Hope you can get your APS running again.
Mark
-
Kers has APS and has used it to make profiles. I wonder though, Ernst, the APS uses Gretag MacBeth logarithms which are not the same as i1 that is in the current Z3200ps machines, yes?
Kers remarked he saw banding coming from the custom profiles made with APS. There could be other causes for that as well, but curious to know your view on how the APS from Z3100 days relates to the current i1 spectrophtometer in the current Z3200ps machines?
Hope you can get your APS running again.
Mark
Hai Mark,
yes i saw some banding, but i think it is wise not to draw any conclusion upon this observation;
you really have to be with your head into color and into Z to fully understand what is going on. And then do a lot of testing.
I mean to say that it is very difficult to say at this moment what causes what and why. This matter is just too complicated, with too many factors that influence the process.
- if i test one lens i already can spend hours on it to see what it does exactly- usually already complicated. (and to conclude that tests on the internet jump too fast to (wrong) conclusions)
so i stay at the side of this - very interesting - discussion, also because i do not have the knowledge nor the means ( spectrophotometer etc) necessary to find out what goes on exactly.
In this case i will be the engineer; i do not know exactly why it works , but if it does i am satisfied.
Looking forward to what the more experienced - like you - find out.
a good thing to keep the discussion to the Z3200 - - the Z3100 and the old APS make things only less clear.
cheers
Pieter
-
Kers has APS and has used it to make profiles. I wonder though, Ernst, the APS uses Gretag MacBeth logarithms which are not the same as i1 that is in the current Z3200ps machines, yes?
Kers remarked he saw banding coming from the custom profiles made with APS. There could be other causes for that as well, but curious to know your view on how the APS from Z3100 days relates to the current i1 spectrophtometer in the current Z3200ps machines?
Hope you can get your APS running again.
Mark
When I had only a Z3100 the APS was an optional thing and I got it. When the Z3200-PS arrived here there was an extra APS license with it. There were some version changes over the 11 years I used it; v131, v140, v141, I have them archived. What I recall though was a change in the headings of the created profiles in the switch from Z3100 to Z3200, as if the color engine / underlying profile creator, changed per machine. I must have written about this in the past. I did not observe much difference between the profile qualities made with either and Color Center improved a lot between the Z3100 and Z3200 that its last version is equal to APS so I did not pay much attention to that difference.
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
March 2017 update, 750+ inkjet media white spectral plots
-
Hai Mark,
yes i saw some banding, but i think it is wise not to draw any conclusion upon this observation;
you really have to be with your head into color and into Z to fully understand what is going on. And then do a lot of testing.
I mean to say that it is very difficult to say at this moment what causes what and why. This matter is just too complicated, with too many factors that influence the process.
- if i test one lens i already can spend hours on it to see what it does exactly- usually already complicated. (and to conclude that tests on the internet jump too fast to (wrong) conclusions)
so i stay at the side of this - very interesting - discussion, also because i do not have the knowledge nor the means ( spectrophotometer etc) necessary to find out what goes on exactly.
In this case i will be the engineer; i do not know exactly why it works , but if it does i am satisfied.
Looking forward to what the more experienced - like you - find out.
a good thing to keep the discussion to the Z3200 - - the Z3100 and the old APS make things only less clear.
cheers
Pieter
Hi Pieter-
Yes, agreed. Extremely complicated.
Mark McCormick and I are currently doing ICC profiles at the same time - he in Massachusetts and I in Florida.
We have successfully made 2 targets and have read them both: 1457 and 1877 from charts Mark made with i1Profiler.
I'm doing an 1877 patch target now, as I speak. MHMG ran into a glitch when attempting to print a 2371 patch target - he's printing using the Mac Utility and I'm using the Windows Utility running on VMWare Fusion for Mac and mine is still reading so far.
We're learning a lot and it looks like we will be able to crack this nut soon.
Going to do an article and tutorial on Z3200.com and include profiles, etc.
Thanks bud - appreciate all you do.
Best -
Mark L
-
When I had only a Z3100 the APS was an optional thing and I got it. When the Z3200-PS arrived here there was an extra APS license with it. There were some version changes over the 11 years I used it; v131, v140, v141, I have them archived. What I recall though was a change in the headings of the created profiles in the switch from Z3100 to Z3200, as if the color engine / underlying profile creator, changed per machine. I must have written about this in the past. I did not observe much difference between the profile qualities made with either and Color Center improved a lot between the Z3100 and Z3200 that its last version is equal to APS so I did not pay much attention to that difference.
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
March 2017 update, 750+ inkjet media white spectral plots
Hi Ernst - thanks for that - it helps fill in puzzle pieces. Do you recall what was the last year they upgraded APS?
You also mentioned that the Software would still make an ICC profile without the dongle. That's interesting.
Would like to get my hands on a copy and the upgrades.
So MHMG and I are making some good progress - will keep everyone posted with the results eventually.
Thanks Ernst -
Mark
-
Going to do an article and tutorial on Z3200.com and include profiles, etc.
Please post a link here when the nut is cracked. Don’t want to miss it!
-
You also mentioned that the Software would still make an ICC profile without the dongle.
Note that some 'copy protection' is built directly into some measuring instruments. It IS the dongle. Copra's 'dongle' is a USB stick.
-
Note that some 'copy protection' is built directly into some measuring instruments. It IS the dongle. Copra's 'dongle' is a USB stick.
Thanks for that reminder Andrew - good point. - Will be very careful.
Mark
-
OK. I've just started the 6000 patch target on my Z3200ps 44" printer. Whoever thinks the HP Z3200ps printer is not a formidable printer with the ability to create profiles of all kinds and sizes, better think twice.
Not only is the Z3200ps Vivera Inkset still King of the Hill, the printer continues to prove itself absolutely the Swiss Army Knife of machines for the small to medium studio photographer/printer.
I ask myself, WHY would you want any other printer when everything else is huge, heavy, incredibly overbuilt and expensive to maintain when there is the Z3200ps still running on the brilliant design brought forth from the Barcelona team using 15 year old ink technology which has time and time again proved itself in head to head tests, still to this day, and all the other attributes that make this printer utterly a pleasure to own and use.
Granted, not everyone will make a 6000 patch target ICC profile, but it can be done.
I'm doing it. Just because I can. Just because this printer can.
Thanks MHMG for the Chart.
Off we go. Will report back in.
Mark
-
I'm doing it. Just because I can. Just because this printer can.
Thanks MHMG for the Chart.
Off we go. Will report back in.
Mark
I continue to have some glitches trying to run patch counts larger than 2000 on the Mac version of the HP Utility. This may be a software bug I can't circumvent with the Mac driver alone, but as Mark L. has already proven, the VMWare Fusion app opens up access to running the HP windows driver version on my Mac, so this avenue is a proven workaround if all else fails. That said, I've successfully auto printed and measured 1457, 1728, and 1877 targets on the Mac. Delightful just to sit back and let the HP Z3200 do its thing and save out a measurement file that can be dragged quickly onto BasicColor RGB Drop (or Argyll with iCCgen as a simple GUI to avoid terminal) and a nice profile built in no time. i1Profiler requires a little text cleanup of the HP generated data file as Doug Grey has shown us, but the HP Z-measured text file then ports easily into the i1Profiler software as well. It's all good! Any state of the art ICC profiling solution is likely to work.
The profile I built with the 1457 patch count for Moab Entrada Natural (my main go-to fine art matte paper) is remarkably excellent. I'd be perfectly happy just to live with the 1457 patch count printed and measured with utter simplicity on my Z3200. i1Profiler does indeed max out the percentage of neutral/near neutral patches in these oddly chosen patch count files as reported by Ethan Hansen, et. al.. The HP printer utility sucks those patch target txt files in without any trouble, then creates an efficient layout of the target based on sheet/roll size selected and prints it. The 1457 patch file used 1 foot of paper on the 44 inch roll I had loaded in the printer, a reasonable economy given that I'd need 3 letter-sise sheets of paper to print this target from i1Profiler for measurement with my hand-held i1Pro2 spectrophotometer. No more having to go into adobe color printer utility or Apple CSU to print out "no color adjust" targets on multiple sheets of paper :)
Although I've admired the Vivera ink permanence since the beginning, I'm still a relative newcomer to the Z3200 owner's club. I've had my Z for about a year now, and I like it more and more as each day passes.
kind regards,
Mark
http://www.aardenburg-imaging.com
-
Doug, do you know offhand whether the Bills Balls print test would reveal the lumpiness caused by saturated inks used at gamut boundry that you referred to earlier, and whether that would be somewhat ameliorated by more patches than 1728?
As background, I printed four samples in P and R out of LR and PS with what I believe an as well as can be done 1728 patch on a very smooth baryta coated almost gloss paper using DropRGB as the engine, I’m still seeing room for improvement with that test. (I believe some of these results could be from imaginary OOG Lab colors that are presently insolvable.)
Attached is an iPad shot of what I’m looking at. The pics on the other side appear excellent but just hoping to see all the Z can do.
-
Be somewhat careful with Bills Balls (not joking). They are synthetic and may contain 'imaginary' colors which is something interesting to use on profiles to see how they deal with them.
The idea behind the balls:
Andrew,
I intended this image to be used without a profile, and the answer about imaginary colors would completely depend on what RGB source profile you tagged it with. All RGB numeric values do fall in the range of 0.0 to full-scale, so if you tagged the image with sRGB, then all colors on all balls would of course be within the gamut of sRGB. You can open the file in Photoshop and assign any RGB source profile to it, then look at the resulting soft-proof for a given printer profile.
Bill
-
Be somewhat careful with Bills Balls (not joking). They are synthetic and may contain 'imaginary' colors which is something interesting to use on profiles to see how they deal with them.
The idea behind the balls:
I agree with Andrew here. Exercise care with these. They (when in ProPhoto) are useful to get a sense of how imaginary as well as highly saturated colors are mapped to ones the printer can print. It's more problematic when used with printers with extra, highly saturated inks. These inks allow the gamut to stick out a bit in portions of the gamut where they provide enhanced color capability. The downside is that this also can reduce smoothness in things like grainger gradients and Bill's Balls. Especially when the source image is a huge space like ProPhoto. Once a requested color is outside of a printer's gamut there is no specification as to how these colors will be mapped.
This is one of the reasons soft proofing is so valuable. Especially when using ProPhoto RGB because the colors shown should, and in my experience do, reflect what will be printed quite well. You will see the same banding soft proofing Bill's Balls that the actual prints show.
To see what they look like using them according to Bill (from Andrews comment), assign the printer profile to the Ball's RGB image. Then convert back to ProPhoto RGB using Relative Intent but with BPC unselected. It's a little tricky to actually print them per Bill's recommendation. You need to print them without color management like one would print a profiling target sheet. See Adobe's ACPU.
-
Doug, do you know offhand whether the Bills Balls print test would reveal the lumpiness caused by saturated inks used at gamut boundry that you referred to earlier, and whether that would be somewhat ameliorated by more patches than 1728?
No, More patches will usually produce a more colorimetrically accurate profile but will not materially change the rendering of Bill's Balls from ProPhoto. A portion of them are imaginary, and most of the rest, aside from the neutral colored ones, are out of gamut so will be rendered based on the profile software designer's chosen algorithm. It's pretty much arbitrary and you will see big differences between Argyll and I1Profiler amongst others. Even when using the same exact scan data to make profiles.
BTW, these differences are a principal reason for Andrew's video that "All Profiles are Not Created Equal." Profile s/w should create the Colorimetric portions of profiles very closely as that is well defined. But even there, some s/w doesn't conform to the latest ICC specs, etiher V2 or V4. In particular the canned ones that came with my Canon 9500 II and Epson 9800 are defective but in different ways.
That said, perfectly well formed, "correct," profiles can and do have very different ways of doing Perceptual intent and especially how they map OOG colors in any Intent.
There's not a right or wrong for these as it's not a measureable attribute. My preference is that imaginary and OOG colors be printed with some similarity to the way they normally look in a wide gamut monitor. These colors are also OOG for the monitor but, unlike printers, monitors have well defined algorithms for how these colors are converted and what color results. Monitors that are similar to the Adobe RGB gamut will show Bill's Balls quite predictably.
As background, I printed four samples in P and R out of LR and PS with what I believe an as well as can be done 1728 patch on a very smooth baryta coated almost gloss paper using DropRGB as the engine, I’m still seeing room for improvement with that test. (I believe some of these results could be from imaginary OOG Lab colors that are presently insolvable.)
Attached is an iPad shot of what I’m looking at. The pics on the other side appear excellent but just hoping to see all the Z can do.
Doesn't concern me at all. I'd be surprised not to see it. Especially on a wide gamut printer with extra saturated inks. Has nothing to do with how well it prints in gamut colors and it's really something that the profile software determines and what the programmer considered important. You will see very different results with different s/w.
-
There's not a right or wrong for these as it's not a measureable attribute. My preference is that imaginary and OOG colors be printed with some similarity to the way they normally look in a wide gamut monitor.
Agreed. I've seen some profiles render Bill's balls to nearly all black and that's rather ugly. I've seen others rendering them so they appear blue. Much more visually pleasing.
-
Agreed. I've seen some profiles render Bill's balls to nearly all black and that's rather ugly. I've seen others rendering them so they appear blue. Much more visually pleasing.
Yup. My 9800 canned ones do that! But they are made incorrectly too. Oh well. BTW, I added a reference to your video about how these vary in my earlier comment while you were posting this.
-
Very interesting. I’ve been playing around with B.B.’s all morning, including rewatching Andrew’s excellent video, playing around with the saturation slider, looking at results on my Adobe RGB monitor and comparing the monitor to actual prints. I think I finally get how that all works together now. Thanks.
One thing I especially believe I’m learning is that I might get more at this point looking for optimal profiling software for my setup and lighting conditions rather than increasing patches from 1728 to 6000, although that would help too as Mark and Mark are discussing in a new post on using the Z to print and measure a 6000 patch set. And as helpful as soft proofing is in the workflow, it’s absolutely necessary to look at actual prints in reaching decisions there.
-
Hi Ernst - thanks for that - it helps fill in puzzle pieces. Do you recall what was the last year they upgraded APS?
You also mentioned that the Software would still make an ICC profile without the dongle. That's interesting.
Would like to get my hands on a copy and the upgrades.
So MHMG and I are making some good progress - will keep everyone posted with the results eventually.
Thanks Ernst -
Mark
This morning I tried to reinstall the HP-APS software based on older installation files I kept. The registration keys did not work anymore and neither the activation page at Gretag Macbeth now X-rite or the registration page at HP exist anymore. The Display Two puck possibly went kaput or I have the keys from the other puck here, the one I sold with the other APS license. I doubt the last though as I had APS working after the sale. Never used the puck anymore for the monitor so it was really a dongle. The Display Pro is much better.
Making profiles based on measurement files looked possible but at the last stage the same, my words: 'wrong Display etc activated, use the other one' error appears. So no route there. I have to dig in older archives but it is probably easier to take the ArgyllCMS solution now. I contributed for that in the past and bought the Android Argyll app last year so I might as well use that.
With the last version 141 of the HP-APS (7-2011 is the likely date of launch of that one) I see 'Copyright Logo GMBH Steinfurt' in the Z3100 profiles made and 'Copyright X-Rite' in the Z3200 profiles made. Structure of the data seems to differ too. Color Center profiles have the HP copyright in the headings.
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
March 2017 update, 750+ inkjet media white spectral plots
-
Thanks Ernst, more puzzle pieces with which to solve the missing APS mystery. MHMG and I both think it became a licensing issue, once everything moved to i1, and your recent information helps to confirm that supposition. Man, I’m sorry you can’t get your APS to activate. I just found Michael Reichmann’s original article on making profiles with the Z3100 and APS:
Michael’s Article on APS Profile Making on Z3100 (https://luminous-landscape.com/making-profiles-with-the-hp-z3100-2/)
(This is part of the subscription based archives) So there are many interesting tips and tricks for using the APS and the means to trick it into making larger targets. It’s interesting, especially considering it goes back to 2009.
But I agree, Ernst, the current color center does most of what APS did, and no tricks, with the exception of making the final ICCProfile from the .TXT file. Argyll works really fine, especially if you are using Rel Col. I imagine Terminal is a second language for you, but if you are interested, you can use the free GUI my son built:
ICC GEN (WIN / MAC) (http://z3200.com/ICC_GEN_For_WIN-MAC-for_%20use_%20with_%20HP-Z3200_Printers.htm)
FWIW, Argyll and Drop RGB perform almost identically with RelCol.
Not sure if you followed this, but MHMG and I both experienced a bug in the Mac Utility where it refuse to finish printing targets over 2000 patches, yet goes on to measure then fails. I found that Windows will, in fact, sail right on through, right up to 6000 patch targets, flawlessly.
I do think the APS is now history, but for those still using it, it does provide a model for doing the same thing in color center. Once in the color measurement dialog, when choosing the target size, instead, just click the + sign which takes you to an opportunity to add a chart file to the list. It adds it, but does not show it until you go back to the drop down menu, and sure enough, it is there.
Chart files made with i1Profiler2, modified via Doug Gray’s suggestions work great.
Maybe it’s just a matter of finding the right key, but if you can’t get your APS working I don’t think it’s a big loss at this point.
Best,
Mark L
-
Thanks Ernst, more puzzle pieces with which to solve the missing APS mystery. MHMG and I both think it became a licensing issue, once everything moved to i1, and your recent information helps to confirm that supposition. Man, I’m sorry you can’t get your APS to activate. I just found Michael Reichmann’s original article on making profiles with the Z3100 and APS:
Michael’s Article on APS Profile Making on Z3100 (https://luminous-landscape.com/making-profiles-with-the-hp-z3100-2/)
(This is part of the subscription based archives) So there are many interesting tips and tricks for using the APS and the means to trick it into making larger targets. It’s interesting, especially considering it goes back to 2009.
But I agree, Ernst, the current color center does most of what APS did, and no tricks, with the exception of making the final ICCProfile from the .TXT file. Argyll works really fine, especially if you are using Rel Col. I imagine Terminal is a second language for you, but if you are interested, you can use the free GUI my son built:
ICC GEN (WIN / MAC) (http://z3200.com/ICC_GEN_For_WIN-MAC-for_%20use_%20with_%20HP-Z3200_Printers.htm)
FWIW, Argyll and Drop RGB perform almost identically with RelCol.
Not sure if you followed this, but MHMG and I both experienced a bug in the Mac Utility where it refuse to finish printing targets over 2000 patches, yet goes on to measure then fails. I found that Windows will, in fact, sail right on through, right up to 6000 patch targets, flawlessly.
I do think the APS is now history, but for those still using it, it does provide a model for doing the same thing in color center. Once in the color measurement dialog, when choosing the target size, instead, just click the + sign which takes you to an opportunity to add a chart file to the list. It adds it, but does not show it until you go back to the drop down menu, and sure enough, it is there.
Chart files made with i1Profiler2, modified via Doug Gray’s suggestions work great.
Maybe it’s just a matter of finding the right key, but if you can’t get your APS working I don’t think it’s a big loss at this point.
Best,
Mark L
I will manage, not really a thing to worry about. Some years back (2011 and later in the files data) I tried to add grey patch targets to Color Center but later on went for APS and had a trial 17 patch greyscale target to print and get measurements for the QTR B&W profiler. Z3200 in B&W mode to use it on. And also on a desktop printer with a trial quad ink mix (Z3200 MK + PK + dilutions). With a new manual spectrometer it was easier to do it manually, 34 patches target file I ended with. I think for the Z3200 it will be better to stay in color mode for print and color management as profiles with enough grey patches will solve the a b deviations easier than ink mixing does. The MK ink is warmer than the neutral PK and Grey inks. Count to that OBA and non-OBA paper whites and it becomes hard to get that a b controlled in ink mixing. So I am grateful for all the puzzling done by the people that contributed to this thread.
Not much of a programmer, more the trial and error guy in manipulating CGAT files. So I recognized the patch number change needed and what columns to strip for a profile creator acceptance.
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
March 2017 update, 750+ inkjet media white spectral plots
-
Well, I had some extra HP Universal gloss paper lying around . . .
I found a work around to print a 4357 target without leaving Mac. Who knows, it could go up to 6001 or infinity.
It's 9:20 pm local time and I'm done for tonight having just printed it. Will let it dry and scan in tomorrow morning. I'm guessing the scanned file might drop into DropRGB or be able to be processed in Argyll, probably also i1Profiler since it's based on a color chart there and only has the HP header. Here's the procedure.
1. Open i1Profiler
a. In User Mode, click “Advanced”
b. Under Printer, device selection, select “RGB Printer”
c. Under Workflow, select Profiling
d. Under Smart Patch Generator, select 4357 (or another profile target patch number)
e. Click on Save
f. In the save dialogue box,
i. Name the file (I named it Chart 4357 Patches}
ii. Select the directory where the file will reside. Desktop works
iii. Select “Custom CGATS(*.txt)”
iv. Then click on “save”
g. A pop up appears with a lot of custom CGATS options (including a D50 illuminate default selection). Accept the defaults. I’m think I’m generally right to do so, but someone might want to double check me on that.
2. Open the file in Textedit. Swap out the header information for this one and save. I modified this header after an APS profiling chart embedded deep in in the APS application files (I too lost my dongle, and sadly remember a tiny bit of DOS from 1989ish. The header will only work with a file of equal size as this outlined one. I suspect it has something to do with the first line). All spaces are actually tabs.
LGOROWLENGTH 21
CREATED "12/10/2017” #Time: 12:57
KEYWORD "SampleID"
KEYWORD "SAMPLE_NAME"
NUMBER_OF_FIELDS 5
BEGIN_DATA_FORMAT
SampleID SAMPLE_NAME RGB_R RGB_G RGB_B
END_DATA_FORMAT
NUMBER_OF_SETS 4357
BEGIN_DATA
3. Open the HP Utility to print the test chart
a. Select the printer, Paper Preset Management, the paper to be profiled, the little gear box on the bottom, then color measurement.
b. Select Print a color chart for later measurement, “Print a color chart for later measurement” and (if you use it), check Print using gloss enhancer, then select Continue
c. In the “Select Color Chart” menu, click on the plus sign, select the file just created with i1Profiler as modified, click on Open, go back to the drop down menu and select that file. Make sure it’s selected in the “Select Color Chart” dialogue box then click Continue.
The chart should begin printing.
Badly dim lit iPhone 6 pics attached off a 36" roll.
ADDENDUM: Proof of concept. I waited an hour, scanned it and saved a CSV file. Dropped that into a BasICColor DropRGB demo and it put out an ICC file. Attached the resulting ICC file to the Universal profile in the utility, and voila. It works.
Looking at the screen in P in soft proof mode, the BB tests look better. But it's a different paper (a significantly worse grade, HP Universal Glossy 36 inch instead of Ilford Gold Fibre Gloss 44). The print looks very good for the Universal paper except for the newly added Granger rainbow which is a mess. The BW ramps look clearly better in person in the new print. For now, I'm blaming it all on that paper and in the picture warm old dim LED living room lighting. Dunno. I'll do more tests later but for now, I'm happy. ColorThink tests on the results with Argyll and other engines will have to wait (12:40 am), probably for a few days for a new roll of IGFG to arrive.
Photos attached.
ADDENDUM 2, strangely this did not work when repeated on a different paper profile. In fact, the target file would not even load into the HP Utility. I’m at a loss why the different results.
-
Hi Brad, just to confirm, yes this is the exact work flow MHMG and I have been discussing and Mark MHMG has been working on. So yes, you have the correct work around for Mac Utility.
As far as adding the patch target size file in under the list, clicking the “+” sign is the correct method, and then using the drop-down menu, the new target will show up. Install profile is the way to go, as Geraldo pointed out in his original thread in order to get the newly generated /ICC file included in the custom paper list. Thanks for listing the steps. We’ve been doing this, but haven’t posted it yet, wanting to finalize our test results. I ran into a glitch with the Windows HP Utility, where although it would print and measure the 44” wide 6000 patch target, it failed to print and measure the 4357 target on 24” Wide Moab Entrada.
After much screwing around, I put a 6 ft. Long table in behind the printer, cut the roll into a sheet that was about 5+ feet, and using “load paper with skew check”, was able to get the spectro to read the chart using the very same workflow of “measure a previously printed chart”. MHMG is testing the bugginess of printing tiff files with Apple Color Sync, etc., and we are continuing to carefully plod through various iterations until we know for sure what bugs are and aren’t in both the Mac and Windows HP Utilities before publishing the results. Your list of steps will come in handy when we do come to that point. Very good. It also confirms our results.
Mark
-
... I found a work around to print a 4357 target without leaving Mac. Who knows, it could go up to 6001 or infinity. ...
Hi Brad, glad you succeeded printing and measuring the 4357 i1P generated target directly from the HP color utility on the Mac. Our workflow is AFAIK identical except for your modification to the header of the patch count target. That said, I have my doubts this is the source of my Mac failing to print the whole patch set direct from the HP color utility for two reasons:
1) I've had the 1728 patch target supplied in the HP Color Utility by HP also fail in the same way at least once although it succeeds usually. Surely that patch target has the header info exactly as it should be (I'd check that out, but I'm not sure where the HP utility software hides that file).
2). I can take the 4357 and other i1P exported CGATs chart files directly into the HP Color Utility, and the HP color Utility knows exactly how to lay them out with no truncation when it export a tiff file one can print and measure as an Image on the HP or other printers. It seems to me that if the HP is getting confused by the header info in the custom target, it would fail to parse the chart file correctly when laying out the patches for a tiff file export. Yet the exported tiff image files are generated exactly as they should be.
That said, I will take another stab at printing the 4357 target using your suggested header modification hopefully later today.
best,
Mark McCG
http://www.aardenburg-imaging.com
-
Cautions on using CGATS files with I1Profiler.
Major detailed breakdown of I1Profiler handling of fractional RGB values:
1. It does retain them if generated and the "smart patch" generator does generate them. However, stored data I the profiles truncates fractional RGB info.
2. It does round RGB values when printing or creating target TIF files. However, the fractional values are used in calculating the profile.
3. Sampled data can be saved in the profile. Unfortunately, fractional RGB values are truncated in the saved data. If that data is re-used, expect the profiles to have additional error due to the truncation.
For consistency in all modes, I would highly recommend rounding all target CGAT files that have fractional RGB values before using them in any target making/reading application. This retains optimal compatibility with I1PRofiler.
I1Profiler may, under certain circumstances, use fractional RGB data when calculating profiles. If you load a CGATS file with fractional RGB values and spectral data it will calculate a profile using that fractional data.
However, I1PRofiler discards fractional data when you just load targets. Further, it truncates rather than rounds so a value of 89.9 becomes 89. Not using fractional data is necessary with I1Profiler given that it prints out to the device driver with 8 bit values. Also, if you save a tiff file it's in 8 bits too.
This can introduce small errors when using targets with fractional RGB data if the printer utility doesn't have a way to deal with them and just prints 8 bits. Especially if the scanned CGATS file contains the fractional data.
-
Thanks Doug. Just in time, I found some time and was just about to try to print some up. Now I'll hold off a bit
Looking at all the i1P generated CGATS files, all the RGB data are solid single digits (e.g., 204.00) instead of some files I saw at least in CMYK targets that contain decimals out to the fourth digit. Is this single digit rounding error the source of your concern? I could understand that a small patch set might not be so much affected by that, but the kind of detail we're trying to render here would.
If that's correct (or regardless), is there some other CGATS rendering software or website you could refer us to that does a better job? I was actually thinking of making a spreadsheet set of data and plugging that in, but I'd rather find something more accessible.
-
Thanks Doug. Just in time, I found some time and was just about to try to print some up. Now I'll hold off a bit
Looking at all the i1P generated CGATS files, all the RGB data are solid single digits (e.g., 204.00) instead of some files I saw at least in CMYK targets that contain decimals out to the fourth digit. Is this single digit rounding error the source of your concern? I could understand that a small patch set might not be so much affected by that, but the kind of detail we're trying to render here would.
If that's correct (or regardless), is there some other CGATS rendering software or website you could refer us to that does a better job? I was actually thinking of making a spreadsheet set of data and plugging that in, but I'd rather find something more accessible.
Here's entry 17 of the smallest smart patch size (400) generatable in I1Profiler:
85.00 72.86 0.00
This is printed as an 8 bit tif containing:
85.00 73.00 0.00
But this is what's saved in the generated profile
85.00 72.00 0.00
So, sadly, there is no simple way to round the RGB data with i1Profiler. I have various workarounds but hadn't previously noticed these details. Just knew I1Proffiler messed things up in places if there was fractional RGB data.
I think I've make a few profiles from extracting the saved data in a profile and it turns out that is a big mistake. Never use saved data in a profile UNLESS it had no fractional RGB in it at the start. That alone is a compelling reason to use only RGB data w/o a non-zero fractional component.
-
So, sadly, there is no simple way to round the RGB data with i1Profiler.
Does it matter? Can you SEE the 'errors' on output?
-
Does it matter? Can you SEE the 'errors' on output?
Both of you are much better than me to opine on that, but I’d imagine since it’s +/-0.86 of the green channel, the right answer is either no or barely, at least for that one patch. This single observation causes me to wonder, Doug, how pervasive these rounding errors are and the fallout from that the cumulative, limiting effect of these rounding errors on the efficacy of larger patch target sets. Very possibly not much at all, but it seems better to manage the things we can when we see them. Which leads me back to an earlier question, is there a better tool to generate the RGB data than i1P? It looks like some of the $800+ profiling tools might generate some, but at unknown quality (to me) and at that cost, the i1P solution looks probably good enough.
-
Both of you are much better than me to opine on that, but I’d imagine since it’s 0.86 of the green channel, the right answer is either no or barely, at least for that one patch. This single observation causes me to wonder, Doug, how pervasive these rounding errors are and the fallout from that the cumulative, limiting effect of these rounding errors on the efficacy of larger patch target sets. Very possibly not much at all, but it seems better to manage the things we can when we see them. Which leads me back to an earlier question, is there a better tool to generate the RGB data than i1P? It looks like some of the $800+ profiling tools might generate some, but at unknown quality (to me) and at that cost, the i1P solution looks probably good enough.
That was just an example of a color showing how it was rounded when printed and truncated when saved in the icc profile. Most of the patches have fractional values. But is rounding them going to produce visual differences? Almost always they will not.
Still, it's something I've avoided for a long time. When I make a patch set that has fractional RGB values I've almost always rounded the RGB values as the first step before using it as a target. This largely as a result of observations by either Ethan or Mark M. I just wanted to avoid any issue.
However, now that I knowI1Profiler actually uses fractional values I may alter my process. I have the ability to create 16 bit tiffs with those fractional values that are compatible with Isis.
However, Andrew's point is germane. At best this is a small affect and very unlikely to create visible differences. I've investigated the impact it has on measured profile accuracy and it's a small effect until one is making profiles over 2 or thousand patches. I suspect it may be more important with very high ( Over 5k) patch count profiles because these errors, which are small but fixed, become a larger portion of the distance between adjacent patches.
It's more of academic interest than anything else. While I can measure improvements with patch counts over 2k I can't really see any difference in the prints. I can't visually tell any difference in reference prints. Even with the standard 957 count target it's difficult to see any difference. Possible, but just barely.
Being a nitpicker, I just don't like these little discrepancies.
-
Thanks Doug. Very helpful and, for us nitpickers, interesting to know.
-
It's more of academic interest than anything else. While I can measure improvements with patch counts over 2k I can't really see any difference in the prints. I can't visually tell any difference in reference prints. Even with the standard 957 count target it's difficult to see any difference. Possible, but just barely.
Being a nitpicker, I just don't like these little discrepancies.
I found that in smaller prints it was difficult to see differences in identical 17” prints printed with 1728 vs. 4357 or 6,000, but much easier to tell the diferences in 44” prints. The larger the print the more apparent the differences by eye. Subtle differences, but there, nevertheless. At that point it seems to become somehow that the realm of “wine connoisseur” descriptors must enter in to be able to discuss those differences, however. Words like smoother, buttery smooth, snappier, more open, richer, more full, etc., become part of the vocabulary, as there is little or no other method of describing differences which are there, but not always immediately apparent, especially without having the prints side by side to compare. I reasoned that if the print at 44” looked really great, (actually spectacular), AND, a 6000 patch profile target was used to print it, why then would there NOT be a difference, meaning “if it looks, smells, walks, talks and tastes like a duck,” as the old saying goes, “then maybe it is a duck.”
Once one becomes attuned to looking for differences, and begins to become aware of what to look for in the subtle nuances of print variations done under controlled printing methods (printing the very same file but with 2 different profiles, easily accomplished with the Z (under job queue > change loaded paper, reprint), then I believe we are looking at an improvement. Talk to audiophilles, and you will hear the same kind of rhetoric - the waxing lyrical, attempting to discuss sound quality nuances of more expensive equipment.
Thus we have entered into the realm of the law of diminishing returns. It may be easy to achieve 85% of any given endeavor on a scale of “perfection”, yet with every percent greater acheivement, the proportionally greater requirements of resource required to attain improvements, until finally, the law of diminishing returns has its way until eventually a paradigm shift renders the point moot. I know this to be true in metal machining and in robotics. Getting 85% to the goal is likely doable, but beyond that, it becomes like pulling teeth to make significant advances.
Perception of quality is of a subjective nature and becomes about taste and ushers in the potential for snobbery. But, apparently, it is the way the world works. Connoisseurship is very real, and among so called connoisseurs, these subtle nuances define the variations in “quality”. I agree, to some extent, being one who chases the rabbit down the rabbit hole and through the warrens, in many differentt areas.
Yet this I have come to understand: Perfection is the enemy of excellence. Obsession the teaser of sanity. To each his/her own. Do what floats your boat, follow your bliss. Or be practical, or frugal, or sane, whatever is the opposite. Make prints your own ways, according to your own choices. It’s not that making a 6000 patch target ICC profile doesn’t come at considerable cost....
And... understanding and communicating those differences as well....
Best,
Mark
-
Hello everyone,
I'm returning to this thread after a couple of days where I had to attend to other things. Here's my latest thinking on using the Z3200 spectro with big targets and to a more general quest of building more accurate profiles.
1). I did try Brad's suggestion of modifying the header in the 4357 patch file, and although Brad successfully printed and measured on his Z, I still had the same bug (symptom being the HP utility thought it printed successfully, but in fact the printed patch count fell short). This remains and unresolved issue for me and may well be related to the fact that I'm on High Sierra with latest HP color utility version (who knows?).
2). Doug's discussion of rounding issues with the i1Profiler data sets is duly noted. Here's my take on it. If you go into PS and use the info tool (it rounds to whole integers when showing both RGB values and LAB values, one can try moving different triplets up or down just one unit of RGB in one channel, say for example raising G from 50 to 51 while holding R and B at 50. Try enough examples and we can see a* and b* values going up or down by 1 unit in many instances, hence 1dE or less depending on the chosen RGB triplet. For moderate chroma to vivid color chroma values, this is indeed probably nothing to worry about and will be mitigated by the profiling engine algorithms, but when it comes to neutrals and near neutrals, say two gray patches sitting side by side in the viewer's field of vision where one patch drifted one up in a* or b* while another drifted down in a* or b*, the errors could become just noticeable to the discerning viewer. Hence, it's worth looking at the rounding issue a little more closely as we try to create better, ie., smoother and more accurate gray ramps on full color printers.
3). This may seem counterintuitive, but Xrite's decision to truncate (i.e. round down) rather than round to nearest whole value has some merit, or at the very least is probably no worse than round to nearest whole value. Consider a chart text file that has one patch with one RGB channel equal to 15.51 and another at 16.49. Round down will cause the printer to print two patches, one with 15 as output value and the other with 16 as the "no color adjust" input values. Round to nearest whole integer will create and 8bit tiff untagged image with 16 and 16 respectively for those two patches. As long as the profiling engine is respecting those RGB text file value differences when using the corresponding spectro measurements to build the profile, I think the outcome is similar, perhaps even better with round down because round down will attempt to preserve differences in the RGB triplet values consistently whereas round to nearest value will cause some RGB triplet pairs to take on bigger differences while others take on smaller differences.
4). All that said, given that fact that i1Profiler generates 8bit tif target images to be printed and measured and HP color Utility does the same, it is certainly easy to avoid the uncertainty of the rounding issues through the printer output and target measuring pipeline, simply by following Doug's suggestion to clean up the patch chart test file, so that the printer is getting fixed integers with no rounding errors when printing the target in a "no color adjust" printer pipeline, and the profiling engine is also getting those corresponding integers when trying to "smooth" and build the resulting ICC profile.
I'm going to take a breather for now from trying to solve the printer bug issue in the HP Utility, and will now try a "straight print" approach by exporting an 8bit patch target tiff image and letting Apple ColorSync Utility "print as target" with 100% magnification. It's imperative for the Z3200's measurement step that the patches are printed at 100% magnification, otherwise the measuring step is bound to fail. There's also a trick to getting CSU to print 100% precisely, but I will cover that step later when Mark L. and I eventually have a chance to put together a tutorial on how to print these big patch count targets reliably on the Z3200, and what the ramifications are for better profile quality (if any) as patch counts get higher and also include more gray/near gray patches than the venerable 1728 (12x12x12 grid) classic target.
cheers,
Mark
http://www.aardenburg-imaging.com
-
Hello all,
I experienced a strange little bug when saving the 4357 patch file out of i1Profiler. When I opened the file to inspect it the Number Of Sets said 4357 but the actual saved sets only went to 2000 something or other (I deleted it without noting the actual number). I saved it again and it was correct this time around. I have not been able to repeat this and perhaps it was something I did wrong but I have no idea what that could have been. Thought I'd throw this out there, just in case this is what is happening to you too.
Thanks one more time for sharing all of this, I'm learning a lot and making better prints because of it.
Mike
-
Hello all,
I experienced a strange little bug when saving the 4357 patch file out of i1Profiler. When I opened the file to inspect it the Number Of Sets said 4357 but the actual saved sets only went to 2000 something or other (I deleted it without noting the actual number)....
Mike
Mike, that would have been a good and "why didn't I think of that!" reason for the printing bug I've been experiencing, but I checked my 4357 chart files, including the one that had Brad's suggested header modification, and all have complete data sets.
Onward and thanks,
Mark
http://www.aardenburg-imaging.com
-
Regarding i1Profiler data truncation: The last time I thoroughly vetted the consequences of using fractional data in i1Profiler was with version 1.63 (late 2015 vintage). I dug through my Excel archives and here were the conclusions.
I ran several cases: - The default i1P 8-bit target image with RGB values rounded to the nearest integer paired with the 16-bit reference. This is the default i1Profiler configuration.
- Default 8-bit i1P target image with reference file truncated to 8-bits (i.e. values truncated down to the nearest integer).
- Default 8-bit i1P target image with reference file rounded to the nearest integer.
- 16 bit target image, 8-bit reference file rounded to the nearest integer value.
- 16 bit target image, reference file truncated to 8-bits.
- A true 16 bit target image having the fractional values in the measurement reference file (target image 16-bit, reference file 16-bit).
- A version with both image and reference truncated to 8 bits.
Options #1, #2, and #3 all made similar but not quite identical profiles, although the differences barely exceeded the measurement tolerances of an iSis. The target images were the same for all three tests. If i1Profiler truncates or rounds 16-bit reference values prior to the profile calculations the profiles should differ. The differences were statistically significant at only a 90% confidence level; these results don't definitively prove i1Profiler makes use of 16-bit reference data. A simple statement by X-Rite would be greatly appreciated.
Options #4 and #5 produced profiles that were statistically different at a 95% confidence level both from each other and from the previous three tests. Having different target image values ended up producing a larger effect than fractional differences in reference files.
Finally, options 6 and 7 - where the target image and reference files should be matched exactly - gave profiles with outputs with no statistically significant differences. This again hints that i1P makes use of 16-bit reference values.
We went on to quantify the profile accuracy by printing a target through each profile and measuring the resulting colors vs. predicted values. The winner was the final option above, with matched 8-bit target image and reference file. Average dE2000 was 0.68 on a Fuji Frontier contone printer and 0.91 on an Epson inkjet. The other options gave Fuji errors in the 0.95 - 1.32 range and Epson errors of 1.18 - 1.67 dE2000.
The larger question is whether these mathematical gyrations made and perceptible difference in the final print. For the most part the answer was no on both printers. The exception was in B&W images where the clear winner again, particularly on the inkjet, was the profile made with matched 8-bit target and reference. Highlight transitions had visibly fewer crossovers and smoother transitions. The matched 16-bit image/reference profiles made prints that some of us thought looked better than from options 1-5 while the rest couldn't see any difference.
-
I ran several cases: - The default i1P 8-bit target image with RGB values rounded to the nearest integer paired with the 16-bit reference. This is the default i1Profiler configuration.
- Default 8-bit i1P target image with reference file truncated to 8-bits (i.e. values truncated down to the nearest integer).
- Default 8-bit i1P target image with reference file rounded to the nearest integer.
- 16 bit target image, 8-bit reference file rounded to the nearest integer value.
- 16 bit target image, reference file truncated to 8-bits.
- A true 16 bit target image having the fractional values in the measurement reference file (target image 16-bit, reference file 16-bit).
- A version with both image and reference truncated to 8 bits.
Ethan, it's good to know that item 7 was the winner because I don't see any way using i1Profller to do what you did in item 6, i.e., save out the target image as 16-bit. It seems to want to generate 8-bit only. Am I missing a preference setting somewhere in i1P, or did you use another piece of software to generate a 16-bit target image from the 16-bit reference file?
cheers,
mark
http://www.aardenburg-imaging.com
-
Ethan, it's good to know that item 7 was the winner because I don't see any way using i1Profller to do what you did in item 6, i.e., save out the target image as 16-bit. It seems to want to generate 8-bit only. Am I missing a preference setting somewhere in i1P, or did you use another piece of software to generate a 16-bit target image from the 16-bit reference file?
You're right - i1Profiler won't make 16 bit images. I created the 16-bit images manually using ImageMagick scripts.
-
Regarding i1Profiler data truncation: The last time I thoroughly vetted the consequences of using fractional data in i1Profiler was with version 1.63 (late 2015 vintage). I dug through my Excel archives and here were the conclusions.
I ran several cases: - The default i1P 8-bit target image with RGB values rounded to the nearest integer paired with the 16-bit reference. This is the default i1Profiler configuration.
- Default 8-bit i1P target image with reference file truncated to 8-bits (i.e. values truncated down to the nearest integer).
- Default 8-bit i1P target image with reference file rounded to the nearest integer.
- 16 bit target image, 8-bit reference file rounded to the nearest integer value.
- 16 bit target image, reference file truncated to 8-bits.
- A true 16 bit target image having the fractional values in the measurement reference file (target image 16-bit, reference file 16-bit).
- A version with both image and reference truncated to 8 bits.
Options #1, #2, and #3 all made similar but not quite identical profiles, although the differences barely exceeded the measurement tolerances of an iSis. The target images were the same for all three tests. If i1Profiler truncates or rounds 16-bit reference values prior to the profile calculations the profiles should differ. The differences were statistically significant at only a 90% confidence level; these results don't definitively prove i1Profiler makes use of 16-bit reference data. A simple statement by X-Rite would be greatly appreciated.
Options #4 and #5 produced profiles that were statistically different at a 95% confidence level both from each other and from the previous three tests. Having different target image values ended up producing a larger effect than fractional differences in reference files.
Finally, options 6 and 7 - where the target image and reference files should be matched exactly - gave profiles with outputs with no statistically significant differences. This again hints that i1P makes use of 16-bit reference values.
I can confirm that I1P uses fractional RGB values when generating a profile. A side effect is being able to create an 8 bit RGB file with truncated fractionals.
Here's the process:
- Generate a patch set with I1P using "Smart Patch Generator"
- Print the chart and make a profile using the normal process. The printed chart will have rounded RGB values but the profile will be made with the 16 bit RGB values.
- Now, drag the newly generated profile into the I1P "Measurement" tab. It will populate the RGB and spectral data that was saved in the profile. This data doesn't round but truncates the RGB values to 8 bits.
- Make a new profile. The new profile will be made from the truncated RGB data. I then made a histogram of the dE00 of 10M random RGB values in device space converted to LAB for both profiles through the AtoB1 tables. Ave. dE00 was .15, with 99% falling below .3. Attached is the histogram.
One can then click on "Patch Set" and save the 8 bit values. Then any profiles made with that saved patch set will produce matching tif and/or print files and I1P will use the proper RGB values.
We went on to quantify the profile accuracy by printing a target through each profile and measuring the resulting colors vs. predicted values. The winner was the final option above, with matched 8-bit target image and reference file. Average dE2000 was 0.68 on a Fuji Frontier contone printer and 0.91 on an Epson inkjet. The other options gave Fuji errors in the 0.95 - 1.32 range and Epson errors of 1.18 - 1.67 dE2000.
The larger question is whether these mathematical gyrations made and perceptible difference in the final print. For the most part the answer was no on both printers. The exception was in B&W images where the clear winner again, particularly on the inkjet, was the profile made with matched 8-bit target and reference. Highlight transitions had visibly fewer crossovers and smoother transitions. The matched 16-bit image/reference profiles made prints that some of us thought looked better than from options 1-5 while the rest couldn't see any difference.
I concur. Your observations are in complete accord with what I've seen though I've been able to achieve ave dE00s of better than .6 on my 9800 with patch sets of 2553 and higher. Much of the improvement comes from redundant patches for colors that show significant change when printed in different locations on the paper.
ADDED: Turns out it's even easier to get rid of fractional values from the Smart Patch Generator. Just save the patch set. Then reload the same patch set. Voila! the fractional values are gone!
-
You're right - i1Profiler won't make 16 bit images. I created the 16-bit images manually using ImageMagick scripts.
I wrote a Matlab function to create 16 bit Isis target files. It also refines the black "diamond" registration marks which are rather crude being composed of .25mm squares and can be selected for either 600DPI or 720DPI to conform with the printer's native resolution. It also prints a time stamped title with relevant info which makes it easier for me to keep track of stuff.
-
ADDED: Turns out it's even easier to get rid of fractional values from the Smart Patch Generator. Just save the patch set. Then reload the same patch set. Voila! the fractional values are gone!
Cool trick! Who woulda thunk it? But it seems to work :)
best,
Mark
http://www.aardenburg-imaging.com
-
Is Babel Color's Patchtool offering solutions for making the Color Center <> Profile Creators linking easier?
I bought it for other purposes but did not use it enough so far.
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
March 2017 update, 750+ inkjet media white spectral plots
-
Is Babel Color's Patchtool offering solutions for making the Color Center <> Profile Creators linking easier?
Interesting question. If it does generate reliably uploadable/printable CGATS text files (and maybe smoothed RGB triplet data), I’d spent the USD 125 to buy it in a heartbeat. I just downloaded a demo version, but the demo version doesn’t export CGATS text files, so hopefully others can test it. But since everyone has had reliability issues uploading the differently formatted CGATS text files so far, I’m a hopeful skeptic.
I did the unthinkable and read the Z’s manual. It cryptically states that it is compatible with CGATS and MonacoPROFILER inputs. The latter was acquired by X-Rite some time ago and discontinued, but people with that may have some success.
-
Interesting question. If it does generate reliably uploadable/printable CGATS text files (and maybe smoothed RGB triplet data), I’d spent the USD 125 to buy it in a heartbeat. I just downloaded a demo version, but the demo version doesn’t export CGATS text files, so hopefully others can test it. But since everyone has had reliability issues uploading the differently formatted CGATS text files so far, I’m a hopeful skeptic.
I did the unthinkable and read the Z’s manual. It cryptically states that it is compatible with CGATS and MonacoPROFILER inputs. The latter was acquired by X-Rite some time ago and discontinued, but people with that may have some success.
AFAIK MonacoProfiler needs older versions of Windows to run. Doable with W7 and XP emulated there but it is getting complicated that way. Beyond W7 that solution is lost. So similar to Kodak Colorflow for profile editing.
Edit: Danny Pascale of Babelcolor has been approachable for questions in the past and used to write on the Colorsync list. We could ask him whether there is a compatible export choice in Patchcolor.
Meanwhile;
http://www.babelcolor.com/patchtool_specifications.htm
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
March 2017 update, 750+ inkjet media white spectral plots
-
Actually, I think MHMG and I are getting close. Understanding that the issue with the file being rejected by the ESP is due to formatting issues in delimited text files which Excel modifies automatically is partly in large part, the problem. The i1 profile ESP in the Z3200ps printer reqires a specific format for the data and just balks at anything not conforming. Having come to an understanding regarding rounding/truncating files to be certain of 8 bit accuracy, potentially, with certain formulas applied and importing the files corectly in Excell, specific mixes of special files can be successfully exported that the Z will, in theory accept. MHMG is working on a few today, but so far there is no “single magic bullet”. Our approach at this point is to begin creating special CGATS custom files, test for certain they work flawlessly, then ultimately publish them on Z3200.com for all to access. I’m hesitant to introduce Monaco/Gretag archaic tech into the present mix, as it is known that i1 profile is the specific tech that the Z3200ps currently plays nice with, as verified by MHMG. After a think-tank session last night, three of us MHMG/ML/Mrs. ML)) came to certain conclusions that should lead to success. Not saying exactly what, yet, to prevent further muddying of the waters.
So now, altough pressing on full steam ahead, we’re slowing down to concentrate on this specific issue of proper formatting and MHMG will be working on adding more neutral and low frequency chroma near-neutral ramps for smoothing. It is our conclusion that offering the optimized files is in the end a far more practical solution than offering a convoluted process that most will not attempt to use, although that info will also be made available. Just an update on what our (MHMG/ML) direction currently is.
Best -
Mark L
-
Mark et. al:
Got to hand it to you guys for persistance in potentially cracking this nut. But is a 4000 patch file profile significantliy better? Just asking. It might be worthwhile buying the Z3200 just for the automated feature of generating huge patch profiles. ;-)
John Nollendorfs
-
Mark et. al:
Got to hand it to you guys for persistance in potentially cracking this nut. But is a 4000 patch file profile significantliy better? Just asking. It might be worthwhile buying the Z3200 just for the automated feature of generating huge patch profiles. ;-)
John Nollendorfs
Remains to be seen John. That's something that MHMG will be able to address and it's on the program.
As far as worth the price of the Embedded Spectrophotometer being worth it, I figured something out last night that is really interesting.
Looking down the road - I hope WAAAAAY down the road, let's say HP discontinues the Z3200ps (hopefully to be replaced by something better). And there's no ink.
Printer becomes door stop, yacht anchor, etc., right?
NOPE!
Actually, as long as the belt and Spectrophotometer are still good, even at the point that the printer can't print, it can still be used as a stand alone Automated Spectrophotometer.
It can generate a TIFF file to be used to print a color target print on another printer, then it can read scan and measure the chart automagically then create a .TXT file for use to be able to convert to ICC profile. It should also be able to install the profiles right in your library automagically.
So all will not be lost even at the end. Potentially lots of use out of this wonder.
So it is worthwhile, I believe.
Best -
Mark
-
Is Babel Color's Patchtool offering solutions for making the Color Center <> Profile Creators linking easier?
I bought it for other purposes but did not use it enough so far.
Met vriendelijke groet, Ernst
http://www.pigment-print.com/spectralplots/spectrumviz_1.htm
March 2017 update, 750+ inkjet media white spectral plots
On it Ernst. Thank you.
Mark
-
I've used patchtool to average CGATs spectral files and they load into I1Profiler. Can't say about uses for the Z3200 tools. One thing you have to do AFTER averaging is to replace the RGB data with the original as patchtool will replace the RGB with sRGB. There is a separate menu option to for that. One of the nice things about the average CGATS option is that you can select outlier threshold to ignore values exceeding a deviation you specify. That requires at least 3 scan files of course.
-
The printing bug on Mac version of HP's color utility for the Z3200 persists, but the effective work-around is to export the HP color target as a tiff file and "print as color target" with Apple ColorSync utility (ACSU) at 100% magnification. I created a 4357 patch target with i1Profiler, then using Doug Gray's observation on how to strip fractional decimal points by reopening and re-saving the reference file in i1Profiler, I then imported that chart file into the HP color utility, and lastly, I then exported a tiff file from HP's color utility based on that reference file.
I then printed this tiff file on my Z3200 using a 44 inch wide roll of Moab Entrada Natural. The baseline media setting was "Fine Art paper (more ink)" Note that this setting invokes a rather unique HP Z series "quad tone" gray ramp which exploits both matte black and photo black inks in the printed output. The final print was 34 x44 inches, and I successfully measured the 4357 patches twice in a row, the first measurement taking place about an hour after printing, the second measurement at approximately 24 hours after printing. I then dropped back to PM5 measure tool, to compare and average those two files. Average dE error was .62 with largest single patch error of dE=2.12 (some of this error may be attributed to dry down effects). I consider the repeatability of the measurements over 4357 patches to be quite good.
The averaged measurement file was then imported into i1Profiler. I set I1 profiler settings on large LUT size, 16 bit, with default contrast and saturation sliders, and "neutralize gray" slide set to 100. Also, I boosted the "smoothing" slider to 75. After the profile was made, I next printed the Aardenburg 60 patch QC target using perceptual rendering, and measured the result (see attached graphs). The tone curve shows that i1Profiler's default contrast setting adds a subtle S-shaved curve to increase midtone contrast back to gamma=1, which indeed differs from relcol/wBPC in a desirable way. The grayscale neutrality plot is extraordinary! It is the smoothest grayscale neutrality graph I have ever seen printed on an inkjet printer. It matches the very gentlest and smoothest grayscale neutrality curves I have previously measured on traditional silver gelatin print processes.
Mark L. and I will soon write up a tutorial that covers the steps involved and make it available at Z3200.com, but suffice to say, the HPZ3200's automatic scanning spectrophotometer enabled us to reach new heights in profile quality, that we probably would not have attempted otherwise :)
cheers,
Mark
http://www.aardenburg-imaging.com