[argyllcms] Re: Three questions: rgb to ti3 rgb, LAB (not xyz), and one other

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Fri, 12 Jan 2018 12:28:32 +1100

Walker Blackwell wrote:

Hi,

An overview of what I'm doing, I apologize for the long post.

1. I make Piezography ink (piezography dot com).
2. Traditionally we "linearize" the ink curves directly
in the driver so that Gray Gamma 2.2 (Adobe RGB) input values print L*
linear in the print. This serves to create a uniform standard for output
across inks and printers.

Not entirely kosher in regard to tonal response if the intention is that
non-color managed AdobeRGB data is being fed into the printer, but
reasonable as a basis for setting the printer up to have a good native
response.

Soft-proofing with "Preserve RGB"
makes a VERY VERY good monitor to print match although it does require
slightly more tweaking of the image.

Color will be wrong though, unless the printer RGB conversion tables
happen to map to primaries that are close to AdobeRGB though.

ICCs can optionally be printed on
top of this system for appearance matching from monitor to print with a
given viewing condition.

Yep - that should be good.

3. I am looking to create an ICC only workflow where I can preserve this
linearity in the print without requiring recalibration of the ink
placement.

I'm not sure what you mean by that. Do you mean that you are implementing
the linearization using some mechanism provided by the printer or its
driver software ?

Instead, this shift will happen in the raster data before it
hits the driver. The reason why I'm doing this is because I'm
in the process of building a dedicated Piezography driver and I would
like to get away from the complicated workflow of calibrating individual
ink channels. It's more elegant to have a simple and standard
icc / media-type workflow.

If you're playing with ink and printer drivers, then I don't
see how you can escape this. It's part of setting up a printer.

ICC profiles will work best on top of a printer workflow
that has reasonable response. Native inkjet response is not
usually reasonable, due to dot gain and ink limits.
The simplest way of taming this is to use per channel
curves, ideally in the native printer primaries. You can
get much finer control over per channel curves than in
an ICC profile, because there is only one dimension
to measure and model.
ICC has to cope with fairly sparse multi-dimensional
samples, and so can't see fine detail necessary to
compensate well for extreme native device responses.

4. I've had some initial success iteratively tuning a set of
measurement files to trick an ICC into behaving linear but this is
complicated and timely. It won't work for a person out in the
world.

I don't recommend this. Use a calibrate, profile workflow.
Calibration is straightforward with the right tools, and
will let you keep a printer in alignment without
having to re-profile regularly.
See <http://www.argyllcms.com/doc/Scenarios.html#PC1>

5. I have had success in building "fake" RGB / LAB data
out of any number of grayscale measurements. In other words: a user
measures (say) 60 monochrome steps from dark to light and my software
will interpolate those steps to 256 and also to "fake"
low gamut LAB color data and also create the corresponding RGB target
data as well. This cgats file works to build RGB ICC profiles with
i1Profiler or Argyll that print correctly with the monochrome-only print
system.

6. My trouble is in figuring out how to control this appearance curve
that adds too much contrast to the monochrome output. This contrast is
not just with this system but also apparent in traditional RGB print
profiles I create for normal epson drivers and color ink.
7. I have almost decided simply to add the ability to "tune"
the shadows more open when building the fake RGB/LAB/XYZ measurement
data. This would allow for a half-and-half appearance model. This is a
little kludgy so I'm not sure this is the way to go. A
programatic approach would be the best IMO. If anyone has specific
details (or build commands that would get there) I would be all ears.

Something like printcal has the -t option to allow some tuning
of the calibrated tonal response:
<http://www.argyllcms.com/doc/printcal.html>

A few questions related to the project above:


Ok. So if I export a normal cgats measurement file (RGB #s from 0-255),
can I simply divide the RGB #s by 2.55 to get the 0-100 RGB numbers
required by the .ti3? It seems to work in my current testing I just want
to confirm if that's ok to do.

Yes. Argyll uses % for text device values by default, rather than assuming
any particular binary encoding.

Also, does Argyll support LAB measurements and not just XYZ?

Yes, but they are exactly equivalent in .ti3 files. i.e. Lab is assumed
to be D50 referred (i.e. ICC PCS style).

I can
convert from LAB to XYZ for a given observer angle and illuminant (for
the project that I'm doing which is a little odd) but I was just
wondering if Argyll can do this on it's own from LAB. I could
not find it in documentation.

See the COLOR_REP value:
<http://www.argyllcms.com/doc/ti3_format.html>

But I wouldn't be messing with .ti3 files, I'd be using
the printer calibration tools instead.

Lastly, I have found that printing evenly spaced LAB values using
Absolute Colorimetric rendering does not preserve linearity in the
print: it actually increases the contrast curve (appearance correction)
significantly.

How are you creating and printing the Lab values ?

I think I am probably building this profile wrong somehow
but my blundering is not following a process yet so it will take some
time. i1Profiler and Argyll look to be nearly identical in their
correction curve with argyll increasing shadow separation slightly over
i1Profiler.

The fundamental purpose of a printer profile is not to provide any
transformation of image data, it is to characterize the device, so
that you can easily create whatever transformation you want. This means
that the interpretation of your image is primarily determined by
the input profile you choose, not the printer profile.

(Big difference between calibration and profiling. See
 <http://www.argyllcms.com/doc/calvschar.html>)

When it comes to nuances like how gamut mapping is performed, then
an ICC workflow allows many technical choices - it could be combined
with the input profile, be separate as an abstract profile, or be
combined into the output profile, or the whole lot combined together
as a device link.
The ArgyllCMS tools favor either combining it into the output profile,
or creating a device link for the overall conversion.

Cheers,
        Graeme Gill.





Other related posts:

  • » [argyllcms] Re: Three questions: rgb to ti3 rgb, LAB (not xyz), and one other - Graeme Gill