Elena [service address] wrote:
To summarize: for each main diagonal in the Lab space (or whathever the 3D PCS is) going to absolute black [even those going to edge centers if you compute it with pos/neg coordinates, so to include red->black, cyan->black, white->black, etc.] you compute a K separation curve, the way xicclu -fif would do if it had already the suggested -p option available, using the -k or -K parameters given. All points laying on the main diagonals would then get their proper separation, optimally chosen and checked by the user with xicclu, if the case.
Sure. I agreed that adjusting K in the whole gamut to meet smoothly with the K at the gamut surface would be a next step, in an email some time back. That would help many cases, but doesn't address the issue of K on the gamut surface being "bumpy" itself.
Those laying between diagonals are constrained to a K curve resulting from interpolating the K curves of the diagonals around [allowing any colorimetrical mismatch]. Since the pre-computed diagonals are just those going to absolute black,
I wouldn't use a "slices" approach, but would just treat it as an interpolation volume, since that is a well supported computational paradigm within the code.
Thinking better of what you wrote... a similarly aimed solution could be generating a device link profile between the desired rgb space and the CMYK device with -G option and a table resolution of 256. Unless the source image has >24 bit color resolution no interpolation should happen. The only matter: I don't think the ICC standard supports 256^3 LUTs...! I noticed that collink itself limits -r to 100 so I assume that is the standard imposed.
I don't think that the standard imposes any such limit, it's a matter of practicality. I doubt that you could invert that many grid points using the current code, in a reasonable amount of time. If "ultra" with a res. of 45 takes up to several hours, then a full resolution table would take about two weeks... Graeme Gill.