[argyllcms] Re: chartread feature request / pipedream...

  • From: Radek Doulik <radek.doulik@xxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Thu, 08 Jul 2010 09:16:25 +0200

Hi,

On Thu, 2010-07-08 at 10:59 +1000, Graeme Gill wrote:
> Alastair M. Robinson wrote:
> > Upon having read the last strip, chartread could build a low-res, 
> > heavily-smoothed model from the readings, then find the peak fitting 
> > error for each strip.  The overall peak error would be displayed - and 
> > then, when the user uses the forward and backward controls to select a 
> > strip for re-reading, the current fitting error for that strip would be 
> > displayed.  I think that would help a lot in increasing confidence in a 
> > set of readings.
> 
> Hmm. Anything is possible of course. Since Argyll is a "tools" sort of
> system, the approach would be to get profcheck to annotate the .ti2 file
> with the delta E of each patch, and then make chartread offer to read
> strips in max to min delta E order.
> 
> But I'm more interested in why you need to use this approach. Do
> you think strips get misread ? Do the patch values vary a lot with
> each attempt at reading ? Is the instrument moving too fast ?

I can report similar problems with i1 reading as well, and IIRC even
with DTP20. I noticed that when I was reading charts containing only
gray patches (say targen -d 0 -s 52). I have a tool to display the
measured values and sometimes some of the values are completely off. It
usually helps to reread the chart again.

First I thought it might be broken bi-directional detection, but it
happens even when running chartread with -B parameter. My (wild) guess
is that it incorrectly detects the beginning of row, might be something
else though. So when I read it second time I try to put the instrument
close to the beginning of the row.

Cheers
Radek

> I've changed the algorithm for "slicing" the patches out of a strip
> in the development code stapshot <http://www.argyllcms.com/Argyll_dev_src.zip>
> - does this work any better ?
> 
> Graeme Gill.
> 
> 


Other related posts: