i1Profiler issue: Not able to print target

[datro]

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

[Rhossydd]

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.

[Mark D Segal]

Thanks Doug.

[Mark D Segal]

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?

[Rhossydd]

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.

[Mark D Segal]

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.

[Rhossydd]

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.

[Mark D Segal]

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.

[Rhossydd]

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.

[Mark D Segal]

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. :-)

[Rhossydd]

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 ??

[GWGill]

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.

[Mark D Segal]

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?

[GWGill]

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).

[Doug Gray]

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.

[Doug Gray]

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.

[Ethan Hansen]

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.

[Doug Gray]

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.

[Ethan Hansen]

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.

[Doug Gray]

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