Luminous Landscape Forum

Raw & Post Processing, Printing => Colour Management => Topic started by: texshooter on February 08, 2018, 11:24:57 pm

Title: No color management
Post by: texshooter on February 08, 2018, 11:24:57 pm
Basic question, but I'm still stumped.

When you print a color test target from the Adobe Color Target Print Utility and with the printer driver set to "No Color Management.", how does the printer know to print blue as blue and yellow as yellow?  Assuming the test image has the Prophoto RGB profile imbeded, how does the printer know that a 255-255-0 patch should be printed from the yellow ink channel?  The printer's color management system was purposefully turned off, so how does the printer know what to do with all the numbers it's fed from the Adobe Target Print Utility without color management to guide it?
Title: Re: No color management
Post by: nirpat89 on February 09, 2018, 06:56:26 am
Basic question, but I'm still stumped.

When you print a color test target from the Adobe Color Target Print Utility and with the printer driver set to "No Color Management.", how does the printer know to print blue as blue and yellow as yellow?  Assuming the test image has the Prophoto RGB profile imbeded, how does the printer know that a 255-255-0 patch should be printed from the yellow ink channel?  The printer's color management system was purposefully turned off, so how does the printer know what to do with all the numbers it's fed from the Adobe Target Print Utility without color management to guide it?
No color management means print 255-255-0 as 255-255-0 and not 254-251-9.  That's all.  ACPU will know what info to send the printer to print the 255-255-0 as an yellow patch.
Title: Re: No color management
Post by: Mark D Segal on February 09, 2018, 08:56:28 am
Basic question, but I'm still stumped.

When you print a color test target from the Adobe Color Target Print Utility and with the printer driver set to "No Color Management.", how does the printer know to print blue as blue and yellow as yellow?  Assuming the test image has the Prophoto RGB profile imbeded, how does the printer know that a 255-255-0 patch should be printed from the yellow ink channel?  The printer's color management system was purposefully turned off, so how does the printer know what to do with all the numbers it's fed from the Adobe Target Print Utility without color management to guide it?

I'm stumped on your question. I have never seen an Adobe Color Target Print Utility. There is simply the Adobe Color Print Utility. Is this what you meant? If so, its sole intention is to work around colour management for printing profiling targets. The colour values (file values) of the patches in the target are sent to the printer without being colour-managed and whatever comes out of the printer is supposed to represent the native behaviour or characterization of the printer. The resulting printed values will likely differ from the file value, which is exactly the information the colour management system needs to know. This information about what the printer prints (read using a spectrophotometer on the printed target) is needed for building a profile which characterizes the printer's behaviour, which in turn assists the colour management system to correct for differences from file values that the printer would print without such management.
Title: Re: No color management
Post by: texshooter on February 09, 2018, 12:31:39 pm
  ACPU will know what info to send the printer to print the 255-255-0 as an yellow patch.

I don't see how that's possible.  A set of RGB values (e.g., 128-128-128 middle gray) without a specified gamma curve (gamma 2.2, 1.8, etc) is gibberish to the printer. The printer needs to know what gamma to interpret the RGB values with, and that gamma curve instruction resides inside the embedded working color space profile, which we deliberately turned off just before printing the target.  So without an encoded gamma curve, I don't see how ACPU knows what to send the printer nor how the printer knows what to receive. 

I understand what Mark said about how the color management system's role is to correct (or improve upon) the printer's first draft. But the printer needs more information than mere sets of RGB values to render a first draft. This video here (https://m.youtube.com/watch?v=jkkEKUZd66A)  (start 7:00) demonstrates that the middle gray 128-128-128 has a *L value of 54 under the sRGB scheme but *L 61 under the ProphotoRGB scheme. Without knowing what gamma the target is, how does the printer know how dark (ie, how much ink density) to print for RGB 128-128-128 middle gray?  First draft notwithstanding.

 
Title: Re: No color management
Post by: Mark D Segal on February 09, 2018, 01:35:13 pm
RGB colours have different numerical values depending on the colour space in which they sit. L*a*b* colours are device independent and each colour has only one unique L*a*b* value. The same L*a*b* value will translate to a different RGB value in an sRGB space versus a ProPhoto space. This article may be helpful: Apple Technical Note (https://developer.apple.com/library/content/technotes/tn2313/_index.html). The goal of colour management is to make an L*a*b* value look as close to the same as possible on a display soft-proof as it will in a print, regardless of what the RGB numbers are for each device. To do that, there is a "translator" from RGB to Lab to RGB embedded in the operating system's colour management module.
Title: Re: No color management
Post by: texshooter on February 09, 2018, 05:23:37 pm
I read the article, and it underscores my point:  "The conclusion to be drawn from this is color values are only meaningful when they are tagged with the proper profile."

Which brings me back to my question, which was perhaps overly open-ended.   Let me ask it like a lawyer would. A yes or no answer only, please (and thank you).

When I print a gray single patch  target through Adobe Color Print Utility with the printer's color management switched off. And that test target has the aRGB profile embedded in it, which means the single gray patch has RGB values of 128-128-128, as well as a LAB value of 54.  What will the printer try to replicate on its first pass?   Will it specifically try to print a gray patch with the LAB value of 54, or will it not?

If your answer is yes, then I will deduce that ACPU does not actually ignore (turn off) the target's embedded aRGB profile. Quite the opposite.  ACPU will instruct the printer to render a gray patch as LAB 54, exactly as the profile prescribed. Hence, color management is not turned all the way off, after all.

Title: Re: No color management
Post by: Doug Gray on February 09, 2018, 05:38:33 pm
I read the article, and it underscores my point:  "The conclusion to be drawn from this is color values are only meaningful when they are tagged with the proper profile."

Which brings me back to my question, which was perhaps overly open-ended.   Let me ask it like a lawyer would. A yes or no answer only, please (and thank you).

When I print a gray single patch  target through Adobe Color Print Utility with the printer's color management switched off. And that test target has the aRGB profile embedded in it, which means the single gray patch has RGB values of 128-128-128, as well as a LAB value of 54.  What will the printer try to replicate on its first pass?   Will it specifically try to print a gray patch with the LAB value of 54, or will it not?
It will not. Targets are not tagged with a colorspace. They are simply RGB values. And, in any case, the ACPU ignores any colorspace that happens to be tagged on the image it prints. It only cares about and sends the RGB bytes. What gets printed, when measured with an appropriate instrument will probably be more or less neutral in color but could vary quite a bit in L*. As an example, there is about a 20 point difference in L* printing (128,128,128) on my Epson and Canon.
Quote

If your answer is yes, then I will deduce that ACPU does not actually disable the target's embedded aRGB profile. Quite the opposite.  ACPU will instruct the printer to render a gray patch as LAB 54, exactly as the profile prescribed. Hence, color management is not turned all the way off, after all.

The purpose of a printer profile is to provide information to an application that understands ICC profiles. The application uses that to determine what are the necessary bytes to send to the printer to print the color.
Title: Re: No color management
Post by: texshooter on February 09, 2018, 06:10:58 pm
It will not. And, in any case, the ACPU ignores any colorspace that happens to be tagged on the image it prints.

In that case, is my following deduction correct?

Printing the following two gray single-patch test targets to the same printer from ACPU with CM turned OFF will yield two printouts with LAB values identical to each other (as measured by a spectrophotometer such as the ColoMunki).

1. Test target patch with RGB 128-128-128 (LAB 54).  This is the target with the embedded aRGB profile.
2. Test target patch with RGB 128-128-128 (LAB 61).  This is the target with the embedded ProphotoRGB profile.

If your answer is yes, then I will deduce that the printer is ignoring the target's LAB values and only accepting its RGB values. And If that is true, I will be confused as to why anyone would want to print a test target from ACPU. The whole point behind printing these two targets (the first in gamma 2.2, the second in gamma 1.8] is to get two printouts that look different. They are different, after all. They even look different when viewed side-by-side on a display. The second is brighter than the first.
Title: Re: No color management
Post by: Doug Gray on February 09, 2018, 06:36:39 pm
In that case, is my following deduction correct?

Printing the following two gray single-patch test targets to the same printer from ACPU with CM turned OFF will yield two printouts with identical LAB values (as measured by a spectrophotometer such as the ColoMunki).

1. Test target patch with RGB 128-128-128 (LAB 54).  This is the target with the embedded aRGB profile.
2. Test target patch with RGB 128-128-128 (LAB 61).  This is the target with the embedded ProphotoRGB profile.

If your answer is yes, then I will deduce that the printer is ignoring the target's LAB values and only accepting its RGB values. And If that is true, I will be confused as to why anyone would want to print a test target from ACPU. The whole point behind printing these two targets (the first in gamma 2.2, the second in gamma 1.8] is to get two printouts that look different. They are different, after all. They even look different when viewed side-by-side on a display. The second is brighter than the first.

Again, the RGB values sent directly to a printer using ACPU or equivalent and color management disabled are not encoded. They don't have a gamma. They don't have a colorspace. They are just RGB values. The printer has a colorspace in the sense that it will print something in response to the RGB values. What it prints is determined by the algorithms that pick what and how many ink drops to plop down. Each printer/paper combination has it's own native "colorspace" which is nothing more than the mapping of the RGB values to whatever it is the printer prints. Of necessity that will vary. A lot. Printer gamuts vary a great deal amongst the various manufacturers, models, and papers. But the whole point of the RGB values not having a pre-defined colorspace is that they can deliver the entire range of colors the printer is capable of. Some may exceed Adobe RGB, others may not even make it in the sRGB gamut. If you were to look at the same target printed by different printers you would see some big variations. Profiles are designed to map well defined colorspaces into what can be printed. They do this by mathematically modeling and interpolating colors of a target against it's native RGB values that created the colors. Then, when an application needs to print L*=50, it can just use the profile to determine what RGB values produces L*50.
Title: Re: No color management
Post by: GWGill on February 09, 2018, 09:13:39 pm
When you print a color test target from the Adobe Color Target Print Utility and with the printer driver set to "No Color Management.", how does the printer know to print blue as blue and yellow as yellow?
Because that's it's job ? i.e. it's job is to turn device dependent color values into prints.

The point of printing those native values out and then measuring them is to create a mapping (Device Profile) between device independent color and that particular printers device dependent values.
Quote
Assuming the test image has the Prophoto RGB profile imbeded,
Why would it have that ? By definition a test image is "in" the native printers device space. i.e. if you were to tag it, it should be with the printers device profile, BUT you are printing the test chart out to characterize the native behavior of the printer to create a device profile for it. (And in fact it would be misleading to tag it with anything - a test chart is always in the native device space of whatever it is sent to - it doesn't have a fixed mapping to device independent space - that's what's special about it.)
Quote
how does the printer know that a 255-255-0 patch should be printed from the yellow ink channel?  The printer's color management system was purposefully turned off, so how does the printer know what to do with all the numbers it's fed from the Adobe Target Print Utility without color management to guide it?
You are not understanding what color management is doing. Color management is typically converting images in one device dependent space into the printers native device dependent space. i.e. this is a (conceptually) two step process, from image to PCS (Profile Connection Space == Device Independent Space) and then from PCS to printer space. Turning off color management skips this and prints the image directly in the native printer space.

(Note that I'm completely ignoring the issue that "printer RGB" is not actually very native to the printer, which is using CMYK + other colorants, but is using some sort of conversion table and print configuration to emulate an RGB like space.)
Title: Re: No color management
Post by: Panagiotis on February 10, 2018, 05:56:03 am
I think I know what you say. If you assign sRGB to a tiff file patch target from iProfiler the colors don't change. So despite that the target is untagged (as it should be) it's values are encoded in sRGB? So is the printer in "Color management" off state expecting sRGB values?

EDIT: This must be related to the subject of the following thread and the null transform which takes place as described in the fifth post by MHMG in this link?
http://forum.luminous-landscape.com/index.php?topic=122831.msg1023376#msg1023376 (http://forum.luminous-landscape.com/index.php?topic=122831.msg1023376#msg1023376)
Title: Re: No color management
Post by: GWGill on February 10, 2018, 08:02:16 am
I think I know what you say. If you assign sRGB to a tiff file patch target from iProfiler the colors don't change. So despite that the target is untagged (as it should be) it's values are encoded in sRGB? So is the printer in "Color management" off state expecting sRGB values?
Nope. By definition a test chart is not encoded in any colorspace except that of the device it is sent to. The point of turning color management off is to ensure that a test chart is treated this way.
Title: Re: No color management
Post by: Stephen Ray on February 10, 2018, 05:27:47 pm
... its sole intention is to work around colour management for printing profiling targets.

Yes, and can also be used to reveal the state of calibration of the printer in its color state before any ICC output profile influence. Much like Onyx, Colorburst, and Roland RIP software (to name a few) provide this opportunity within their setup process. Untagged printer or “quality” evaluation TIFF (usually PDF nowadays) files usually have resolution lines, gray scales, Pantone comparisons, flesh tones, memory colors, etc., to use as visual targets as well as targets for instruments.

Not to derail the thread but, is it safe to say;

“If a print from this evaluation file using “all profiles off” is anything but neutral, the printer in its current state is not calibrated to any standard for the current ink / media.”?

(Standard being at least a neutral gray step ramp black through white.)
Title: Re: No color management
Post by: Mark D Segal on February 10, 2018, 08:17:30 pm

Not to derail the thread but, is it safe to say;

“If a print from this evaluation file using “all profiles off” is anything but neutral, the printer in its current state is not calibrated to any standard for the current ink / media.”?



Professional printers are linearized and calibrated to a common standard (in factory) before they leave the factory. What that standard is and especially what the tolerances are we don't know, haven't been told and are unlikely to be told. But the printers are not meant to be used "all profiles off" unless they are being used with "Printer Manages Color" in which case internal algorithms take over and manage colour, so it's for most purposes a non-issue. With application colour management they must be profiled for each paper to render colours including grayscale more or less correctly.
Title: Re: No color management
Post by: digitaldog on February 11, 2018, 10:30:04 am
I don't see how that's possible.  A set of RGB values (e.g., 128-128-128 middle gray) without a specified gamma curve (gamma 2.2, 1.8, etc) is gibberish to the printer.
It is partially gibberish but the ICC profile defines this and more is (has to be) embedded in the document. No ICC profile, doesn't matter printing without color management, the numbers are sent 'as is' and measured to produce said profile with gamma encoding explained within. As correctly stated, the target has no nor needs no color space embedded for target printing but we need that color space data from this target as the final result of the profile process.
Title: Re: No color management
Post by: texshooter on February 11, 2018, 04:46:27 pm
It is partially gibberish but the ICC profile defines this and more is (has to be) embedded in the document. No ICC profile, doesn't matter printing without color management, the numbers are sent 'as is' and measured to produce said profile with gamma encoding explained within. As correctly stated, the target has no nor needs no color space embedded for target printing but we need that color space data from this target as the final result of the profile process.

So exactly what information does the printer (with CM off) request from the target (untagged)? Doug Gray says "RGB bytes," but I don't know what that means.
Title: Re: No color management
Post by: digitaldog on February 11, 2018, 04:53:03 pm
So exactly what information does the printer (with CM off) request from the target (untagged)? Doug Gray says "RGB bytes," but I don't know what that means.
The printer doesn’t request in this context. It behaves and that behavior is measured.
Title: Re: No color management
Post by: texshooter on February 11, 2018, 04:59:46 pm
The printer doesn’t request in this context. It behaves and that behavior is measured.
Let me rephrase.  What information (stimulus) does the printer react to (response)?
Title: Re: No color management
Post by: digitaldog on February 11, 2018, 05:01:30 pm
Let me rephrase.  What information (stimulus) does the printer react to (response)?
For this discussion, a triplet of RGB numbers.
Title: Re: No color management
Post by: texshooter on February 11, 2018, 05:04:58 pm
For this discussion, a triplet of RGB numbers.

And to confirm, the printer does not respond to gamma curve information nor LAB number triplets? Only RGB numbers?
Title: Re: No color management
Post by: digitaldog on February 11, 2018, 05:07:03 pm
And to confirm, the printer does not respond to gamma curve information nor LAB number triplets? Only RGB numbers?
For this discussion, soft of. Just examine the measurement data. It's Lab.
Title: Re: No color management
Post by: texshooter on February 11, 2018, 05:17:52 pm

The fog is starting to lift.  I had presumed that LAB values were profile-dependent and, thus, cannot exist outside of (or in the absence of) the profile. I will conduct the experiment I discussed in reply #7 to bring it all home.
Title: Re: No color management
Post by: GWGill on February 11, 2018, 06:50:21 pm
I had presumed that LAB values were profile-dependent and, thus, cannot exist outside of (or in the absence of) the profile.
Quite the opposite. LAB are device independent. They correspond to how we see color.

The printer responds to device dependent values like RGB, CMYK etc.

So with a test chart we sent RGB values to the printer, and when we measure them with a color instrument we get the corresponding LAB values. We now have the basic data to make a Device Profile.
Title: Re: No color management
Post by: Mark D Segal on February 11, 2018, 07:17:46 pm
The fog is starting to lift.  I had presumed that LAB values were profile-dependent and, thus, cannot exist outside of (or in the absence of) the profile. I will conduct the experiment I discussed in reply #7 to bring it all home.

What exactly are you trying to "bring home" and how will what you described in Reply 7 do that? Grateful if you could explain, because I'm not "getting it".
Title: Re: No color management
Post by: Stephen Ray on February 11, 2018, 09:41:37 pm
As an example, there is about a 20 point difference in L* printing (128,128,128) on my Epson and Canon.

Meaning their calibration is not the same until the ensuing ICC output profile(s) actually corrects the machines to match one another, which is essentially using output profiles as a calibration process.

Agree?

Title: Re: No color management
Post by: Doug Gray on February 11, 2018, 10:02:02 pm
Meaning their calibration is not the same until the ensuing ICC output profile(s) actually corrects the machines to match one another, which is essentially using output profiles as a calibration process.

Agree?

Exactly.  THe RAW rgb values are used to map to the entire printable gamut. This varies a lot with printers and so the RAW rgb values don't conform to any standard colorspace. They are sui generis, or unique to each printer and paper combination. By printing a target with RAW rgb values the printer can print whatever it is capable of. This is then used to create a printer profile.  Then the various working spaces are first converted to Lab. Those Lab values go through a lookup process using the profile to determine the RAW rgb colors that produce the requisite colors the printer is capable of.
Title: Re: No color management
Post by: Stephen Ray on February 11, 2018, 10:29:39 pm
... a target with RAW rgb values...

So, back to the OP's numbers of 128, 128, 128;  a "middle" gray in the three common RGB spaces, untagged, because they are in fact in the "middle," should print the same with all profiles off?
Title: Re: No color management
Post by: Doug Gray on February 11, 2018, 10:49:47 pm
So, back to the OP's numbers of 128, 128, 128;  a "middle" gray in the three common RGB spaces, untagged, because they are in fact in the "middle," should print the same with all profiles off?
They will print the same color when printed without color management if the printer settings and paper are unchanged. It will typically be close to a neutral color. Profiles are not used when printing w/o color management. Typically, if the RGB values are the same (128,128,128) one can expect the printed color to be close to neutral but it often isn't. When printing a neutral L*=50 with color management the actual RGB values needed to produce a neutral color are used as the profile will determine the correct RGB values for the particular paper in use.
Title: Re: No color management
Post by: Stephen Ray on February 11, 2018, 11:10:45 pm
They will print the same color when printed without color management

I hope this info brings it home for the OP from the perspective of his referenced video.
Title: Re: No color management
Post by: texshooter on February 12, 2018, 12:12:32 am
I hope this info brings it home for the OP from the perspective of his referenced video.

I'm hoping the test results will show that the printer responds to the LAB triplet numbers (per digitaldog) instead of the RGB triplet numbers (per Doug Gray).  I'm hoping my printer can tell the difference between these two targets, because my display surely can.

Title: Re: No color management
Post by: Doug Gray on February 12, 2018, 01:49:08 am
I'm hoping the test results will show that the printer responds to the LAB triplet numbers (per digitaldog) instead of the RGB triplet numbers (per Doug Gray).  I'm hoping my printer can tell the difference between these two targets, because my display surely can.
Printing, with color management disabled, only takes RGB values, not Lab. Lab values do not go from 0-255.

Further, Lab IS a defined color space. The RGB triplets used to print profile targets are not in a defined colorspace. They are interpreted directly by the printer driver in such a way as to map to the range of colors a printer/paper combo can print. They have little to no relationship with any defined colorspace such as Lab, sRGB, ProPhoto, etc.
Title: Re: No color management
Post by: kirkt on February 12, 2018, 08:16:33 am
Pretend you have a printer with a keypad attached to it - via the keypad you can enter an RGB triplet directly in the printer's native color space and the printer will print a color patch as a result.  So, you enter a triplet (say 128, 128, 128) and it prints a patch that is sort of middle gray.  Then you measure that patch with a spectrophotometer and you get a spectral response, characterized as a L*a*b* value.  You compare that result to what you want, or know, that RGB triplet to represent: say the measured result is L*55, a*1, b*1 but the desired result is L*50, a*0, b*0.  You can devise a relationship between the printer's NATIVE response (the patch it printed in response to your input) and the desired response so that when the printer receives an RGB triplet of 128, 128, 128 from the keypad, it will print a patch that measures L*50, a*0, b*0 instead of its native L*55, a*1, b*1 - that relationship is the ICC profile.  Say you could load your mapping relationship (profile) on a hypothetical SD card and plug that card into the hypothetical keypad - then, when you enter 128, 128, 128 on the keypad, the keypad would read the profile from the card, beep boop bop and, via the profile, convert that input triplet in the printer's native space (128, 128, 128) into a modified triplet (say, 123, 124, 125) so that it would result in a printed patch of L*50, a*0, b*0 instead of the native L*55, a*1, b*1.

In color management, the input color space (the RGB triplet) is converted to a device-independent value first (the PCS), so that an RGB triplet in one input space that represents the same color in another space (but with different RGB values) is sent to the printer in its native color space as the same native value.

This is an oversimplification, but the point is, to establish the relationship between the native output and the desired output, you need to know the native output.  This is what you get when you print a target with no color management. 

kirk
Title: Re: No color management
Post by: Mark D Segal on February 12, 2018, 10:05:13 am
Nice way of putting it.
Title: Re: No color management
Post by: nirpat89 on February 12, 2018, 11:37:17 am
Love the sound effects!
Title: Re: No color management
Post by: arobinson7547 on February 13, 2018, 04:50:34 pm
I did not read the whole thread [yet]

but a long time ago the story was told, "The Color of Toast".

See if this helps your conversation, at all.
Title: Re: No color management
Post by: texshooter on February 13, 2018, 05:14:55 pm
The results are in.

I created two step-wedge test targets from Photoshop, one in the ProphotoRGB space and the other in the AdobeRGB space, and then printed each one with color management turned off. Then I measured the zone V middle gray patch with the ColorMunki.

Target #1 =  ProphotoRGB color space.  Notice that Zone V has RGB = 128,128,128 and *L = 61.  And notice how it is visually brighter than the other. This is to be expected because ProPhotoRGB has a 1.8 gamma curve.

(https://farm5.staticflickr.com/4671/38439303600_83c1e87fd4_c.jpg) (https://flic.kr/p/21yKtKN)prophoto (https://flic.kr/p/21yKtKN) by texshooter (https://www.flickr.com/photos/136762677@N06/), on Flickr


Target #2 = AdobeRGB color space.  Notice that zone V has RGB = 128,128,128 and *L = 54.  And notice how it is visually darker than the other. This is to be expected because AdobeRGB has a 2.2 gamma curve.

(https://farm5.staticflickr.com/4602/38439303890_7b9d2da5fb_c.jpg) (https://flic.kr/p/21yKtQN)aRGB (https://flic.kr/p/21yKtQN) by texshooter (https://www.flickr.com/photos/136762677@N06/), on Flickr

So the question is:  How does the printer respond to each of these targets? Does the printer read (respond to) the RGB triplets or the LAB triplets? Will these two target print differently or will they print the same?

The results:  They print the same.  The ProphotoRGB target printed at *L = 32.6 and the AdobeRGB target printed at *L = 32.3, which I will treat as close enough to be the same.

So Doug Gray is right. However, I'm still left confused about one thing. (And by the way, I appreciate all the refreshers on how color management works in general, but my question is more granular than that and is focused to just one step of the process, namely the step where the calibration system tells the printer how the user (me) wants middle gray to appear. Everything else I get.)

If the printer (with CM Off) renders middle gray the same way regardless of the color space (and gamma curve) the target was created in (and intended for), then how does the printer calibration software (eg, ColorMunki) tell the printer how the photographer (me) wants middle gray to appear as? When I use the ColorMunki to profile my printer/paper combo, I don't have a choice of what test target gets printed or whether middle gray should be *L=54 instead of *L=61). The ColorMunki does that automatically. It prints a chevron-shaped strip of patches from its own mystery internal library.   I have no idea how the ColorMunki software is instructing the printer to interpret middle gray. Because I have no control over this, I'm left in the dark and don't know what's going on.  All I know is this:

If I'm working in the AdobeRGB color space in photoshop, I want middle gray to print as *L=54 because that is how it appears on the display. And when I am working in the ProphotoRGB color space, I want middle gray to print as *L=61 because that is how it appears on my display.  The ColorMunki program never asks me which target I wold like to print. It only prints what it wants to print, a one-size-fits-all target, which means that the printer is left thinking that middle gray only has one possible meaning. And that is not true.  I don't understand why it doesn't matter what the gamma curve of the test target is when generating an ICC profile. I would think it matters a great deal. The printer needs to know that "middle gray" does not have only one definition. But that's what the ColorMunki software is telling the printer. Doesn't seem right to me.

Sidebar question:

I know that every printer is imperfect and will tend to print either too dark or too light. That's why we calibrate them.  But in my experiment the zone V middle gray patch printed way darker than it should have. I was expecting a rendering of *L=50 to 60, but got *L= 32.   Is that normal?


Title: Re: No color management
Post by: Stephen Ray on February 13, 2018, 05:53:41 pm
However, I'm still left confused about one thing.

So, what happens when you make prints with PROFILES ON? Do you see the results you're looking for?

PS:  Yes, your printer is way out of calibration.
Title: Re: No color management
Post by: GWGill on February 13, 2018, 06:35:18 pm
The results:  They print the same.  The ProphotoRGB target printed at *L = 32.6 and the AdobeRGB target printed at *L = 32.3, which I will treat as close enough to be the same.
If they don't, then you haven't turned Color Management off.
Quote
If the printer (with CM Off) renders middle gray the same way regardless of the color space (and gamma curve) the target was created in (and intended for), then how does the printer calibration software (eg, ColorMunki) tell the printer how the photographer (me) wants middle gray to appear as?
It doesn't, because Color Management doesn't work that way. Calibration might, but you weren't talking about Calibration up to now.
Quote
I have no idea how the ColorMunki software is instructing the printer to interpret middle gray. Because I have no control over this, I'm left in the dark and don't know what's going on.
Obviously not.

Color Management (http://www.argyllcms.com/doc/ColorManagement.html)

Summary - profiling doesn't change the printer. What it does is give the computer system & applications information about how the printer behaves. The applications then use that to transform images from the colorspace they are tagged with into the printers native colorspace. i.e. the printer always behaves the same - it isn't doing the Color Management.

Quote
I know that every printer is imperfect and will tend to print either too dark or too light. That's why we calibrate them.
So now you are talking about Calibration rather than Profiling. They are quite different things.

Calibration vs. Characterization (http://www.argyllcms.com/doc/calvschar.html)
Title: Re: No color management
Post by: texshooter on February 13, 2018, 06:48:40 pm

So now you are talking about Calibration rather than Profiling. They are quite different things.

Calibration vs. Characterization (http://www.argyllcms.com/doc/calvschar.html)

My ColorMunki only came with one button, not two, so I'd be interested to know what device you use to calibrate with and what device you use to characterize with.
Title: Re: No color management
Post by: Stephen Ray on February 13, 2018, 08:42:27 pm
My ColorMunki only came with one button, not two, so I'd be interested to know what device you use to calibrate with and what device you use to characterize with.

I'm not sure if you've mentioned what printer you are using but I believe you don't need to venture there. Normally, to control the "black box" brains of a professional printer, investment in a third-party RIP is required. If / when you properly create your ICC output profile, it will correct the color values to your liking to the best ability of your system. However, at least you know your printer is "dark" using this particular printer setting, media, and ink at this time. 

Professional printers are linearized and calibrated to a common standard (in factory) before they leave the factory.

Maybe Mark can explain your dark un-profiled print, but I think in the history of the world, no printer mfr who also sells ink has ever calibrated a printer to make a light print. ;-)

Title: Re: No color management
Post by: texshooter on February 13, 2018, 09:13:30 pm
So, what happens when you make prints with PROFILES ON? Do you see the results you're looking for?

When I print the ProphotoRGB target using the ICC profile I made by the ColorMunki, I get *L 57.6  (should be *L 61 according to the info panel in PS)
When I print the AdobeRGB target using the ICC profile (same profile as above), I get *L 51.3  (Should be *L 54 according to the info panel in PS)

This tells me that although the ICC profile has missed its mark, it at least can tell the difference between a ProphotoRGB image (gamma 1.8] and a AdobeRGB image (gamma 2.2). I deduce this because the measured Lab value of the ProphotoRGB print is roughly 6 points higher than the AdobeRGB print, which is in the right direction, thank God.

The how is a mystery.

Sidebar:

Because I don't use an ICC profile when printing to the Epson ABW driver, I was curious to see how the ABW driver would render these two targets.

The ProphotoRGB target printed with *L 52.0  And the AdobeRGB target printed with *L 52.1  Exactly the same!  This tells me that the ABW driver converted the ProPhotoRGB image into AdobeRGB. Or more precisely, gamma 1.8 to gamma 2.2.    That's why they say always to work in gamma 2.2 when planning to print to the ABW driver. You'll never be able to match your print to screen otherwise.

Title: Re: No color management
Post by: Doug Gray on February 13, 2018, 09:14:29 pm
PS:  Yes, your printer is way out of calibration.

No, it's not. Those Lab numbers texshooter measured are not unreasonable. Apart from that printer calibration is something one does with a RIP. RGB calibration requires a service manual and the purpose is to bring the printer into spec so that the canned profiles provided produce accurate prints. It's not something accessible to end users. It's really for things like having the head changed by a manufacturing trained service tech and even then many don't do it if they even know how. If you make your own profiles it really isn't necessary unless you use a RIP which directly controls the CYMK inking. Calibration with a RIP allows you to skip having to create new profiles when the printer drifts.
Title: Re: No color management
Post by: Doug Gray on February 13, 2018, 09:21:30 pm
When I print the ProphotoRGB target using the ICC profile I made using the ColorMunki, I get *L 57.6  (should be *L 61 according to the info panel in PS)
When I print the AdobeRGB target using the ICC profile (same profile as above), I get *L 51.3  (Should be *L 54 according to the info panel in PS)

Au contraire. That's about what you should get. Printed colors are scaled to the paper's white point. If you measure the unprinted paper L* it will be under 100, typically about 95 or 96.  If L* wasn't scaled then high key prints would have their brightest areas clipped to the paper's white point. Not good. If you want to print a specific color exactly, and it's in the printer's gamut, print using Absolute Colorimetric. You will find the L* values increases and will be quite close to the L* you get reading the info in Photoshop.
Title: Re: No color management
Post by: texshooter on February 13, 2018, 09:32:52 pm
Au contraire. That's about what you should get. Printed colors are scaled to the paper's white point. If you measure the unprinted paper L* it will be under 100, typically about 95 or 96.  If L* wasn't scaled then high key prints would have their brightest areas clipped to the paper's white point. Not good. If you want to print a specific color exactly, and it's in the printer's gamut, print using Absolute Colorimetric. You will find the L* values increases and will be quite close to the L* you get reading the info in Photoshop.

Ah, je vois.
Title: Re: No color management
Post by: GWGill on February 13, 2018, 10:11:13 pm
My ColorMunki only came with one button, not two, so I'd be interested to know what device you use to calibrate with and what device you use to characterize with.
OK - so you are a troll. No point in responding any further then.
Title: Re: No color management
Post by: Mark D Segal on February 13, 2018, 10:21:18 pm
OK - so you are a troll. No point in responding any further then.

According to Wiki: In Internet slang, a troll (/troʊl, trɒl/) is a person who sows discord on the Internet by starting quarrels or upsetting people, by posting inflammatory,[1] extraneous, or off-topic messages in an online community (such as a newsgroup, forum, chat room, or blog) with the intent of provoking readers into an emotional response[2] or of otherwise disrupting normal, on-topic discussion,[3] often for the troll's amusement.

Now, this poster is a Senior Member who joined in 2011 with no particular history of "trolling", so not clear to me why you are saying this.

I think this person is trying to understand certain principles of how colour management works and he's not there yet despite some remarkably good responses, including your technical ones, in this thread.
Title: Re: No color management
Post by: nirpat89 on February 13, 2018, 10:41:43 pm
Wow this things still going on...even after the excellent description of kirkt.
Title: Re: No color management
Post by: Mark D Segal on February 13, 2018, 10:56:16 pm
Reply 35 seems to indicate a basic misunderstanding of what matters for the production of targets intended to be used for measurement and the creation of paper/printer profiles. The device independent L*a*b* values in the target reference file are the operational values. These target file values should be printed with no embedded RGB profile. The printer reproduces them in "printer space" thereby characterizing how the printer reproduces those target file values. The spectro is used to read the printed target and create the profile as kirkt described it in his very post above. There is no need and no point to messing with RGB values in targets through this whole procedure.
Title: Re: No color management
Post by: Lundberg02 on February 14, 2018, 12:02:20 am
three pages of restating the obvious, when the OP could have googled it
Title: Re: No color management
Post by: texshooter on February 14, 2018, 12:12:02 am
Reply 35 seems to indicate a basic misunderstanding of what matters for the production of targets intended to be used for measurement and the creation of paper/printer profiles.

I'm going to assume that all printers are programmed from the factory to render RGB 128,128,128 as a shade of gray that is exactly 50% as dark as the darkest shade the printer is capable of printing.  If zero picoliters of ink quantifies the lightest shade the printer nozzle can make, and if 100 picoliters of ink quantifies the darkest shade the printer nozzle can make, then RGB 128,128,128 will land on the page as 50 picoliters of ink.  Without color management, of course.

Whether true or not, this visual helps me.
Title: Re: No color management
Post by: texshooter on February 14, 2018, 12:14:03 am
three pages of restating the obvious, when the OP could have googled it

You presume to understand my question as I intended it.
Title: Re: No color management
Post by: Doug Gray on February 14, 2018, 12:40:09 am
I'm going to assume that all printers are programmed from the factory to render RGB 128,128,128 as a shade of gray that is exactly 50% as dark as the darkest shade the printer is capable of printing.

There is no particular reason for factories to do this. There is only need for consistency for any given printer model. Perhaps in the earliest days of printers before color management was codified something like that occurred.
Title: Re: No color management
Post by: texshooter on February 14, 2018, 12:49:10 am
There is no particular reason for factories to do this. There is only need for consistency for any given printer model. Perhaps in the earliest days of printers before color management was codified something like that occurred.

Since RGB 128,128,128 always prints the same (with CM off) by the same printer. I cant see how the printer knows how dark to render 128,128,128 unless the manufacturer programmed the printer to spit out a predetermined volume of ink for each 128,128,128 pixel.  No?
Title: Re: No color management
Post by: Doug Gray on February 14, 2018, 12:59:30 am
Since RGB 128,128,128 always prints the same (with CM off) by the same printer. I cant see how the printer knows how dark to render 128,128,128 unless the manufacturer programmed the printer to spit out a predetermined volume of ink for each 128,128,128 pixel.  No?
Of course. A manufacturer designs a printer to produce a certain level of repeatability for any given RGB triplet. They just don't much care about forcing it to a specific value when color management is disabled.  It can and does vary with printers and even different paper settings on the same printer.
Title: Re: No color management
Post by: nirpat89 on February 14, 2018, 01:54:04 am
Of course. A manufacturer designs a printer to produce a certain level of repeatability for any given RGB triplet. They just don't much care about forcing it to a specific value when color management is disabled.  It can and does vary with printers and even different paper settings on the same printer.
The printer manufacturer provides accuracy.  Color management provides precision

Yes, no, may be?

_________

Correction:  Should be the other way around.  Caught by kirkt (see post #60 for elaborate explanation.)
Title: Re: No color management
Post by: texshooter on February 14, 2018, 01:55:57 am
Of course. A manufacturer designs a printer to produce a certain level of repeatability for any given RGB triplet. They just don't much care about forcing it to a specific value when color management is disabled.  It can and does vary with printers and even different paper settings on the same printer.

So let's run with that.  Let's say that my specific printer/paper settings combo was preprogrammed to lay down 50 units of ink for every 128,128,128 pixel (with CM off).

Now we feed the printer a sheet of EEF and let Colormunki do its thing. (Actually, two sheets because ColoMunki makes two passes.)

After that is said and done, we now have an ICC profile.

Now let's print out my ProphotoRGB 11-step target with CM turned ON and the above ICC profile selected.  For simplicity sake, let's just print out the zone V patch, the one with an eyedropper value  of RGB 128,128,128 and LAB 61.

If we could examine this print under a microscope, we would no doubt see that the printer did not lay down 50 units of ink like it did when CM was turned off.  On the contrary, the actual number would be greater or fewer than 50 units due to the influence of the ICC profile. Let's say, for the sake of argument, that the ICC profile caused the printer to lay down 40 units of ink instead of 50. Why 40 units, you ask?  Because that's how many units of black ink it took to satisfy the Colormunki. The Colormunki wants middle gray to render a certain way and, by God, it will see it through.

What I want to know is what does the Colormunki think 128,128,128 should look like?  It must have its own definition of middle gray preprogrammed into it by the manufacturer. And this definition of middle gray  must be in units of L*a*b because that's how the Colormunki spectrophotometer see things--in L*a*b.

 It is the nature of this internal preprogrammed definition of middle gray as it exists in the eye of the Colormunki that lies at the heart of my inquiry.

Or is the rabbit hole getting too deep?
Title: Re: No color management
Post by: Doug Gray on February 14, 2018, 02:38:15 am
So let's run with that.  Let's say that my specific printer/paper settings combo was preprogrammed to lay down 50 units of ink for every 128,128,128 pixel (with CM off).

Now we feed the printer a sheet of EEF and let Colormunki do its thing. (Actually, two sheets because ColoMunki makes two passes.)

After that is said and done, we now have an ICC profile.

Now let's print out my ProphotoRGB 11-step target with CM turned ON and the above ICC profile selected.  For simplicity sake, let's just print out the zone V patch, the one with an eyedropper value  of RGB 128,128,128 and LAB 61.

If we could examine this print under a microscope, we would no doubt see that the printer did not lay down 50 units of ink like it did when CM was turned off.  On the contrary, the actual number would be greater or fewer than 50 units due to the influence of the ICC profile. Let's say, for the sake of argument, that the ICC profile caused the printer to lay down 40 units of ink instead of 50. Why 40 units, you ask?  Because that's how many units of black ink it took to satisfy the Colormunki. The Colormunki wants middle gray to render a certain way and, by God, it will see it through.

What I want to know is what does the Colormunki think 128,128,128 should look like?  It must have its own definition of middle gray preprogrammed into it by the manufacturer. And this definition of middle gray  must be in units of L*a*b because that's how the Colormunki spectrophotometer see things--in L*a*b.

 It is the nature of this internal preprogrammed definition of middle gray as it exists in the eye of the Colormunki that lies at the heart of my inquiry.

Or is the rabbit hole getting too deep?

The Colormunki is a spectrophotometer. It measures the percentage of light that is reflected at regular intervals across the visible spectrum. This data is recorded and mathematically transformed using the CIE 1931 human, 2 degree standard observer model which produces 3 values, called X, Y, and Z. These are then converted to Lab.

You can find all the math details and learn much about colorspaces here:
http://www.brucelindbloom.com/

Enjoying the rabbithole?
Title: Re: No color management
Post by: texshooter on February 14, 2018, 02:57:10 am
You can find all the math details and learn much about colorspaces here:
http://www.brucelindbloom.com/

Enjoying the rabbithole?

Too deep for me.
Title: Re: No color management
Post by: Alan Goldhammer on February 14, 2018, 08:18:58 am
My ColorMunki only came with one button, not two, so I'd be interested to know what device you use to calibrate with and what device you use to characterize with.
You can use the ColorMunki to both calibrate (if desired) and profile your printer using the ArgyllCMS software that Graeme Gill developed and maintains.  A useful primer, in addition to the materials on the Argyll website can be found at:  https://www.ludd.ltu.se/~torger/photography/argyll-print.html#toc0

Alan
Title: Re: No color management
Post by: Mark D Segal on February 14, 2018, 08:23:54 am
I'm going to assume that all printers are programmed from the factory to render RGB 128,128,128 as a shade of gray that is exactly 50% as dark as the darkest shade the printer is capable of printing.  If zero picoliters of ink quantifies the lightest shade the printer nozzle can make, and if 100 picoliters of ink quantifies the darkest shade the printer nozzle can make, then RGB 128,128,128 will land on the page as 50 picoliters of ink.  Without color management, of course.

Whether true or not, this visual helps me.

I think I mentioned in a post further up that the printers are linearized and calibrated to a common company standard before leaving the factory and we are not made privy to what those standards are, but if you profile the printer and the profiling works properly we don't need to concern ourselves about this. No matter what they do, printer performance can vary from user to user for a number of different reasons and that is why we do custom profiling.
Title: Re: No color management
Post by: kirkt on February 14, 2018, 09:02:08 am
The printer manufacturer provides accuracy.  Color management provides precision

Yes, no, may be?

The other way around.  The printer manufacturer makes sure that if you feed it an RGB triplet it will print that triplet in a repeatable, well characterized manner so that if you feed it the triplet 100 times, the variation between prints will be small, within some quantifiable tolerance for coverage uniformity, measured reflectance or density, etc.  That is precision, regardless of whether or not that printed value represents what the user desires (the "actual" value).

Accuracy is the printer's ability to print an input that represents a reference value - if you feed the printer an RGB triplet that represents L*50, it should print at L*50.  If it does, it is accurate, if it does not it is not accurate.  Color management and ICC profiles provide the method by which the printer's native color (which is precise and repeatable) gets transformed into an accurate representation of a specific target color - that is, the difference between the print and the reference (usually expressed as deltaE) is within some tolerance.  If the difference between the print and the reference falls within the tolerance, the printer is "accurate."

Think of it this way:  You are sighting in a rifle - you take 5 shots at a target and they are all very tightly clustered (precise) but high and left of the target's bull's eye.  So the rifle is precise (tight cluster of hits) but not accurate (the bull's eye is the reference).  So you adjust the scope via an ICC profile and, when done correctly, the tight cluster of shots is still tightly clustered (precise) but now it is tightly clustered on the bull's eye (accurate).

In this analogy, you do not adjust the rifle (the printer) you adjust the scope (the ICC profile) to optimize the inherent precision of the rifle so that it is both precise AND accurate.

kirk
Title: Re: No color management
Post by: nirpat89 on February 14, 2018, 09:09:04 am
The other way around.  The printer manufacturer makes sure that if you feed it an RGB triplet it will print that triplet in a repeatable, well characterized manner so that if you feed it the triplet 100 times, the variation between prints will be small, within some quantifiable tolerance for coverage uniformity, measured reflectance or density, etc.  That is precision, regardless of whether or not that printed value represents what the user desires (the "actual" value).

Accuracy is the printer's ability to print an input that represents a reference value - if you feed the printer an RGB triplet that represents L*50, it should print at L*50.  If it does, it is accurate, if it does not it is not accurate.  Color management and ICC profiles provide the method by which the printer's native color (which is precise and repeatable) gets transformed into an accurate representation of a specific target color - that is, the difference between the print and the reference (usually expressed as deltaE) is within some tolerance.  If the difference between the print and the reference falls within the tolerance, the printer is "accurate."

Think of it this way:  You are sighting in a rifle - you take 5 shots at a target and they are all very tightly clustered (precise) but high and left of the target's bull's eye.  So the rifle is precise (tight cluster of hits) but not accurate (the bull's eye is the reference).  So you adjust the scope via an ICC profile and, when done correctly, the tight cluster of shots is still tightly clustered (precise) but now it is tightly clustered on the bull's eye (accurate).

In this analogy, you do not adjust the rifle (the printer) you adjust the scope (the ICC profile) to optimize the inherent precision of the rifle so that it is both precise AND accurate.

kirk

Yes, Kirk:  I thought the right way, wrote the wrong way....thanks for catching the obvious booboo.  Your elaboration is perfect!
Title: Re: No color management
Post by: kirkt on February 14, 2018, 09:33:43 am

...

What I want to know is what does the Colormunki think 128,128,128 should look like?  It must have its own definition of middle gray preprogrammed into it by the manufacturer. And this definition of middle gray  must be in units of L*a*b because that's how the Colormunki spectrophotometer see things--in L*a*b.

 It is the nature of this internal preprogrammed definition of middle gray as it exists in the eye of the Colormunki that lies at the heart of my inquiry.

Or is the rabbit hole getting too deep?

The Colormunki has no opinion about how 128, 128, 128 should look.  It is a measuring device.  The output of the system you use to print a target with no color management (the representation of the printer's native output) is measured by the Colormunki and compared to the known target values to form the basis for the ICC profile.  The profiling software is the thing that will compare the target values for each patch (stored in a reference file, usually with a ".cie" file extension) to the measured values you acquired with the Colormunki.

Maybe it is not apparent to you - RGB color spaces are artificial representations of color - you need to know their primaries (chromaticities) and white point to understand how an RGB triplet represents a specific color that we can see.  Because each RGB color space has its own primaries and white point, the color "Cherry Red" might be 235, 15, 35 in one color space and 220, 13, 40 in another - they both are the exact same color, but the RGB triplets are different because they originate in different RGB color models.  This is what makes them DEVICE-DEPENDENT.  In contrast, Profile Connection Spaces (PCS) are based in the physiology of how a "Standard" human observer perceives light of a specific "tristimulus" value - that is, how our visual systems interpret that light.  These physically-based models of color form the basis for our ability to relate various artificial, device-dependent RGB models to each other - as such, they are DEVICE-INDEPENDENT.  Hence the term "profile connection spaces" - the physically-referred PCS can connect one artificial RGB space to another, as long as the relationship between the RGB space and the PCS is known.  It is sort of like Google Translate for color.  Again, I would defer to the color experts here, as I am sure I am oversimplifying.

The printer internals are designed to lay down ink.  How much gets laid down in response to a native RGB input is beyond me, but I assume that printer manufacturers have it figured out pretty well for their ink formulations and media types.  It sounds like you are trying to adopt the Zone System for digital photography and you want to understand how Zone V in your digital image file in Photoshop in a particular RGB color space gets printed to a density of Zone V on a specific printer-paper combination.  Take a deep breath and trust that color management is the way to go about characterizing this relationship.

Your first question should really be, what is Zone V in a device-(in?)dependent definition?  Is it L*50?  Is it the black density that your printer and ink can produce that is halfway between maximum black and paper white?  At least these definitions have a physical meaning, in terms of your destination, which I hope like hell is printed output.

You may want to go to the Piezography.com website and download the free Piezography profiles - you will have no use for them, but in that download there is a user manual that you might want to read, particularly the Grayscale Management section.

Have fun!

kirk

Title: Re: No color management
Post by: Doug Gray on February 14, 2018, 11:06:14 am
You can use the ColorMunki to both calibrate (if desired) and profile your printer using the ArgyllCMS software that Graeme Gill developed and maintains.  A useful primer, in addition to the materials on the Argyll website can be found at:  https://www.ludd.ltu.se/~torger/photography/argyll-print.html#toc0

Alan
Yep.

Torger's printing, measurement, and profiling breakdown is a particularly excellent exposition. Highly recommended to really wrap one's mind around color, printers, and profiling. Just an outstanding piece.

texshooter,
Please review all the comments made by the folks here. They are quite good. Really thoughtful and trying to explain things in various ways. This can be difficult when first going into the gory details. But you are getting really excellent advice. Probably because you are also doing work and have an instrument that you can use and explore with and are willing to do so.
Title: Re: No color management
Post by: joofa on February 14, 2018, 11:52:05 am

RGB color spaces are artificial representations of color

How can all RGB spaces be artificial when CIE did original experiment with an RGB space?

Quote
In contrast, Profile Connection Spaces (PCS) are based in the physiology of how a "Standard" human observer perceives light of a specific "tristimulus" value - that is, how our visual systems interpret that light. 

Original CIE RGB space(s) were "based in the physiology of how a "Standard" human observer perceives light of a specific "tristimulus" value".

And, a frequently used, so called, Profile Connection Space, is XYZ. Which is just another RGB space - after all it is a matrix multiple of CIE RGB space.

Quote
These physically-based models of color form the basis for our ability to relate various artificial, device-dependent RGB models to each other - as such, they are DEVICE-INDEPENDENT.  Hence the term "profile connection spaces" -

There is nothing stopping making CIE 1931 RGB the "profile connection space" (as mentioned it is just a matrix transform away from XYZ). However, some how XYZ has come to be that canonical one.

Quote
the physically-referred PCS can connect one artificial RGB space to another, as long as the relationship between the RGB space and the PCS is known. 

IMHO, no artificiality here in general. CIE did original experiments in an RGB space. That can't be an artificial space! If anything, XYZ could be called artificial in some sense, after all its primaries are outside the visible gamut.
Title: Re: No color management
Post by: kirkt on February 14, 2018, 12:29:43 pm
I think, perhaps, this conflates R, G and B spectral representations of light with R, G and B numerical values in a device-dependent color model.  I should have been more succinct and stated that the color spaces (ProPhoto, AdobeRGB, sRGB) that the OP is referencing.... Again, I am engaging in simplification to explain the general aspects of color management in the context of the OP's query.  I am not qualified to debate the history and physics of color science.

kirk
Title: Re: No color management
Post by: joofa on February 14, 2018, 12:33:18 pm
I think, perhaps, this conflates R, G and B spectral representations of light with R, G and B numerical values in a device-dependent color model.  Again, it is simplification to explain the general aspects of color management in the context of the OP's query.  I am not qualified to debate the history and physics of color science.

kirk

The point is how can XYZ be 'device independent', PCS, and CIE 1931 RGB is not by your estimation. The only difference between them is a matrix transform. Thats all.
Title: Re: No color management
Post by: kirkt on February 14, 2018, 12:35:45 pm
The point is how can XYZ be 'device independent', PCS, and CIE 1931 RGB is not by your estimation. The only difference between them is a matrix transform. Thats all.

See my edit, referencing the OP's color spaces used.

kirk
Title: Re: No color management
Post by: Doug Gray on February 14, 2018, 01:03:43 pm
The point is how can XYZ be 'device independent', PCS, and CIE 1931 RGB is not by your estimation. The only difference between them is a matrix transform. Thats all.

Not the only difference. Standard RGB spaces must first be "de-gammafied," put into linear space, then a matrix transform applied, then re-gammafied to the target RGB space.

Generally, RGB spaces, outside of things like ProPhoto (ROMM) RGB, are designed to approximate something physically realizable for color additive devices like monitors, projectors, and such. The XYZ PCS space is a convenient intermediary but not strictly necessary for RGB space conversions. It's major convenience is that the XYZ values are linear and positive. The CIERGB space requires negative numbers to represent many colors in the human gamut. If one allows negative numbers, any RGB colorspace, even sRGB, can represent all of the CIE gamut colors.

The LAB PCS space is normally used for subtractive color devices such as printers. It make 3D lookup tables feasible. However, the ICC LAB PCS, unlike CIELAB, fails as a general colorspace for additive RGB devices since some of them exceed the limits if ICC LAB PCS which clips a* and b* at -128.
Title: Re: No color management
Post by: digitaldog on February 14, 2018, 01:08:39 pm
How can all RGB spaces be artificial when CIE did original experiment with an RGB space?
Only some like RGB working spaces which are all synthetic (including sRGB of course). Nothing artificial about the RGB ICC profiles for my Epson's.
Title: Re: No color management
Post by: joofa on February 14, 2018, 01:37:32 pm
Not the only difference. Standard RGB spaces must first be "de-gammafied," put into linear space, then a matrix transform applied, then re-gammafied to the target RGB space.

I mentioned standard XYZ and CIE 1931 RGB. I think these spaces don't have a gamma.
Title: Re: No color management
Post by: Doug Gray on February 14, 2018, 01:49:29 pm
I mentioned standard XYZ and CIE 1931 RGB. I think these spaces don't have a gamma.

They aren't, of course, but essentially all RGB spaces in common usage have a gamma or modified gamma.. I actually use a modified Adobe RGB profile with a gamma=1 in Photoshop, but only with high bit resolution. It produces image resizing without the Moire risk.

XYZ also has the advantage that it's self descriptive outside of a global intensity magnitude. Others need to have the primaries specified. Even LAB requires a reference white point (in XYZ) to define a specific color though D50 is typically just assumed.
Title: Re: No color management
Post by: joofa on February 14, 2018, 02:36:42 pm
They aren't, of course, but essentially all RGB spaces in common usage have a gamma or modified gamma..

Yes. However, IMHO, I don't think that adding gamma changes the device independence or dependence characterization.

Quote
I actually use a modified Adobe RGB profile with a gamma=1 in Photoshop, but only with high bit resolution. It produces image resizing without the Moire risk.

That is interesting. I think Bartvander Wolf did some experiments on gamma / no-gamma in image resizing and reported here on LL. I have forgotten what was his prognosis.

Quote
XYZ also has the advantage that it's self descriptive outside of a global intensity magnitude. Others need to have the primaries specified. Even LAB requires a reference white point (in XYZ) to define a specific color though D50 is typically just assumed.

LAB is (mostly) glorified non-linear (gamma-imposed) XYZ color space. But, if one is digging more into color spaces, then there are at least 4 different representations of a 'color space' from the same data / experiments. They are listed here:

Color Space Representations (https://www.dpreview.com/forums/post/60266239)

Usually, the colorimetry community has focused on the representation #1 only. However, others are quite useful for certain calculations. For e.g., here it used to show that a frequent misconception that daylight is green is misconstrued:

Is daylight green? (https://www.dpreview.com/forums/post/59468138)

The interesting thing is that since the 4 representations in the first link are different - would yield different numerics - then what is an 'absolute' color space? One would possibly have to settle that a metameric black color space is the real absolute space. Because, one can't make metameric colors to become suddenly visually differentiated by only using a different mathematical representation.

So all color spaces are 'artificial'  ;D I guess, that could be seen as a generalization of what Kirkt said - though probably not in the way intended.
Title: Re: No color management
Post by: Doug Gray on February 14, 2018, 04:18:32 pm

The interesting thing is that since the 4 representations in the first link are different - would yield different numerics - then what is an 'absolute' color space? One would possibly have to settle that a metameric black color space is the real absolute space. Because, one can't make metameric colors to become suddenly visually differentiated by only using a different mathematical representation.

So all color spaces are 'artificial'  ;D I guess, that could be seen as a generalization of what Kirkt said - though probably not in the way intended.

True, Lots of ways too look at things. The reasonably bright LED flashlight in my hand emits fewer visible photons than my hand, that is holding it, emits invisible photons. Since we can't see the latter, we don't think about them.
Title: Re: No color management
Post by: joofa on February 14, 2018, 04:28:28 pm
True, Lots of ways too look at things.

What is implicit in the definition of a color space, though hardly talked about, is a certain weight function that defines the mapping between radiant energy and color representation via so called 'color numbers'. More on it here:

Color Spaces, CIE and Otherwise - The Hidden Weight Matrix (https://www.dpreview.com/forums/post/58910026)
Title: Re: No color management
Post by: Doug Gray on February 14, 2018, 05:04:55 pm
What is implicit in the definition of a color space, though hardly talked about, is a certain weight function that defines the mapping between radiant energy and color representation via so called 'color numbers'. More on it here:

Color Spaces, CIE and Otherwise - The Hidden Weight Matrix (https://www.dpreview.com/forums/post/58910026)

Well, we benefit from using a canonical form, even with it's imperfections.  I like your point about the subset of metamers remaining metamers regardless of choice of colorspaces.

Getting back to this thread's topic, I looked at three different printer paper combos. A glossy with the Canon 9500II and Epson 9800 as well as a matte with the 9800. The native drivers (w/o color management) printed RGB 128,128,128 as L* 34, 57, and 40 respectively so there is quite a variation in device space RGB printed colors.
Title: Re: No color management
Post by: Stephen Ray on February 14, 2018, 05:37:55 pm
Getting back to this thread's topic, I looked at three different printer paper combos. A glossy with the Canon 9500II and Epson 9800 as well as a matte with the 9800. The native drivers (w/o color management) printed RGB 128,128,128 as L* 34, 57, and 40 respectively so there is quite a variation in device space RGB printed colors.

These discrepancies are explained how?
Title: Re: No color management
Post by: Doug Gray on February 14, 2018, 05:53:00 pm
These discrepancies are explained how?

Native device RGB spaces are somewhat arbitrary and that is somewhat necessary as they have to map all the RGB values to rather non-uniform gamuts. I am not surprised by this. In fact I'd be surprised if they were all quite close.

What matters is how smoothly and repeatedly they operate. Profiles take care of the rest.
Title: Re: No color management
Post by: Stephen Ray on February 14, 2018, 06:23:02 pm
Native device RGB spaces are somewhat arbitrary and that is somewhat necessary as they have to map all the RGB values to rather non-uniform gamuts. I am not surprised by this. In fact I'd be surprised if they were all quite close.

What matters is how smoothly and repeatedly they operate. Profiles take care of the rest.

Are you suggesting printer mfrs, (Canon & Epson in your case) "calibrate" or "pre-set" a few disparate print media of theirs to the values (or thereabouts) that you've measured? Do you imagine most machines leaving the factory would measure close to your numbers for the individual media?
Title: Re: No color management
Post by: Doug Gray on February 14, 2018, 06:39:07 pm
Are you suggesting printer mfrs, (Canon & Epson in your case) "calibrate" or "pre-set" a few disparate print media of theirs to the values (or thereabouts) that you've measured? Do you imagine most machines leaving the factory would measure close to your numbers for the individual media?
They don't set it to the measured values but to a range of colors specific to media and printer. My measurements are just one point on each. Printers of the same make and model and paper will vary only a little from those readings.

For the high end professional printers each printer is individually calibrated and settings stored in the printer's electronics. They may do that as well for lower end machines though it's likely the acceptable tolerances are wider. Manufacturers normally go through cycles of refinement and cost reduction. It may well be cheaper and better to calibrate each printer separately. Alternatively, tighter manufacturing tolerances may allow them to skip the step.

My main point is that there is no special reason for manufacturers to all use the same L*  RGB targets and they clearly do not.
Title: Re: No color management
Post by: Stephen Ray on February 14, 2018, 07:16:41 pm
My main point is that there is no special reason for manufacturers to all use the same L*  RGB targets and they clearly do not.

Thanks for your observations. It would be interesting to learn what others are measuring from the same machine models using the same media.
Title: Re: No color management
Post by: BradSmith on February 14, 2018, 07:20:44 pm

Think of it this way:  You are sighting in a rifle - you take 5 shots at a target and they are all very tightly clustered (precise) but high and left of the target's bull's eye.  So the rifle is precise (tight cluster of hits) but not accurate (the bull's eye is the reference).  So you adjust the scope via an ICC profile and, when done correctly, the tight cluster of shots is still tightly clustered (precise) but now it is tightly clustered on the bull's eye (accurate).

In this analogy, you do not adjust the rifle (the printer) you adjust the scope (the ICC profile) to optimize the inherent precision of the rifle so that it is both precise AND accurate.

kirk

This seems to me to be an excellent analogy of what is going on.  Well done Kirk
Title: Re: No color management
Post by: Doug Gray on February 15, 2018, 01:20:34 am
The other way around.  The printer manufacturer makes sure that if you feed it an RGB triplet it will print that triplet in a repeatable, well characterized manner so that if you feed it the triplet 100 times, the variation between prints will be small, within some quantifiable tolerance for coverage uniformity, measured reflectance or density, etc.  That is precision, regardless of whether or not that printed value represents what the user desires (the "actual" value).

Accuracy is the printer's ability to print an input that represents a reference value - if you feed the printer an RGB triplet that represents L*50, it should print at L*50.  If it does, it is accurate, if it does not it is not accurate.  Color management and ICC profiles provide the method by which the printer's native color (which is precise and repeatable) gets transformed into an accurate representation of a specific target color - that is, the difference between the print and the reference (usually expressed as deltaE) is within some tolerance.  If the difference between the print and the reference falls within the tolerance, the printer is "accurate."

Think of it this way:  You are sighting in a rifle - you take 5 shots at a target and they are all very tightly clustered (precise) but high and left of the target's bull's eye.  So the rifle is precise (tight cluster of hits) but not accurate (the bull's eye is the reference).  So you adjust the scope via an ICC profile and, when done correctly, the tight cluster of shots is still tightly clustered (precise) but now it is tightly clustered on the bull's eye (accurate).

In this analogy, you do not adjust the rifle (the printer) you adjust the scope (the ICC profile) to optimize the inherent precision of the rifle so that it is both precise AND accurate.

kirk

Kirk,
It is the location of the bullseye that varies with printers/papers. My Epson 9800, unlike the Canon 9500 has always printed consistently and it's profiles are quite accurate except at lower luminances. One can reverse the canned profiles of any printer to determine what the printer was designed to print when given an RGB triplet. For instance the 9800 reports it will print L*=32 for RGB 128,128,128 and L*=69 for RGB 200,200,200.  It actually prints L*=34 and L*=69. In other words the 9800 is printing very close to it's design target. The reason the Epson prints L*34 when the canned profile reports 32 is that they incorporate BPC in their A2B1 and B2A1 tables. This is not in accord with ICC specifications but a common practice none the less. The result is reported lower L* than is actually printed at low L* values. It gets much worse lower. It reports L*=0 for RGB 0,0,0 when it should be reporting L*=4, its actual black point.
Title: Re: No color management
Post by: Stephen Ray on February 15, 2018, 02:11:30 am
Is there a benefit of not targeting a logical bullseye of L*50?
Title: Re: No color management
Post by: Doug Gray on February 15, 2018, 02:21:10 am
Is there a benefit of not targeting a logical bullseye of L*50?

I suspect there is. The darker colors are a complex mix of overlapping inks and there could well be more non-linearity in these regions. Lighter colors are more likely to behave more smoothly since there are fewer dot on top of dots as well as more uninked areas. By setting the RGB 128,128,128 at lower L* they leave more room in the device RGB space for dealing with these issues.  But it's just a guess. They clearly are doing it on purpose so it has to provide some benefit.

For what it's worth, the Canon 9500II canned profiles are not nearly as accurate as the Epson and the actual printer colors for RGB 128,128,128 are a fair amount lower than the canned profiles indicate which is over 50. Another factor that might be at play is the black point of the 9500 is quite high, close to L*=8 on their glossy media.
Title: Re: No color management
Post by: kirkt on February 15, 2018, 10:33:54 am
The bull's eye/rifle analogy was to describe precision versus accuracy, not something specific about a particular printer.  Hopefully it was helpful.  Precision and accuracy get used interchangeably in colloquial use, but they have specific definitions in engineering and scientific context (i'm an engineer). 

kirk
Title: Re: No color management
Post by: Doug Gray on February 15, 2018, 11:43:49 am
The bull's eye/rifle analogy was to describe precision versus accuracy, not something specific about a particular printer.  Hopefully it was helpful.  Precision and accuracy get used interchangeably in colloquial use, but they have specific definitions in engineering and scientific context (i'm an engineer). 

kirk

kirk,

Your bullseye analogy is quite good but invoked some additional discussion as to the fact that each printer maker has, for whatever reasons, targeted their unmanaged color RGB space differently so the RGB 128,128,128 does not produce L*=50. People naturally think of a bullseye as centered and hence should target L*=50. whereas each printer design may and do have different mappings. However, it's also obvious from your comments you know this and were not implying that RGB 128,128,128 should produce L*=50. I found your comments quite clear and well stated.


As an aside, here's one way to identify how a manufacturer maps their RGB device space if, for instance, we wish to know what color a printer is designed to print 128,128,128 as.

1. Create an image patch in Photoshop filled with RGB 128,128,128.
2. Assign the printer/paper profile to that image.
3. Convert the image to Lab colorspace using Abs. Col. Intent.
4. Examine the Lab value. This is what the printer manufacturer has targeted.

To the extent wear and tear, manufacturing variations, and such come into play the printer actual color printed may vary from this. Custom profiles provide a way to compensate for these.
Title: Re: No color management
Post by: Stephen Ray on February 16, 2018, 03:18:26 pm
What I am finding from cursory checks around the inter webs is L* targets for middle gray, either 128 or 50% dot is from ~ L*50 to L*60. Some sources is a research paper from CalPoly about G7, various RIP targets, and performing Doug’s method of tagging printer profiles then converting them to LAB using Abs Col Intent. The profiles I tested are Canon IPF1000 provided for popular 3rd party papers. Apparently the IPF1000 has an on-board calibration process. Maybe most pro printers from Canon have this now. I don’t know.

I’ve just spent exactly 1 minute at Canon’s “Experience Center” showroom, repair and customer service facility but no one was available to answer a technical question at the technical center. So much for that, however I will return soon just because it’s walking distance. My “experience” was short of what my expectations would have been years ago but nowadays I expect my experience to be exactly what it was this morning. Quote, “Please check our website. Please come again.” Epson announced last year they want to build a showroom. May be my next stop.
Title: Re: No color management
Post by: Doug Gray on February 16, 2018, 06:03:15 pm
Good idea to keep in mind that L*=50 is only 18% reflectance or about 20% of what is reflected off unprinted paper.

No idea why some manufacturers chose higher or lower points. I've looked at a few Canon's and they are all just over 50. Epsons tend to be under 40. I think it just depends on how the designers decide to do the rasterization.

An important question outside the neutral colors: What is the color difference distribution for single bit changes across the device RGB space. At least for 8 bit drivers. And how does the L* target influence this distribution?

Curious as to what info and rationale you get from your inquiries.
Title: Re: No color management
Post by: nirpat89 on February 17, 2018, 06:26:27 am
As an aside, here's one way to identify how a manufacturer maps their RGB device space if, for instance, we wish to know what color a printer is designed to print 128,128,128 as.

1. Create an image patch in Photoshop filled with RGB 128,128,128.
2. Assign the printer/paper profile to that image.
3. Convert the image to Lab colorspace using Abs. Col. Intent.
4. Examine the Lab value. This is what the printer manufacturer has targeted.

To the extent wear and tear, manufacturing variations, and such come into play the printer actual color printed may vary from this. Custom profiles provide a way to compensate for these.

Doug: 

I thought I will try this sequence and see what happens.  It would be interesting to do this on various printers and papers and compare.

1 and 2, I understand.  In 3, for converting to Lab, Photoshop simply converts to Lab (image>mode>check Lab.  There is no option for intent.  Is there an another way?

Anyway, if I simply have a block of 128-128-128, assign it a printer profile and change the mode, the results are as attached.
The end result is a Lab of 44, -3, -2.

Does that sound right?  Wouldn't this number be representative of what Photoshop sends to the printer and not what the printer print it as.  I am not understanding it.

I used the profile provided by the paper manufacturer (Canson Rag Photographique on Epson SC P400.) 

:Niranjan.

Title: Re: No color management
Post by: Doug Gray on February 17, 2018, 11:01:37 am
1 and 2, I understand.  In 3, for converting to Lab, Photoshop simply converts to Lab (image>mode>check Lab.  There is no option for intent.  Is there an another way?

Yes, Edit->ConvertProfile, This will give you conversion options. The Image->mode>Lab does not use Absolute Intent and has no conversion options.
Title: Re: No color management
Post by: nirpat89 on February 17, 2018, 09:42:05 pm
Yes, Edit->ConvertProfile, This will give you conversion options. The Image->mode>Lab does not use Absolute Intent and has no conversion options.
Got it.  Did it that way.  Now the block is (46, -3, -1).