[Openicc] New options on the mainline
Robert Krawitz
rlk at alum.mit.edu
Sat Jan 19 16:31:02 PST 2008
Date: Sun, 20 Jan 2008 01:19:04 +0100
From: Gerhard Fuernkranz <nospam456 at gmx.de>
Robert Krawitz wrote:
> I added some new options on the mainline, to assist people who want to
> linearize the driver. These have only been added to the Epson driver,
> at least at this time. By default, all of these options are disabled,
> so the driver uses whatever values have been set internally.
>
> 1) Drop size selection. There are three new settings, Drop Size
> Small, Drop Size Medium, and Drop Size Large,
Instead of three parameters, shouldn't this better be a (variable
sized) array in order to specify a varying number of drop sizes?
Possibly, although the number of drop sizes isn't likely to ever get
very large, and we don't really have a user interface for arrays. No
Epson printers at present have more than 3 drop sizes (at any one
time); if Epson ever goes to 7 or 15 levels, we'll worry about it
then.
Btw, it's possibly also noteworthy, that usually at different DPI
resolutions different number of ink levels are available.
Usually it's always 3 levels, although in some cases one or two levels
don't work (at low resolution, some printers only do anything with
levels 1 and 3). That's something someone will discover quickly
enough during tuning.
> that can be used to
> specify the relative sizes of the three drops. The screening code
> assumes that the ratios specified relate to the number of drops of
> each size that will produce a constant darkness; sizes of 0.25,
> 0.5, and 1.0 mean that 4 small drops are treated as equivalent to 2
> medium drops or 1 large drop.
>
> * The largest drop size you want active should be set to 1.
> Normally that means the large drop size. However, if you don't
> want to use the large drop size (at very high resolution), you
> may set one of the smaller drops to 1.
>
> * A drop size of 0 is not used. So if you set the large drop size
> to 1, the small drop size to 0.25, and the medium drop size to 0,
> only the small and large drops will be used.
>
> * Drop sizes should be specified in ascending order, other than
> drops of 0 size. For example, you should not set the small drop
> size to 0.5 and the medium drop size to 0.25. If you do, the
> results are undefined.
>
> 2) Light ink value options. These options, which are available for
> whichever light inks are available on the particular printer, can
> be used to set the intensity relative to the dark ink. "Intensity"
> means the inverse of the amount of ink required to achieve a
> particular darkness. For example, a Light Cyan Value of 0.25 means
> that the driver will trade off 4 drops of light ink for 1 drop of
> dark ink.
>
> 3) Light ink transition options. These options, which are available
> for each channel with light inks, specify at what point the driver
> will start using dark ink. This is expressed as a fraction of the
> intensity of the light ink. For example, if Light Cyan Transition
> is set to 0.40, the driver will start using dark ink when the
> amount of light ink reaches 40%. So and the Light Cyan Value is
> 0.25, the driver will start using dark ink at 0.1 (6554 on a raw
> scale of 0-65535).
>
> 4) Light ink scaling options. These options replace the previous
> light ink transition options, which basically just adjusted the
> density of the light ink relative to the dark ink. I expect that
> these will be the least useful of the new options, but I may be
> wrong.
I'm wondering, whether user-supplied channel-splitting/calibration
curves, i.e. Cyan input => Dark Cyan and Cyan input => Light Cyan,
wouldn't provide more flexibility for the user to establish an
arbitrary blending between the dark and light inks? I guess that
such curves would also make 2) 3) and 4) obsolete?
Yes, although it would be more complicated to implement. If it turns
out to be really necessary, we can look at it then. Of course,
someone else might want to go ahead and implement it :-)
> * Color Correction should be set to one of the following:
>
> + Raw if you want to adjust all the settings manually. In Raw color
> correction mode, there will be no automatic correction of any
> kind, including density adjustment. If you're not careful, you
> may find yourself using an excessive amount of ink with this
> setting. You will need to adjust the Density control or the
> controls for the densities of the individual colors. You may want
> to use this to establish custom densities and ink limits to
> achieve maximum gamut.
> + Density if you want to use Gutenprint's choice of density, but
> otherwise have no automatic color correction applied. This choice
> of setting should be safe (at least in RGB mode; in CMYK mode it's
> possible for too much ink to be applied). This is useful if
> you're satisfied with Gutenprint's default ink limits, but want to
> adjust the linearization yourself.
Do "raw" and "density" mode honor user-supplied linearization
curves? Or in other words, which mode do I need to select, if I
want _Gutenprint_ to apply _my own_ linearization (and possibly
channel-splitting) curves, which I supply as parameters? (my
understanding is that this is basically the most desired mode of
operation, at least for CMYK printers, and for CcMmYKk printers
which are not operated in a multicolor mode, but which emulate CMYK
by channel splitting).
Yes, they do honor user-supplied linearizations. They just don't
apply the defaults.
> + Uncorrected if you want to use Gutenprint's choice of
> linearization, but otherwise have no cross-channel correction
> applied. If you're satisfied with Gutenprint's linearization and
> want to profile the driver, this may be a good selection.
>
> I do not recommend using the default, which is usually High
> Accuracy. This setting performs inter-channel adjustments in HSL
> space, which probably won't yield the optimum results.
>
> Comments please.
And how to deal with multicolor printers? Do I understand
correctly, that there is currently no print mode available, which
accepts "DeviceN" input (i.e. one input channel for each ink)?
Yes there is, actually -- see src/testpattern to see how to use it.
If someone wants to do N-channel linearization and RGB->DeviceN or
CMYK->DeviceN, it will work just fine with Gutenprint (if they have a
way of talking to the driver).
--
Robert Krawitz <rlk at alum.mit.edu>
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gutenprint -- http://gimp-print.sourceforge.net
"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
More information about the openicc
mailing list