[argyllcms] Re: Creating a null transform output device
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Wed, 14 May 2008 12:54:15 +1000
Roger Breton wrote:
What I need is a destination profile that does not modify the sources RGB
values. So, I guess inside a TRC/matrix profile, the TRCs have to be linear
and the diagonal in the matrix must all be 1s and the rest of the matrix
terms be 0?
Roger,
a destination profile never sees the source RGB values,
so there is no way it can modify/not modify them. The destination
profile just gets PCS values.
If you use the same matrix based RGB profile back to back,
the internals of the matrix and the TRC's is largely
irrelevant, as long as it is functional and assuming
the intermediate PCS representation doesn't quantize things
too badly. So something like sRGB / AdobeRGB etc. is probably
the safest.
It's actually rather the contrary I need to do. This is a Windows driver and
I don't have a choice of the "printer" profile (Destination). It's the
Source profile that I have control of.
Do you, or do you not have a choice over the printer/destination profile ?
If you don't, then why are you bothering with the printer, since
you obviously can't actually use any device profile that you
create for it ! (at least, not unless you're hoping to do the
color management separately to the printer driver.)
I guess that the biggest issue may be simply that the printer
driver may be overly fussy about what sort of RGB device profiles
it accepts. If (for instance) it insists that they have
to be Output class profiles, then none of the usual
RGB matrix profiles will be recognized, since they will
be Display or Colorspace class.
It is possible in principle to create an Output class
matrix profile using the CLUT machinery, but it would
take some fiddling around to do so.
A crude equivalent using the current Argyll tools would
be to create a large number of test points (say 10000)
using targen, then use fakeread to create (say) an sRGB
"device" .ti3 file, edit the .ti3 and change DEVICE_CLASS from "DISPLAY"
to "OUTPUT", then use profile to create a colorimetric table only
profile to use as the input and output space. An XYZ PCS clut type
may be the most accurate for this purpose (profile -ax).
(Beware of AdobeRGB, it's green colorant lies outside the
ICC Lab PCS encoding range, so you shouldn't use it
in anything that could possibly be converted to ICC range Lab).
You may have to register the profile with the printer driver
before the driver will give you the option of using it.
There, I think the problem is different as I don't see how I could
short-circuit that transformation or prevent the conversion?
If there is no magic flag, source profile = destination profile is it.
The more I think about this the more I think that this will nor work because
I'd be profiling on top of an existing profile.
If you're dealing with device values, there is no such thing as "a" device
profile,
they are always profile pairs.
Graeme Gill.
Other related posts:
