AW: Colorsync-users Digest, Vol 14, Issue 36
Hi Martin, The "issue" with F52 is the papertint. With F52 it is the first time that we are handling a reference characterization data set which is as far as -10b* from neutral. In fact, this papertint reflects quite well what we get from the many uncoated production substrates and prints, so this standard, describing a specific offset printing condition is really good... but: The issue is to be found in the typical handling of a white point in the ICC color workflow. The complete greybalance tips over to this very bluish paper tint and then the CMY-balance gets "out of order" to compensate accordingly. Maybe one of the ICC profiling solutions delivers some bette interpretation with the perceptual intent? With our attempt to keep a most consistent color appearance possible, we have developed our own gamut mapping. please find a little Lab-tif file showing a FOGRA39 to FOGRA52 conversion here: https://owncloud.gmgcolor.com/owncloud/index.php/s/OdMOCwwMz1PcQv8 If you open this in Photoshop, you can compare the image on the different Layers and you will see what a typical ICC conversion is doing, when you convert from F39 to F52, or what a GMG- DL-profile is doing. Our profiles can be used either in our ColorServer application or within our Photoshop-Plugin. Kind regards Juergen -----Ursprüngliche Nachricht----- Von: Colorsync-users [mailto:colorsync-users-bounces+juergen.seitz=gmgcolor.com@lists.apple.com] Im Auftrag von colorsync-users-request@lists.apple.com Gesendet: Samstag, 9. September 2017 16:53 An: colorsync-users@lists.apple.com Betreff: Colorsync-users Digest, Vol 14, Issue 36 Send Colorsync-users mailing list submissions to colorsync-users@lists.apple.com To subscribe or unsubscribe via the World Wide Web, visit https://lists.apple.com/mailman/listinfo/colorsync-users or, via email, send a message with subject or body 'help' to colorsync-users-request@lists.apple.com You can reach the person managing the list at colorsync-users-owner@lists.apple.com When replying, please edit your Subject line so it is more specific than "Re: Contents of Colorsync-users digest..." Today's Topics: 1. RE: FOGRA52 & i1Profiler [subject corrected] (Roger Breton) 2. RE: FOGRA52 & i1Profiler [subject corrected] (Roger Breton) 3. RE: FOGRA52 & i1Profiler [subject corrected] (Roger Breton) 4. Re: FOGRA52 & i1Profiler [subject corrected] (Martin Orpen) 5. Re: FOGRA52 & i1Profiler [subject corrected] (Graeme Gill) 6. Re: FOGRA52 & i1Profiler [subject corrected] (Martin Orpen) 7. Re: FOGRA52 & i1Profiler [subject corrected] (Graeme Gill) 8. Re: FOGRA52 & i1Profiler [subject corrected] (Martin Orpen) 9. Re: FOGRA52 & i1Profiler [subject corrected] (Dan Bergstrom) ---------------------------------------------------------------------- Message: 1 Date: Fri, 8 Sep 2017 15:31:40 -0400 From: "Roger Breton" <graxx@videotron.ca> To: "'Martin Orpen'" <martin@idea-digital.com>, "''colorsync-users?lists.apple.com' List'" <colorsync-users@lists.apple.com> Subject: RE: FOGRA52 & i1Profiler [subject corrected] Message-ID: <7858301d328d9$19748fc0$4c5daf40$@videotron.ca> Content-Type: text/plain; charset="utf-8" How's the Perceptual Intent? / Roger -----Original Message----- From: Colorsync-users [mailto:colorsync-users-bounces+graxx=videotron.ca@lists.apple.com] On Behalf Of Martin Orpen Sent: Friday, September 8, 2017 1:04 PM To: 'colorsync-users?lists.apple.com' List <colorsync-users@lists.apple.com> Subject: Re: FOGRA52 & i1Profiler [subject corrected]
On 4 Sep 2017, at 19:27, Martin Orpen <martin@idea-digital.com> wrote:
I’ve downloaded it and it works very well (and with the yellow as I’d expect from the 52 data).
Having taken a closer look, BasICColor Print is also producing poor relative intent separations from the 52 data. The neutral rendering is just as questionable as i1Profiler’s — the only difference being that X-Rite’s engine maintains the hideous blue blacks and BasICColor neutralises it. The magenta plummets by 30% between L31 & L28, while yellow climbs by 20% and cyan drops 6%. I’ve never seen results this bad from any other data set. It’s ridiculous having a *standard* that requires massive editing before repro houses can create an ICC profile that matches the generic profiles published by the ECI. -- Martin Orpen Idea Digital Imaging Ltd _______________________________________________ Do not post admin requests to the list. They will be ignored. Colorsync-users mailing list (Colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/graxx%40videotron.ca This email sent to graxx@videotron.ca ------------------------------ Message: 2 Date: Fri, 8 Sep 2017 16:11:36 -0400 From: "Roger Breton" <graxx@videotron.ca> To: "'Martin Orpen'" <martin@idea-digital.com>, "''colorsync-users?lists.apple.com' List'" <colorsync-users@lists.apple.com> Subject: RE: FOGRA52 & i1Profiler [subject corrected] Message-ID: <78c9a01d328de$ae8419a0$0b8c4ce0$@videotron.ca> Content-Type: text/plain; charset="utf-8" Martin wrote :
It’s ridiculous having a *standard* that requires massive editing before repro houses can create an ICC profile that matches the generic profiles published by the ECI.
Doesn't the ECI site offers some kind of "standard" Fogra52 ICC profile? I suppose you long tried that option. / Roger ------------------------------ Message: 3 Date: Fri, 8 Sep 2017 16:28:38 -0400 From: "Roger Breton" <graxx@videotron.ca> To: "''colorsync-users?lists.apple.com' List'" <colorsync-users@lists.apple.com> Subject: RE: FOGRA52 & i1Profiler [subject corrected] Message-ID: <78f8f01d328e1$0e8869d0$2b993d70$@videotron.ca> Content-Type: text/plain; charset="utf-8" Oops! Misread what Martin wrote.... What about using the same "tools" used by the ECI to generate their generic ICC profile? / Roger -----Original Message----- From: Colorsync-users [mailto:colorsync-users-bounces+graxx=videotron.ca@lists.apple.com] On Behalf Of Roger Breton Sent: Friday, September 8, 2017 4:12 PM To: 'Martin Orpen' <martin@idea-digital.com>; ''colorsync-users?lists.apple.com' List' <colorsync-users@lists.apple.com> Subject: RE: FOGRA52 & i1Profiler [subject corrected] Martin wrote :
It’s ridiculous having a *standard* that requires massive editing before repro houses can create an ICC profile that matches the generic profiles published by the ECI.
Doesn't the ECI site offers some kind of "standard" Fogra52 ICC profile? I suppose you long tried that option. / Roger _______________________________________________ Do not post admin requests to the list. They will be ignored. Colorsync-users mailing list (Colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/graxx%40videotron.ca This email sent to graxx@videotron.ca ------------------------------ Message: 4 Date: Fri, 8 Sep 2017 21:39:15 +0100 From: Martin Orpen <martin@idea-digital.com> To: "'colorsync-users?lists.apple.com' List" <colorsync-users@lists.apple.com> Subject: Re: FOGRA52 & i1Profiler [subject corrected] Message-ID: <AAC48E54-AFB1-4331-9A16-DB91731F7C9A@idea-digital.com> Content-Type: text/plain; charset=utf-8
On 8 Sep 2017, at 20:31, Roger Breton <graxx@videotron.ca> wrote:
How's the Perceptual Intent?
Smooth, but the blacks still don’t match. And, as the aim here is to generate profiles for black & white or critical neutral reproduction in CMYK, we don’t really need any proprietary perceptual voodoo. We need blacks that match.
It’s ridiculous having a *standard* that requires massive editing before repro houses can create an ICC profile that matches the generic profiles published by the ECI.
Doesn't the ECI site offers some kind of "standard" Fogra52 ICC profile? I suppose you long tried that option.
Yep, and that’s where the problem is. PSO Uncoated and whatever number of variants you want to produce yourself from the 47 data yield images that match *fairly* well. PSO Uncoated v3 and your custom ICC profiles made from the 52 data yield images that don’t match. -- Martin Orpen Idea Digital Imaging Ltd ------------------------------ Message: 5 Date: Sat, 9 Sep 2017 09:08:04 +0200 From: Graeme Gill <graeme2@argyllcms.com> To: ColorSync <colorsync-users@lists.apple.com> Subject: Re: FOGRA52 & i1Profiler [subject corrected] Message-ID: <4520dfb5-763a-f387-3d2a-e7f3fd6ad6ff@argyllcms.com> Content-Type: text/plain; charset=UTF-8; format=flowed Martin Orpen wrote:
The Fogra 52 data produces neutrals composed of CMK and zero Y in both i1Profiler and Argyll.
I'm not seeing that (at least with my current code): colprof -v -qm -kx fogra52 icclu -fb -ia fogra52.icc 100.0 0.0 0.0 [Lab] -> Lut -> 0.007017 0.000764 0.081098 0.000000 [CMYK](clip) 50.0 0.0 0.0 [Lab] -> Lut -> 0.082952 0.039821 0.172167 0.656606 [CMYK] 40.0 0.0 0.0 [Lab] -> Lut -> 0.195334 0.103255 0.268755 0.778196 [CMYK] 30.0 0.0 0.0 [Lab] -> Lut -> 0.704504 0.399554 0.299435 0.917631 [CMYK] 20.0 0.0 0.0 [Lab] -> Lut -> 0.998257 0.923926 0.930881 0.996716 [CMYK] 10.0 0.0 0.0 [Lab] -> Lut -> 0.994710 0.972349 0.899008 0.998990 [CMYK] 0.0 0.0 0.0 [Lab] -> Lut -> 0.983620 1.000000 0.915429 1.000000 [CMYK] colprof -v -qm -kz fogra52 icclu -fb -ia fogra52.icc 100.0 0.0 0.0 [Lab] -> Lut -> 0.007017 0.000764 0.081098 0.000000 [CMYK](clip) 50.0 0.0 0.0 [Lab] -> Lut -> 0.606688 0.510562 0.654812 0.000731 [CMYK] 40.0 0.0 0.0 [Lab] -> Lut -> 0.695956 0.650859 0.853761 0.179810 [CMYK] 30.0 0.0 0.0 [Lab] -> Lut -> 0.791740 0.543053 0.444419 0.844733 [CMYK] 20.0 0.0 0.0 [Lab] -> Lut -> 0.998257 0.923926 0.930881 0.996716 [CMYK] 10.0 0.0 0.0 [Lab] -> Lut -> 0.994710 0.972349 0.899008 0.998990 [CMYK] 0.0 0.0 0.0 [Lab] -> Lut -> 0.983620 1.000000 0.915429 1.000000 [CMYK] what exactly are you looking for ? Cheers, Graeme Gill. ------------------------------ Message: 6 Date: Sat, 9 Sep 2017 12:15:53 +0100 From: Martin Orpen <martin@idea-digital.com> To: "'colorsync-users?lists.apple.com' List" <colorsync-users@lists.apple.com> Subject: Re: FOGRA52 & i1Profiler [subject corrected] Message-ID: <65DD99CB-90C3-4AC6-9CEB-26D8C7AC0CDB@idea-digital.com> Content-Type: text/plain; charset=us-ascii
On 9 Sep 2017, at 08:08, Graeme Gill <graeme2@argyllcms.com> wrote:
colprof -v -qm -kz fogra52
icclu -fb -ia fogra52.icc 100.0 0.0 0.0 [Lab] -> Lut -> 0.007017 0.000764 0.081098 0.000000 [CMYK](clip) 50.0 0.0 0.0 [Lab] -> Lut -> 0.606688 0.510562 0.654812 0.000731 [CMYK] 40.0 0.0 0.0 [Lab] -> Lut -> 0.695956 0.650859 0.853761 0.179810 [CMYK] 30.0 0.0 0.0 [Lab] -> Lut -> 0.791740 0.543053 0.444419 0.844733 [CMYK] 20.0 0.0 0.0 [Lab] -> Lut -> 0.998257 0.923926 0.930881 0.996716 [CMYK] 10.0 0.0 0.0 [Lab] -> Lut -> 0.994710 0.972349 0.899008 0.998990 [CMYK] 0.0 0.0 0.0 [Lab] -> Lut -> 0.983620 1.000000 0.915429 1.000000 [CMYK]
what exactly are you looking for ?
Yellow in separations with increased K generation :) In profiles I made using Argyll in March this year I was getting this from -kx 300 TAC 60.000000 0.000000 0.000000 [Lab] -> Lut -> 0.042220 0.021155 0.138908 0.493434 [CMYK] 50.000000 0.000000 0.000000 [Lab] -> Lut -> 0.082952 0.039821 0.172168 0.656604 [CMYK] 30.000000 0.000000 0.000000 [Lab] -> Lut -> 0.703806 0.399562 0.299396 0.917587 [CMYK] 20.000000 0.000000 0.000000 [Lab] -> Lut -> 0.910211 0.696531 0.426875 0.996719 [CMYK] 10.000000 0.000000 0.000000 [Lab] -> Lut -> 0.932469 0.806219 0.293490 0.998988 [CMYK] 0.000000 0.000000 0.000000 [Lab] -> Lut -> 1.000000 0.864791 0.135001 1.000000 [CMYK] But, more importantly, this is what you actually get from relative conversions: 50.000000 0.000000 0.000000 [Lab] -> Lut -> 0.103877 0.046326 0.000000 0.712330 [CMYK] 30.000000 0.000000 0.000000 [Lab] -> Lut -> 1.000000 0.531888 0.077466 0.945821 [CMYK] 0.000000 0.000000 0.000000 [Lab] -> Lut -> 1.000000 0.864791 0.135001 1.000000 [CMYK] And perceptual has NO yellow whatsoever! 50.000000 0.000000 0.000000 [Lab] -> Lut -> 0.078745 0.037454 0.000000 0.635533 [CMYK] 30.000000 0.000000 0.000000 [Lab] -> Lut -> 0.265519 0.116809 0.000000 0.776893 [CMYK] 0.000000 0.000000 0.000000 [Lab] -> Lut -> 1.000000 0.549650 0.000000 0.922678 [CMYK] -- Martin Orpen Idea Digital Imaging Ltd ------------------------------ Message: 7 Date: Sat, 9 Sep 2017 15:57:15 +0200 From: Graeme Gill <graeme2@argyllcms.com> To: "colorsync-users@lists.apple.com >> ColorSync" <colorsync-users@lists.apple.com> Subject: Re: FOGRA52 & i1Profiler [subject corrected] Message-ID: <0e66500b-08e9-be72-74bd-83befd7fd7e7@argyllcms.com> Content-Type: text/plain; charset=UTF-8; format=flowed Martin Orpen wrote:
Yellow in separations with increased K generation :)
Why ? The nature of the device response is that you can either have lots of yellow or you can have the result being neutral. Take your pick. i.e. the amount of yellow is correct to reproduce the desired color. [ Perceptual response also depends to a degree on the source profile used. ] Cheers, Graeme Gill. ------------------------------ Message: 8 Date: Sat, 9 Sep 2017 15:35:29 +0100 From: Martin Orpen <martin@idea-digital.com> To: "'colorsync-users?lists.apple.com' List" <colorsync-users@lists.apple.com> Subject: Re: FOGRA52 & i1Profiler [subject corrected] Message-ID: <641CB64A-7671-4D76-BA09-616A7A8BADDB@idea-digital.com> Content-Type: text/plain; charset=utf-8
On 9 Sep 2017, at 14:57, Graeme Gill <graeme2@argyllcms.com> wrote:
Martin Orpen wrote:
Yellow in separations with increased K generation :)
Why ?
The nature of the device response is that you can either have lots of yellow or you can have the result being neutral.
Take your pick.
i.e. the amount of yellow is correct to reproduce the desired color.
In print, the result doesn’t look neutral, or natural. If you make a high GCR custom profile from FOGRA52 and proof or print the results to compare them to images separate using PSO Uncoated v2 they do not match and will not get approved by a client. They are too blue. High GCR profiles using the FOGRA47 data work better than those made from 52. If the device demanded blue blacks, why doesn’t the ECI profile generate them? -- Martin Orpen Idea Digital Imaging Ltd ------------------------------ Message: 9 Date: Sat, 9 Sep 2017 14:52:18 +0000 From: Dan Bergstrom <DanBergstrom@primarycolor.com> To: Martin Orpen <martin@idea-digital.com> Cc: "'colorsync-users?lists.apple.com' List" <colorsync-users@lists.apple.com> Subject: Re: FOGRA52 & i1Profiler [subject corrected] Message-ID: <205D2B3C-C8A4-4E06-A8B7-615478A11E59@primarycolor.com> Content-Type: text/plain; charset=UTF-8 Yeah and low TAC will look thin (weak). Also you want each channel to have good shape. -- Dan Bergstrom | Color Technology and Quality | PRIMARY COLOR ORANGE COUNTY http://www.primarycolor.com | T 949 660 7080 C 949 616 4986
On Sep 9, 2017, at 7:35 AM, Martin Orpen <martin@idea-digital.com> wrote:
On 9 Sep 2017, at 14:57, Graeme Gill <graeme2@argyllcms.com> wrote:
Martin Orpen wrote:
Yellow in separations with increased K generation :)
Why ?
The nature of the device response is that you can either have lots of yellow or you can have the result being neutral.
Take your pick.
i.e. the amount of yellow is correct to reproduce the desired color.
In print, the result doesn’t look neutral, or natural.
If you make a high GCR custom profile from FOGRA52 and proof or print the results to compare them to images separate using PSO Uncoated v2 they do not match and will not get approved by a client.
They are too blue.
High GCR profiles using the FOGRA47 data work better than those made from 52.
If the device demanded blue blacks, why doesn’t the ECI profile generate them?
-- Martin Orpen Idea Digital Imaging Ltd _______________________________________________ Do not post admin requests to the list. They will be ignored. Colorsync-users mailing list (Colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/danbergstrom%40prima...
This email sent to danbergstrom@primarycolor.com
------------------------------ Subject: Digest Footer _______________________________________________ Colorsync-users mailing list Colorsync-users@lists.apple.com https://lists.apple.com/mailman/listinfo/colorsync-users ------------------------------ End of Colorsync-users Digest, Vol 14, Issue 36 ***********************************************
Juergen Seitz wrote: Hi,
With F52 it is the first time that we are handling a reference characterization data set which is as far as -10b* from neutral.
but handling paper tints is routine in general ICC print profiling.
The issue is to be found in the typical handling of a white point in the ICC color workflow.
What issue is that ? - I'm not aware of any such issues.
The complete greybalance tips over to this very bluish paper tint and then the CMY-balance gets "out of order" to compensate accordingly.
I got the impression that Martin was concerned about behavior near black, not white, and near black the paper color has very little influence. Graeme Gill.
Dear list. I have a question. A typical print RGB ICC will create contrast curves to match print output to a monitor. When printing on low dMax papers (matte) this contrast curve is higher than on high dMax papers (glossy). My question is this: is there any ICC system out there that you know of that does not create this contrast curve? I’m looking to build entirely linear ICCs where printed contrast of a given image (let’s say an Adobe RGB/Gamma2.2 image) is linear from dMax to dMin. I understand that this will create problems where contrast is perceptible different between matte and glossy papers for any given image, but that is sort-of the point for the project I have in mind. Happy 2018 :) Best, Walker
On Jan 5, 2018, at 10:11 AM, forums@walkerblackwell.com wrote:
A typical print RGB ICC will create contrast curves to match print output to a monitor.
Hmm...that's not exactly correct. Any standard ICC output profile will be designed to match appearance, period. Different media (display, printer, whatever) will have different gamuts, and viewing conditions will potentially differ. How to deal with gamut mismatches (clip, compress, whatever) is controlled by the rendering intent and may well be, in some circumstances, logically equivalent to a contrast curve. Viewing conditions (bright / dim, white point, etc.) can also have similar results; the proper result for bright conditions is (roughly) to lay down more ink (make prints darker) than for dim conditions.
My question is this: is there any ICC system out there that you know of that does not create this contrast curve?
With the caveat that you've just asked a leading question, such that you hopefully understand better with my explanation above...any "serious" CMS should be adjustable to your needs. If you're not afraid of the command line, I can wholeheartedly recommend ArgyllCMS as superlative. You can, if you have a proper workflow, make fine art reproductions that you can lay on a table next to the originals such that the artist herself will have difficulty distinguishing between the two. Plus, it's free and open source...and Graeme Gill, the author, not only has forgotten more about color science than most others will ever know, he's most helpful and responsive. X-Rite is the 800-pound gorilla of the market. Their hardware is superlative. Many speak highly of their software, and they're probably the ones to go to if the command line isn't for you. There're other choices, many of them well worth considering and of significant merit. But Argyll is my unreserved recommendation, and I'd suggest at least having a look at X-Rite if Argyll isn't an option. Cheers, b&
On Jan 5, 2018, at 12:38 PM, Ben Goren <ben@trumpetpower.com> wrote:
On Jan 5, 2018, at 10:11 AM, forums@walkerblackwell.com wrote:
A typical print RGB ICC will create contrast curves to match print output to a monitor.
Hmm...that's not exactly correct.
Any standard ICC output profile will be designed to match appearance, period. Different media (display, printer, whatever) will have different gamuts, and viewing conditions will potentially differ. How to deal with gamut mismatches (clip, compress, whatever) is controlled by the rendering intent and may well be, in some circumstances, logically equivalent to a contrast curve. Viewing conditions (bright / dim, white point, etc.) can also have similar results; the proper result for bright conditions is (roughly) to lay down more ink (make prints darker) than for dim conditions.
This is what I meant in my clunky (match to monitor) terms. Aka, the monitor really should have been “appearance” yes, sorry. I guess my question is, has anyone found a scientifically consistent way to get around this “appearance” match and simply set the output conditions for linear? I have not seen or read this as an explicit workflow in my research . . .
My question is this: is there any ICC system out there that you know of that does not create this contrast curve?
With the caveat that you've just asked a leading question, such that you hopefully understand better with my explanation above...any "serious" CMS should be adjustable to your needs.
So far I have not found this to be the case and I have used just about all of the “major” ones FWIW.
If you're not afraid of the command line, I can wholeheartedly recommend ArgyllCMS as superlative. You can, if you have a proper workflow, make fine art reproductions that you can lay on a table next to the originals such that the artist herself will have difficulty distinguishing between the two. Plus, it's free and open source...and Graeme Gill, the author, not only has forgotten more about color science than most others will ever know, he's most helpful and responsive.
I’ll post on that list thank you.
X-Rite is the 800-pound gorilla of the market. Their hardware is superlative. Many speak highly of their software, and they're probably the ones to go to if the command line isn't for you.
Yes. Have used since before Xrite took over Gretag . . . well, used that too . . . I do inkjet R&D after all. ;) Best, Walker
There're other choices, many of them well worth considering and of significant merit. But Argyll is my unreserved recommendation, and I'd suggest at least having a look at X-Rite if Argyll isn't an option.
Cheers,
b&
On Jan 5, 2018, at 10:52 AM, forums@walkerblackwell.com wrote:
I guess my question is, has anyone found a scientifically consistent way to get around this “appearance” match and simply set the output conditions for linear?
"Linear" by what measure? Ink coverage? Total reflectivity? L*? And what do you expect to happen to out-of-gamut samples -- colors your monitor can create that your printer can't? What's your viewing environment like? If you set the print in that splash of sunlight coming through the window, will you be upset that even the black patch of the print is brighter than the monitor's white? Typically, linearization is something done before profiling, and as a means of improving the consistency and applicability of profiles. As in, linearize printer serial number #3141 and profile BrandName Premiere Photo Matte paper, and the profile should be equally valid for any printer of the same model with that paper paper after it's also been linearized. The measure for linearization doesn't matter so long as it's consistent, doesn't have inversions / discontinuities, and so on. I imagine most manufacturers that implement this feature use total reflectivity. ArgyllCMS has a function I've never personally needed to do something similar with printers that don't support in-printer or in-driver linearization. It would probably also be useful to ask _why_ you want "linear" output. The most common closely-related scenario I can think of would be to send "raw" data to the printer as the first step in creating a profile. "Print without color management" would be the typical phrase...and it can be a real bear, sometimes, to make that happen. The least unreliable and most universal approach is the so-called "null transform" hack: assign the image to a particular profile (doesn't matter) and use that exact same profile for the printer profile. Worst case, if the CMS is even remotely sane, you might get some floating-point rounding going on, but simply breathing on the print will change the color appearance by more than that rounding will. Cheers, b&
On Jan 5, 2018, at 1:15 PM, Ben Goren <ben@trumpetpower.com> wrote:
On Jan 5, 2018, at 10:52 AM, forums@walkerblackwell.com wrote:
I guess my question is, has anyone found a scientifically consistent way to get around this “appearance” match and simply set the output conditions for linear?
"Linear" by what measure? Ink coverage? Total reflectivity? L*?
L* yes. (Only thinking about the neutral and near neutral axis so completely in-gamut).
What's your viewing environment like?
For the sake of this exercise, the viewing environment is the conditions inside of the spectro. Just dMax to dMin (related to tile white) is the only considerations as far as environment is considered. The viewer is the spectro.
If you set the print in that splash of sunlight coming through the window, will you be upset that even the black patch of the print is brighter than the monitor's white?
Typically, linearization is something done before profiling, and as a means of improving the consistency and applicability of profiles.
Yes. I’m talking about linearization as a ink on paper destination not of a target tiff file.
As in, linearize printer serial number #3141 and profile BrandName Premiere Photo Matte paper, and the profile should be equally valid for any printer of the same model with that paper paper after it's also been linearized. The measure for linearization doesn't matter so long as it's consistent, doesn't have inversions / discontinuities, and so on. I imagine most manufacturers that implement this feature use total reflectivity. ArgyllCMS has a function I've never personally needed to do something similar with printers that don't support in-printer or in-driver linearization.
It would probably also be useful to ask _why_ you want "linear" output.
Linear output allows for 100% consistent movement of shadows and highlights in Photoshop. Aka, any input or output shadow changes in a photoshop curve will act the same way as the highlights. When an ICC that does appearance matching is involved, shadow movements are minimized relative to the shadow compression (and can also be de-stabalized related to RelCol) making shadow adjustments to the image unstable and not consistent. I say this as the maintainer and current builder of Piezography which is a linear print output workflow that has been going for about 2 decades now. I’m wondering about how this can be applied to color ink workflows, not just b&w with ink curves.
The most common closely-related scenario I can think of would be to send "raw" data to the printer as the first step in creating a profile. "Print without color management" would be the typical phrase...and it can be a real bear, sometimes, to make that happen. The least unreliable and most universal approach is the so-called "null transform" hack: assign the image to a particular profile (doesn't matter) and use that exact same profile for the printer profile. Worst case, if the CMS is even remotely sane, you might get some floating-point rounding going on, but simply breathing on the print will change the color appearance by more than that rounding will.
Yes. RGB-Space to RGB-Space (null transform). I’m talking about an actual ICC that is created after the fact that prints linear for any given gamma (lets say AdobeRGB/Gamma2.2 for sake of the discussion.) and does work for a given paper/printer/ink. Cheer! Walker
Cheers,
b&
Hi, Am 05.01.2018 um 18:11 schrieb forums@walkerblackwell.com:
A typical print RGB ICC will create contrast curves to match print output to a monitor. When printing on low dMax papers (matte) this contrast curve is higher than on high dMax papers (glossy).
Not sure if there is such a thing as a "typical print ICC" (profile?). The gamut mapping in the perceptual table of print profiles is vendor-specific. It may do a viewing condition adjustment from (assumed or defined) source to destination, or some other transformation, or it may be purely colorimetric with compression (and expansion) of the lightness axis (also known as black point compensation), or something in-between, something entirely different, ... - vendors are free to do whatever. The colorimetric table just maps input (PCS) color to output (device, i.e. RGB or CMYK) values, clipping any out-of-gamut colors (but there are different ways to do this, too).
My question is this: is there any ICC system out there that you know of that does not create this contrast curve?
So you want colorimetric then (probably with BPC so lightness axis is not subject to clipping).
Let’s say we have 18 equidistant values (actual patches in a target) from 0-255 in Photoshop. These would be
[...]
Let’e say our dMax is L* 14.45 on Matte Paper and our dMin (paper white) is L* 96.5
So, Photoshop value of 0 of would be L* of 14.45 and Photoshop value of 255 would be L* of 96.5
What I’m talking about is simple. Is there a consistent way to calibrate with an ICC such that numbers above print like this when measured with a spectro (approximately as the real values have been rounded to 2 decimals):
Sure. The spacing (and meaning) of the values in the source (image) file as outlined mandates the use of a L*-based source profile. It's not related to the output (print) profile at all. But if you were to just assign this source profile to a source (image) file that originally used an encoding with another tone curve characteristic, think again. I.e., wether the values are spaced according to L* is independent of the encoding. It's perfectly possible to have (e.g.) a gamma 2.2 source file with contrast steps being visually equidistant according to L*, you'd just have to space the values accordingly in the file: L* (0..100) -> R=G=B gamma 2.2 (0..255) --------------------------------------- 5 -> 24.03 10 -> 33.18 15 -> 42.17 20 -> 51.71 ... etc. If you were to decode these values according to L*, the contrast steps would no longer be equidistant. You'd have to decode with gamma 2.2 to arrive (again) at the equidistant L* steps. So, all in all, your question seems to be more related to how your source (image) files are created, than the profile(s) used. Florian.
On Jan 5, 2018, at 5:21 PM, Florian Höch <lists+colorsync-users@hoech.org> wrote:
Hi,
Am 05.01.2018 um 18:11 schrieb forums@walkerblackwell.com:
A typical print RGB ICC will create contrast curves to match print output to a monitor. When printing on low dMax papers (matte) this contrast curve is higher than on high dMax papers (glossy).
Not sure if there is such a thing as a "typical print ICC" (profile?).
The gamut mapping in the perceptual table of print profiles is vendor-specific. It may do a viewing condition adjustment from (assumed or defined) source to destination, or some other transformation, or it may be purely colorimetric with compression (and expansion) of the lightness axis (also known as black point compensation), or something in-between, something entirely different, ... - vendors are free to do whatever.
That’s been my problem/observation over the years even though I rely on these vendor specific tweaks every day to keep things simple between different papers types, printers, work spaces, viewing spaces, etc. What I’m trying to do is something entirely different and not industry sanctioned exactly. I guess I’m trying to do a viewing condition "chiropractor adjustment": to create a system for predictably printing values that are aligned from dark to light (as measured in L* D50 from a spectro) and have that calibration happen only in the output ICC while leaving the source image/colorspace alone and without funky curves anywhere else but inside of the ICC . . .
The colorimetric table just maps input (PCS) color to output (device, i.e. RGB or CMYK) values, clipping any out-of-gamut colors (but there are different ways to do this, too).
hmm. I will look into this. Thank you.
My question is this: is there any ICC system out there that you know of that does not create this contrast curve?
So you want colorimetric then (probably with BPC so lightness axis is not subject to clipping).
ok. I will investigate. Thank you.
Let’s say we have 18 equidistant values (actual patches in a target) from 0-255 in Photoshop. These would be
[...]
Let’e say our dMax is L* 14.45 on Matte Paper and our dMin (paper white) is L* 96.5
So, Photoshop value of 0 of would be L* of 14.45 and Photoshop value of 255 would be L* of 96.5
What I’m talking about is simple. Is there a consistent way to calibrate with an ICC such that numbers above print like this when measured with a spectro (approximately as the real values have been rounded to 2 decimals):
Sure. The spacing (and meaning) of the values in the source (image) file as outlined mandates the use of a L*-based source profile. It's not related to the output (print) profile at all.
But if you were to just assign this source profile to a source (image) file that originally used an encoding with another tone curve characteristic, think again. I.e., wether the values are spaced according to L* is independent of the encoding. It's perfectly possible to have (e.g.) a gamma 2.2 source file with contrast steps being visually equidistant according to L*, you'd just have to space the values accordingly in the file:
L* (0..100) -> R=G=B gamma 2.2 (0..255) --------------------------------------- 5 -> 24.03 10 -> 33.18 15 -> 42.17 20 -> 51.71 ... etc.
If you were to decode these values according to L*, the contrast steps would no longer be equidistant. You'd have to decode with gamma 2.2 to arrive (again) at the equidistant L* steps.
So, all in all, your question seems to be more related to how your source (image) files are created, than the profile(s) used.
Florian. _______________________________________________ Do not post admin requests to the list. They will be ignored. colorsync-users mailing list (colorsync-users@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/colorsync-users/forums%40walkerblack...
This email sent to forums@walkerblackwell.com
participants (5)
-
Ben Goren
-
Florian Höch
-
forums＠walkerblackwell.com
-
Graeme Gill
-
Juergen Seitz