Constant pinging of i1iSis with i1Profiler

[Shane Webster]

Perhaps "constant pinging" isn't quite accurate, but I've noticed when i1P launches, it automatically initializes my i1iSis and then causes the measurement light to flash approximately every 3 seconds as long as the i1P app is open, regardless of what I'm doing within the app.  When using MT, it initializes the iSis but does not flash the light.  Is there some reason why i1P would constantly be flashing the iSis?  Will the flashing of the light shorten its life in such a way that the iSis should be disconnected when not in use and i1P is open?

[terrywyse]

It's actually XRite Device Services that is "pinging" the iSis. You could simply unplug the USB cable until you're actually ready to measure. Since the iSis uses LED lamps, I doubt that the flashing is causing any harm to the unit or shortening lamp life.

Terry

[Ethan_Hansen]

Constant toggling of the LED certainly is not going to increase the lamp lifetime. I both spoke with X-Rite's tech support and emailed them regarding this issue. They claimed that it had never been reported before, they hadn't seen it, and it must be my computer. When I replied that it happened on at least 7 different machines running four different operating systems and on both an iSis and iSis XL, well, "we have never heard of this before."

Call or email X-Rite: It is time they heard about this problem. I, for one, do not want to have to replace a dimmed LED sooner than necessary. I do not know what minimum luminance level the iSis requires. The lifetime of bright, white LED bulbs is inversely proportional to the bulb temperature. Depending on how well the iSis heat sink around the bulb performs - assuming there is a heat sink at all - the constant flashing may not be a significant problem. If it is enough to heat up the bulb, however, lifetime will suffer.

[Shane Webster]

I'll let X-Rite know, though based on what I've read and seen, they're not exactly zippy in releasing fixes to their products.  I always love the "it's your computer" explanation.  For what it's worth, I'm running a Mac with OS 10.6.6.  Don't know if it appears on the windows side or not.

[Ethan_Hansen]

I'll let X-Rite know, though based on what I've read and seen, they're not exactly zippy in releasing fixes to their products.  I always love the "it's your computer" explanation.  For what it's worth, I'm running a Mac with OS 10.6.6.  Don't know if it appears on the windows side or not.

We only tried a few versions of Windows: XP, Vista x64, Server 2008 R2, Win 7 x32, and Win 7 x64. Also OS/X 10.6.7. Not exactly an easily reproducible bug; it's easy to see how they missed it...

[digitaldog]

I believe this behavior is as intended (through X-Rite Services).

[Ethan_Hansen]

I believe this behavior is as intended (through X-Rite Services).

On Windows, at least, the iSis light only blinks while i1Profiler is running. The X-Rite Device Services Manager (xrdd.sys) is always running. While we were testing i1Profiler, we found that sticking a chart in the iSis prior to clicking the "Measure" button in i1Profiler sometimes caused the confusion. Nothing happened until the next attempt at reading a chart. Then, i1Profiler gave a device error instead of measuring the chart. Recovering took either exiting and relaunching i1Profiler or switching away from the Measure panel, reloading the chart definition, power cycling the iSis, and beginning measurements anew.

If this behavior is indeed intended, the intentions are at best insane - further slowing an already painful workflow is no help - or, at worst, an attempt to burn out iSis lamps sooner. I'll give X-Rite the benefit of the doubt and ascribe it to simple lack of debugging.

[digitaldog]

On the Mac, X-Rite services is also always running as a bkgnd process. If however you launch an X-Rite product (even MeasureTool), this starts the blinking. It may be to keep the LED ‘warmed up’, I don’t know. But again, I think its designed this way. Considering that an LED should last 25-50K hours (to what I hear is at least 70%), I’m not sure I’m super concerned about this behavior. I turn the unit off when I’m not measuring anything. I don’t know why anyone would not do otherwise. That’s what the on/off switch on the back is for. This from a guy who will very soon be generating his own electricity with a 3.5K photovoltaic tracker <g>.

Note, the newer behavior of how targets are ‘accepted’ in i1P isn’t something I like much. I prefer how MT operates whereby you click the Measure button, then insert the target.

[Ethan_Hansen]

No blinking on a PC when MeasureTool or ProfileMaker is launched. However, the PC version appears not to use the new and improved drivers. Chart reading remains slower, but more accurate and consistent.

i1Profiler reads a sheet at least 25% faster, but we saw all too frequent (4 times out of 322 measurements or 1.3%) instances where the data were corrupted by mixing of color values between adjacent patches. Our software has detected this a grand total of 3 times out of over 12628 measurements (0.02%) made using MeasureTool. And, to answer the next question, i1Profiler did not detect misalignment or measurement problems on any of the misread charts. Initially we thought that although i1Profiler offered us no advantage for building profiles, we could use its faster iSis measurement speed. Given the level of chart misreading, I am not sure about even that. We could only detect the problem because our charts include a number of repeated patches across the color field area. Starting with a standard, i1Profiler-generated target, you would never know there was a problem.

[eronald]

On Windows, at least, the iSis light only blinks while i1Profiler is running. The X-Rite Device Services Manager (xrdd.sys) is always running. While we were testing i1Profiler, we found that sticking a chart in the iSis prior to clicking the "Measure" button in i1Profiler sometimes caused the confusion. Nothing happened until the next attempt at reading a chart. Then, i1Profiler gave a device error instead of measuring the chart. Recovering took either exiting and relaunching i1Profiler or switching away from the Measure panel, reloading the chart definition, power cycling the iSis, and beginning measurements anew.

If this behavior is indeed intended, the intentions are at best insane - further slowing an already painful workflow is no help - or, at worst, an attempt to burn out iSis lamps sooner. I'll give X-Rite the benefit of the doubt and ascribe it to simple lack of debugging.

As the iSis is now their heavy production instrument I think it can hope for tender loving software support and. As long as the transport mechanism keeps working, and the thing gives readings, frankly I don't care what other faults it has. Although I should warn people here that banging it around is a VERY bad idea.

Edmund

[digitaldog]

And, to answer the next question, i1Profiler did not detect misalignment or measurement problems on any of the misread charts.

The lack of error checking i1P is substantial. It really needs to be looked at and addressed in the next release.

I still prefer using MeasureTool. Often I’m measuring and building profiles at the same time.

Speaking of an odd disconnect, can anyone answer this question (and yes, I emailed X-Rite but haven’t heard back):

When using an iSis in i1P, setting measurements for UV Cut and Non Cut (M0/M2), I save the data. But which is used to build the profile? There’s no indication I can see that one or the other is used once you move from the measurement workflow to the profile creation workflow. Can I select if Cut vs. No cut is used?

What am I missing?

At least using MeasureTool, I save both measurements out as CGATs and can load the one I want to use in i1P. What i1P is actually doing is a complete mystery to me.

[Ethan_Hansen]

The lack of error checking i1P is substantial. It really needs to be looked at and addressed in the next release.

I still prefer using MeasureTool. Often I’m measuring and building profiles at the same time.

There are two problem. One is that the data are not using the new XRGA standard. i1Profiler complains about loss of accuracy in this case. The other is that you can not feed the measurement results into the OBC module - only combined data sets are supported with the new mxf format.

Speaking of an odd disconnect, can anyone answer this question (and yes, I emailed X-Rite but haven’t heard back):

When using an iSis in i1P, setting measurements for UV Cut and Non Cut (M0/M2), I save the data. But which is used to build the profile? There’s no indication I can see that one or the other is used once you move from the measurement workflow to the profile creation workflow. Can I select if Cut vs. No cut is used?

What am I missing?

At least using MeasureTool, I save both measurements out as CGATs and can load the one I want to use in i1P. What i1P is actually doing is a complete mystery to me.

There is no way of choosing which data set is used when measuring in i1Profiler. Based on our limited experimenting, when a combined mxf format) file is saved, the No Cut (M0) data are used. This became apparent when profiles for papers with high levels of brighteners came out with the same yellow cast to the highlight areas that Monaco Profiler produced. Feeding the same measurements into ProfileMaker triggered the software-based optical brightener compensation algorithms, giving nicely neutral highlights.

I do not know which measurement set is used if you save the data in CGATS format. We did the above testing to see how well the OBC module worked, which forced saving in mxf format. (The OBC module remains a painful exercise, but performed very well on some papers while other stocks such as bright white office paper were hopeless. For them, the software algorithms in ProfileMaker gave far superior results.)

[digitaldog]

There are two problem. One is that the data are not using the new XRGA standard.

My understanding is one needs a Rev E for this anyway. Is there anyway to check this in the saved text file as I have a Rev E and older Rev C data.

The other is that you can not feed the measurement results into the OBC module - only combined data sets are supported with the new mxf format.

There’s still the old standalone app, that should work right?

There is no way of choosing which data set is used when measuring in i1Profiler. Based on our limited experimenting, when a combined mxf format) file is saved, the No Cut (M0) data are used.

That seems silly. What are they thinking?

[Ethan_Hansen]

My understanding is one needs a Rev E for this anyway. Is there anyway to check this in the saved text file as I have a Rev E and older Rev C data.

Our iSis spectros are Rev C. Making measurements from i1Profiler converts the data to XRGA. You can check in the saved CGATS file from i1Profiler. In the header there will be the following lines:

KEYWORD "DEVCALSTD"
DEVCALSTD "XRGA"

These entries are not present in MeasureTool generated files, so i1Profiler defaults to non-XRGA. If you save to the new mxf format, down near the end of the file there is an entry for the calibration standard:

<cc:Resources>
...
   <cc:ColorSpecificationCollection>
   ...
      <cc:ColorSpecification Id="XRitePrismDefault">
      ...
      <cc:MeasurementSpec>
      ...
         <cc:CalibrationStandard>XRGA</cc:CalibrationStandard>
... etc.

There’s still the old standalone app, that should work right?

No clue. It required such a constrained, linear workflow that I have not tried it in a long time. The results also were usually no better than and often worse than using our software-based algorithms for OBA detection and compensation.
 

> There is no way of choosing which data set is used when measuring in i1Profiler. Based on our limited experimenting, when a combined mxf format file is saved, the No Cut (M0) data are used.
That seems silly. What are they thinking?

Thinking? We don't need no stinking thinking!

[digitaldog]

Our iSis spectros are Rev C. Making measurements from i1Profiler converts the data to XRGA. You can check in the saved CGATS file from i1Profiler.

Yes, I’ve seen that in the text files with both units but none the less, I’m not positive the Rev C is doing anything. I know for a fact there’s a difference in measurements between a Rev C and E! I was told this was updated in the E for XRGA. Something to keep in mind if you are working with multiple units of different Rev’s and expecting to correlate the data.

[Ethan_Hansen]

Yes, I’ve seen that in the text files with both units but none the less, I’m not positive the Rev C is doing anything. I know for a fact there’s a difference in measurements between a Rev C and E! I was told this was updated in the E for XRGA. Something to keep in mind if you are working with multiple units of different Rev’s and expecting to correlate the data.

My suspicion is that the Rev E reports data using the XRGA spec while the Rev C reports in the older spec. I base this on the difference in measurements between using i1Profiler and MeasureTool or ProfileMaker. MT and PMP give one set of values, i1Profiler another.