Interesting study from Ryerson University on expanded color gamut printing.

[Correct Color]

Erik,

Working in different spaces seems to me to be a problem and particularly the destination space.

Sorry, but it sounds to me like you're a fine engineer, but that your knowledge of image reproduction may be a little spotty.

It is at least conceivable to combine image creation spaces and image working spaces into one "vision space" such as XYZ or L*a*b*.

It is not possible to extend that to destination spaces.

An image is a part. Once an image is colour corrected and modified to the point where someone says, that is what I want, then it should have a specification of its colour. It could be designed with a single set of accurate colour values such as XYZ. It is then up to the printers (manufacturers) to reproduce that image as close as possible based on an accurate colour description of that image.

Yes. And that's what color management does.

The thread which we have completely derailed here now has to do with profiling offset printing inksets that include the colors Cyan, Magenta, Yellow, Black, Orange, Green, and Violet.

To start, you cannot send XYZ or L*a*b* data to these or any other printers and get a print. You have to send the data in such a way as to use the CMYKOGV colorants.

Let's say you've achieved your ends and we're using XYX. We now have to convert the XYZ image to a CMYKOGV image. There's no other way. Are we at least agreed on that?

Okay. How do you do that?

But before you decide just on that, there is much more.

This image we're converting to CMYKOGV isn't just printing on this press. It's part of an ad campaign and it's going to be on billboards, on busses, in magazines, printed on banner stands at trade shows, on the internet.

None of these processes are likely to be CMYKOGV. The billboards, busses and magazines are all going to be CMYK. The fabric flags may be some bizarre inset with turquoise in place of cyan, and a couple other weird primaries as well. That means that this image converted to CMYKOGV will not print to any of these applications. So it has to be converted to CMYK or some other inkset. However... The CMYK primaries for none of these processes are going to be the same. The printing processes for all of these destinations are going to be different; the printing resolutions for each of these processes are going to be different; the single and multi-channel ink loads for each of these processes are going to be different; the white points for all these media are going to be different, and the reflectivity of all these media is going to be different.

And then there's the web, which uses sRGB as a pretty much universal standard. You can't display an XYZ image on the web, so you'll at least have to convert to RGB. If you want to have any chance of displaying correctly, you'll have to convert to sRGB, and then still... you're at the mercy of every individual monitor on which your image will be viewed. They all diplay at least somewhat differently, about 99 percent of them have never been profiled, and most of the ones that were profiled were profiled incorrectly.

That's the issue faced in the business of reproducing color. The only way you have any hope of maintaining color fidelity to your original image is to devise a process to determine how each one of these machines reproduces color, characterize that machine in that state, and then convert your image to that characterization at print time.

Believe me, there are no end of people out there who don't quite get it; who think there should be an easier way; who curse guys like me for "inventing" this process.

But this process isn't an invention. It's a response to existing conditions and those conditions cannot change.

Your image may indeed be a part, but every single means of reproducing it for viewing is going to vary somewhat from every other means. In order for it to look the same on all, you have to have a characterization of each means, and then convert the image to that characterization.

There is no other way.



Mike

 

[gordo]

Gordo,



Well the way I'd describe it:

Individual CMYK channels have no L*a*b* information in them at all. Because they're not L*a*b*; they're CMYK.

They have L* values because the channels are greyscale.

If you have a CMYK image that is, let's say, a solid color that is C=40 M=30 Y=20 K=10, then the individual pixels in each channel would be 40, 30, 20, and 10 percent coverage. But those numbers relate only to the amount of that colorant in that colorspace for that color. They don't relate to anything else.

With RGB or CMYK the tone values of each greyscale channel is combined to give you the color. That is also what happens on the press.

True, if you view any of those channels individually in Photoshop, it displays them as black. But that's just for viewing purposes.

It's because that's what they are - greyscale. In the RIP each greyscale channel is passed through a threshold array in order to create the halftone dots that will be burned to plate for the press. Each binary (pseudo) greyscale channel is then assigned an ink color and then the four (pseudo) greyscale channels are recombined on the press to create the composite image - basically the same thing that PhotoShop does.
AFAIK there is no way to create halftone dots from L*a*b* pixel values.

Photoshop does the same thing with RGB or L*a*b*. View them any way but individually, however, and they show up as their actual colors.

Of course. That's what combining greyscale images that have been assigned colorants will do.[/QUOTE]

 

[Correct Color]

Gordo,

In large-format inkjet printing these days, some marketing genius somewhere -- I'm not sure who's to blame, all the manufacturers have adopted the term -- has decided to call multiple-dot-size printing capability as "greyscale."

I rail against this, since it co-opts a term that already has a perfectly fine and straightforward meaning in our industry and adds another completely different meaning that as far as I'm concerned, makes very little sense.

I'm railing a little too, here, I guess. Thinking on it a bit, I can see why it is at least defensible to think of each individual colorant channel in any digital image as a "greyscale" image. They are after-all monochromatic in the sense that they have no colors save their actual color. But I've never thought of them that way myself, and I don't think I'll start now.

To me they're not greyscale images because that is not their function.

I also teach that the terms CMYK and RGB have dual meanings in this industry. Most people think of them as processes only. That why many people to this day still say, "My press/printer is CMYK, so I need to send it CMYK.

Well, then how is it your monitor is RGB but it will display a CMYK file just fine?

The answer is that when talking about digital files, RGB and CMYK don't describe processes; they describe pixel definitions. And some certain working RGB or CMYK colorspace that you might happen to have a file in in Photoshop is really kind of irrelevant, unless at print time you intend to pass the file through to the printer un-color managed. Because when the image goes through color management, either to the monitor or through a RIP, the only value of each pixel that matters is the L*a*b* value. The colorspace it is in is only a roadmap for color management engines to get to that L*a*b* value.

It's because that's what they are - greyscale. In the RIP each greyscale channel is passed through a threshold array in order to create the halftone dots that will be burned to plate for the press. Each binary (pseudo) greyscale channel is then assigned an ink color and then the four (pseudo) greyscale channels are recombined on the press to create the composite image - basically the same thing that PhotoShop does.

I can see that happening as a pass through. I cannot see it happening if you use color management.

AFAIK there is no way to create halftone dots from L*a*b* pixel values.

But that's exactly how printing dots are created.

Way back when -- if I recall the was actually preached in "Real World Color Management" -- it was thought to be a very bad idea to convert from one CMYK color space to another, because you had to account for the black generation strategy in the first color space when making the move. But in actuality, this isn't true. Because regardless of the black generation strategy in any profile, the L*a*b* value of any pixel remains the same, and it's the L*a*b* value that matters. Nothing else.

RIP's convert pixels into dots. They do that using information in profiles.

When I -- or anyone else -- make a printer profile, the idea is to create a machine state, which is a definition of all the variables that relate to printing with a particular ink using a particular machine on a particular media, and then to make a characterization of that machine in that state. That characterization is the ICC profile.

In order to create the characterization file, a set of patches are printed pass through -- with no color management applied -- to the machine in the state you're characterizing. The patches are combinations of raw values in whatever inking configuration the machine happens to be.

Assuming it's CMYK, then each patch is some combination of CMYK values. Let's say there's a patch that's C=40 M=30 Y=20 K=10. The RIP prints that patch, then when you read it with a spectrophotometer, you'll get a L*a*b* value; let's say for demonstration purposes in this case it's L=62 a=0 b=-9.

Then what happens is that using the profile you've created here, when the RIP sees a pixel that has the L*a*b* value L=62 a=0 b=-9, it knows to create the dots C=40 M=30 Y=20 K=10.

The ICC profile-making engine does that calculation on every patch in the patch set, and interpolates missing colors.

So, whatever the individual colorant channels were in the incoming files, they will not be reproduced by color management with their CMYK definitions unchanged. They won't be used at all by the RIP except to use them as a map to get to their L*a*b* values based on how the incoming color space was defined to the RIP. It will then create printing dots to recreate that L*a*b* value in the destination color space.



Mike

 

[Deleted member 16349]

To start, you cannot send XYZ or L*a*b* data to these or any other printers and get a print. You have to send the data in such a way as to use the CMYKOGV colorants.

Let's say you've achieved your ends and we're using XYX. We now have to convert the XYZ image to a CMYKOGV image. There's no other way. Are we at least agreed on that?

Okay. How do you do that?

But before you decide just on that, there is much more.

This image we're converting to CMYKOGV isn't just printing on this press. It's part of an ad campaign and it's going to be on billboards, on busses, in magazines, printed on banner stands at trade shows, on the internet.


Your image may indeed be a part, but every single means of reproducing it for viewing is going to vary somewhat from every other means. In order for it to look the same on all, you have to have a characterization of each means, and then convert the image to that characterization.

True, I am a simple engineer and what I try to do is think of what the simplest way is to solve a problem.

I never said anything about sending XYZ values to a printer. Any printing device has input values and output values for a specific set of conditions. Hopefully the device is consistent enough.

The input values to a digital printer can be quite arbitrary. They don't even need to have the same number of inputs for the number of ink channels. One might as well call the inputs to a digital printer, input1, input2, etc. The input names don't really need to have a direct relationship to the output colour.

With offset, it is a bit more constrained, since the inputs are the total combination of screens one can print with n number of inks. Yes, if you map the outputs to the inputs, with respect to a set of conditions such as paper, screen, densities, ink sets, etc. then one should get a reasonably predictable process.

Yes, this characterizing the output to the input must be done for any imaging device. But at least if one uses XYZ for the image, one knows what one is aiming at.

So what is needed? There is a need for very fast characterizations of how devices print or display colour. New technology for print that can measure large numbers of patches ( say 10,000) at one time, easy and fast. Large data bases, basically ICC. I just suggest that it is done in XYZ.

Back to the Ryerson study. They seem to have use basically a very direct method to print the spot colours based on a custom profile but they used Lab for spot colours. They could have done it with XYZ, I guess, and got the same result.

I still think the Ryerson study has a lot of value but it depends on how one looks at it.

 

[gordo]

I'm railing a little too, here, I guess. Thinking on it a bit, I can see why it is at least defensible to think of each individual colorant channel in any digital image as a "greyscale" image. They are after-all monochromatic in the sense that they have no colors save their actual color. But I've never thought of them that way myself, and I don't think I'll start now.

The individual channels do not have color (a*b*) values. They do have tone values (L*)

To me they're not greyscale images because that is not their function.

Your definition of their function does not determine whether they are greyscale images or not. The channels are greyscale because they are made from a range of monochromic (grey) tones. They only contain Luminance (lightness) information and no color information. They are achromatic.

I also teach that the terms CMYK and RGB have dual meanings in this industry. Most people think of them as processes only. That why many people to this day still say, "My press/printer is CMYK, so I need to send it CMYK.

Well, your students are correct if the output device uses CMYK colorants. And whatever you send to that output device will end up being CMYK. Where, and when that conversion takes place is another matter.

Well, then how is it your monitor is RGB but it will display a CMYK file just fine?

The answer is that when talking about digital files, RGB and CMYK don't describe processes; they describe pixel definitions.

RGB and CMYK refers to the number of greyscale channels that make up the composite image. I.e. a CMYK image has 4 channels while a CMYKOG image has 6 channels.

On a sidebar, early color photography made use of greyscale channels to make color images. They'd take 3 greyscale ("black and white") photos - each with an R, G, or B filter in front of the lens. Compositing those three greyscale images would result in a color image. It's the same basic principle used in today's digital cameras.

(SNIP)

And some certain working RGB or CMYK colorspace that you might happen to have a file in in Photoshop is really kind of irrelevant, unless at print time you intend to pass the file through to the printer un-color managed. Because when the image goes through color management, either to the monitor or through a RIP, the only value of each pixel that matters is the L*a*b* value. The colorspace it is in is only a roadmap for color management engines to get to that L*a*b* value.

I can see that happening as a pass through. I cannot see it happening if you use color management.

But that's exactly how printing dots are created.

Printing dots, if we're talking about halftone dots, are not created from L*a*b* values. I cannot speak for inkjet printers.

Way back when -- if I recall the was actually preached in "Real World Color Management" -- it was thought to be a very bad idea to convert from one CMYK color space to another, because you had to account for the black generation strategy in the first color space when making the move. But in actuality, this isn't true. Because regardless of the black generation strategy in any profile, the L*a*b* value of any pixel remains the same, and it's the L*a*b* value that matters. Nothing else.

I think I agree.

RIP's convert pixels into dots. They do that using information in profiles.

They convert pixel tone values of individual separated greyscale channels into dots using a threshold array.

When I -- or anyone else -- make a printer profile, the idea is to create a machine state, which is a definition of all the variables that relate to printing with a particular ink using a particular machine on a particular media, and then to make a characterization of that machine in that state. That characterization is the ICC profile.

In order to create the characterization file, a set of patches are printed pass through -- with no color management applied -- to the machine in the state you're characterizing. The patches are combinations of raw values in whatever inking configuration the machine happens to be.

Assuming it's CMYK, then each patch is some combination of CMYK values. Let's say there's a patch that's C=40 M=30 Y=20 K=10. The RIP prints that patch, then when you read it with a spectrophotometer, you'll get a L*a*b* value; let's say for demonstration purposes in this case it's L=62 a=0 b=-9.

Ok

Then what happens is that using the profile you've created here, when the RIP sees a pixel that has the L*a*b* value L=62 a=0 b=-9, it knows to create the dots C=40 M=30 Y=20 K=10.

The ICC profile-making engine does that calculation on every patch in the patch set, and interpolates missing colors.

The C=40 M=30 Y=20 K=10 you reference are tone - not color - values (i.e. greyscale) for an area for each channel. Then the resulting greyscale channels are individually passed through a threshold array to become halftone screened binary images. Which are then burned to plate to be printed.

So, whatever the individual colorant channels were in the incoming files, they will not be reproduced by color management with their CMYK definitions unchanged. They won't be used at all by the RIP except to use them as a map to get to their L*a*b* values based on how the incoming color space was defined to the RIP. It will then create printing dots to recreate that L*a*b* value in the destination color space.

Mike

Assuming CMYK, it may alter the tonal values of the individual greyscale channels in order to have the RIP generate halftone dots that, when printed as a composite, result in the target L*a*b* value(s). If the source is an RGB image then the determination of the tone values of the individual generated 4 greyscale channels happens during the conversion from RGB to CMYK.

 

[Correct Color]

Well then...

The individual channels do not have color (a*b*) values. They do have tone values (L*)

All L values are tone values. Not all tone values are L values. L values are values corresponding to a specific color space (some variant of L*a*b*.) Tone values in a single pixel of an image do not do this. A 100% pixel in the magenta printer of an image does not correspond to L=0. It does not correspond to any color space. It merely means 100%.

Your definition of their function does not determine whether they are greyscale images or not. The channels are greyscale because they are made from a range of monochromic (grey) tones. They only contain Luminance (lightness) information and no color information. They are achromat

I suppose my main problem with this is that basically, it's irrelevant. The digital world works with pixels. Thinking in these terms obfuscates that, in my opinion.

Well, your students are correct if the output device uses CMYK colorants. And whatever you send to that output device will end up being CMYK. Where, and when that conversion takes place is another matter.

So I assume here you're either trolling a bit or being deliberately obtuse. Since there isn't any way to actually send print language information to a printing device -- such as an RTL file -- without passing it through some mechanism to create that file, it's universally accepted linguistic shorthand that sending a file to the printer means sending it to that mechanism, be that the "black box" in a desktop printer or a RIP.

And assuming proper color management is in place that mechanism doesn't care whether that file is RGB or CMYK, because the RGB of CMYK values are only pointers in a particular color space to the L*a*b* value of that pixel.

RGB and CMYK refers to the number of greyscale channels that make up the composite image. I.e. a CMYK image has 4 channels while a CMYKOG image has 6 channels.

On a sidebar, early color photography made use of greyscale channels to make color images. They'd take 3 greyscale ("black and white") photos - each with an R, G, or B filter in front of the lens. Compositing those three greyscale images would result in a color image. It's the same basic principle used in today's digital cameras.

Yeah, well... Here's the thing: I'm an old-timer too. Older than you, I'd wager. But all that stuff is from another era. Yes, RGB and CMYK 'could' refer to greyscale channels. But today, they're considered pixel values. While it's not incorrect to say they're components of greyscale images, it's also not incorrect -- and more precise in digital imaging -- to say they are the primary color values in the smallest unit of complete color information in a digital image, which is a pixel. They are understood in digital imaging as pixel values. And unless you’re photo-setting type, shooting images on film, using a process camera, stripping it all together and burning plates, up until the moment you physically create the plates, you’re imaging digitally.

Printing dots, if we're talking about halftone dots, are not created from L*a*b* values. I cannot speak for inkjet printers.

Yes. They are.

They convert pixel tone values of individual separated greyscale channels into dots using a threshold array.

No. Think about it a bit. This entire discussion basically assumes a single-profile CMYK tif image converted to another CMYK profile. But that seldom happens these days. A typical print file these days is going to be a PDF that might include some named spot color elements, some CMYK images, and maybe some RGB images as well. What "individual separated greyscale channels" is the RIP going to use in this instance to get to the final colorspace?

What you're describing is the way this was all done and thought of when separations were made with a process camera, and plates were burned analog. And that's all well and good, and it's not exactly wrong to think that way. But it's not greyscale images that do the work digitally.

It's pixels.

RIP's convert the L*a*b* values of individual pixels into printing dots using a threshold array; something has to create the dots, I'm not denying that. I'm saying it's individual pixel values that the RIP uses, not greyscale images.

The C=40 M=30 Y=20 K=10 you reference are tone - not color - values (i.e. greyscale) for an area for each channel. Then the resulting greyscale channels are individually passed through a threshold array to become halftone screened binary images. Which are then burned to plate to be printed.

"...for an area of each channel." Yeah, that "area" would be a .... pixel. Which is what the RIP processes.

Assuming CMYK, it may alter the tonal values of the individual greyscale channels in order to have the RIP generate halftone dots that, when printed as a composite, result in the target L*a*b* value(s).

And here's where your argument falls completely down. Using a RIP and using color management, you can process RGB or CMYK images equally. Why? Well, provided the RIP was accurately told the actual RGB or CMYK colorspace of every image, then the RGB and CMYK definitions of the pixels in the files are roadmaps to the correct L*a*b* value for those pixels; so it can then map those pixel values to corresponding colorant values in the destination color space -- which is the printer profile.

If the source is an RGB image then the determination of the tone values of the individual generated 4 greyscale channels happens during the conversion from RGB to CMYK.

How?

Converted to 'what' CMYK?

Are you saying it's converted to some intermediate CMYK space used for greyscale creation purposes? Why? And what if the gamut of that CMYK space is smaller than the destination color space, or what if it has a different white point? And what values for the incoming RGB colorspace does the RIP use to make this conversion?

Or are you saying the conversion is to the destination color space? If so, if there's only one conversion — to the destination space — then why not use that same process for CMYK?


RIP's convert pixels (not greyscale images) into dots.

(If you won't take my word for it, maybe you'll take Adobe's. That's not a graphic of a gresycale image being turned into a dot there. And I'll add I've been using that RIP description far longer than they've been using that logo. My consultant's fee check has yet to arrive.)

They convert pixels into dots using information in profiles. That information includes definitions of a particular machine state and a characterization of a machine in that state. However those dots are then transferred to media, that’s how it works.




Mike

 

[Andy_warp]

We run dye sublimation which is a weird monster. Mr. Adams inadvertently provided enough bread crumbs for me to follow through various forums to achieve some semblance of color management. Thanks Mike! Check is in the mail! I already knew how to do density readings and set up ink limits, so his invaluable info really tied it together for me.

I had never thought of the channels as grayscale until running a rip with grand format inkjet printing. Our old hp scitex accepted (8) 1 bit tifs to make each print file. I had a reprographics background, so 1 bit images made sense to me from dealing with converting grayscale images to group 4 tifs in Photoshop. (With dithering)

My printer came with the option of orange and violet to expand the gamut, however the manufacturer did not have much success rolling it out universally. My understanding was that it was kind of a diminishing return. The added effort for profiling and keeping the extended colors printheads clear was the issue. They basically told me the extended gamut wasn’t needed unless you were securing a giant contract for Home Depot! Lol! This was a little disappointing for me as the gamut in dye sub is notoriously small. What I lack in gamut is made for in consistency. I can literally run “patches”

I still battle every day with my customers about the best way to preserve their color info. It really IS all about minimizing color space changes and profile swaps. Many just don’t understand what a rip does. I encourage them to leave everything as rgb as long as possible...and let the rip do the conversion. Once. When asked what the difference between rasterizing in Photoshop to the rip I just tell them it’s more accurate with less conversion or chance of unneeded profile interference. It will always be that way until someone invents an inkjet that prints square dots. Don’t get me started on how differently indesign and illustrator render and handle the same frigging spot colors. In this format of printing we have the added nightmare of file compression. It really is the bane of our existence considering most every raster image requires upsampling. I got a 4.5 gig .psb the other day for an 8foot image. 300 ppi 16 bit image absolutely riddled with compression artifacts. It was absolutely no better that the 150 meg jpeg they included as well. People ask me what resolution do you need...well...that matters less than the compression, and people just don’t understand that.

I actually HAVE used lab in Photoshop to color correct finicky images and it works awesome! Once I understood I was kind of moving the whole color space around the image it really made sense to me. Less chance to get your image out of harmony. Just pushing cmyk sliders around has never really worked great for me because moving k adjust the “lightness” of the image as well as the color. It’s easy to get your image out of whack and skewed disproportionately to warm or cool.

The newer Photoshop with the camera raw filter lets you change color in much the same way, by just adjusting the overall color temperature. It’s great! You have to be working in rgb though.

At any rate, the comments here were far more interesting to me than the study.

 

[Correct Color]

Mr. Adams inadvertently provided enough bread crumbs for me to follow through various forums to achieve some semblance of color management. Thanks Mike! Check is in the mail!

*Dryly* Thanks. It'll probably get here along with the check from Adobe.

Seriously, the way it's supposed to work is that you decide from all my keen insights to hire me; and I'll wager if you had, you'd have actually spent less money in the end if you had than by following the breadcrumb trail.

But anyway...

When asked what the difference between rasterizing in Photoshop to the rip I just tell them it’s more accurate with less conversion or chance of unneeded profile interference.

Actually while that many times is indeed a benefit... That is one of those confusing things terms, but the real difference is that when you rasterize in Photoshop, you're rasterizing -- typically vectors -- into pixels; when you rasterize in a RIP, you're rasterizing pixels into dots.

Pixels (picture elements) are the smallest unit of complete color information in a digital image. Dots are the smallest unit of individual colorant in a printed image. They're completely different things and the terms are not interchangeable, even though lots of people who should know better do just that..

That's also why a digital image is not four -- or three, or whatever -- greyscale images. All the color channel information in a digital image is contained in each pixel in the image. Put them all together and look at them from far enough away, and you see that image. All the processes that image passes through use the information in those pixels to reproduce color. While it's true that you can in Photoshop look individually at the color values in the pixels of each component color as a representation of a greyscale image, it's only that, a representation. The color information is contained in the pixels.

Anyway, thanks for the compliments.

(I'll add though that I do a ton of work in dye sub, from flags to Chromluxe; oddball inksets are a particular specialty, and I don't share all my secrets here. Please feel free to get in touch any time.)


Mike Adams
Correct Color

 

[Alois Senefelder]

Hello Correct Color (Colour)



"All the processes that image passes through use the information in those pixels to reproducecolor". In what way does these "Pixels which are an integral part of a Bitmap

reproduce CMYK Printer Separations ??? Are you talking about "Color Correction" for Printing Ink Hue Error ?





Regards, Alois

 

[Correct Color]

Alois,

In what way does these "Pixels which are an integral part of a Bitmap

reproduce CMYK Printer Separations ??? Are you talking about "Color Correction" for Printing Ink Hue Error ?

Well, first off, no. I'm not talking about "color correction" per se, or color correction for any ink hue errors. One key principle of color management is that there aren't any specific defined values for any primary colors, including CMY and K. ISO standards notwithstanding, the fact is that CMYK values and densities can differ greatly from inkset to inkset and from profile to profile. And it's not that one's right or another is wrong. It's just that in moving from one colorspace to another, to make an accurate transform the primaries in both colorspaces have to be defined. Correctly.

So... Moving bitmap pixel values to reproduce CMYK printer separations...

To start with, once again, a pixel is the smallest unit of complete color information in a digital file. So that means that pixel includes tone values for each primary color space it is in; RGB, CMYK, L*a*b*, CMYKOGV, whatever. And the number of numbers in the pixel will always be the same as the number of primary colors in the colorspace.

So, just keeping to CMYK, if you have a particular pixel in a particular CMYK image, what that pixel contains is 4 numbers representing four primary color tone values for that pixel.

And that's all that's in it.

Nothing else.

So let's say those values are C=100 M=50 Y=100 K=10.

That's all the information in that pixel. There's no information here about printing conditions at all. No white point; no inking information; nothing about dot size or generation. How do you convert this digital info into actual, physical, printing dots?

Well... A RIP converts pixels into dots using information in profiles.

And a profile is going to contain information of two varying types: Machine-state information, and a characterization of that machine in that state.

So first, machine-state information: Your pixel has the values C=100 M=50 Y=100 K=10, but what's your printing process? AM screens so you want dots C=100 M=50 Y=100 K=10 dots respectively, or FM screens so you want dots covering C=100 M=50 Y=100 K=10 of the media, respectively? What are are dot gain curves for each channel? Are your primary channels one single ink or are there light inks built into one or all of the channels? AM or FM, what are your dot sizes?

None of that information is contained in your pixels, but you can't create dots without it. All that machine-state data simply has to be present or you can't create printing dots at all. That machine-state date is always part of a profile a RIP uses to convert pixels into dots.

And it's possible to create dots using just this information; "passing through" CYMK values with no color space information supplied. In that case, your C=100 M=50 Y=100 K=10 pixel values will reproduce C=100 M=50 Y=100 K=10 dots values be they 75 line screen dots or 300 line screen dots, or stochastic 3 picoliter CMYKcmyk dots or 60 picoliter CMYK dots.

However, what's your media white point, how reflective is your media, and what are your actual primary colors? You're calling them CMYK, but what are their actual color values? And when printed in combinations, what colors do they produce?

There are people out there using pass-through transforms and getting what they consider reasonable results, but a pass-through can't answer these questions; so it's always by nature going to be inaccurate to whatever extent the variables in their actual destination printing environment are different from whatever colorspace they work their original images in. Note also that in a pass-through environment, it's mandatory that you must send color information using the same exact primary color definitions as your destination color environment: no RGB images; no named spot colors. The RIP will try and process them, but it has no information in a pass-through to process them correctly.

The best and most practical use of pass-through printing is to create a machine-state, then send pass-through color patches to the machine in that state. You can then read those patches and get a file that is a representation of the machine in that state. That representation will then include the media white point, the reflectivity of the media, your actual primary color values, and examples of what colors they reproduce when printed in combinations. This file is a characterization of your machine in a particular state.

And when you combine the characterization file with the machine-state information, then you're using color management.

So, when you send your CMYK file to the RIP, you will have to tell the RIP in what color space it was created. You do this either by embedding that information in the file -- the file date, not the individual pixels -- and telling the RIP to honor embedded profiles, or by telling the RIP to use a certain CMYK colorspace to process incoming CMYK information.

When you do that, then the RIP, pixel by pixel, maps the values of the color tone information of each pixel in the incoming file from its creation colorspace to the L*a*b* value associated with it in that colorspace. It then looks for that L*a*b* value in the destination color space -- the characterization file, which is an ICC profile -- and creates dots based on the machine-state information to which that file is attached, and creates printing dots accordingly.


That's the process I'm describing.


(Yeah, to anyone who wants to chime in, there is a third way to convert pixel information into dots: Device links. Device links have their adherents. It just so happens I'm not one of them. And I've ever only fooled with them enough to know I don't like them very much. From their evangelists though, one of the key preaching points is that they supposedly don't use L*a*b*. Which is true enough on the surface. However, since a device link is a combination of two ICC profiles, and both of those profiles were created using L*a*b*, well... I'd call that a little disingenuous.)



Mike Adams
Correct Color

 

[Andy_warp]

*Dryly* Thanks. It'll probably get here along with the check from Adobe.

Seriously, the way it's supposed to work is that you decide from all my keen insights to hire me; and I'll wager if you had, you'd have actually spent less money in the end if you had than by following the breadcrumb trail.

But anyway...

I was hoping it wasn't taken "dryly" I had nowhere to go but up with the state of the color management until I did some convincing of the need for new or at least current tech to profile.
With the new easy media wizards it makes things much easier...I would probably struggle quite a bit going the route of your unpublished secrets! I know the profiling "wizards" add their own flavor to things. If there was one thing I would pick your brain for, it would be that.

The compliments were definitely genuine!

The most important thing I took from your insights was that I was creating a machine characterization as opposed to a magic file extension to have every color print perfect. I'm sure there would be many holes you could poke in our workflow, but I am happy with where it is at. One thing here that NO profile can account for is improper asset handling and non-industry standard prepress workflow procedures. Another thing is the maintenance and cleanliness of your equipment. If I had implemented some serious process control before I profiled...I may not have.

I'm glad it went in the order it did for me, and again, thank you for sharing your insights!

 

[Correct Color]

I was hoping it wasn't taken "dryly"...

Just a little wry observation there. Don't mind me.



Mike