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!