Message
Re: [colorvision_group] Application suggestions for reading
2006-03-08 by CDTobie@aol.com
In a message dated 3/8/06 10:33:59 AM, dlenos@... writes:
I would think that the program could monitor the reading for a given patch and 'flag' it if it is too far out of bounds with what the expected reading was.
There are no "expected" readings... the EyeOne software used to do attempt this, and it was so annoying that they changed it. If you are using one inkset on a gloss paper, or another on a matte paper, the hue of red, or density of black could vary by large amounts... such that the check would not be much of a check, if it were set far enough out to not trigger for normal differences. And if you profile something like a small gamut inkset, then a totally different set of expected values would be needed. You end up needing premeasured sets for every printer model and general paper type... something we wish to avoid.
This would be easy if the colors were far apart in the spectrum, but still possible to at least flag by beeping or surrounding the patch w/ red outline to indicate it is a suspect. Also, at times, esp when I was trying to read quickly I would get a 'dbl-click' on the same patch - what this does is put the same reading in two successive boxes, requiring me to go back a square and read the proper target - if a reading taken is within a tolerance of the previous reading or time limit (ie no one can read two successive patches in 3 seconds) the app should flag it.
Sometimes two adjacent patches actually do measure the same, so there would be false errors from this as well. If we randomize the patches (as we have in the past) then there is no way to look at the matrix and see whether patches are in the right order, and the likelihood of errors is increased, in an attempt to decrease them. Randomized patch sets require that the software and math do all the work, and that premeasurements be availble to check against.
Lastly, when trying to look over the the entire target, after I am done, for obvious 'mis-reads' it can be tough to identify them against the actual target - I usually hold it up to the monitor and compare.
We will have toggle keys in the next beta that will allow you to quickly toggle from pure to measured values, assisting in finding bad reads in the less organized sections of the 225 patch target. But there really shouldn't be many bad reads; if you miss a patch, it shows up in the matrix quite clearly, if you double read a patch, that shows up as well. You would have to both skip one, and double another in the same row, to have it not be clear at the end of the row, when the bell sounds at the wrong time. Even with a double, compensating, error, unless it all happens in the same section of the same row, there will be visually obvious matrix errors. With that level of errors, you'd be better off waiting and reading it in the morning...
- I don't have the software in front of me but in the option to view the the whole square as it was read (not pure or split view) - it would be great if in each sq the actual three read values were able to be toggled on, next to the expected values. And even better if a suspected mis-read was hi-lited in red (ie, same reading as prev box, or outside the expected values)
The read values are available if you go back to the patch with the arrow keys, but the auto-mode instantly moves you forward to a new, unmeasured, patch as you take readings, so you don't see these numbers. Any reading method that involved looking at numbers, or even looking at the screen, while measuring would be terribly slow... I can read 225 patches without a single error, time after time, in five minutes. Some system that involved looking at the screen even once per row would slow me down considerably, and looking at the screen with each patch would take several times as long, as well as tending to get me lost, and increase the likelihood of misreadings.
We went through a many of these ideas when developing the interface, and its quite optimized for the set of parameters we selected. To change it now would mean to change to a whole different set of assumptions (random patches, mathematical checks, premeasured sets to check from, etc), and optimize to those instead. Given that this is a patch-at-a-time reader, not a strip-at-a-time reader, I believe the choices me made are the strongest set, and our implementation of them is pretty well optimized. But further improvements and options are on the way, as time allows.
C. David Tobie
Product Technology Manager
ColorVision Business Unit
Datacolor Inc.
CDTobie@...
www.colorvision.com