Interesting study from Ryerson University on expanded color gamut printing.

[Deleted member 16349]

Erik said: "The testing was done without regards to standards or G7. Straight from characterization of the printers and the target Lab values of Pantone colours to the printer outputs."

Erik later said: "The authors are probably not aware of what they are saying. IMO what is said is that one can go from a colour target to the colour output, with a characteristic profile that maps the printing device, without any need for curves or G7."



The question of stability is more grist for further tests. I will discuss this further with the group. I think that there are tests along this line currently being undertaken by some Clemson students. I will find out more when I get settled in.



Exactly. All the rest of the discussion of consistency takes a back seat to the big point. For a printer who does multiple changeovers a day of largely spot color work, the savings are huge.

John, first I will say good luck with your new position at Clemson. Hope it works out well for you and your students.

Secondly, I have to say I am happy with the study. My comments about the authors not being aware of what they were doing was not to down grade the study. What the study showed as far as I am concerned is a positive example of a straight forward approach to matching colour. Often when I read technical papers, I find information that is helpful to how I view the process but was not something the authors were aware of.

Good luck with your testing of the EG printing method on flexo or offset. I think it will tend to highlight the fundamental problem of process inconsistency. There has been, for a long time, related results to the consistency of printing multiple inks instead of a spot colour. There is also a consensus on which method is more consistent. It is also done every day.

With CMYK one can consider the K as a spot colour. So the question is, is it more consistent to print a combination of CMY to get a black or gray or to print K as a solid or a screen. From general practice, some CMY is removed from an image and replaced with K and it is said that this approach is more consistent during a run.

So we get back to the old question about which needs to be done first. IMO it has always been that the processes first need to be made consistent and predictable before trying methods that greatly depend on process consistency. This seems to be generally understood in all other industries and with the development of any science. One can not develop science with technologies that are inconsistent.

I worked at Tetra Pak and in the mid 1980's, we ran a spot colour with CMYK EB Inks on five unit offset web presses. We were well aware of the potential benefit of running CMYK builds to replace some of the spot colours but knew the process was not consistent enough. I still think there is good potential but I also think the process needs to be designed to be more consistent. I suspect that your future test will show some problems with consistency.


I would also say that flexo and offset can be designed to be much more consistent. With offset, one will need to get rid of the ductor roller and with flexo, one will need to get rid of the anilox inker. The problem I see is that there is no will in the industry to actually face up to what I think are fundamental problems. This probably means that much of this effort with the Ryerson study and the coming press investigations, will go to waste if it shows that in the end, the results are not as hoped.

 

[gordo]

Gordo said: "If they're just testing gamuts and the ability to hit specific PMS colors or determine the recipes that the software came up with then there is no need to print their tests. They could have done the evaluations in software."

Yeah, that would have made our test easier! But how would we test the builds? We could use the software itself to test whether it agreed with itself, but that presumes that the software will accurately predict the color of the build that it came up with.

A least one of the vendor participants has that capability in their EG solution.

Gordo said: "I haven't seen any data on the number of EG installs in either flexo or offset. Judging by what I've learned talking to printers at trade shows like LabelExpo in Europe and N A I doubt that there are more flexo printers doing EG than offset."

I suggest attending an FTA conference. Perhaps your view may change?

I couldn't find any reference to EG printing in the listed FTA conference sessions. Perhaps you could provide a link?
I would just like to see published data for the number of EG installs in either flexo or offset. I don't think the data exists. I was at labelexpo in Brussels last year and several flexo presses were running EG. But that doesn't suggest any level of adoption by the industry.

 

[JohnTheMathGuy]

I couldn't find any reference to EG printing in the listed FTA conference sessions. Perhaps you could provide a link?
I would just like to see published data for the number of EG installs in either flexo or offset. I don't think the data exists. I was at labelexpo in Brussels last year and several flexo presses were running EG. But that doesn't suggest any level of adoption by the industry.

Hmmm... I looked at the sessions for the FTA Fall Conference next month. I don't see a lot about EG. But there used to be a lot! Try this. Here is a quote from one of my old blogposts:

In 2013 Mark Mazur conducted a survey that estimated that 10% to 20% of printers in the flexo world were using extended gamut. Don Carli's prediction came true, but about 15 years later than he predicted, and only within one segment of the print market.

More recently, the percentage has been soaring. Dawn Connell (Brand Marketing of Snyder’s Lance, who own Snyder’s pretzels, Jays, Kettle, Pop Secret, and Archway, to name a few) spoke at the Flexographic Technical Association forum in spring of 2016. In her presentation she said that 85% of their work is expanded gamut.

In 2016, Kevin Bourquin of Cyber Graphics told me that they have 5500 SKUs separated for expanded gamut. I just checked back with him. As of April 30, 2018, the number is 8615. I should also mention that Kevin spoke on expanded gamut at the FTA Forum conference in Indianapolis on May 7, 2018. (Rumor has it that he mentioned my blog.)

Kevin's presentation isn't the only presentation on expanded gamut at a high profile conference. I just got news that Mike Strickler will be speaking on the same topic at another big print conference at the end of September / beginning of October. This won't be just a quick twenty minute thingie. He has a whole seminar. Smart guy, this Mike fellow. We taught each other everything we know.
https://johnthemathguy.blogspot.com/2018/05/the-heyday-of-expanded-gamut-printing.html

I add to this a conversation that I had with Steve Balschi who is the color guru at PrintPack in Atlanta. PrintPack is a major packaging printer with something like $400M is annual sales. Most of their presses are flexo. Steve tells me that he never sees a job which is not expanded gamut.

 

[gordo]

JohnTheMathGuy

I know that there are hundreds of thousands of SKUs printed every week - and not just in the US. I had said as much in one of my previous posts.
That was not my question.
My question was the number of shops - not SKUs nor brands - flexo and or offset running EG for label/packaging work.
Also it’s not that there’s not a lot on EG printing at the upcoming FTA conference - it’s that there is apparently nothing about EG printing at the FTA conference. Zero. So your suggestion to attend the FTA conference to gain insight would be a waste of time and money.

 

[Correct Color]

So...

The study just deals with spot colours but it can be applied to images too as long as Lab values are NOT used.

From discussing this with the software folks at the various companies, I understand that spot colors and images are treated differently.

I'd interject a word of caution here. The way any RIP works is that in the end it generates a tif which it then converts into the final print file. It only treats spot colors and images differently in that for a spot color vector, it disregards the original creation color space of the print file and assigns to the pixels it creates in the final tiff the L*a*b* value associated with the spot color name assigned to that vector. For images, for each pixel it assigns the L*a*b* value associated with the color value for that pixel in the color space (this CMYK, that RGB, whatever) as defined in the original print file.

The RIP then converts from that tif, pixel by pixel, from L*a*b* to the destination color space -- the printer profile. At this point, individual pixels could have initially been in images or spot color vectors; they are the same to the RIP.

So using ICC color management, there's never any way not to use L*a*b*; be it for spot colors or images. So while it's true that initially RIP's treat images and spot colors differently, that's only initially. When it comes time to actually create printing dots, they do not.

And that's important because... I'll just go ahead and say that I'll hazard a guess that over the years I've actually made more CMYK + N color profiles than anyone else commenting here. And back when I started, I did a great, great deal of testing of various profile-making engines. And one key difference between profile-making engines is the rendering intents in each engine. For instance, some may have a very good perceptual rendering intent, but a very poor relative colorimetric rendering intent, or vice versa. And the effect can be then that one will handle the initial transformation of images just fine, but fall down on spot colors, and vice versa.

Which can be a disaster. Not many packages are just spot colors or just images. Testing for one or the other exclusively is likely to give you a poor result.

And I'll finally just add that after some exhaustive research I settled on one profile-making engine I use exclusively.

And it's not on your list.



Mike Adams
Correct Color

 

[fiatlux]

So...

I'd interject a word of caution here. The way any RIP works is that in the end it generates a tif which it then converts into the final print file. It only treats spot colors and images differently in that for a spot color vector, it disregards the original creation color space of the print file and assigns to the pixels it creates in the final tiff the L*a*b* value associated with the spot color name assigned to that vector. For images, for each pixel it assigns the L*a*b* value associated with the color value for that pixel in the color space (this CMYK, that RGB, whatever) as defined in the original print file.

(SNIP)

Mike Adams
Correct Color

Could you elaborate/clarify?
I was under the impression that RGB, CMYK, and CMYK+X,X,X images were actually composites of greyscale images. So the RIP just screens the tone values in each channel when doing the final separations. AFAIK L*a*b* is not involved.
When creating images to be printed EG I just manually add 1 or more greyscale images for each EG ink color. The extra channels are identified by named PMS colors but they are still just greyscale images. PShop doesn't quite display the composite EG image correctly but it does print correctly to inkjet or offset. Works fine.

 

[Correct Color]

Could you elaborate/clarify?
I was under the impression that RGB, CMYK, and CMYK+X,X,X images were actually composites of greyscale images. So the RIP just screens the tone values in each channel when doing the final separations. AFAIK L*a*b* is not involved.

Sure.

The clarification is that that isn't the way it works.

What a RIP does is convert pixels -- the smallest unit of complete color information in a digital image -- into dots -- the smallest unit of individual colorant in a printed image.

Individually, digitally, pixels are groups of numbers -- little boxes with numbers in them. That's why CMYK files are larger than RGB files; each CMYK pixel contains four numbers and each RGB pixel contains three numbers.

And the RIP does this by using information in profiles. That's why profiles are the least understood but most important part of the digital printing process. They tell the RIP everything it is ever going to know about how to make printing dots.

But anyway... The RIP takes the incoming file, and looks -- by whatever method, be it spot color defined vectors or individual pixels -- for the L*a*b* value of each element as defined either by the color profile defined to the RIP of the incoming file, or by a L*a*b* value described in its internal spot color library of a named vector in the file. It then creates a L*a*b* tif image from which it then, pixel by pixel, converts to a printer language file -- usually called an RTL file in my end of the industry -- which it does by converting the L*a*b* value of each pixel into the corresponding CMYK (or CMYK + whatever additional primaries are in the inkset) value for that L*a*b* value combination of dots in the destination color space -- the printer profile.

(Edited to add: I'll add that there is a difference between what you're doing and adding the same elements in say, Illustrator. In the case of Photoshop, when you save your image, you're still most likely saving a rasterized file of some sort. And that means that to the RIP, it won't be images and named spot color vectors; it will just be pixels. And what that means is that along the way, your Pantones have gone through the transform to whatever color space you're in in Photoshop -- through the associated rendering intent you selected -- before they get to the RIP.

May work okay, but it's not the most direct way, and the Photoshop transform could lose you some capability when colors could be in gamut of your printer but out of the gamut of your Photoshop working color space.)



Mike

 

[fiatlux]

Sure.

The clarification is that that isn't the way it works.

What a RIP does is convert pixels -- the smallest unit of complete color information in a digital image -- into dots -- the smallest unit of individual colorant in a printed image.

Individually, digitally, pixels are groups of numbers -- little boxes with numbers in them. That's why CMYK files are larger than RGB files; each CMYK pixel contains four numbers and each RGB pixel contains three numbers.

And the RIP does this by using information in profiles. That's why profiles are the least understood but most important part of the digital printing process. They tell the RIP everything it is ever going to know about how to make printing dots.

But anyway... The RIP takes the incoming file, and looks -- by whatever method, be it spot color defined vectors or individual pixels -- for the L*a*b* value of each element as defined either by the color profile defined to the RIP of the incoming file, or by a L*a*b* value described in its internal spot color library of a named vector in the file. It then creates a L*a*b* tif image from which it then, pixel by pixel, converts to a printer language file -- usually called an RTL file in my end of the industry -- which it does by converting the L*a*b* value of each pixel into the corresponding CMYK (or CMYK + whatever additional primaries are in the inkset) value for that L*a*b* value combination of dots in the destination color space -- the printer profile.



Mike

Sorry, that makes no sense to me.

Are you talking about what an inkjet does?

That's why CMYK files are larger than RGB files; each CMYK pixel contains four numbers and each RGB pixel contains three numbers.

If you take a single RGB channel (which is greyscale) it is 1/3 the megapixel size of the RGB image. If you take a single CMYK channel (which is greyscale) it is 1/4 the megapixel size of the CMYK image. CMYK image file sizes are larger because they have an extra greyscale image vs an RGB image which only has 3 greyscale images.

Something is amiss.

 

[Correct Color]

Something is amiss.

What's amiss is that in actuality there are no "greyscale" images involved. Digital images are groups of pixels -- picture elements -- period. That is how they are defined.

If you want to think of each channel as an individual greyscale image that's your business, but it's not. Each channel is the amount of a particular colorant needed to reproduce a particular color in a particular color space.

For example:

Let's take Pantone 485C. In Photoshop, its L*a*b* value is shown as L=50 a=60 b=55. Photoshop doesn't do decimals, but close enough.

The idea, when you select Pantone 485C, is to try and print as close to L=50 a=60 b=55 as you possibly can. That is your goal.

And what happens is if you're working in Photoshop in Adobe 1998 RGB, you're not creating a Pantone 485C greyscale image; you're creating a group of RGB pixels in that area that have the RGB values of R=225 G=38 B=28, those being the Adobe 1998 RGB values that equal Pantone 485C. If you were in SWOP CMYK, you'd be making pixels with the values of C=6 M=99 Y=100 K=1. Of course 485C isn't in the gamut of SWOP, so that's as close as Photoshop can get in that color space. Of course in other RGB color spaces or other CMYK spaces, the values would be different. But that is how this works. L*a*b* is the "connection color space."

And this is true on any form of printing. Up to the point of creating the printing dots, the processes are all the same.

If you take a single RGB channel (which is greyscale) it is 1/3 the megapixel size of the RGB image. If you take a single CMYK channel (which is greyscale) it is 1/4 the megapixel size of the CMYK image. CMYK image file sizes are larger because they have an extra greyscale image vs an RGB image which only has 3 greyscale images.

Okay, that made me laugh.

I guess you could look at it that way and come to that conclusion.

But do this:

Open any image in Photoshop, take the plus magnifying glass and drill all the way down on any part of it. Eventually you'll see the little boxes which are the pixels. Click around on any of them with the picker eyedropper and you can see their pixel values in RGB, CMYK, and L*a*b*. Every pixel has 3 RGB values and 4 CMYK values. Those values are what determines the size of the file.



Mike

 

[fiatlux]

When I produce an EG image to be placed in InDesign (or whichever) I have to supply it as an eps DCS file. That has an image file to place in the app and separate grey scale images for each of the colors that make up the final composite image. i.e. 5, 6, 7, 8 image files. The RIP screens each of those greyscale image files which will then be composited on press. AFAIK, the same thing happens when you send a composite CMYK image to the RIP.

 

[gordo]

This is very interesting. I'm with fiatlux in my understanding. I have an extensive graphics library and cannot find any info on this. The composite pixel Lab values are used for the monitor display, however there doesn't seem to be any info on RIPs looking at those values to create the individual channels that will be printed.

Mike, could you provide an industry reference source that elucidates your understanding?

 

[Correct Color]

When I produce an EG image to be placed in InDesign (or whichever) I have to supply it as an eps DCS file. That has an image file to place in the app and separate grey scale images for each of the colors that make up the final composite image. i.e. 5, 6, 7, 8 image files. The RIP screens each of those greyscale image files which will then be composited on press.

What you're describing only works if you disable color management altogether.

In that case, then yes, L*a*b* is not involved. L*a*b* (or in some cases XYZ) is what makes color management work.

AFAIK, the same thing happens when you send a composite CMYK image to the RIP.

If -- if -- you are not using color management at all and create files in CMYK, then they would pass through in the same fashion.

Since I don't know you, or your workflow, I suppose I don't know you're not doing this. However, it's kind of hard to picture anyone actually doing this -- and even more-so getting it right. All the Adobe applications are built to assume color management is on. It'd take some doing to over-ride it.

But if you are, I could save you a bunch of money.

If you are, you're farming with a stick...

and I sell tractors.


(Edited to add: I do have to point out though that even in this instance, your DCS files are not greyscale images. They are made up of pixels in individual colorant channels, and the RIP still has to convert those pixels to dots, using whatever inking instructions are incorporated into whatever media profile it is using. The difference is just that it applies no ICC profile to the result.)


Mike Adams
Correct Color

 

[Deleted member 16349]

So...






I'd interject a word of caution here. The way any RIP works is that in the end it generates a tif which it then converts into the final print file. It only treats spot colors and images differently in that for a spot color vector, it disregards the original creation color space of the print file and assigns to the pixels it creates in the final tiff the L*a*b* value associated with the spot color name assigned to that vector. For images, for each pixel it assigns the L*a*b* value associated with the color value for that pixel in the color space (this CMYK, that RGB, whatever) as defined in the original print file.

The RIP then converts from that tif, pixel by pixel, from L*a*b* to the destination color space -- the printer profile. At this point, individual pixels could have initially been in images or spot color vectors; they are the same to the RIP.

So using ICC color management, there's never any way not to use L*a*b*; be it for spot colors or images. So while it's true that initially RIP's treat images and spot colors differently, that's only initially. When it comes time to actually create printing dots, they do not.


Correct Color

Again, IMO using Lab colour values are not suitable for colour management. There are two reasons for this view.

One reason is that the math does not work and the second reason is that Lab values do not represent the physics of what is happening when multiple sources are added together such as when multiple pixels are representing different colours.

One does not have to be a colour management expert to be concerned about the use of Lab values in this context.

First the math. Please correct me if I am wrong on the basic colour science.

Lab values are generated from XYZ values. Lab values are non linear constructions from XYZ. So here is the math problem I see with Lab.

If one has multiple sources, each having a different XYZ value, one can add the X's, Y's and Z's and divide by the number of sources and one will have an average XYZ value.

If one has multiple sources and converts them to Lab values first, and then average them, this will produce a final average Lab value. Here is the problem.. If one converts the final average Lab value back to XYZ, it will not equal the average XYZ value calculated when the XYZ values were not converted to Lab values.

Now the question is, which method more represents the physics?

The second reason.

Lab values have more to do with visual perception than the physics of the light being emitted or reflected. I suspect there was never an intention of using Lab values for processing colour data but most probably only for the final visualization.

XYZ values are more related to what is physically happening. What one sees is the summation of multiple sources of light. Each source has a spectrum and they are additive to give an average that one sees from any small location. So averaging XYZ values of very small pixels should be a better match to the physics. AFAIK, adding spectral curves and getting an average curve, which then can determine the final colour is common practice. I think adding the XYZ values follow this logic.

So all colour management uses Lab as the primary colour value connecting it all together. So maybe colour management is doing it wrong. Just because it is being done does not mean it is being done correctly. When things are done incorrectly, there is a lot of frustration.

If ICC is only using Lab values, I don't see why it would be so hard to change that. A bunch of smart programmers could do this easily. Using XYZ values could be investigated easily and should be better.

 

[Correct Color]

Erik,

Interesting.

All I can say in response is that I didn't invent any of this. I just use it. And I'm not a physicist so I won't attempt to argue any points of that.

What I will say though is that color management is what I do for a living, and it does work.

I suspect there was never an intention of using Lab values for processing colour data but most probably only for the final visualization.

Obviously you're right there, since Lab dates to the 1800's.

However just because something wasn't designed to do a thing doesn't mean it can't do it. Otherwise Apollo 13 wouldn't have made it home. I'm sure there's validity to a lot of what you're saying, but my response would be that while all that may be true, the only thing that matters with anything is how well it works.

And I'll tell you that done correctly, color management does work, and it overwhelmingly uses Lab.

I can tell you as well that back when I was researching and evaluating and comparing profile-making engines, I don't recall which but a few used XYZ instead of Lab. It just wasn't a determining factor in how well they worked though. The most important determining factor was their rendering intents. They mattered to the final results much more than Lab or XYZ as the profile connection space.

I'm not defending Lab here, per se, btw. I've read thoughts like yours before, and they're interesting. But we are where we are, and there are enough variables in the whole business of reproducing color and how humans interact with color that I myself don't think switching Lab in color engines to XYZ would make any difference at all.

Besides, every color library out there -- including Pantone and including color libraries you can make in every RIP, works as a name and a Lab value.

My point I guess is that the ship has sailed. And from where I sit, what makes color management -- what makes color profiles work -- is the knowledge and skill and skill of the profile-maker. Everything else is secondary.

If ICC is only using Lab values, I don't see why it would be so hard to change that. A bunch of smart programmers could do this easily. Using XYZ values could be investigated easily and should be better.

ICC doesn't require Lab. The ICC profile-making engine in Fiery XF RIP uses XYZ. I'm sure there are others that do as well, that's just the only one I recall off the top of my head. And the Fiery engine from where I sit is one of the better ones out there too, btw.

But it's not the best.



Mike

 

[Deleted member 16349]

ICC doesn't require Lab. The ICC profile-making engine in Fiery XF RIP uses XYZ. I'm sure there are others that do as well, that's just the only one I recall off the top of my head. And the Fiery engine from where I sit is one of the better ones out there too, btw.

Glad to hear that. So at least basing it on XYZ has shown to be a workable method. That's good.

For most situations, the error is probably not so great to be an issue but for some situations it might. It is difficult to test a faulty method with all possible situations. As an engineer, it bothers me that a method that is not based on a more fundamental foundation, is used when it is possible to correct it. A lot of small errors can add up.

There are a lot of faults in the printing process but that has not stopped people from producing print and making a living. But if one wants to fully automate the processes, eliminating errors does have importance.

 

[gordo]

(Edited to add: I do have to point out though that even in this instance, your DCS files are not greyscale images. They are made up of pixels in individual colorant channels, and the RIP still has to convert those pixels to dots, using whatever inking instructions are incorporated into whatever media profile it is using. The difference is just that it applies no ICC profile to the result.)


Mike Adams

I mean greyscale only in the sense that the individual CMYK channels do not have color information (L* but no a* or b*)

I guess you aren't able to provide an industry reference source that elucidates your understanding? There's nothing in the literature that I have.

 

[Deleted member 16349]

.

I can tell you as well that back when I was researching and evaluating and comparing profile-making engines, I don't recall which but a few used XYZ instead of Lab. It just wasn't a determining factor in how well they worked though. The most important determining factor was their rendering intents. They mattered to the final results much more than Lab or XYZ as the profile connection space.

Mike, my view is also that the image itself should be using XYZ to describe the colour of each pixel for printing (and maybe static display on monitors etc.). Then only at the final step would a profile convert the XYZ data to screen values. This way one should be able to avoid all the colour space issues and tone issues that are not really required.

Mike or Gordon, have you ever seen images using XYZ data to describe the pixel colour?

 

[Correct Color]

Erik,

Mike, my view is also that the image itself should be using XYZ to describe the colour of each pixel for printing (and maybe static display on monitors etc.). Then only at the final step would a profile convert the XYZ data to screen values. This way one should be able to avoid all the colour space issues and tone issues that are not really required.

To me, the thing is that that's one of those things that sounds ideal in theory, but...

The way I describe it in seminars and the like: Every image in our industry goes through three color space phases: Creation space; working space; destination space. The trick to color management is managing the changes through those spaces.

Now, destination spaces can't be made to be a one-size fits all space, be it XYZ or L*a*b* or anything else. They are representations of a particular device reproducing color in a particular state.

So what you're proposing is combine creation and working spaces so that every single image be created and worked in XYZ. That means every cellphone; every high-end camera; every design or photo-editing application create and work exclusively in XYZ.

Would it be of benefit?

Well, it could be of some benefit and some people argue to work in L*a*b* in Photoshop. But no one does.

But regardless of whether it would be of any benefit or not, it's simply not going to happen. If you want to make it happen, your starting point will be convincing Adobe. Good luck with that. Then you can move on to X-Rite. Remember that as it stands now, all digital Pantone libraries are in L*a*b*. They all consist of a name and a L*a*b* value. Also all X-Rite profiling software uses L*a*b* measurements. Good luck with that.

Then you can move on to Apple. They started using Display P3 RGB for iPhone images, but that's okay. They're always eager to take input from outsiders.

Ahem.

Then if you succeeded, conceivably what you'd accomplish would be to reduce the risk of improper colorspace changes between creation space and working space. And while that's no small feat, you could accomplish the same thing by using L*a*b*. And no one does.

All I can tell you in the end is that I've been doing this for fourteen years now, and I've read in all that time interesting theories about the limitations of L*a*b*, and they're always just that: Interesting. But I've never seen them come into play out in the real world. And some of the work I do and clients I have are absolutely as demanding and high-end as it gets.

Mike or Gordon, have you ever seen images using XYZ data to describe the pixel colour?

Well, the technical kind of wise-ass answer is that you never can, since you're always viewing through whatever profile the monitor is using, and not the profile of the image. But no, not unless it was somewhere else and I was unaware. XYZ isn't an option in Photoshop, and that's about the only photo viewing/editing software I use.



Mike

 

[Correct Color]

Gordo,

I mean greyscale only in the sense that the individual CMYK channels do not have color information (L* but no a* or b*)

I guess you aren't able to provide an industry reference source that elucidates your understanding? There's nothing in the literature that I have.

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.

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.

True, if you view any of those channels individually in Photoshop, it displays them as black. But that's just for viewing purposes. 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.

I suppose that since there are 100 steps in the L channel in L*a*b*, and we think of CMYK as 100 steps, you could think of the values in an individual CMYK colorant channel as L values. But they're not; they're backwards. L=100 is complete absence of color. Any CMYK=100 is complete presence of color.

Also CMYK on computers is only identified as 0-100% for convenience sake. There are really 256 steps.



Mike

 

[Deleted member 16349]

The way I describe it in seminars and the like: Every image in our industry goes through three color space phases: Creation space; working space; destination space. The trick to color management is managing the changes through those spaces.

Now, destination spaces can't be made to be a one-size fits all space, be it XYZ or L*a*b* or anything else. They are representations of a particular device reproducing color in a particular state.

So what you're proposing is combine creation and working spaces so that every single image be created and worked in XYZ. That means every cellphone; every high-end camera; every design or photo-editing application create and work exclusively in XYZ.

Would it be of benefit?

Well, it could be of some benefit and some people argue to work in L*a*b* in Photoshop. But no one does.

Thanks for these comments although I am not convinced. Working in different spaces seems to me to be a problem and particularly the destination space. In my ideal view, the image based on XYZ values is the ultimate colour target and any other version is going to be problematic. The idea of spaces is problematic in my view. What is really the need for such a concept in any effort to make a reasonably accurate reproduction?

In designing a mechanical part, one would use inches or millimetres and there is no confusion. A part designed in North America can be made in China quickly and accurately. It is the system of defining the dimensions of the part that makes this possible.

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, my view is of what might be ideally possible but that is what I do. For now, there are existing methods that you have to deal with but ones that seem to me to be wasteful and frustrating for many.

Just a note. There have been efforts to work in Lab in Photoshop. Dan Margulis had given many seminars on the subject and written books on it. It might not be popular to do but there were people working in Lab.