[argyllcms] Re: Determining proper error value for -r

This  note isn't  in reply  to the  note I'm  replying to;  I just
figured I'd keep the thread going since it's part of the topic.

Before  I go  any further,  the only  really important  part. What
``average deviation as a percentage'' does the following sample of
values  represent? These partial  readings are  of the  same color
(paper white, in this case) in different patches on the same sheet
of paper, and the last line is the standard deviation.

  LAB_L   LAB_A   LAB_B   400     410     420     430     440
  94.69   2.28    -9.05   27.72   49.83   84.45   104.77  109.47
  95.23   2.32    -9.36   27.92   50.59   86.03   106.81  111.64
  95.37   2.32    -9.29   28.09   50.88   86.36   107.08  111.88
  95.3    2.29    -9.35   27.62   50.39   86.09   107     111.85
  95.22   2.31    -9.21   28.2    50.71   85.86   106.5   111.29
  95.2    2.34    -9.25   27.45   50.21   85.82   106.61  111.38
  95.37   2.28    -9.35   27.92   50.73   86.4    107.23  112.02
  95.23   2.31    -9.3    27.88   50.41   85.84   106.69  111.54
  0.22    0.02    0.11    0.25    0.34    0.61    0.77    0.81

(That's the readings of but one  ``color'' patch from a chart with
a  few dozen  such. If  you  need the  full  set  of the  spectrum
readings, just give a holler.)

Once I understand how a  real-world sample such as that translates
into a value for -r, I think I'll know enough to do enough testing
on my  own to  see if  there's any  chance that  I'm on  the right
track.

Anyway, the immediate  impetus for me to start  thinking about all
this  comes from  this  past  Sunday, when  I  spent  part of  the
afternoon  at  my  parents' place--ostensibly  for  dinner--in  an
essentially  futile attempt  to  profile my  parents' cheap  color
laser printer. For what  it is, it's not all that  bad, but my mom
was complaining that  the colors on screen (which  I'd profiled in
the  past)  don't  match  those  from  the  printer. Part  of  the
problem, I'm sure, is that  cheap color laser printers suffer from
generally-unobtrusive (to  ``home users'') but  definitely visible
banding.

I'm  pretty confident  that  I  should be  able  to  get a  ``good
enough'' profile to  make my mom happy, but only  if I can conquer
-r. I think  I know enough to  be able to do  that, now...but I'll
have to  spend another  afternoon at their  place to  do it. Since
they're  good people  and the  food  is wonderful,  that's not  so
terrible...I'd just rather spend the time there on something other
than the computer....

What  I'm  envisioning for  the  future  is a  two-pass  profiling
process, not  noticeably different  for the  end user  from what's
currently used for high-end profiling. I  think it has a chance at
giving  better  results for  high-end  profiling,  and I'm  almost
certain it'll  make profiling  poorly-behaved devices  pretty much
straightforward.

Here's one  way it  could work, though  the specifics  about which
files, commands, etc., do what aren't at all critical.

You'd  generate a  preliminary target  mostly as  usual, but  pass
something to  targen to tell  it that this is  a target not  to be
used  to create  an ICC  profile,  but to  characterize the  error
response of  the device  / printer /  paper /  etc. Logically, the
target  would just  be the  same smaller  target repeated  several
times; for example, if you  asked for a 1,000-patch target, targen
might create a 100-patch target with ten copies of each patch.

When  you run  profile over  the results  of reading  that target,
profile wouldn't  (necessarily) create an ICC  profile; instead it
would create  a (say) ti4  file that contained  a characterization
of  the  error  response  (such  as a  matrix  that  says  to  use
such-and-such an error for  a volume centered around this-and-that
point,  or  whatever)  and  whatever  information  (trivially,  an
embedded ICC  profile) that  targen needs  to create  an optimized
target.

Next, you'd re-run targen, which would use that ti4 file to create
your ideal target. Finally, when  you process the results, profile
would  refer to  the ti4  file  to know  how to  handle the  error
ranges.

So, in short, the end user does much the same thing as before, but
Argyll is doing  the extra step of figuring out  where to be fuzzy
and where to be precise.

Make sense?

Cheers,

b&

Other related posts: