[argyllcms] Re: targen options / Inkjet profiling / profile-editing

Hello Gerhard, hello list

Making good profiles for inkjet printers is hard stuff. Especialy, if 
you are using a RGB-driver, which is doing is own RGB-CMYK-conversion.

I see two ways to go:

A) The way of the professionals in the graphic arts:

1) Use a real CMYK-driver. Gutenprint (former GIMP-print) delivers this 
possibility.

2) linearize your printer before and set a proper inklimit.
The inklimit for every single channel should be evaluated by printing 
steps of the pure CMY (K) colors and measuring LCH-values. I C 
(Saturation) is not going higher and H begins changing, than this the 
point for the inklimit of the channel.
The software for linearization should calculate smooth curves for every 
channel and lead to neutral grey.
Often you need also an inklimit for the overprinting of colors. This 
mainly made by visual evaluation. Printing a chart with colors from 400% 
to 200% and inspecting, were noo bleeding of colors exist.
Here the driver should be able to apply an GCR, which replaces CMY throug K.

3) print the testchart on the linearized printer
The quality of an ICC-profile is based on the linearity of the printed 
testchart.

4) generate a profile with GCR for the neutrals
The startingpoint of the GCR is depending how big the black drops are, 
and if the printer may have an additional grey.
Big drops and additional grey needs GCR with a late starting point only 
in the dark colors. Otherwise, you get something what is called 
"peppering". If you have very small drops and/or additional gray GCR can 
start more early in the middle or lighter colors.

Thats the way, the professionals are doing it. Now a way for hackers:

A) Calculate an DeviceLink-profile from sRGB to your printer-profile

b) Inspect how the curves of an neutral sRGB-gray are mapped to 
RGB-values of the printer.
Fine is printing equal sRGB gray steps and comparing the visual result 
with the RGB-values in the devicelink-profile.

C) manipulate the devicelink-profile to get the result, you want:
- E.G. Smooth the RGB-curves of the devicelink-profile mathematicly
- change the curves with an gradation-curve tool

D) print with the optimized devicelink-profile


As both argyllcms and littlecms support devicelinks, this should be a 
possible way.

:-) Jan-Peter

By the way, did you made your printer-profile with a spectro, or with a 
scanner ?



Gerhard Fuernkranz schrieb:
>   Graeme Gill schrieb:
> 
> 
>>Are you converting from a device space (e.g. some sort of
>>RGB or a CMYK space) ? e.g. How is neutral defined, in terms
>>ofd L*a*b*, R=G=B, or K values ?
>>
> 
> R=G=B in sRGB.
> 
> 
>>If so, are you using the same source profile for both the
>>former (satisfactory) situation, as well as the unsatisfactory
>>one of the RGB inkjet ?
>>
> 
> Sure, in both cases the source is sRGB, and I also used the same test 
> image ("Fujical").
> 
> 
>>If not, how sure are you that the source profile is accurate
>>in the greys, and that it is not that profiles test chart that
>>needs extra grey test patches. (This has certainly been my
>>experience in some situations.)
>>
> 
> sRGB should be pretty accurate in the grays, for a synthetic gray wedge 
> with R=B=G.
> 
> 
>>Another question/suggestion is on how you supplemented the
>>output device test chart. In theory the best way is
>>an iterative approach. Profile and link as usual.
>>Feed a series of (input space defined) grey values
>>into this link, and record the output device values.
>>Print and measure them. Add the device and PCS values
>>to the output device test chart and re-create the output
>>profile. Repeat if necessary.
>>
> 
> I don't remember exactly, since its a while ago. I think I supplmened 
> approx. 125 points near the gray axis, with [a*,b*] values of [0,0], 
> [3,0], [-3,0], [0,3], [0,-3], at 25 different lightness levels and 
> converted these PCS values to RGB with the old profile, printed and 
> measured the patches, and added the results to the .ti3 file. Then I 
> created a new profile. But I did not make further iterations (iterations 
> are time consuming due to one day drying time for inkjet prints, until 
> the color drift stabilizes). I also guess, that my supplemented points 
> were distributes too regularly.
> 
> 
>>If the above is not the whole problem (ie. lack of adequate sampling
>>along the grey axis), then it could be the limitation of the resolution
>>of the profile. The basic multi-dimensional representation is of relatively
>>coarse resolution (typically 9-33 per axis), and if the device behaviour
>>along the neutral axis changes more rapidly than can be represented
>>by the multi-d tables, the neutral will not be controlled sufficiently.
>>
> 
> That's basically what I meant with "corcscrew" characteristics.
> 
> 
>>One way of tackling this as to add more points down the neutral axis
>>in the test chart (as you have been doing), but also upping the
>>resolution of the A2B and B2A tables. This is normally controlled by
>>the -q flags, but can be overridden in some of the programs. The cost
>>is generally an exponentially greater computation time of course.
>>
> 
> Sure, but unfortunately even my faster PC (Athlon XP 2600+, not the 
> fastest available, but also not so slow) has only a limited computing 
> power :-)
> 
> 
>>The ultimate answer is that such systems benefit from a calibration
>>system. A calibration system would quite finely sample the individual
>>colorant channels response, and will quite finely control them. In this
>>way the neutral axis can be made almost as perfect as is possible,
>>before the profiling system gets to deal with it. (Argyll doesn't
>>currently contain tools aimed at this particular task.)
>>
> 
> Do you mean an (independent) linearization of each channel with 
> high-resolution 1D luts?
> 
> I've no doubts that this is very helpful, if the device channels correspond to
> the actual device colorants, since the colorants usually mix rather smoothly. 
> This corresponds also to my experience. In my "successful" case, the CMYK 
> channels already did have a nearly linear response, when I plotted C,M,Y, or 
> K vs. the euclidian CIELAB distance to paper white.
> 
> But I'm sceptical, whether this also works well for devices, where the 
> controlled channels do NOT directly correspond to the device colorants. My 
> inkjet of course prints with CMYK inks, but I can only send RGB values to the 
> driver (and I have no a priori knowledge about the driver's internal RGB -> 
> CMYK mapping, and the flaws of this mapping). Thus I could only linearize the 
> RGB channels. But will linearized RGB channels also imply a smooth RGB->Lab 
> mapping near the gray axis? Maybe, if I'm lucky. But maybe not.
> 
> Another idea might be to linearize all three RGB channels not separately, but 
> together, in order to optimize the grayscale accuracy?
> 
> Btw, I've also another CMYK example, which did not work as well as the 
> "successful" one. Here the problem was obviously caused by course 
> quantization due to a low number of screen levels, particularly in light 
> areas. The profile simply outputs 4 values (CMYK), which are quantized 
> independently by the halfone threshold arrays, and this also resulted in 
> alternating color shifts into C, M, or Y direction along the grayscale (for 
> light grays), if -kh was used for profile generation (these color shifts of 
> course disappeared with -kx, at the cost of more visible lightness steps, 
> than with -kh, so it's a tread-off). A vector quantization in Lab space (to 
> the percetually nearest discrete CMYK tuple) would likely give better results 
> in this case, than per channel quantization, but of course this would be a 
> too great demand on a profile.
> 
> Regards,
> Gerhard
> 
> 
> 
> 
> 


-- 
--

homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Kastanienallee 71 ------- http://www.colormanagement.de
10435 Berlin --------- mailto:homann@xxxxxxxxxxxxxxxxxx

Other related posts: