No color management

[texshooter]

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?

[nirpat89]

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.

[Mark D Segal]

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.

[texshooter]

  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  (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.

 

[Mark D Segal]

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. 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.

[texshooter]

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.

[Doug Gray]

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.

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.

[texshooter]

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.

[Doug Gray]

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.

[GWGill]

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.

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.)

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.)

[Panagiotis]

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

[GWGill]

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.

[Stephen Ray]

... 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.)

[Mark D Segal]

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.

[digitaldog]

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.

[texshooter]

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.

[digitaldog]

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.

[texshooter]

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)?

[digitaldog]

Let me rephrase.  What information (stimulus) does the printer react to (response)?

For this discussion, a triplet of RGB numbers.

[texshooter]

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?