UCR in rip
- Thread starter kirkjack
- Start date
Gerhard
Active member
Re: UCR in rip
Hi Kirk,
UCR in general works only with RGB. Also in Photoshop you have to convert the picture first to RGB (or LAB) and then return it back to CMYK with the new UCR settings. But this might affect the picture quality. Try implementing an ink saving software that reduces the ink values automatically. There are different vendors like Agfa, ORIS or OneVision on the market.
Otherwise simply reduce the ink value manually to 240. Take care that (for Web) the black is still on 100. This will evenly reduce your ink values but it is by far not as profssional as using an approved software doing this.
Best regards,
Gerhard
Hi Kirk,
UCR in general works only with RGB. Also in Photoshop you have to convert the picture first to RGB (or LAB) and then return it back to CMYK with the new UCR settings. But this might affect the picture quality. Try implementing an ink saving software that reduces the ink values automatically. There are different vendors like Agfa, ORIS or OneVision on the market.
Otherwise simply reduce the ink value manually to 240. Take care that (for Web) the black is still on 100. This will evenly reduce your ink values but it is by far not as profssional as using an approved software doing this.
Best regards,
Gerhard
Re: UCR in rip
Now, I only entered the industry a few years ago, so I'm no guru when it comes to "getting one's hands dirty with separations" etc. But, from my understanding UCR and GRC are simply the methods by which the black channel/plate/separation is actually arrived at to begin with. Without them we could only print in CMY.
So with that in mind, if you already have a "K" separation, it is nonsensical to say "apply UCR/GRC to this CMYK image;" Unless what you're meaning is taking the CMYK first into L*a*b* and then back into CMYK.
Now, I only entered the industry a few years ago, so I'm no guru when it comes to "getting one's hands dirty with separations" etc. But, from my understanding UCR and GRC are simply the methods by which the black channel/plate/separation is actually arrived at to begin with. Without them we could only print in CMY.
So with that in mind, if you already have a "K" separation, it is nonsensical to say "apply UCR/GRC to this CMYK image;" Unless what you're meaning is taking the CMYK first into L*a*b* and then back into CMYK.
Gerhard
Active member
Re: UCR in rip
If you want to apply UCR/GCR in Photoshop and you have already a CMYK picture, yes, you convert it again to RGB or L*a*b* (better), then configure the URC/GCR values and convert the file back to CMYK.
Using specified software as mentioned above you don't need this. This software applies a 4-channel color conversion on the final PDF file (before ripping), reducing the CMY values and increasing the K value. The benefit is a reduced ink coverage. This improves the drying time, reduces TAC, reduces color variations throughout a print run and reduces make ready time.
If you want to apply UCR/GCR in Photoshop and you have already a CMYK picture, yes, you convert it again to RGB or L*a*b* (better), then configure the URC/GCR values and convert the file back to CMYK.
Using specified software as mentioned above you don't need this. This software applies a 4-channel color conversion on the final PDF file (before ripping), reducing the CMY values and increasing the K value. The benefit is a reduced ink coverage. This improves the drying time, reduces TAC, reduces color variations throughout a print run and reduces make ready time.
mattbeals
Well-known member
Re: UCR in rip
Don't forget Alwan.
Alwan can take care of all your color conversions but deal with them in a very intelligent way by creating device link profiles for each conversion. One of the key features of Alwan Color Hub is to be able to reduce the amount of ink used without affecting overall image quality.
Yes, using GCR in your HQ RIP for the RGB to CMYK conversion will do that. But what about existing CMYK that someone sends in? For that to be done well you need to use device link profiles that are made well. Further you need something that can tell when the profile changes so that the device link profile can change dynamically too. Alwan can do that. For example, you have two CMYK images destined for SNAP. In your PDF you have two CMYK images, one is SWOP2006 #3 and the other is GRACoL #1. Both images have TAC's higher than 240. What do you do? If you use a static device link profile you can deal with either the SWOP or the GRACoL image. Say you do the SWOP image. What happens to the GRACoL image? Alwan can handle those situations. And by putting Alwan in front of the RIP everything is already checked and converted before it hits the RIP/Proofer. Think of it this way. You preflight your files so why not preflight your images for ink coverage AND fix them in an intelligent way?
Alwan may look expensive up front but the ROI on it can be faster than you might expect.
Don't forget Alwan.
Alwan can take care of all your color conversions but deal with them in a very intelligent way by creating device link profiles for each conversion. One of the key features of Alwan Color Hub is to be able to reduce the amount of ink used without affecting overall image quality.
Yes, using GCR in your HQ RIP for the RGB to CMYK conversion will do that. But what about existing CMYK that someone sends in? For that to be done well you need to use device link profiles that are made well. Further you need something that can tell when the profile changes so that the device link profile can change dynamically too. Alwan can do that. For example, you have two CMYK images destined for SNAP. In your PDF you have two CMYK images, one is SWOP2006 #3 and the other is GRACoL #1. Both images have TAC's higher than 240. What do you do? If you use a static device link profile you can deal with either the SWOP or the GRACoL image. Say you do the SWOP image. What happens to the GRACoL image? Alwan can handle those situations. And by putting Alwan in front of the RIP everything is already checked and converted before it hits the RIP/Proofer. Think of it this way. You preflight your files so why not preflight your images for ink coverage AND fix them in an intelligent way?
Alwan may look expensive up front but the ROI on it can be faster than you might expect.
Re: UCR in rip
Matt, so you're saying that if I have a PDF with a SWOP image and a GRACoL image, and I send it through Alwan, that it will know the SWOP image is a SWOP image and a GRACoL image is a GRACoL image? Not unless they are tagged with a profile it won't. And it can't be tagged with more than one CMYK profile unless PDF 1.4 or higher I believe (in PDF 1.3 the whole document is seen as having only one CMYK profile, and certainly PDF/X-1a or PDF/X-3 are both this way).
Alwan works like any other color conversion program. ANY program, if it is color managing CMYK (and this is always true of input RGB, which will have to assume the default if a profil eis not embedded), has to have a default input/source profile and output/destination profile. If I set my color conversion program as input U.S. Web Coated (SWOP) v2 and output GRACoL2006_Coated1v2, and tell it to color manage CMYK, ALL CMYK will be assumed to be U.S. Web Coated (SWOP) v2 (which is the set input profile, unless the program allows embedded CMYK profiles to override the default input profile AND I have a PDF 1.4 that can contain multiple CMYK ICC profiles).
So let's say we have a Quark or InDesign PDF/X-1a or PDF/X-3. Quark and InDesign ignored the CMYK ICC profiles and used the CMYK numbers in the image, and only used the SWOP profile for display on-screen and as the Output Intent of the PDF. Any PDF coming from these programs are not honoring anything except the document ICC profile, which is what the PDF will have as the Output Intent (if Adobe makes the PDF from Quark postscript even this is not true).
So although Alwan may see higher TAC and can fix that, if it's doing any color management conversion, the destination profile is taking care of the TAC. So yes, the TAC limiting feature can be used by itself to conform the image to the ink limit of the destination profile.
But what you're saying I take it is that the GRACoL image will be seen as GRACoL and the SWOP image will be seen as SWOP and the input profile doesn't matter in this case, which it always does (with the two exceptions I listed above, which both have to be true for what you're saying to be true IMO. Those are: the program has to allow embedded CMYK profiles to override the default input profile AND the incoming PDF has to be a PDF 1.4 that can contain multiple CMYK ICC profiles. Otherwise, the program is choosing ONE ICC profile (either the embedded CMYK profile if allowed to override the default CMYK input profile, or the default input profile if the program does not allow overriding of embedded profiles - which would be stupid to do if one is color managing CMYK at all) and using that ONE ICC profile as source/input profile for all CMYK.
So let's say we have a PDF/X-1a with a SWOP Output Intent, and our default input profile in Alwan is SWOP also. Let's say that the output profile in Alwan is set to GRACoL2006_Coated1v2. What will happen? I believe that the SWOP and GRACoL images would be assumed to be SWOP and then converted to GRACoL2006_Coated1v2, thereby messing up the color of the GRACoL image because it's assumed to be SWOP which it is not. Also all vector colors (even PANTONE CMYK numbers) would incorrectly be assumed to be SWOP and they would also erroneously get color managed too.
Let's say we have a PDF/X-1a with a GRACoL2006_Coated1v2 Output Intent (haven't seen one yet, just a mental exercise), and our default input profile in Alwan is SWOP. Let's say that the output profile in Alwan is set to GRACoL2006_Coated1v2. What will happen? If Alwan allows the embedded profile to override the default input profile, then the SWOP image would be assumed to be GRACoL and wouldn't be color managed, and the GRACoL image, since it is already in the default space, wouldn't be color managed either (so would be doing what I'm already doing, which is not color managing CMYK). But let's say Alwan doesn't let the embedded profile override the default input profile. What would happen then? I believe that the SWOP and GRACoL images would be assumed to be SWOP and then converted to GRACoL2006_Coated1v2, thereby messing up the color of the GRACoL image because it's assumed to be SWOP which it is not.
See why I have decided not to color manage CMYK? This is just a couple examples. If Adobe and Quark aren't honoring CMYK profiles, I can:
1. Decide to color manage CMYK and probably mess something up and cause inconsistent color problems
-OR-
2. Decide that using the customers numbers is the safest thing to do until they see a proof and then only do something if they don't like the color on the proof.
There's a lot of stuff when talking about color management that sound good, but really, do we want to cause problems? No. And unless we have really ALL these things at the same time (all profiles embedded at creation, all profiles honored downstream in every app and passed through to the final PDF - which requires PDF 1.4 for the multiple profiles, and profile override automatic in conversion program, along with purity for black channel for black only type and drop shadows, and ink limiting would be done through the conversions), then the best we can do is only ink limiting at the most without possibly/probably causing problems.
Don
Matt, so you're saying that if I have a PDF with a SWOP image and a GRACoL image, and I send it through Alwan, that it will know the SWOP image is a SWOP image and a GRACoL image is a GRACoL image? Not unless they are tagged with a profile it won't. And it can't be tagged with more than one CMYK profile unless PDF 1.4 or higher I believe (in PDF 1.3 the whole document is seen as having only one CMYK profile, and certainly PDF/X-1a or PDF/X-3 are both this way).
Alwan works like any other color conversion program. ANY program, if it is color managing CMYK (and this is always true of input RGB, which will have to assume the default if a profil eis not embedded), has to have a default input/source profile and output/destination profile. If I set my color conversion program as input U.S. Web Coated (SWOP) v2 and output GRACoL2006_Coated1v2, and tell it to color manage CMYK, ALL CMYK will be assumed to be U.S. Web Coated (SWOP) v2 (which is the set input profile, unless the program allows embedded CMYK profiles to override the default input profile AND I have a PDF 1.4 that can contain multiple CMYK ICC profiles).
So let's say we have a Quark or InDesign PDF/X-1a or PDF/X-3. Quark and InDesign ignored the CMYK ICC profiles and used the CMYK numbers in the image, and only used the SWOP profile for display on-screen and as the Output Intent of the PDF. Any PDF coming from these programs are not honoring anything except the document ICC profile, which is what the PDF will have as the Output Intent (if Adobe makes the PDF from Quark postscript even this is not true).
So although Alwan may see higher TAC and can fix that, if it's doing any color management conversion, the destination profile is taking care of the TAC. So yes, the TAC limiting feature can be used by itself to conform the image to the ink limit of the destination profile.
But what you're saying I take it is that the GRACoL image will be seen as GRACoL and the SWOP image will be seen as SWOP and the input profile doesn't matter in this case, which it always does (with the two exceptions I listed above, which both have to be true for what you're saying to be true IMO. Those are: the program has to allow embedded CMYK profiles to override the default input profile AND the incoming PDF has to be a PDF 1.4 that can contain multiple CMYK ICC profiles. Otherwise, the program is choosing ONE ICC profile (either the embedded CMYK profile if allowed to override the default CMYK input profile, or the default input profile if the program does not allow overriding of embedded profiles - which would be stupid to do if one is color managing CMYK at all) and using that ONE ICC profile as source/input profile for all CMYK.
So let's say we have a PDF/X-1a with a SWOP Output Intent, and our default input profile in Alwan is SWOP also. Let's say that the output profile in Alwan is set to GRACoL2006_Coated1v2. What will happen? I believe that the SWOP and GRACoL images would be assumed to be SWOP and then converted to GRACoL2006_Coated1v2, thereby messing up the color of the GRACoL image because it's assumed to be SWOP which it is not. Also all vector colors (even PANTONE CMYK numbers) would incorrectly be assumed to be SWOP and they would also erroneously get color managed too.
Let's say we have a PDF/X-1a with a GRACoL2006_Coated1v2 Output Intent (haven't seen one yet, just a mental exercise), and our default input profile in Alwan is SWOP. Let's say that the output profile in Alwan is set to GRACoL2006_Coated1v2. What will happen? If Alwan allows the embedded profile to override the default input profile, then the SWOP image would be assumed to be GRACoL and wouldn't be color managed, and the GRACoL image, since it is already in the default space, wouldn't be color managed either (so would be doing what I'm already doing, which is not color managing CMYK). But let's say Alwan doesn't let the embedded profile override the default input profile. What would happen then? I believe that the SWOP and GRACoL images would be assumed to be SWOP and then converted to GRACoL2006_Coated1v2, thereby messing up the color of the GRACoL image because it's assumed to be SWOP which it is not.
See why I have decided not to color manage CMYK? This is just a couple examples. If Adobe and Quark aren't honoring CMYK profiles, I can:
1. Decide to color manage CMYK and probably mess something up and cause inconsistent color problems
-OR-
2. Decide that using the customers numbers is the safest thing to do until they see a proof and then only do something if they don't like the color on the proof.
There's a lot of stuff when talking about color management that sound good, but really, do we want to cause problems? No. And unless we have really ALL these things at the same time (all profiles embedded at creation, all profiles honored downstream in every app and passed through to the final PDF - which requires PDF 1.4 for the multiple profiles, and profile override automatic in conversion program, along with purity for black channel for black only type and drop shadows, and ink limiting would be done through the conversions), then the best we can do is only ink limiting at the most without possibly/probably causing problems.
Don
mattbeals
Well-known member
Re: UCR in rip
Don, I'm not sure where to begin...
For Alwan or any other application to know what the color is we either need the objects tagged, an output intent or assumed defaults for untagged objects. In my example I was not referring to PDF/X at all. When I said that if you have a SWOP and a GRACoL image in a PDF I was assuming that it would be understood that I am referring to tagged objects in the PDF. You're right in saying that in the absence of those profiles there is no way to know their origins. I guess I should have been very explicit.
Working from the above Alwan will dynamically create device link profiles to optimize the SWOP to destination conversion as it will also do with the GRACoL image.
If there is an output intent it will honor that (unless you tell it to ignore the profiles or output intent) and build one dvl to make the conversion.
If there are no profiles and no output intent then assumptions about which rgb/cmyk profiles will need to be made.
True the destination profile should have embedded in it a TAC. That works if the press spec's match the profile. But if it doesn't like in my example then you have to some how reduce the ink amount (re-separate it). Which Alwan can do. Further it can "preflight" the color and "normalize" the color which can bring the added benefit of maintaining the visual appearance (through image analysis and Alwan's color expertise) while reducing the amount of ink used on press. Even if the profile matches the press condition.
Think of it as preflighting color and correcting it. Which is really no different than any other preflight and correction process. And I'm not talking about color correction in the classical sense. That's where Elpical Claro and Agfa Intellitune come in to play.
Don, I'm not sure where to begin...
For Alwan or any other application to know what the color is we either need the objects tagged, an output intent or assumed defaults for untagged objects. In my example I was not referring to PDF/X at all. When I said that if you have a SWOP and a GRACoL image in a PDF I was assuming that it would be understood that I am referring to tagged objects in the PDF. You're right in saying that in the absence of those profiles there is no way to know their origins. I guess I should have been very explicit.
Working from the above Alwan will dynamically create device link profiles to optimize the SWOP to destination conversion as it will also do with the GRACoL image.
If there is an output intent it will honor that (unless you tell it to ignore the profiles or output intent) and build one dvl to make the conversion.
If there are no profiles and no output intent then assumptions about which rgb/cmyk profiles will need to be made.
True the destination profile should have embedded in it a TAC. That works if the press spec's match the profile. But if it doesn't like in my example then you have to some how reduce the ink amount (re-separate it). Which Alwan can do. Further it can "preflight" the color and "normalize" the color which can bring the added benefit of maintaining the visual appearance (through image analysis and Alwan's color expertise) while reducing the amount of ink used on press. Even if the profile matches the press condition.
Think of it as preflighting color and correcting it. Which is really no different than any other preflight and correction process. And I'm not talking about color correction in the classical sense. That's where Elpical Claro and Agfa Intellitune come in to play.
Re: UCR in rip
Since we see that each image must have an embedded profile or the whole PDF have an Output Intent (in which case all of that colorspace, e.g. CMYK, is seen as the being in the Output Intent, which can be ignored or used depending on the program's settings).
In the event of a PDF 1.4 (or higher) where there is no Output Intent, but each image has an embedded profile, what ICC profile is seen as attached to the lineart? Or is it seen as being untagged and therefore takes on the default CMYK ICC profile in the color conversion (or any other) program?
Also, even if PDF/X-1a (supposedly not a color managed format), would Alwan or PDF Enhancer or any other color conversion tool that you know of, at any time, treat the CMYK as untagged CMYK and not color manage it if the source and destination are different in the color conversion program? What about PDF/X-3? Does it depend on the configuration of the tool are do all tools treat these the situations the same?
Don
Since we see that each image must have an embedded profile or the whole PDF have an Output Intent (in which case all of that colorspace, e.g. CMYK, is seen as the being in the Output Intent, which can be ignored or used depending on the program's settings).
In the event of a PDF 1.4 (or higher) where there is no Output Intent, but each image has an embedded profile, what ICC profile is seen as attached to the lineart? Or is it seen as being untagged and therefore takes on the default CMYK ICC profile in the color conversion (or any other) program?
Also, even if PDF/X-1a (supposedly not a color managed format), would Alwan or PDF Enhancer or any other color conversion tool that you know of, at any time, treat the CMYK as untagged CMYK and not color manage it if the source and destination are different in the color conversion program? What about PDF/X-3? Does it depend on the configuration of the tool are do all tools treat these the situations the same?
Don
mattbeals
Well-known member
Re: UCR in rip
Since we see that each image must have an embedded profile or the whole PDF have an Output Intent (in which case all of that colorspace, e.g. CMYK, is seen as the being in the Output Intent, which can be ignored or used depending on the program's settings).
MB: Right.
In the event of a PDF 1.4 (or higher) where there is no Output Intent, but each image has an embedded profile, what ICC profile is seen as attached to the lineart? Or is it seen as being untagged and therefore takes on the default CMYK ICC profile in the color conversion (or any other) program?
MB: None in the example I gave. If the art is untagged then we must make an assumption. If it is tagged, that profile then.
Also, even if PDF/X-1a (supposedly not a color managed format), would Alwan or PDF Enhancer or any other color conversion tool that you know of, at any time, treat the CMYK as untagged CMYK and not color manage it if the source and destination are different in the color conversion program? What about PDF/X-3? Does it depend on the configuration of the tool are do all tools treat these the situations the same?
MB: It's not that PDF/X-1a is not color managed. It is more that the color management/conversion has already taken place and the output intent is notifying the receiver what the color space is. You can tell certain programs to override the output intent yes. It all depends on the software and how it is individually configured. Your conversion settings and defaults may be singularly unique or they may be more generic. It *only* depends on what you want to do.
See: http://www.mattbeals.com/misc/alwan.png
Since we see that each image must have an embedded profile or the whole PDF have an Output Intent (in which case all of that colorspace, e.g. CMYK, is seen as the being in the Output Intent, which can be ignored or used depending on the program's settings).
MB: Right.
In the event of a PDF 1.4 (or higher) where there is no Output Intent, but each image has an embedded profile, what ICC profile is seen as attached to the lineart? Or is it seen as being untagged and therefore takes on the default CMYK ICC profile in the color conversion (or any other) program?
MB: None in the example I gave. If the art is untagged then we must make an assumption. If it is tagged, that profile then.
Also, even if PDF/X-1a (supposedly not a color managed format), would Alwan or PDF Enhancer or any other color conversion tool that you know of, at any time, treat the CMYK as untagged CMYK and not color manage it if the source and destination are different in the color conversion program? What about PDF/X-3? Does it depend on the configuration of the tool are do all tools treat these the situations the same?
MB: It's not that PDF/X-1a is not color managed. It is more that the color management/conversion has already taken place and the output intent is notifying the receiver what the color space is. You can tell certain programs to override the output intent yes. It all depends on the software and how it is individually configured. Your conversion settings and defaults may be singularly unique or they may be more generic. It *only* depends on what you want to do.
See: http://www.mattbeals.com/misc/alwan.png
APS
Registered Users
Re: UCR in rip
Kirk
The PDF at the link below describes how the Harlequin RIP deals with Colour Management with ColorPro enabled.
www.globalgraphics.com/pdfs/products/colorpro_wp.pdf
Kirk
The PDF at the link below describes how the Harlequin RIP deals with Colour Management with ColorPro enabled.
www.globalgraphics.com/pdfs/products/colorpro_wp.pdf
Similar threads
PressWise
|
A 30-day Fix for Managed Chaos
As any print professional knows, printing can be managed chaos. Software that solves multiple problems and provides measurable and monetizable value has a direct impact on the bottom-line. “We reduced order entry costs by about 40%.” Significant savings in a shop that turns about 500 jobs a month. Learn how……. |
