My thoughts exactly, RGB is RGB is RGB, however the patches are distributed
between 0 and 255.
0,0,0 means "Black"
255,255,255 (or 1.0, 1.0, 1.0) remains "White" as far as the "device" is
concerned.
I suspect it is the way the device values are "distributed" between the two
extremes, within targen, using the -c parameter that can make a difference? I
have not looked at how the generated *.ti1 file looks like, internally, using
the -c argument, so I cannot say for sure but that's my intuition. If I know, a
priori, that I'm going to be "sampling" a larger color space like AdobeRGB over
a smaller color space like sRGB, maybe it makes more sense that the "scale"
(for the green ramp, for example) does not share the same "increments" as the
scale that would be used for sampling sRGB green?
To me, there is nothing that targen can do that would cause it to be a "better
fit", gamut wise, to a ProPhoto or sRGB or AdobeRGB... Device values are device
values are device values...
In sRGB, Blue is represented by RGB = 0.0, 0.0, 1,0.
In AdobeRGB, Blue is represented by RGB = 0.0, 0.0, 1,0.
In ProPhotoRGB, Blue is represented by RGB = 0.0, 0.0, 1,0.
In ColorMatchRGB, Blue is represented by RGB = 0.0, 0.0, 1,0.
You see?
Sorry to beat this point, Yves.
Best / Roger
-----Original Message-----
From: argyllcms-bounce@xxxxxxxxxxxxx <argyllcms-bounce@xxxxxxxxxxxxx> On Behalf
Of Henrik Olsen
Sent: Sunday, July 7, 2019 4:12 PM
To: argyllcms@xxxxxxxxxxxxx
Subject: [argyllcms] Re: Testing my new printer
Den 7. jul. 2019 kl. 21.02 skrev Yves Gauvreau <gauvreau-yves@xxxxxxxxxxx>:
Sorry Graham but I did use -c ProPhoto just to see and used a program like
tiffgamut to see what gamut the target would have (ProPhoto) and it's a
perfect fit with sRGB.
Maybe there is something I didn't see?
