Rendering intent

[Thierry]

Hi everybody,

A little question about rendering intent in image processing apps and workflows: do you have a good reason to choose Perceptual and not relative colorimetric? I know that when you want to convert towards a smaller color space, this rendering intent is supposed to give you a better result by keeping intact the relationships between colors.

But with this setting, all images are modified even if it is not necessary (the colors in the CMYK file are modified even when the RGB file presents no out of gamut colors). Therefore, the interest of choosing Perceptual and not relative colorimetric seems to be limited to images presenting difficult (out of gamut) colors but even in this case, the gain doesn't seems visible, according to my tests… What do you think?

Best regards.

THierry

 

[Colorblind]

I always use relative colorimetric intent, the only exception being when I convert to a newspaper profile by using perceptual.

 

[tmiller_iluvprinting]

I always use relative colorimetric when converting CMYK-CMYK, or when an image that is RGB does not present many colors that are outside of the CMYK destination space. I use Perceptual when the RGB image
contains many colors outside of the CMYK destination space and I want to maintain the relationships between the colors. I scan a large amount of original artwork, and the gain is quite visible when you are separating what I like to call 'circus color' artwork.
Regards,
Todd

 

[Thierry]

Thanks for your answers. Todd, it's exactly what I do but it's always nice to see somebody else confirming it.

Regards.

 

[Lukas Engqvist]

I compare perceptual to "zooming out" and relative to "cropping" a subject. It is confusing though that relative conversion is what gives the closest to what the customer perceives as long as the colours are in gamut (need I say Black Point Compensation is a must!) and that perceptual is used to preserve the relative relationships between colours... don't we just love the way we need to approach terminology

 

[rich apollo]

When using a perceptual rendering intent colors aren't changed equally. Colors out at the periphery of the color gamut will change much more than colors close to the neutral axis.

Here I've uploaded a file that's pretty nice for observing the levels lost when converting.

 

[David Milisock]

Relatve BPC on or Off?

Relatve BPC on or Off?

That's the real question, Adobe uses BPC (Black Point Compernsation) on by default. Relative colorimetric with BPC on is very similar to perceptual but not ICC compliant.

Let me suggest this read the definitions of the rendering intents very closely then superimpose a Prophoto RGB color space over any standatd CMYK color space eith a profile editior and apply what you see to the definition. Then make your decision.

I myself use relative colorimetric when the size of the source color space is similar or equal to the destination.

There is no corrrect way to convert an ultra wide RGB color space to a narrow CMYK or even a very narrow RGB color space, I prefer to use perceptual rendering for those situations.

I do this because with these circumstances using relative with BPC off can result in different but similar out of gamut colors rendering so closely in CMYK that you can't tell the difference. Perceptual rendering maintains the preception of these differences in the destination space.

 

[David Milisock]

I compare perceptual to "zooming out" and relative to "cropping" a subject. It is confusing though that relative conversion is what gives the closest to what the customer perceives as long as the colours are in gamut (need I say Black Point Compensation is a must!) and that perceptual is used to preserve the relative relationships between colours... don't we just love the way we need to approach terminology

I agree if you relative colorimetric BPC on is a must but it is not ICC complaint and the result many times is very close to perceptual, however perceptual is ICC comliant. At least BPC was not compliant the last time I checked, I know there has been some discussion.

 

[TerryWyse]

I agree if you relative colorimetric BPC on is a must but it is not ICC complaint and the result many times is very close to perceptual, however perceptual is ICC comliant.

I think if the goal is quality rendering of images, then whether or not something is "ICC compliant" or not is pretty moot. In any case, BPC is nearly a de-facto option these days, not only in Adobe products but in many others including proofing RIPs.

But I digress....

The only point I wanted to make was regarding large or "ultra-wide" RGB spaces. Like you alluded to Thierry, just because an RGB image is tagged with ProPhotoRGB or some other wide gamut space, that doesn't mean the image is actually USING all that color gamut ("gamut volume"). I've plotted enough ProPhoto images in ColorThink and can tell you very few make use of the extra available color gamut....I would dare say few photographic images will use much beyond a sRGB/AdobeRGB gamut, at least in their original un-edited form. It's possible of course that someone could take a normal photographic image and then edit in such a way (Saturation mainly) that it might push the image beyond it's "natural" bounds and start using some of the extra gamut available to it in something like ProPhoto. HDR-processed photos might be an example that would more-or-less naturally exceed sRGB/AdobeRGB...but other than that, it's not all that likely that a photo would extend into something as large as ProPhotoRGB.

Point being, I would worry much more about the *destination* color space being too small (newsprint, uncoated offset, etc.) than the RGB image being too "large" by virtue of the profile it's tagged with and choose the rendering intent accordingly. In other words, probably any image going to newsprint, I'd be thinking perceptual...but if I were converting to something like GRACoL Coated1 or ISO Coated, I'd be thinking relative colorimetric + BPC no matter what color space the RGB image was tagged with.

Just my inflation-adjusted 3 dE worth,
Terry

 

[David Milisock]

I think if the goal is quality rendering of images, then whether or not something is "ICC compliant" or not is pretty moot. In any case, BPC is nearly a de-facto option these days, not only in Adobe products but in many others including proofing RIPs.

But I digress....

The only point I wanted to make was regarding large or "ultra-wide" RGB spaces. Like you alluded to Thierry, just because an RGB image is tagged with ProPhotoRGB or some other wide gamut space, that doesn't mean the image is actually USING all that color gamut ("gamut volume"). I've plotted enough ProPhoto images in ColorThink and can tell you very few make use of the extra available color gamut....I would dare say few photographic images will use much beyond a sRGB/AdobeRGB gamut, at least in their original un-edited form. It's possible of course that someone could take a normal photographic image and then edit in such a way (Saturation mainly) that it might push the image beyond it's "natural" bounds and start using some of the extra gamut available to it in something like ProPhoto. HDR-processed photos might be an example that would more-or-less naturally exceed sRGB/AdobeRGB...but other than that, it's not all that likely that a photo would extend into something as large as ProPhotoRGB.

Point being, I would worry much more about the *destination* color space being too small (newsprint, uncoated offset, etc.) than the RGB image being too "large" by virtue of the profile it's tagged with and choose the rendering intent accordingly. In other words, probably any image going to newsprint, I'd be thinking perceptual...but if I were converting to something like GRACoL Coated1 or ISO Coated, I'd be thinking relative colorimetric + BPC no matter what color space the RGB image was tagged with.

Just my inflation-adjusted 3 dE worth,
Terry

I think you make an excellent point about the content of the capture. Just because it's prophoto does not mean that it uses all the gamut of the color space. Where I've seen issues where more of the gamut was used were in the case of captures of floral arrangements and promotion pieces where the lighting was wide gamut. Such is the case for casinos, some signage for malls and the such.

More importantly while BPC may be defacto it is only such for those who are in the Adobe world only which is not the case in point for some global locations and work flows specifically signage and some art renderings.

Using the relative colorimetric rendering intent with BPC will provide conversions that cannot be duplicated in other applications that are ICC compliant. How much that matters depends on the user. One example with quality images may be theatrical story boards done in Painter, I can hardly see that it would matter for many of the lower cost graphic applications. In reality the question is how much can it matter? Most likely not that much judging by the standards we see applied by many in the graphic industry. However with that said perceptual rendering will be compliant across the entire range of ICC compliant graphic applications. That's what the ICC standards were supposed to be about.

If the image uses a large portion of an ultra wide gamut then you will want BPC on if you use the relative colorimetric conversion, BPC has no use with perceptual rendering. In addition you may even want to step the conversions from ultra wide RGB to a more narrow RGB like Adobe then to CMYK with perceptual or relative with BPC on. It depends on the image and how picky you are.

As said I use Relative colorimetric with BPC off only and then only for source and destinations that are nearly identical in gamut size.

Perceptual rendering is used by me for any wide gamut to narrow gamut conversions because it maintains the spacial relationship of source color in the destination space. It allows you to maintain the art when applying the science of color.

I've heard programmers state that in their opinion BPC was Adobes way of handling the problems that ICC color management had with the GDI. It does solve the problem but at a cost.