Hello Graeme On 6-Jan-2011, Graeme Gill wrote: > Elena [service address] wrote: >> Any way I proceed, I'm more or less getting bluish bumps in the deep blacks. >> And xicclu seems to confirm some serious problem in that area, when looking >> with >> it at the kplot. I included details, using a ofps 1300 target as reference. > > This is not unusual, given the way the code currently works. It > prioritises accuracy over smoothness at the grid points, which can lead to > sudden jumps in the black separation near the dark gamut boundary, resulting > in > less accurate color in the device space interpolated (ie. between grid point) > areas. Increasing the quality level (ie. grid resolution) can help a bit, > but the best way of minimizing the problem is to set a suitable black > generation curve. See <http://www.argyllcms.com/doc/Scenarios.html#PP6>. > (You can demonstrate that this is going to have an effect by seeing > what -kz and -kr do.) Unfortunately, yesterday later, I tried -qh also, but the problem persists. I also tried an "abundant" approach: profiling with the original 1300 patches PLUS new ofps patches generated with -c (merged by hand). In any case, I see VISUAL improvement in the Rel. intent (the bluish bump is no more visible), while there's nothing to do for the Perc. intent, where the bump is always strong. I don't feel to play with too many K curves since I noticed that colprof doesn't actually fully obeys my rules. If I state for example -kp 0 0 1 1 .5 and also -l300 -L100, colprof shouldn't for any reason limit the K max level (it does instead) or, worst, change its monotonic increasing. However, please explain me why this strange behavior of xicclu: plotting -g with -fb -ir does show the K turning down, while plotting the perc. intent gray (-g -fb -ip) DOESN'T (see previous pictures) - BUT, if you measure the C,M,Y,K values in the rgb->CMYK picture converted with Perc. intent, you actually SEE the black ramping down! Is it a bug ?? I'm turning a bit mad... /&