Z3200 - Better ICC Color Profiles

[digitaldog]

Thanks Andrew.  Cha-ching.

Send checks or money orders to.....    Glad it worked out. Curious if you end up seeing any differences with the newer 1728 target (the older may have been Bills?)

[Mark Lindquist]

Send checks or money orders to.....    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

[Doug Gray]

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.

[Mark Lindquist]

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

[Doug Gray]

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.

[Brad P]

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

[Doug Gray]

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.

[MHMG]

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

[MHMG]

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

[Doug Gray]

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.

[MHMG]

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.

[Brad P]

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.

[MHMG]

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

[Doug Gray]

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.

[Mark Lindquist]

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

[GrahamBy]

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.

[Mark Lindquist]

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

[Doug Gray]

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.

[Brad P]

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.

[Mark Lindquist]

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

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