Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: datro on August 08, 2017, 11:42:30 pm
-
In the past, I've had no problems printing my profile targets with i1Profiler....been doing it for years. A while back I updated to 1.7.1 but today was the first time I've needed to do some new profiles. When I hit the "Print" button in i1Profiler to print my 4-page target, nothing happens. No error popup, nada. Normally, I should see the Windows print dialogue so I can choose the printer and set the driver preferences. I'm running Windows 10 (1607) 64-bit. I have sent a request in to x-rite, but who knows how long that will take.
Has anyone else seen this problem?
Thanks,
Dave
-
It's OK on a Mac.
-
Likewise, works on OSX 10.11x.
BTW, X-Rite support will respond, usually within a day or two.
-
BTW, X-Rite support will respond, usually within a day or two.
Jeff, Mark, thanks for the verification of status on the Mac.
Well, I have good news and bad news. The good news is that x-rite responded almost immediately to my query (< 24 hours). The bad news is that x-rite has verified this problem as a known "software bug" that will be fixed in the next release. They provide a couple of workarounds. Here's what they sent to me:
*** Start of x-rite response ***
Comment: The RGB Printer profiling “Print” button does not work in the Test Chart workflow step. This has been verified and logged as a software bug to fix in the next update of i1Profiler. In the meantime, you have a few options:
1. Some users have reported that if they uninstall one of their printers (preferably one that you no longer use) and then reboot the PC, the “Print” button worked.
2. You can save the test chart out as a TIFF and then print it with all color management turned off.
3. You can uninstall i1Profiler 1.7.1 and X-Rite Device Services Manager in Control Panel > Programs & Features, reboot the PC, and then reinstall i1Profiler 1.6.7 using the following link: http://www.xritephoto.com/ph_product_overview.aspx?ID=1397&Action=Support&SoftwareID=1672
*** End of x-rite response ***
I will try option 1 first, then if that doesn't work I'll go directly to option 3. Seems amazing to me that such a problem with a key feature of the software could somehow escape being caught in the QA process before release of the latest version.
Dave
-
Actually, it's not amazing, unfortunately. I'm anxiously awaiting the next release as well, hoping a couple of other bugs get fixed.
If it were me, I would probably go for option (2), making sure to use the Adobe Color Print Utility (ACPU, free download from the Adobe website) for printing the targets. I have found from several tests that this is a highly reliable way to print profiling targets that aren't colour-managed.
-
I have a W10 system with the latest version of i1Profiler and had not run into the problem because I exclusively use ACPU, with no issues. I tried printing from i1Profiler, and indeed the bug is present.
Richard Southworth
-
Actually, it's not amazing, unfortunately. I'm anxiously awaiting the next release as well, hoping a couple of other bugs get fixed.
If it were me, I would probably go for option (2), making sure to use the Adobe Color Print Utility (ACPU, free download from the Adobe website) for printing the targets. I have found from several tests that this is a highly reliable way to print profiling targets that aren't colour-managed.
I tested printing targets from i1Profiler on three Windows boxes in the office. It worked on one machine and failed on the other two. Be careful using ACPU on Windows. It scales targets down to a greater extent than on a Mac. Depending on the target layout and the instrument you use, this may reduce measurement accuracy or even prevent i1Profiler from being able to recognize the target. You can compensate by increasing the size of the target by 4% in Photoshop using nearest neighbor interpolation.
As an alternative we have a simple utility (https://www.drycreekphoto.com/tools/ChartPrinter/) for Windows users that bypasses Adobe's color management path.
-
Ethan,
I've had no issues with the slightly smaller target using ACPU and Windows 10 - I manually scan the patches using an i1Pro. Can you be more specific as to the conditions where the shrinkage might cause a problem?
Richard Southworth
-
After saving the profiling targets out of i1Profiler as an untagged TIFF image, I print these targets from ACPU using Mac OSX 11.x, and there is no size reduction of the patches. The patches are supposed to be 8mm square, they are exactly that (I measured some), and the spectro reading process works as intended.
-
The ACPU Windows problem is well known and Adobe seems not to care. I profile using ArgyllCMS and even though the patch size is 4% smaller, I have no problems reading them with an i1 spectrometer.
-
Can you be more specific as to the conditions where the shrinkage might cause a problem?
The main problem occurs when using an autospectrophotometer that needs specific sizing data of the chart that's being read*. Hand held measurements shouldn't really be effected unless you're trying to use the smallest patch size possible when you might start getting read errors from under sized patches.
* It is possible to hack a reference file to accommodate for the resizing, but it's not a simple task.
-
After saving the profiling targets out of i1Profiler as an untagged TIFF image, I print these targets from ACPU using Mac OSX 11.x, and there is no size reduction of the patches. The patches are supposed to be 8mm square, they are exactly that (I measured some), and the spectro reading process works as intended.
Indeed it is. However, depending on the Spectrophotometer and the degree of shrinkage, it may be moot. I have seen no such issues with Window customers when I use my custom targets from i1P on an iSis XL which can be picky about size. The issue appears to disappear by NOT using the default or minimum target size parameters when creating a target. Not enough 'fudge factor' in size I suppose. I'd suggest having this check box OFF and upping the various values a tad.
-
Welcome back Andrew!
-
Welcome back Andrew!
;D
-
Andrew,
Interesting suggestion regarding not taking the default patch sizing and make it larger before printing with ACPU. I will try that before going to the trouble of uninstalling i1Profiler and back-dating to a previous version (BTW x-rite seemed to push NOT to take that option in some further communication I had with them).
Just a note for anyone looking at the actual numbers in Andrew's screen shot: Don't just take those numbers and plug them in to your setup. His numbers (and I believe the "Header Length" option which I don't have on my setup) are specific to the device he is using, i.e. the iSisXL. For users with an i1Pro2 (my situation) the default patch size is 8mm x 8mm (or .315 in x .315 in). Andrew's "expanded size" patches are actually smaller than that, but I believe that is because he is using a different measurement device.
FWIW,
Dave
-
Andrew,
Interesting suggestion regarding not taking the default patch sizing and make it larger before printing with ACPU. I will try that before going to the trouble of uninstalling i1Profiler and back-dating to a previous version (BTW x-rite seemed to push NOT to take that option in some further communication I had with them).
Just a note for anyone looking at the actual numbers in Andrew's screen shot: Don't just take those numbers and plug them in to your setup. His numbers (and I believe the "Header Length" option which I don't have on my setup) are specific to the device he is using, i.e. the iSisXL. For users with an i1Pro2 (my situation) the default patch size is 8mm x 8mm (or .315 in x .315 in). Andrew's "expanded size" patches are actually smaller than that, but I believe that is because he is using a different measurement device.
FWIW,
Dave
I'm interested in following this as I broke down and ordered an ISIS 2 XL which should arrive in a few days. My usual approach is to just save the tif file and print with Photoshop using the null transform technique and I'm curious to see how that works with the ISIS compared to just printing directly. I prefer going through Photoshop since that lets me easily place identifying text on the target which helps with organization. Also, my windows machine doesn't maintain dimensions which makes ACPU marginal.
I hope it solves the issue I'm having with some matte papers with the I1Pro 2.
-
Welcome back Andrew!
I,too,am glad to see Andrew Rodney again on the Forum.
Regards,
Dale
-
I've been using ACPU several years for targets from my Epson 3880, and recently for my Canon Pro-100. All profiles have been created with no issues, using both an normal I1 Pro and an UV Cut i1 Pro, all on a Windows 10 system running i1Profiler. As I remember, we went to ACPU when Photoshop deleted the "No Color Management" command from the Print dialog.
So here's the question - can somebody tell me why the combination of Photoshop CC set to "Printer Manages Colors" and the print driver set to color management off, is not an appropriate method for target printing, specifically for a W10 system?
Richard Southworth
-
Hi Richard,
This whole business is about as transparent as a mud-bath. I've been trying for a long time to get to the bottom of it but, requests for clarification have been met with silence. Anyhow, as much as I could piece together, and may not be totally correct, are two factors: (1) there is colour management happening embedded in the operating systems which turning off colour management in the printer driver does not touch, and (2) ACPU doesn't turn anything off - it is a work around.
-
I found a stock of 4x6 Epson premium gloss, that I would like to use for snapshot printing on my Pro-100. The generic Canon "other glossy" profile doesn't work very well, so I decided to crank out my own. I have 8.5x11 Epson premium gloss, so I printed a two page i1Profiler auto generated target, untagged image in Photoshop, "Printer manages colors" in Photoshop, and an appropriate media choice in the Canon print driver with color management turned off.
The targets look ok, and they are the correct size, no shrinkage. I'll let them dry, and will report back as to the profile performance.
Richard Southworth
-
I found a stock of 4x6 Epson premium gloss, that I would like to use for snapshot printing on my Pro-100. The generic Canon "other glossy" profile doesn't work very well, so I decided to crank out my own. I have 8.5x11 Epson premium gloss, so I printed a two page i1Profiler auto generated target, untagged image in Photoshop, "Printer manages colors" in Photoshop, and an appropriate media choice in the Canon print driver with color management turned off.
The targets look ok, and they are the correct size, no shrinkage. I'll let them dry, and will report back as to the profile performance.
Richard Southworth
Anytime you make a target for profile generation and don't use ether the ACPU or direct printing from the profiling software, you should check the process by testing the quality of the print profiles. An easy check is a set of patches from Bruce Lindbloom that are in multiples of 10 over L*, a* and b*. Print them out using Abs. Col Intent and measure them. For the ones in gamut, they should be quite close and nearly always less than 2 dE in error.
http://www.brucelindbloom.com/ProfileEvaluation.html
-
Anytime you make a target for profile generation and don't use ether the ACPU or direct printing from the profiling software, you should check the process by testing the quality of the print profiles. An easy check is a set of patches from Bruce Lindbloom that are in multiples of 10 over L*, a* and b*. Print them out using Abs. Col Intent and measure them. For the ones in gamut, they should be quite close and nearly always less than 2 dE in error.
http://www.brucelindbloom.com/ProfileEvaluation.html
No question that it's thorough, but because of that, for most purposes far too much work - that's 11 pages of printing, target scanning and measurement - yipes. Firstly, one should measure only colours that are in-gamut relative to the capabilities of the profile/paper/printer being evaluated. OOG colours screw-up the accuracy testing royally. Secondly, a much smaller sample set would tell one what needs to be known.
-
So here's the question - can somebody tell me why the combination of Photoshop CC set to "Printer Manages Colors" and the print driver set to color management off, is not an appropriate method for target printing, specifically for a W10 system?
Since Photoshop CS (?; can't recall exact version), you can't print without color management. Printer Manages Color isn't doing that and in fact, on Windows, everything you send out using that mode gets converted to sRGB! You need to use the process defined by the profile maker software, ACPU or some other application designed for this task to print the targets correctly. Or a very old copy of Photoshop that had either the No color management option in the Print dialog or a slightly newer one that allowed you to use the old "null profile" trick which Adobe later coded to stop working without posting a warning to download ACPU.
-
No question that it's thorough, but because of that, for most purposes far too much work - that's 11 pages of printing, target scanning and measurement - yipes. Firstly, one should measure only colours that are in-gamut relative to the capabilities of the profile/paper/printer being evaluated. OOG colours screw-up the accuracy testing royally. Secondly, a much smaller sample set would tell one what needs to be known.
Indeed. When I mentioned I use a "set of patches" it was not the complete set of images but a selection of in gamut patches from the Lab images. I have a collage of some from each of the L=10 through L=90 that Fit on a 4x6" as I've had exactly the same issue with small paper sizes that can't be realistically scanned directly and have to be spot measured and checked against a larger paper size profile. Before I made the collage I just printed the L30,50, and 70 images and checked them. The L=0 and 100 images should be ignored as they are just there for completeness.
The view proof out of gamut mask in Photoshop works well to locate suitable patches but they should be at least 20 units from a boundary because the mask only detects colors that are 6 dE or more beyond the gamut.
-
The view proof out of gamut mask in Photoshop works well to locate suitable patches but they should be at least 20 units from a boundary because the mask only detects colors that are 6 dE or more beyond the gamut.
The other thing one can do is use ColorThink Pro's Color Worksheet and 3D grapher functions to visually see ever colour that fits within a profile space by overlaying the patch data with the gamut of the paper/printer profile. I believe this should be a lot more precise than using Photoshop's gamut warning.
-
Since Photoshop CS (?; can't recall exact version),
CS4 was teh last version to be able to print without colour management.
That's one reason I've never upgraded since ..... and not regretted it at all.
Nice to see you back Andrew :-)
-
The other thing one can do is use ColorThink Pro's Color Worksheet and 3D grapher functions to visually see ever colour that fits within a profile space by overlaying the patch data with the gamut of the paper/printer profile. I believe this should be a lot more precise than using Photoshop's gamut warning.
I agree. Much better. However, I found that as long as you are 20 dE away from the gamut mask the colors are in the printable gamut. The advantage is there is no need to own any other software, just the measuring device.
However, that's what I did 10 years ago as a free, crude but effective quick check.
My preferred tools these days are Patchtool and, for detailed analysis, Matlab. For this purpose Patchtool has a built in patch generation for creating similar in-gamut Lab patches. It outputs both tif and CGATS with an excellent compare tool for checking the measured print results. It's also only about $100 or so. Patchtool is hard to beat for cost/value in print accuracy testing.
I've had Colorthink Pro for almost 10 years and it makes some beautiful plots/graphs but find it much too slow when working with a large image color set. Matlab runs a couple orders of magnitude faster and, being program oriented, makes it much easier to do custom "what-ifs." Most of the stuff I do/did was creating specialized test charts where Matlab can do what just isn't available with any other tools I've seen. But it's also very pricey w/o an academic subscription.
-
Let's forget profiling for the moment, and concentrate on Andrew's statement, i.e. PS modifies the rgb values to the printer driver even though "Printer Manages Color" is invoked. This is in direct opposition to the description statement in the print dialog box, screenshot attached. So has Photoshop seen the error of their ways and corrected this problem? How do we find out for sure? I couldn't come up with any reliable way to print to a file so I could measure the actual rgb values sent to the printer driver.
Richard Southworth
-
I agree. Much better. However, I found that as long as you are 20 dE away from the gamut mask the colors are in the printable gamut. The advantage is there is no need to own any other software, just the measuring device.
However, that's what I did 10 years ago as a free, crude but effective quick check.
My preferred tools these days are Patchtool and, for detailed analysis, Matlab. For this purpose Patchtool has a built in patch generation for creating similar in-gamut Lab patches. It outputs both tif and CGATS with an excellent compare tool for checking the measured print results. It's also only about $100 or so. Patchtool is hard to beat for cost/value in print accuracy testing.
I've had Colorthink Pro for almost 10 years and it makes some beautiful plots/graphs but find it much too slow when working with a large image color set. Matlab runs a couple orders of magnitude faster and, being program oriented, makes it much easier to do custom "what-ifs." Most of the stuff I do/did was creating specialized test charts where Matlab can do what just isn't available with any other tools I've seen. But it's also very pricey w/o an academic subscription.
Yes, Patchtool is a go-to application, and Danny's manual is an education. Matlab - good for those with a fairly deep math background, but from what I see on their website, not terribly expensive - a "home" license is USD 149.
-
Let's forget profiling for the moment, and concentrate on Andrew's statement, i.e. PS modifies the rgb values to the printer driver even though "Printer Manages Color" is invoked. This is in direct opposition to the description statement in the print dialog box, screenshot attached. So has Photoshop seen the error of their ways and corrected this problem? How do we find out for sure? I couldn't come up with any reliable way to print to a file so I could measure the actual rgb values sent to the printer driver.
Richard Southworth
I did some measurements using "Printer Manages Color" with Photoshop using a Canon 9500 II and Windows 10 x64. For the driver's default settings RGB colors were converted to sRGB. However, when using ICM in the printer driver they were not converted.
I did this experiment largely as a result of Ctien's blog comments that he preferred "Printer manages color" and was curious about the interplay with the notion that Photoshop always converts colors to sRGB in this mode. It turned out that it usually does, but not always.
As an aside, I print target charts in Photoshop using null transform. I get the warning with a link to ACPU which I ignore. It works fine on the most current Win Photoshop. However, because of the warning, I run a measurement check whenever they release an updated version. Also, I have no idea whether it works on Apples.
http://forum.luminous-landscape.com/index.php?topic=119132.msg990356#msg990356
-
Yes, Patchtool is a go-to application, and Danny's manual is an education. Matlab - good for those with a fairly deep math background, but from what I see on their website, not terribly expensive - a "home" license is USD 149.
Wow! I didn't realize they had released a home (non-commercial) version. I hadn't updated mine since 2015. It's a commercial license version I used in business - mostly EE stuff but some optical and specialized print related stuff. But I no longer use it for business. I'm retired now but I print (gratis) for some local artists and non-profits. So that's great news! I'm definitely going to update to that.
-
Ok, I'm now a believer, PS sucks for printing profile targets. I tried scanning the "Printer Manages Colors" targets, got to line 24 and no go, just too far removed from the reference. I printed again using ACPU, obviously different appearance. I'll never doubt the collective wisdom of this group again!
Richard Southworth
-
Let's forget profiling for the moment, and concentrate on Andrew's statement, i.e. PS modifies the rgb values to the printer driver even though "Printer Manages Color" is invoked. This is in direct opposition to the description statement in the print dialog box, screenshot attached. So has Photoshop seen the error of their ways and corrected this problem? How do we find out for sure? I couldn't come up with any reliable way to print to a file so I could measure the actual rgb values sent to the printer driver.
Richard Southworth
See Dave P's comments below the article about Printer Manages Color here:
http://theonlinephotographer.typepad.com/the_online_photographer/2015/07/andrew-rodney-on-the-importance-of-custom-printer-profiles.html (http://theonlinephotographer.typepad.com/the_online_photographer/2015/07/andrew-rodney-on-the-importance-of-custom-printer-profiles.html)
Again, the idea is to send the numbers, as is, through the driver which Photoshop since CS4 (thanks for remanding me) can't do without some modification of the data or without some color management.
-
See Dave P's comments below the article about Printer Manages Color here:
http://theonlinephotographer.typepad.com/the_online_photographer/2015/07/andrew-rodney-on-the-importance-of-custom-printer-profiles.html (http://theonlinephotographer.typepad.com/the_online_photographer/2015/07/andrew-rodney-on-the-importance-of-custom-printer-profiles.html)
Again, the idea is to send the numbers, as is, through the driver which Photoshop since CS4 (thanks for remanding me) can't do without some modification of the data or without some color management.
Dave P:
"Picking "Printer Manages Colors" on Windows guarantees that your color data will be converted to sRGB."
The graphs I showed in my "Down the Rabbit Hole" thread are compelling evidence that Dave is wrong. While the defaults do convert to sRGB, the ICM driver selection does not using Windows 10 and PS CC.
I can provide the green tiff patches and CGATS file if anyone wishes to try it out on their setup.
Also, I've been using the null transform to print targets in Photoshop pretty much forever. The warning an redirect to ACPU still pops up and I ignore it. It has always worked and continues to work. You don't even need a profile for the paper or printer you actually use. You can assign any RGB printer profile then print making sure you use exactly the same profile. The selections, Perceptual, Rel, Abs, Sat, and even BPC have zero affect on what gets printed since the image is already in printer space so ignore them or set them arbitrarily.
The key thing is to Assign the profile (any printer profile) , then print using Photoshop manages color using exactly the same profile. When you see the warning (which shows up in Windows) hit Cancel and print.
Andrew,
The videos you provide free of charge on your website are really superb. Good job and a great help to people trying to get a handle on color management. When people ask me where to learn the "how to" of CM I send them there.
-
The graphs I showed in my "Down the Rabbit Hole" thread are compelling evidence that Dave is wrong.
I can provide you his email (off list) if you want to go there; way, WAY above my pay grade. :D
-
If it's the Dave P I think it is, the likelihood of him being wrong about what the code does is VERY remote - unless there are new factors brought into the process between the time he said that and the time you tested it.
-
If it's the Dave P I think it is, the likelihood of him being wrong about what the code does is VERY remote - unless there are new factors brought into the process between the time he said that and the time you tested it.
It's indeed the same Dave P (of Adobe). He could be wrong, something new could have come up under Windows since that article he commented upon, which wasn't that long ago. But it's unlikely he's wrong about what happens in Print within Photoshop or any Adobe application. That's his baby there in terms of coding.
Dave Polaschek said:"This always happens. When using "Printer Manages Colors" on Windows, Windows ICM 2.0 assumes that any color data passed to it is in sRGB, so Photoshop converts the colors to sRGB (so users don't get wrong colors when printing). We can't know whether the user has picked ABW or not (the driver-specific print settings are a black box to us at this point), and we must provide sRGB to the OS in this case."
-
I can provide you his email (off list) if you want to go there; way, WAY above my pay grade. :D
I would much appreciate that Andrew. Since most of my career was in software/firmware design (remarkably similar to Norman Koran but without the photography talent) :) , I do know mistakes happen. And sometimes they are mine. But I've seen the best and smartest people make them was well. This is a pretty arcane area and I'd like to get to the bottom of it. Personally, the things I am most interested in is why I get absolutely great results using null transform and always have. But the thing about always converting to sRGB just can't be right unless I did something really brain dead. The Lab green patches increased in saturation up to around a*=70 and sRGB clips at 37. So something is really off.
-
I'm lost. If the patch is green wouldn't the a* increase to -70 and the clipping point you're referring to be a*-37?
-
I'm lost. If the patch is green wouldn't the a* increase to -70 and the clipping point you're referring to be a*-37?
The patches were created in increments of -5 *a in Lab. The image was then converted to ProPhoto, Adobe RGB , and sRGB. The sRGB cliped at a*=-37, Adobe RGB at about -65 or so. The printer itself ran out of gamut at around *a=70 or so.
The printed tiffs were measured and plotted in the linked post. The default printer driver settings did indeed convert (and clip) to sRGB as can be seen in the posted charts. They also boosted both the luminance and saturation over what sRGB is supposed to be with a clipped sRGB green printed around a*=-45 instead of *a=37 which is where sRGB clips. And that explains how some people rather like the printed images from sRGB space using "printer manages." Canon just boosted both the saturation and luminance. However, when ICM was selected in the printer driver the images in the larger colorspaces printed far above the sRGB clip point up to near where the printer gamut limits color.
-
This is a fascinating discussion (and I AM following it with interest, as I too like to understand how things really work), but as the OP I thought I'd interject some updated information about dealing with the well-known scaling problem with ACPU on Windows systems.
After some experimentation I've found that setting the patch size to 8.3 mm x 8.3 mm in i1Profiler before saving out the TIF files will result in patches that are exactly 8mm x 8mm (the default size when using the i1Pro2 device) when printed with ACPU on a Windows 10 system. So this is a nice easy work-around for the ACPU scaling problem on Windows. Of course I'd like to see Adobe fix the problem, but this works for now and allows me to get on with making profiles.
The only down side is that since you are specifying larger patches to i1Profiler, it may end up requiring an additional target page to be printed (depending on how many patches you are printing).
Dave
-
So this is a nice easy work-around for the ACPU scaling problem on Windows.
Sorry, but it's not a work round for all applications. The patches are still resized, which will give problems to some devices. You've just discovered that using a hand held device doesn't need as accurately printed targets as some autospectrometers.
-
Thanks Doug.
-
Sorry, but it's not a work round for all applications. The patches are still resized, which will give problems to some devices. You've just discovered that using a hand held device doesn't need as accurately printed targets as some autospectrometers.
Paul, perhaps his work-around solves HIS particular issue, and if it works for him, isn't that good (for him)?
Also, I wonder about your last sentence. I was under the impression that an i1Pro2 with i1Profiler for example (you weren't specific about which devices you have in mind) does expect a specific patch-size and patch array, otherwise it will pop an error notice on reading. One can specify different patch sizes in i1Profiler, but then the printed target should respect them because the hardware and software expect them. Is that not the case with this specific hand-held device?
-
Also, I wonder about your last sentence. I was under the impression that an i1Pro2 with i1Profiler for example (you weren't specific about which devices you have in mind) does expect a specific patch-size and patch array, otherwise it will pop an error notice on reading. One can specify different patch sizes in i1Profiler, but then the printed target should respect them because the hardware and software expect them. Is that not the case with this specific hand-held device?
A hand held device can't know what size patches are because it will depend on scanning speed. They just have to conform to a loose specification so that the scanning head can be aligned (manually) with the row being measured and is wide enough to allow enough measurements to be registered as the spectro is dragged across.
In the case of autospectrophotometers sizing is more important as the machine needs to know where patches are located on the page to read. Hence why some won't like resized charts.
-
A hand held device can't know what size patches are because it will depend on scanning speed. They just have to conform to a loose specification so that the scanning head can be aligned (manually) with the row being measured and is wide enough to allow enough measurements to be registered as the spectro is dragged across.
The software knows the expected patch size because the user tells it, and the software knows what the spectro should be reading along the row (relative to that patch size) because there is a position-tracking bar code on the scanning guide that a reader buried in the under-side of the spectro picks-up; so I am given to believe at least with an i1Pro2 and i1Profiler working together the accuracy of the patch size may be important to assure correct operability. It's of course a different system from the automated readers, but I'm not convinced at least in this case that it's lenient on patch-size accuracy.
-
there is a position-tracking bar code on the scanning guide that a reader buried in the under-side of the spectro picks-up;
I hadn't seen that before. From the looks of it the accuracy can't be huge though. The DTP70 need 0.1mm accuracy in target specification.
-
I hadn't seen that before. From the looks of it the accuracy can't be huge though. ............
Well, who knows for sure - kind of moot unless someone has actually tested the limits and has data.
-
Well, who knows for sure - kind of moot unless someone has actually tested the limits and has data.
It's possible that the stripes are only there to detect scanning speed, too slow or too fast, rather than relating to the position of patches.
-
It's possible that the stripes are only there to detect scanning speed, too slow or too fast, rather than relating to the position of patches.
I'm not sure - heck, X-Rite is dreadful at providing info even on basic functionality, let alone the inner workings; but I expect that the guidance system combined with the patch size is needed for the software to know which patch to expect as the unit moves across the target, so that when the colour is returned from the reading the software knows whether the match is correct. If it can't match well enough, it springs an error message. Anyhow, we're quite far off the O/P's original problem, so maybe best to leave this off-shoot at that; we're just hypothesizing. :-)
-
I expect that the guidance system combined with the patch size is needed for the software to know which patch to expect as the unit moves across the target,
That wasn't needed with the original i1Pro. We just get a 'can't read' error if it's read too fast or slow.
Maybe the new graticule just allows the software to refine it's too slow or fast error message to something a little more helpful ??
-
It's possible that the stripes are only there to detect scanning speed, too slow or too fast, rather than relating to the position of patches.
The zebra ruler is primarily to let it track patch locations of normal vs UV only scans. In the UV scan there isn't enough contrast between patches to auto-recognize.
-
The zebra ruler is primarily to let it track patch locations of normal vs UV only scans. In the UV scan there isn't enough contrast between patches to auto-recognize.
Graeme, wouldn't this then imply that the patch size printed on the target being scanned needs to be reasonably accurate so that the actual location will cohere with the program's expected location?
-
Graeme, wouldn't this then imply that the patch size printed on the target being scanned needs to be reasonably accurate so that the actual location will cohere with the program's expected location?
I don't think so no. The zebra ruler doesn't have to be used for normal (i.e. M0) scans, but does have to be used for M1 and M2 scans which both synthesize the illuminant from A and UV passes. So what I think happens is that the initial (normal) scan does the usual patch recognition based on the spacers or patch to patch contrast and the driver records the zebra stripe (i.e. physical distance) of the patch boundaries so determined, and then uses those distance records to parse up it's readings on the second UV only pass.
Of course it would be possible to combine auto-recognition with the distance awareness available from the zebra ruler to make it more resilient in the face of varying scanning speed, but I have no idea if the X-Rite driver has any capability of doing this. (My memory when I was looking at it, was that it didn't use the zebra ruler by default for M0).
-
The software knows the expected patch size because the user tells it, and the software knows what the spectro should be reading along the row (relative to that patch size) because there is a position-tracking bar code on the scanning guide that a reader buried in the under-side of the spectro picks-up; so I am given to believe at least with an i1Pro2 and i1Profiler working together the accuracy of the patch size may be important to assure correct operability. It's of course a different system from the automated readers, but I'm not convinced at least in this case that it's lenient on patch-size accuracy.
The zebra tracking stripes are spaced 2mm apart. The sensors in the I1Pro base use quadrature pickup (you can see the slight offset of the required two pickups under the I1Pro 2) which means two things. The tracking positional resolution is 0.5mm and the positional information is not dependent on speed or even direction chnages. I've done some tests where, rather than just swiping across a row, I go partway across, reverse over several patches, then resume to the end of the row. The patch color data was collected correctly.
However, this test was done with Patchtool which uses the X-rite dll driver. I have not repeated the test with I1Profiler.
-
Indeed it is. However, depending on the Spectrophotometer and the degree of shrinkage, it may be moot. I have seen no such issues with Window customers when I use my custom targets from i1P on an iSis XL which can be picky about size. The issue appears to disappear by NOT using the default or minimum target size parameters when creating a target. Not enough 'fudge factor' in size I suppose. I'd suggest having this check box OFF and upping the various values a tad.
Good suggestion. I just got my XL on Win 10 and have found exactly the same problem. I didn't notice it at first since I print targets with Photoshop using null transform but I wanted to run a crosscheck because the repeatability of the XL is really good and the XL wouldn't take my ACPU print due to it's shrinkage. There's a few workarounds such as resizing but I like the idea of changing the default patch sizes.
Really annoying to hit the I1Profiler print button and nothing happens. That's your pretty basic bug! Must have been a real PITA for you in working with your Win 10 clients.
-
I dug through our previous tests with the iSis and ACPU. We printed targets using patch sizes ranging from 5mm through the default minimum of 6mm and on up to 7mm. The targets were then measured repeatedly and dE comparisons made. We compared both between measurements and on measurements of a single page with repeated color values.
There was marginal increase in measurement variation increased steadily when actual (measured on paper) horizontal patch size dipped below 6.1 mm and vertical below 6.05mm until the patch size hit 5.8mm. Variability increased steadily until 5.65mm, and fell off a cliff from there. We also saw that if the page was inserted slightly off-angle that variability - particularly within page - increased by roughly the equivalent of shrinking patch size by 0.1mm.
For targets that may be printed using ACPU on windows we settled on a patch size of 6.6mm. Our internal self checks (based mainly on repeated patch colors at the top and bottom corners) sometimes still flag issues when reading pages that are inserted at an angle even though the iSis happily reads the chart. Aside from operator error, we haven't had any problems reading ACPU scaled targets with a 6.6mm patch size in the target image.
-
I dug through our previous tests with the iSis and ACPU. We printed targets using patch sizes ranging from 5mm through the default minimum of 6mm and on up to 7mm. The targets were then measured repeatedly and dE comparisons made. We compared both between measurements and on measurements of a single page with repeated color values.
There was marginal increase in measurement variation increased steadily when actual (measured on paper) horizontal patch size dipped below 6.1 mm and vertical below 6.05mm until the patch size hit 5.8mm. Variability increased steadily until 5.65mm, and fell off a cliff from there. We also saw that if the page was inserted slightly off-angle that variability - particularly within page - increased by roughly the equivalent of shrinking patch size by 0.1mm.
For targets that may be printed using ACPU on windows we settled on a patch size of 6.6mm. Our internal self checks (based mainly on repeated patch colors at the top and bottom corners) sometimes still flag issues when reading pages that are inserted at an angle even though the iSis happily reads the chart. Aside from operator error, we haven't had any problems reading ACPU scaled targets with a 6.6mm patch size in the target image.
Ethan,
Thanks for providing this information. Since receiving the Isis yesterday, I've had more limited data but it's consistent with yours. I also have one sheet that fed poorly and with some stress into the 9500. The result was significant distortion beyond an angular image shift. The image top printed at 10 3/16 (correct) width while the bottom printed at 10 3/32. The average dE on multiple passes was .10 except for 1 where it expanded to .25 with several patches over 2 dE. Looking at the spatial distribution, the largest errors were on the right hand edge.
The instrument looks to be highly repeatable providing reasonable alignment or slightly larger patch sizes. I'm actually impressed with how well it worked with my warped target.
Next, I really need to have a good quality crosscheck between ACPU and the Photoshop null transform. Ideally, the sizes should be exact with the image printed in exactly the same place to avoid positional inking variance. Now, with I1Profiler's print button broken, I can't do that. It's typically the major error source when I verify the null-transform v ACPU consistency.
-
Forgot to mention one rare gotcha. Sometimes when dealing with a mildly shrunken iSis print i1Profiler stubbornly refuses to recognize the target. I assume from watching the paper feed that i1Profiler simply does not read far enough down the page to pick up the positioning bar. An easy fix is to trim off ~1/8" (3mm for those residing in lands not covered by the dictates of King Ed the 2nd) from the top of the page and feed the iSis again.
-
In the past, I've had no problems printing my profile targets with i1Profiler....been doing it for years. A while back I updated to 1.7.1 but today was the first time I've needed to do some new profiles. When I hit the "Print" button in i1Profiler to print my 4-page target, nothing happens. No error popup, nada. Normally, I should see the Windows print dialogue so I can choose the printer and set the driver preferences. I'm running Windows 10 (1607) 64-bit. I have sent a request in to x-rite, but who knows how long that will take.
Has anyone else seen this problem?
Thanks,
Dave
Full uninstall, reboot, then reinstall the latest 7.1.1 version fixed the problem for me.
Well, I'm back to looking at this issue after pretty some rather interesting excursions into understanding the I1 ISIS 2 I picked up a few weeks ago. Great instrument for those of us that are impatient.
I had tried uninstalling a printer driver. No joy. Then I noticed at the XRite website that version 1.7.1 release was specifically to fix a problem where pressing the print button wouldn't print RGB targets. But my version was 1.7.1. However, I auto-updated it when I1Profiler notified me of the new version and after that was when I noticed the issue.
So I uninstalled I1Profiler. Rebooted. Then installed the current 1.7.1 download directly and rebooted again. The print button works! I don't often use the print button and prefer just using the null transform technique but I do depend on it for cross checking on Photoshop updates to make sure Adobe hasn't broken that trick. Well, other than the stupid warning that pops up when you do it which you just cancel and move on.
-corrected version number
-
Good to know. You mean version 1.7.1, not "7.1.1", right?
-
Good to know. You mean version 1.7.1, not "7.1.1", right?
:)
Yep. Thanks for the catch.
-
I know this thread is old, but in the absence of any updates from xRite on this issue (can't believe how long it takes them to fix really major problems >:( ), and also the need to make some more profiles, I thought I'd follow Doug's suggestion and try un-installing i1Profiler 1.7.1 and doing a complete re-install of 1.7.1. It works - the "Print" button now functions properly! Not sure why this un-install/re-install fixes it, but I wanted to confirm that it is worth doing if you are using 1.7.1 on Windows and want to print your profile targets directly from i1Profiler rather than use ACPU.
Dave