Rendering intent for color conversions

As I understand it, when I make a new CMYK swatch in InDesign and type my recipe in, Adobe converts it to LAB and that is the number that is used behind the scenes to convert to RGB or to different CMYK profiles. Curiosity question: does the software reference the ICC profile that is set as the working space in order to make that initial CMYK to LAB conversion? Also, is it known if the software preserves and uses the numbers to the right of the decimal points for CMYK and LAB values, or does it all get rounded off? And finally, going far into the weeds: is it known what rendering intent is used?

Starting with last question first, the rendering intent is what you choose in Photoshop > Edit > Color Settings. At the top of the dialog box there in Photoshop are your choices for what color model your CMYK and RGB should be expressed in. These become the working color spaces for CMYK and for RGB. Working spaces imply that whatever picture you open and edit in Photoshop, it takes on this ICC profile of color model. Having a same choice from Photoshop for ICC color model means consistency in interpreting color, file after file. Near the bottom of the expanded Color Settings dialog box is the Rendering Intent, which is usually set to Relative Colorimetric.
What is Rendering Intent? ACE is the translator. His job is to translate visual color from one math number world to another math number world, with the intention of holding the visual color the same. When he translates numbers (representing colors) from one color space to another, inevitably some color will be lost in translation. Rendering Intent is a conscious decision for how to compromise colors that might be outside the gamut of the receiving color space. Bear in mind that many pictures, some color lost in translation is so slight so as to be scarcely perceptible.
Make your house rules choices here in Photoshop. Save as named .csf file. Then, in Bridge, click on Edit > Creative Suite color settings. Choose to apply this new custom-named house rules for your color workflow. In applying it, Bridge sends out instructions to Illustrator, InDesign, and Acrobat to follow the lead of Photoshop in adopting the same "house rules" for translating color.
If the Photoshop file being placed into InDesign already has the house-rules color space profile, it passes straight into InDesign without being re-interpreted/re-translated. (Like having a Smart Tag that allows you to drive through the toll-booth of the interstate. Like having a passport and express check-in at the airport. No need to re-examine you; you are already cleared. These are illustrations, by the way!)
Yes (your second question), ACE, in a behind-the-scenes support operation, checks all ICC color profile "passports" to see whether you need translating prior to entry, or merely waved through into InDesign. If the picture file already has the same working space as defined in Photoshop, it is allowed in unchanged. If the picture file doesn't have the same house color space, it is translated to the working color space, and allowed in afterwards. You might liken it to being issued a temporary passport. Do numbers get rounded off? Yes and no. Visual colors that exist in both color realms can be translated with great precision. Visual colors outside of the gamut of the receiving color space will change a bit, which is to say their numbers also change a bit.
As to your first question, is LAB at the center of things? Yes, in Photoshop. Lab color mode is the closest thing to a number system that consistently matches human visual color perception. Photoshop natively thinks in Lab, and translates out to all other color models, especially RGB and CMYK. Make sure to always run your pictures through Photoshop first (I like it's color management policies to force a permanent change to the house color space by choosing Conver to Working RGB/CMYK). After that, you place them into InDesign. In this way, all pictures already have a SpeedPass, so to speak, and InDesign does not re-translate the color. InDesign does not handle the Lab numbers, but is rather given the resulting conversion numbers by the translator, ACE, (if it needs to) working behind the suite of four softwares.
You might enjoy reading the book: Real World Color Management by Fraser, Murphy, and Bunting, and really geek out on this sort of thing.
Hope this helps,
Mike Witherell in Maryland

Similar Messages

Rendering Intent for monitors?

We hear a lot about rendering intent in relation to printing, but isn't the concept equally important in relation to monitor displays? And how does this operate in LR2? Or is Windows (in my case) responsible for making the rendering decisions?
I have a calibrated and profiled monitor (I use a spyder) and am aware that LR uses (Linear) ProPhotoRGB as the working colour space. Obviously the range of colours recordable by my SLR and retained within the LR working space far exceeds the gamut of colours that can be displayed. Does anyone know how LR2 handles the out-of-gamut colours for display? I suspect that it employs a sort-of relative rendering intent and simply clips these colours - i.e. displays them as the 'nearest' available colour. Alternatively, it could use a perceptual intent, shifting the whole spectrum into the monitor colour space, thus altering all colours but keeping the relation between colours. This is important stuff, isn't it?
The use of the 'relative' method would accurately preserve those colours that can be displayed so that printer output can be predicted with some certainty. But, it would also mean that I will never be aware from the display (not even imperfectly) of the full range of colours that are in the file. At worst, it could cause 'posterisation' as the out-of-gamut colours accumulate at the edges of the displayable colour space.
The use of the 'perceptual' method, however, will mean that I can be aware of the range of colours but that these will be imperfectly displayed with implications for the accurate assessment of likely printer output.
Anyone care to take up this discussion?

>I'm sure my monitor does not support the percptual intent. Might it be possible in a future edition (LR3 ?) to have LR offer the perceptual intent irrespective of monitor capability? This is not an area that I know much about.
It is not dependent on the monitor. It only depends on the calibration solution you use. The calibration software needs to support generating the perceptual intent.
>At present this means, I think, that I may be losing the range of colour tones (levels of saturation) that may be presented in certain scenes that I photograph. They will be unviewable. Does this matter given that most of these 'lost' tones will be unprintable too? Well, it might matter. For one thing some printers can now (I believe) print colours outside the (mainly) SRGB space that my monitor is capable of. For another, I am losing the ability to choose which is more important to me - the full colour tonal range, or colour accuracy. The problem of posterization has already been mentioned.
Yes, that is a problem. Currently you can only really solve it by using a wider gamut monitor (becoming more and more common) or using the right calibrator (I Believe the eye one calibrators can do v4 profiles). In photoshop you can set the system up to desaturate everything on the monitor by a certain percentage to avoid these issues. You cannot do that in Lightroom. For the second part, basically every printer nowadays prints outside of sRGB.
Many even go beyond adobeRGB. Safe from getting a better monitor there is not much you can do about it.

Color Conversion for all Elements

Hi,
I am writing some plug in which can convert Color of the PDF for that i have used "PDDocColorConvertPage" it is perfectly working well for Grayscale Conversion, But the same method is not working for the Pantone (SpotColor) to CMYK conversion, so i tried with PDColorConvertPDEElement it is also not working,I don't find any Code sample to use that function. I was blocked, please help me out to find the best method for color conversion problem.
Regards,
Kumar.K

I am using Acrobat 9, Here i am giving the code which working now, in that my objective is to change all the elements to Grayscale, but i am sure that i did some mistakes, Please let me know where i made the mistake
Code:
AVDoc avDoc = AVAppGetActiveDoc();
char str[256];
ASPathName aoPDFPathName = NULL;
char* OutputPdfFileName = "C:\\Output.pdf";
ASText pathText = ASTextNew();
ASFileSys aoFileSys = NULL;
pathText = ASTextFromScriptText(OutputPdfFileName, kASRomanScript);
aoFileSys = ASGetDefaultFileSysForPath(ASAtomFromString("ASTextPath"), pathText);
if(avDoc==NULL)
sprintf(str,"There is no PDF document loaded in Acrobat.");
else
PDDoc pdDoc = AVDocGetPDDoc (avDoc);
int numPages = PDDocGetNumPages (pdDoc);
ASInt32 ai, aiNumElems;
PDEContent aoPDEContent = NULL;
PDEElement aoPDEElement;
PDPage aoPage = NULL;
aoPage = PDDocAcquirePage(pdDoc, 0);
aoPDEContent = PDPageAcquirePDEContent(aoPage, 0);
aiNumElems = PDEContentGetNumElems(aoPDEContent);
sprintf(str,"The active PDF Page has %d Elements.", aiNumElems);
AC_Profile prof;
ACProfileFromCode(&prof, AC_Profile_DotGain15);
for (ai = 0; ai < aiNumElems; ai++)
aoPDEElement = PDEContentGetElem(aoPDEContent, ai);
PDColorConvertPDEElement(pdDoc, aoPDEElement, prof, AC_UseProfileIntent, true);
if (aoPDEContent != NULL){
PDPageReleasePDEContent(aoPage, 0);
// inform the user if we have done a color conversion.
if(ASBoolToBool(gbConverted) == true)
AVAlertNote("Color transform has been done to Gray");
else
AVAlertNote("No color transform was made.");
aoPDFPathName = ASFileSysCreatePathName (aoFileSys, ASAtomFromString("ASTextPath"), pathText, 0);
PDDocSave (pdDoc, PDSaveFull | PDSaveCollectGarbage | PDSaveLinearized, aoPDFPathName, ASGetDefaultUnicodeFileSys(),NULL, NULL);
PDDocClose (pdDoc);
ACUnReferenceProfile(prof);
Thanks,
Kumar.K

Rendering Intent

Lately, I've come to the conclusion that the proper rendering intent for printing is Absolute, with the caveat that there is no out of gamut colors with which to accommodate. The text in the selection menu for this function states that Absolute is best for simulating a particular device. Well, duh, it's the monitor I want to simulate, not some veiled look supplied by Perceptual or Relative.
So why are those two the recommended pick? There is no shift in dynamic range when invoking Absolute as soft proof unless there is trouble in gamut. If little to no shift between Relative and Perceptual can be seen, use Absolute.
You don't know how much screwing around with curves etc I have gone through trying to match Perceptual to the screen w/o soft proof enabled.
Who decided on the algorithms for these functions, and what was the criteria, particularly visual? It sure sells a bunch of ink and paper trying to get it right!

Addendum:
Been doing a bit of reading:
http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm
From the article:
"Absolute colorimetric preserves the white point, while relative colorimetric actually displaces the colors so that the old white point aligns with the new one (while still retaining the colors' relative positions). The exact preservation of colors may sound appealing, however relative colorimetric adjusts the white point for a reason. Without this adjustment, absolute colorimetric results in unsightly image color shifts, and is thus rarely of interest to photographers." (Emphasis theirs)
So, I took my test image and proceeded to ad a grayscale to the bottom and printed both Relative and Absolute. The results show that the gray scale shifted color in Absolute, very slightly from neutral to a barest cream color, which corresponds to a gray value I knew to be quite neutral, but slightly low in blue, to more neutral in Relative. This is what I expected to find based on the above definition.
I also noted that the first and last stop of the 21 step part were clipped back to 19 steps in Absolute. I can easily do that with levels, if that's all it takes.
No unsightly colors appeared in the image. I showed the two images to ma associate, who is a colorist by training, and her selection was the Absolute. (Interestingly, after running it I tended toward the Relative! As Jeff said YMMV, but in this case, slightly!).
My whole effort is this: I want to obtain the maximum dynamic range of which the paper/ink is capable. I will specify the white point as I can using the info palette. After that, I want the conversion to do what I asked...white is white black is dMax of the combo. This shading back from this standard by the rendering intent is counter intuitive, as well as counter productive.
So it comes down to this:
What is meant by color accuracy
What is meant by the white point.
I define color accuracy to be what I see on the screen, pre soft proof, white point to be the white of the paper. If I want to depart from that I can do so at will, but to try to get it to match the screen before even departing is a load I wish not to have. The most reliable way to do this would be for the Info palette give out the actual numbers after invoking the soft proof.
But I suppose that's asking too much!
Thanks for looking.

[AS][IDCS3] PDF Export Preferences Color Conversion setting

I want to set the field of Color Conversion (as equivalent to manual setting under Output>Color>Color Conversion) to "No Color Conversion" in Applescript but couldn't figure it out.
My skeleton Applescript is as follow:-
tell application "Adobe InDesign CS3"
   tell PDF export preferences
       -- I want to set No Color Conversion for Color Conversion here
   end tell
   tell document 1
       export format PDF type to filename without showing options
   end tell
end tell
I have search through Applescript ID CS3 dictionary but couldn't find the answer. Hope someone can advise. Thanks!

Use:
set effective PDF destination profile to use no profile
Shane Stanley <[email protected]>
AppleScript Pro Sessions <http://scriptingmatters.com/aspro>

Own Profiles - Rendering Intent

Need Saturation Rendering Intent for printing.
Using my own printer profiles (made using Colorvision Printfix Pro) I get the best results from these profiles using Saturation as the rendering intent with the ink set I have. Lightroom only allows Perceptual or Relative.
It's frustrating that I either have to compromise quality printing from light room or go to all the bother of avoiding LR for printing altogether.
Regards,
Lennythelens

I second this. I also get the best results with the 'Saturation' rendering intent using the default Canon paper profiles. I have not been able to adjust for this and have to print out of photoshop. It would be great to have this feature in Lightroom since the printing module is so effective and convenient for bulk printing.

Choosing profiles for forced RGB to CMYK color conversion

When a mixed RGB/CMYK PDF is opened in Illustrator CS6, Illustrator forces a conversion to one color space or the other. See this screenshot: http://imgur.com/sK8iEdn
I assume this is a limitation of Illustrator and there's no way to keep both color spaces. Under that assumption, Is it possible to choose the profiles used for the conversion from RGB to CMYK? Can Illustrator be made to use the RGB and CMYK profiles defined in its Color Settings to make this conversion?

I did some experiments with Illustrator CS6 and the MacBeth RGB test chart and verified my results with Photoshop CS6. I discovered Illustrator is (mostly) doing what it should be doing, within a 1% error (probably rounding) on the output CMYK values. Here's a summary, in case anyone else needs this info:
Assuming the source file's elements are all untagged, when a mixed RGB/CMYK PDF is opened in Illustrator and CMYK mode is
chosen, Illustrator will use the profiles and rendering intent defined in
Color Settings to make the color conversions from RGB to CMYK. Thus, we
have control over the profiles used for this conversion.
If the RGB elements in the PDF file have embedded ICC profiles,
Illustrator will use the embedded ICC profile instead of the RGB profile
defined in Color Settings. This ONLY happens, however, if the PDF file
also includes the correct CMYK output intent profile.
If the PDF doesn't contain a CMYK output intent, Illustrator will fall
back on the Color Settings RGB profile for RGB->CMYK conversion. I believe it
would be more correct for Illustrator to use the embedded RGB profile and
the CMYK profile defined in Color Settings, but that's not how it seems to work.
If the PDF contains the incorrect CMYK output intent, Illustrator will
ignore the Color Settings and respect the embedded RGB and CMYK profiles
for the conversion, as might be expected.

What Rendering intent is used when exporting with a different color space?

Hi,
I would be ever so grateful if any one can tell me what rendering intent is used by LR4 when exporting using a custom colour space as there is not an option as there is with the print module.
Thanks.
Message title was edited by: Brett N

Jeff Schewe wrote:
Bob_Peters wrote:
The rendering intent in the Export dialog is Perceptual.
Actually, an RGB color space to RGB colorspace is always only Relative Colorimetric...and adding Perceptual would only work with certain V4 ICC color spaces (you can find perceptual V4 color spaces for sRGB and ProPhoto I think but I'm not sure they would work in Lightroom anyway).
When using an RGB print output profile you can select either Perceptual or Relative and have the intents actually applied.
True.
The case of interest to me is when I have to print a lot of files using a third-party profile and maintain the original filename so it appears on the back. That is why I made the request more than a year ago.
The problem with the Print module is that it clobbers the filename but does allow 2 choices for the rendering intent. Having to deal with weird filenames creates a mess when matching, say, 50 prints with custom notecards.

Color Management : Rendering Intent Grayed Out

Currently running Lightroom vers 1.3.1. on a MAC mini 1.25 GHz Power PC G4 with Tiger 10.4.11. Not much RAM and not much of a printer. But totally enjoying Lightroom. My point is that prior to upgrading to the latest version of Lightroom I had no issues with Lightroom. None that a new Mac with more RAM and processing power plus a higher end printer couldn't handle much better. But to my point I use to be able to select between Perceptual and Relative in rendering intent. Now I don't have the ability as it has been grayed out after having chosen "Managed by Printer" in Color Management prior to printing. Have I missed checking something in preferences or haven't done correctly?
Thanks

WOW! If the spirit of Christmas lives. I was just going over the Lightroom Tutorial with yourself and Michael Reichmann and listening to the both of you discuss Color Management settings, profiles and render intent. And low and behold who should reply just seconds after I closed the quicktime file and checked to see if I there was a reply to this message! Yikes!
Thanks for the info!
By the way have thoroughly enjoyed the Tutorial!

How to control Display Rendering Intent in PS CS3 & XP?

Does anyone know a way to control the display rendering intent in Photoshop CS3 runing on XP?
The consensus seems to be that Relative Colormetric is always used. If I am using a large working space such as ProPhotoRGB, I would like to be able to switch between Perceptual and Relative Colormetric.
Here is some info I think may be relevant:
http://www.color.org/advantagesv4.pdf says one of the advantages of v4 over v2 is to "permit profiles containing multiple rendering intents to be specified for input and display devices as they currently are for output profiles".
Using http://www.color.org/version4ready.xalter I see that my system is not v4 compatible, but Photoshop CS3 does correctly render images with v4 profiles on my computer.
When I look at the profile that came with my monitor, using ICC_Inspector from http://www.color.org/profileinspector.xalter, I see it is ICC version 2, and the rendering intent is listed as Perceptual.
If use Monitor_RGB as my working space, and do edit > convert_to_profile, converting from ProPhotoRGB to MonitorRGB:
Using engine:Microsoft_ICM, I get different result for Perceptual vs Relative_Colormetric.
Using engine:Adobe(ACE), I get the same results for all intents, and they all look very close to Microsoft_ICM Perceptual.
However the original image in the ProPhotoRGB space is apparently rendered to my display space using Relative Colormetric because it looks like the image produce using convert_to_profile: Microsoft_ICM Relative Colormetric.
Thanks.

Let me think about this.
Looking at my monitor profile with the Color Sync Utility (I’m on a mac), the rendering of the profile is Perceptual.
With Photoshop, I open a saturated Pro Photo image. View: Proof Setup: Custom. Device to Simulate, Monitor Profile.
This is supposed to show me a file conversion to my monitor color space. I see no change in color (as long as preserve numbers is disabled). It makes sense, because the conversion is something that happens anyway. I can never truly see a Pro Photo image. It must be translated to my monitor profile before I see anything.
I can change the rendering and black comp all day long and it does not affect the color I see. I have to assume that what I see is actually a Perceptual rendering, not Relative Colorimetric, because Perceptual is the intent embedded in the Monitor ICC profile.
CMYK is a little different. With the same image open, View: Proof Setup: Custom. US Web Coated SWOP v2. Relative Colorimetric, Black Point checked. Simulate Paper White.
Now duplicate the image. Convert to Profile: US Web Coated. Relative Colorimetric, black point enabled. Now View: Proof Setup: Custom. Device to Simulate, monitor profile. Absolute Colorimetric.
Comparing the two images, the color is a dead on match.
In the second image (already converted to CMYK), if I change the rendering and black comp, the color shifts dramatically. This behavior is different from what I saw earlier, soft proofing Pro Photo to monitor, where the rendering and black point settings did not change the image color.
So at this point I have to conclude that Photoshop can control the display rendering for a CMYK image. But with RGB, it’s locked in somehow. I would imagine it defaults to Perceptual, not Relative Colorimetric. Can you open your monitor profile and check the rendering?
I have a utility that actually allows me to change the intent of an ICC. I went ahead and did that to the monitor profile and saved a copy, with Relative as intent. Using this in Proof Setup (with Pro Photo image) also yields no change. Makes sense, because the color gamut of the new copy is identical, and Photoshop is rendering a file conversion.
To get the Relative Colorimetric display requires changing the system profile to the new profile. Unfortunately when I do this, the screen color goes absolutely bonkers. All color are super saturated and I can hardly make out anything. I have no idea what that means.
I apologize for rambling on, I’m probably not much help. Thanks for the link and I will look into this matter more when time allows.

CMYK to RGB color conversion?

Hi,
I have to convert CMYK color array in the RGB color space and vice versa.
I am using the following code;-
UID colorUID = iDrawing->GetColorUID(kFalse);
UIDRef colourUIDRef(iDrawing->GetDataBase(), colorUID);
InterfacePtr<IColorData> colorData(colourUIDRef, UseDefaultIID());
char
strColor[16]={0};
if(colorData->GetColorSpace() == kPMCsCalRGB)
    ColorArray rgbColor = Utils<IUIColorUtils>()->GetRGBColorValue(m_DB, colorUID);
    sprintf(strColor,
"#%.2x%.2x%.2x", ToInt32(rgbColor[0] * 255), ToInt32(rgbColor[1] * 255), ToInt32(rgbColor[2] * 255));
else
    ErrorCode errStatus = GetRGBColorStr(colourUIDRef, strColor);
ErrorCode GetRGBColorStr(UIDRef colourUIDRef,
char* strColor){
    ErrorCode status = kFailure;
    do
          I
nterfacePtr<IColorData> colorData(colourUIDRef, UseDefaultIID());          IDataBase* m_DB = colourUIDRef.GetDataBase();
// If color sapce is other then RGB then get the colour array
    ColorArray colourArray = colorData->GetColorData();
    // If the colour space is CMYK then convert it to RGB
    if(colorData->GetColorSpace() == ICMSProfile::kSourceTypeBuiltInCMYK)    {
          IDocument* document = Utils<ILayoutUIUtils>()->GetFrontDocument();
          ColorArray rgbColor = Utils<IColorSystemUtils>()->ColorTransform( document, colourArray, ICMSProfile::kSourceTypeBuiltInCMYK,ICMSProfile::kSourceTypeBuiltInRGB);
     sprintf(strColor,
"#%.2x%.2x%.2x", ToInt32(Round(rgbColor[0] * 255)), ToInt32(Round (rgbColor[1] * 255)), ToInt32(Round(rgbColor[2] * 255)));     status = kSuccess;
}while(kFalse);
return status;
}while(kFalse);
return status;

I did some experiments with Illustrator CS6 and the MacBeth RGB test chart and verified my results with Photoshop CS6. I discovered Illustrator is (mostly) doing what it should be doing, within a 1% error (probably rounding) on the output CMYK values. Here's a summary, in case anyone else needs this info:
Assuming the source file's elements are all untagged, when a mixed RGB/CMYK PDF is opened in Illustrator and CMYK mode is
chosen, Illustrator will use the profiles and rendering intent defined in
Color Settings to make the color conversions from RGB to CMYK. Thus, we
have control over the profiles used for this conversion.
If the RGB elements in the PDF file have embedded ICC profiles,
Illustrator will use the embedded ICC profile instead of the RGB profile
defined in Color Settings. This ONLY happens, however, if the PDF file
also includes the correct CMYK output intent profile.
If the PDF doesn't contain a CMYK output intent, Illustrator will fall
back on the Color Settings RGB profile for RGB->CMYK conversion. I believe it
would be more correct for Illustrator to use the embedded RGB profile and
the CMYK profile defined in Color Settings, but that's not how it seems to work.
If the PDF contains the incorrect CMYK output intent, Illustrator will
ignore the Color Settings and respect the embedded RGB and CMYK profiles
for the conversion, as might be expected.

RIP with same color conversion as Adobe

Hi
for the color conversion of our images and pdfs we use Photoshop and Idesign (What I´m talking about here is to put an input profile, a rendering intent, and a output profile).
99,99% of the time we use relative colorimetric with black point compensation to do the conversion. So we use those 2 applications as if they were rips.
I must say that we are very happy with the results.
What we are looking for right now is trying to automate that process.
We have been using a rip called Colorgate Productionserver 7. This rip have hot folder workflow (wich is what we want) BUT the color conversion is not the same as the one that Photoshop and Indesign have (using the same input profile, rendering intents and output profile).
We have been doing much testing with rgb images and we don´t like how this rip converts the images to the output profile.
It leaves the pure blacks a little bit more washed out than what the Adobe conversion would do and also if you send the image as a tiff file the rip respects the rendering intent of that queue and converts the image accordingly but when you send that SAME image inside a pdf (whether is cmyk or rgb) the rip WILL ALWAYS use the relative colorimetric conversion (without black point compensation) to do the color conversion regardless of the rendering intent that you have in that queue. Indesign honors embedded profiles, rendering intents and output profiles perfectly.
So what we are looking for is a hot folder-queue based rip that have a color conversion really similar (or the same if possible) as the one of Photoshop or Indesign and have the black point composition option in the rendering intent menu.
I don´t know if Adobe has a similar product or if it has licensed it´s color management to anyone.
Thank you
Palodislow

Hello Palo,
Colorgate has announced, that Productionserver 8 'utilizes the latest Adobe PDF Print
Engine (APPE) by default':
http://www.colorgate.com/en/rip-software/rip-software/productionserver-8.html?aktPos=20
May be you'll get then the desired 100% compatibility...
I am using version 6. I could stabilize my processes by simplifying the workflows for PDFs.:
Just one color space for RGB images, just one color space for CMYK components,
explicit assignment of the two profiles, explicit assignment of the two rendering intents.
No use of embedded profiles and hopefully no use of InDesign's general color settings,
which may be in contradiction to the settings in Productionserver. My InDesign PDFs
are generally made for Leave Colors Unchanged.
I had discussed some issues with Colorgate: printing of Lab components and printing
of images by K-only (black and gray inks). The company is cooperative, but it's obviously
impossible to clarify the extremely complex workflows just by post and e-mail.
My experiences, which are as well based on two other RIPs (years ago), are laid down
here, a preliminary version finished just now:
http://docs-hoffmann.de/cmsflow03072013.pdf
Please contact me eventually by private e-mail (last page of doc).
Best regards --Gernot Hoffmann

Where are the rendering intent options found in LR on a Mac?

I can't find the dialog to set the rendering intent when printing from Lightroom. How do I change from Perceptual to Relative Colormetric or visa versa? (Also, how do I change the type of paper I'm using, etc.)
I'm using LR 1.3 on Mac OS X 10.5 on a MacBook Pro, printing to a Canon Pixma iP1800.

Read that link and the user generated content: http://learn.adobe.com/wiki/display/LR/Set+print+color+management+-+Learn+More
There is lots of good stuff there. In short you have two choices. You either use driver managed, in which case you set up everything as normal in the driver and you make sure you turn ON ICM in the driver. In this case, the driver controls the color management and it depends on the driver whether you get any control over rendering intent. Or you print Lightroom managed. In which case you choose the correct paper and ink density in the driver and turn OFF ICM in the driver. You then manually choose the correct icc profile for the paper/ink settings combination. The latter can be tough as the icc profiles often have very cryptic names and this is where lots of people get it wrong I think. If you let Lightroom manage color, you get the mentioned control over rendering intent and blackpoint compensation.

Rendering intent when displaying, exporting or soft proofing?

I am trying to make use of soft proofing to adjust my images for a given output device for which I have ICC profiles. The two profiles I am playing with are for a Lambda and a Fuji Frontier. The Lambda working space almost fits within Adobe RGB, it exceeds it in only a few places but is noticeably smaller for a number of other colors. The Frontier working space is for most colors a bit smaller than the Lambda and about equal for only a small number of colors. The Frontier working space would also almost fit into sRGB (to give you an impression of its size).
When soft proofing with Aperture, dark greens desaturate more with the larger Lambda working space than with Frontier one. If the rendering intent were relative colorimetric, colors should be clipped more and limited by the smaller working space of the Frontier. If perceptual is used then colors would in general be somewhat more compressed (ie, desaturated) with the smaller Frontier working space. But I see rather the opposite. In short, neither explanation makes sense.
So I tried exporting from Aperture into Adobe RGB and ProPhoto RGB hoping that both would be big enough to contain most of the internal gamut of Aperture in order not to require much compression or clipping when converting from the internal color space of Aperture (I saw no difference between Adobe RGB and ProPhoto RGB in the exported files, so I guess both are large enough for my purposes). And I then converted/soft proofed these files from Photoshop into my two output profiles. More options (different rendering intents, black point compensation) but none seemed to really match what Aperture was soft proofing. I still have a lot of ideas what to try out but if anybody could shed some light on rendering intents and soft proofing with Aperture, it would be very much appreciated.
(A related question, what rendering intent is used when converting colors, let's say defined in the Lab space in Photoshop, to the screen? I guess this is defined in the monitor profile, which in turn is created by the monitor calibration software, and therefore might depend on the latter. I would guess some kind of perceptual, but how the colors are really fitted and converted from the larger Lab color space into the smaller monitor one might very noticeably been different calibration software and will be different again for the monitor profile supplied by Apple.)

I went on about this a little more scientific by creating an image with three rectangles: red, blue and green.
All of them are 100%, e.g. (255, 0, 0). Colorspace: ProPhoto RGB.
Results when exporting the images to AdobeRGB and sRGB, concentrating on the reds:
- sRGB looks very washed out
- AdobeRGB looks a bit washed out
- Original ProPhoto has so much red that it almost drives me nuts
Now, I would really expect similar results when activiating soft proofing.
But when selecting either AdobeRGB or sRGB, the reds always drive me nuts.
There is just no difference at all to the original ProPhoto image!
Conclusion 1: Dorin, you were right, previews are in AdobeRGB. What I saw in the reds was the difference between ProPhoto and AdobeRGB. Somehow my screen seems to have extreme reds (calibrated recently with an X-Rite ColorMunki Display).
Conclusion 2: Soft proofing with AdobeRGB and sRGB really DOES NOT WORK!

"paste profile mismatch" ... what rendering intent is used?

When using edit > convert to profile... one can choose 1 of 4 rendering intents (Photoshop CS3).
Does anyone know which 2 of the 4 are used in the following situation ?
paste profile mismatch
You are pasting content copied from a document with a different color profile.
Source: (profile)
Destination: (different profile)
What would you like to do ?
( ) convert (preserve color appearance)
( ) don't convert (preserve color numbers)
My guess is that the second option uses the "absolute colorimetric" rendering intent.
But what about the first option (preserve color appearance) ? Does it use "perceptual" or "relative colorimetric" ?
And in case this issue has not been improved upon in CS4, I'd suggest that the corresponding rendering intent be mentioned in the dialog box (in addition to or instead of the "preserve..." explanation).

The first one converts using the conversion options set in your color settings, under more options. The second doesn't convert, it assigns the destination document color space. No numbers are converted, but their appearance in the new document will change as they take on a different profile.
More about color conversion options:
http://help.adobe.com/en_US/Photoshop/11.0/WS46189F37-21A5-441e-8FF5-A5C35BCEDF67.html
More about rendering intents:
http://help.adobe.com/en_US/Photoshop/11.0/WS6078C298-CB20-4dc8-ACD4-D344110AA026.html

Rendering intent for color conversions

Similar Messages

Maybe you are looking for