[argyllcms] Re: RGB profile for HP Color LaserJet. Targets.

  • From: Nikolay Pokhilchenko <nikolay_po@xxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Wed, 19 Aug 2009 10:41:23 +0400

Thank you, Alastair! But I'm not completely agreed with one of your thought.

Alastair M. Robinson wrote:
>
> I see some "interesting" effects in the saturated greens and blues in
> particular - my guess would be these are resulting from the printer
> driver's own RGB -> CMYK conversion and gamut mapping.  I suppose
> there's no easy way to disable some of this driver enhancement?

Yes. The printer is network one. I have no rights to change it's settings.

> If you run profcheck -v on your .ti3 file and profile, you'll get a list
>   of patches and a measure of the fitting error.  This gives you a hint
> as to where the trouble-spots are,
>

I disagree with you for this certain case: when the initial target was not 
optimized across perceptual space, the really-problem patches may have a little 
preliminary-profile fit error in the device space. This approach will work only 
for the space the target optimized is. With your recommendations I'll be able 
to see errors in the device space, but it didn't mean I'll see errors in the 
color (perceptual) space.
I think when the device is quite nonlinear, the quality evaluation may be done 
only in perceptual space, nor the device space.

> What I think I'd do in this situation is hand-craft a second target by
> taking the RGB values of the trouble-spots and scattering a few points
> around each.
> For instance, your worst patch is: 0.709800 0.717650 0.258820, so I
> might add:
> 0.71 0.72 0.25
> 0.69 0.73 0.24
> 0.70 0.75 0.23
> or something like that - just a cluster of points around the trouble spot.

For given target data it improves the device behavior characterization, but 
will be less useful for resulting color images.

> If doing that for the points with the highest error gave me, say, 50
> points, then I'd generate a target in the normal way, but with 742
> rather than 792 patches, then adjust it in a spreadsheet.
>

I've do that earlier, but now I concerned on perceptual patches spread first.
I clarify for myself that the time spent for handicraft is better to spent for 
perceptual-spread target printing (if the printer isn't offset press :) ). But 
in this case I struck the problem with perceptual spread for my preliminary 
target data+

> What I usually do is take each full-spread patch, average the RGB values
> to give grey, then replace each RGB value with a mixture of the original
> and grey value, ramping the proportions so that the first few patches
> are using the original RGB values, the last few are using the greyscale
> equivalents of the original RGB values, and in the middle I use a 50/50
> mix of the two.
>

Alastair, what aim do you achieve such way? The good developing of a grayscale?
I wrote some month ago about my way: the cylinder, randomly filled by patches 
around the gray Lab (or Jab) axis.

> I'd then add my hand-crafted patches around the trouble spots.
>
> Now I'd generate the chart, print, read, and finally add these readings
> to the original readings, so I had a single .ti3 file containing 1584
> patches, and profile using that.
>

Yes, me too.

> With a badly-behaved device response to track, it's probably worth using
> the -qh flag to colprof.
>

I often use even -qu for colprof.

I think the best profiling way is to print both the device space and the 
perceptual space optimized tagets. IMHO this approach can improve both the 
device and the perceptual behaviors - both the A2B and B2A tables.

Thank for your response, Alastair!

Other related posts: