[argyllcms] Re: Limitations on Colormunki patch sizes?
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Mon, 06 Jan 2014 17:54:07 +1100
BC Rider wrote:
Hi,
> I
> found Argyll poor at detecting row contamination (i.e. width). I saw
> degradation in
> Excel long before Argyll flagged errors. Staggered layout (i.e. CM layout)
> improved
> detection performance over non-staggered layout (i.e. i1pro layout) but still
> not
> good.
It is not intended to detect misaligned scans - that would be almost impossible.
To detect such problems would mean having a very precise idea what values are
expected, and the whole point of doing a measurement is that you don't know what
the values are ! Making the patch detection more fussy would make it much
less usable overall. You may well end up in a situation where you can't
read a chart.
So the intention and assumption is that you want to make one measurement
and make it as dependable as possible. This is why the default Munki charts
have pretty big patches - lots of margin for misaligned scans so that
you can be confident of the readings. If people want to experiment with
smaller patches, then it's their lookout to make sure that the scan
accurately takes the instrument aperture over the patches - don't
expect the software to magically detect when there is a problem - it's
not a camera !
I chose the staggered layout for the Munki specifically because it reduces
the impact of any accidental cross contamination from adjacent strips, and
makes the detection of a grossly misaligned scan at least possible.
> I also noticed randomized targets were much more tolerant of small
> spacers. In fact spacers may not even be needed on randomized targets but I
> didn't
> investigate this further.
Yes, this is correct for small numbers of patches, but as you increase the
number
you get to the point where you can't get enough contrast between the patches for
reliable detection (it's a statistical thing.). Spacers are the only way of
guaranteeing
this for large patch sets. In the randomized layouts the patch order is
optimized to
maximize recognition reliability.
> 4) Sometimes there were one or two data points with dE
> errors disconnected from the group. Very occasionally a truly wild data
> point occurs.
> This happens regardless of patch size. Rescanning the patch brings these back
> in line.
Hmm. I'm guessing this is the patch recognition not working correctly. It would
be good to track this down. One way of narrowing this down would be to identify
a color sequence where this is more likely, so that it will pop up often enough
to test to eyeball the debug graphs.
> The downside of the CM layout is a tremendous amount of wasted white space at
> the
> beginning and end of each row.
That's due to the size of the instrument and the location of its aperture, and
the difficulty of estimating where the aperture actually is. You can't really
drag the instrument over the edge of the paper, and there will be recognition
errors
if there isn't a minimum amount of white space before the first patch. Lack of a
white space run-off area can also cause patch recognition problems (patch
count).
> To that end, I'd suggest Printtarg
> updates to: 1) Allow scaling patch width and length separately,2) Allow
> setting the
> white space at the beginning/end of each row (perhaps specify minimum mm
> required?)3)
> Option to not print strip indexing and/or allow font size scaling Advanced
> users could
> then tailor either the i1pro or Munki layouts to suit virtually any need.
Thanks for your suggestions, I'll take a not of them. I'm not sure when they
may get implemented though :-(
Graeme Gill.
Other related posts:
