And btw on the Mac, I vaguely remember that I solved my problems in the end
by writing parsers and generators for bitmap files directly in the internal
CUPS format so I could create testcharts and check they were getting passed
through untouched. Which is not something that Joe User is supposed to do.
Edmund
On Tue, Jul 7, 2020 at 7:12 AM edmund ronald <edmundronald@xxxxxxxxx> wrote:
Graeme,
Although my knowledge of ICC workflows is 1 % of your I have a comment to
make.
The ICC deliberately adopted an external profiling model where the user is
responsible for color matching. This allows vendor finger-pointing — no
device is ever responsible for a precise color match— and means the user is
supposed to magically ensure the "profiling" of each device, at every
moment. However of course as no color matching is built into the devices
(screens, printers, cameras), no hooks are of necessity present in the
device driver software to help with profiling. Just as the calibrators—eg
the i1— have no standard interface to any software. The result is
paradise, with devices constantly dropping out of calibration due to drift,
settings changes, incompatible software etc, or even users are not capable
of calibrating — viz. the fact that i's getting impossible to spit out a
testchart on the Mac because of Mike's Sweet's attitude— or the fact that
calibration software like that yucky thing called Argyll not working with
calibrators like the new i1 series because there is no reason to have a
public interface spec— and of course you will explain to me that I'm dumb
and the world is perfect.
At the ICC we had meetings where people openly admitted it was getting
impossible for a consumer to print a testchart on an inkjet. Nobody really
cared. As the color geek for Gutenprint, I tore out my hair trying to
track the changes in Mac OS. As an Adobe engineer once wrote me when I
filed a printing bug, "You are using the less used print path".
The reality is that the whole system architecture should track COLOR
coming into and out of each device — instrument, monitor, printer— and the
same should be the case in the software. But in fact all the printers and
monitors work in color independent, scale-less device spaces and so without
a major effort at standardisation the hell we're seeing is guaranteed to
last forever. Which is all to the benefit of incumbent vendors who achieve
lockin. As a RIP manufacturer once told me "profiling is usually locked
down in installed RIPs because the (intermediate) supplier wants to prevent
users from changing paper".
Edmund
On Tue, Jul 7, 2020 at 5:02 AM Graeme Gill <graeme@xxxxxxxxxxxxx> wrote:
edmund ronald wrote:
so just distribute a null profile to be used when printing targets endof
story
It doesn't work like that.
What's commonly referred to as a "profile" is a device profile,
i.e. half the typical color management transform.
What's needed is a color transform that conveys device values
though without modifying them. The general way of specifying
that is a device link, but many workflows don't support
device links at their color management implementation
point, and may not even support a source pixel format that
matches the destination pixel format (i.e. the workflow may
assumed the source is RGB space when the destination/device
space is CMYK etc.).
Graeme Gill.
