I have done a colour profile conversion from ProPhoto to sRGB test comparing different methods in PS, basically Perceptual against the others. I thought the Perceptual colour profile conversion, at the cost of altering some of the colours found in the boundaries of sRGB close to the border with ProPhoto, would reallocate some ProPhoto tones close to those boundaries into sRGB, so colour relationships are maintained in an attempt to keep some colour gradation in the ProPhoto areas out of reach for sRGB.

But nothing of that seemed to happen. I converted a softly graduated patch in the R and G channels (B=128 in all of it, I took one of the central patches in Bruce Lindbloom test chart: Bruce Lindbloom -> Info -> An RGB Image Containing All Possible Colors), R varying from 0 to 255 in columns and G varying from 0 to 255 in rows, making use of all conversion models: Perceptual, Saturation, Rel Colorimetric and Abs Colorimetric, and all of them produced the same pixels going to 0 or 255 in the same channels (R or G).

The conversion was done in 16 bit and converted to 8 bit for output. Anyway I also did the conversion in 16 bit and analysed the 16-bit output image, and the same pixels went black/saturated so it is not a matter of integer rounding.

This is the patch assigned in ProPhoto and converted to sRGB:




These are the pixels where R and/or G channels went black (blue colour) or saturated (red colour) after the conversion:

R . G


And this is the intersection showing in gray colours those pixels that found a non-clippped correspondence in sRGB:




What am I missing? what is actually PS's Perceptual conversion doing?

Regards.

Perceptual in PS

Post #160

A thread entirely worth reading, I missed that one thanks.
BTW what does exactly Shift-Ctrl-Y display? check gamut, in which sense? what's the meaning of the gray areas? (this gray changes when changing the work space)

BR

The Gamut warning (gray by default) is supposed to show you the colors in your image that are not in the gamut of the color space you are soft-proofing (based on the profile you tell the soft-proof dialog to use.

The reason for showing the O.O.G. colors is because there is little way of predicting what they will look like after you convert. My education about that came from sending a Prophoto RGB file with some intense yellow-oranges to be printed on an HPZ3100 with Epson Enhanced Matte paper. The few areas that were3 out of gamut came out reddish and gray in the print. I learned quickly how to soft proof!

See View, Proof Setup. The grey indicates that the color can not be expressed with that profile.

Thanks, I configured it to provide gamut warning over sRGB and produced the same shape as I previously got. Again the correctly converted area doesn't change when changing method.

Because the only valid options when converting from one matrix profile to another (such as sRGB, ProPhoto, etc.) are Relative Colorimetric and Absolute Colorimetric. Any other profile conversion setting is ignored.

GLuijk,
as Jonhathan said, matrix profiles do not have perceptual rendering. When you ask for perceptual, you get relative, and colors outside the destination gamut are clipped.
Pay attention to gamut warning there are many lut profiles that use hybrid intent. Relative well inside the destination gamut and perceptual near the boundaries. So gamut warning can't yield true values near the gamut boundaries.

Jacopo

Ok thanks all, I understand now what soft proofing is.

Going back to the profile conversion itself, I have not yet had time to read carefully the insteresting thread referenced by Panopeeper, but had a rough look at it. Can we conclude then that Perceptual conversion in Photoshop is a bit fake when using matrix defined profiles and is far from the idea to keep textures and gradation even if the destination colour profile is smaller than the original? in such a way as:




And why cannot PS set some interpolated correction when dealing with matrix defined profiles to 'imitate' the desired Perceptual behaviour?

When matrix-based profiles are used in PS, PS always does Relative Colorimetric during conversion (even if Perceptual is selected). Thus when going from ProPhoto to sRGB, the white points are mapped (chromatic adaptation) and then any points that lie outside the sRGB gamut are clipped (these would be negative values in sRGB space or values that exceed 1.0 (in normalized floating-point coordinates)).

Perceptual intent makes no sense for matrix-based profiles.

Right, but the story changes when using the Microsoft ICM engine instead of Adobe ACM for the conversion. I have repeated the tests with the MS algorithms and:
- Perceptual, Saturation and Relative colorimetric yield almost identical results, and they prevent more pixels from clipping after the conversion than the Adobe engine.
- And now Absolute colorimetric works different: it prevents more pixels to go 0 than the former three, but it saturates more pixels even than the Adobe engine:

This is the result of the same conversion as before, I took the R channel:




To see the differences compared to Adobe ACM engine, I overlaped in layers and difference (or substraction, no idea how is in the English PS) blending mode the result of the MS conversions and the Adobe ACM:

Sure it does, but you're still NOT getting any perceptual mapping. Its impossible. There's no table to do so.

how are non-matrix profiles codified? they are made of 3 curves? they are made of some 3D mapping? and why is possible to implement perceptual mapping on them and not through a mathematically defined matrix?

Sorry for such basic questions but I am very new to these matters.

BR

Hi,

A perceptual transform in an ICC profile is usually a multidimensional (often 3D) lookup table. In general, however, it can be a concatenation of several individual transforms (e.g., a matrix multiplication, followed by a set of 1D linear curves, followed by a multidimensional lookup table, followed by another set of 1D linear curves).

When you consider the perceptual intent as implemented, say, in a standard ICC printer profile, it's basically all done with the lookup table.

Impossible is a bit of an overstatement. Currently in Photoshop with the Adobe CMM perceptual rendering when converting matrix profiles may not be possible since there are no lookup tables, but that does not mean that a smarter CMS could not do the job.

Profiling a device such as a printer requires quantifying the characteristics of the device. Since printers are not well behaved devices, it is difficult to characterize them mathematically and lookup tables are a convenient brute force method of characterizing them.

Matrix spaces are mathematically defined and are fully characterized by their parameters. A smart CMS should have no trouble in converting from ProPhotoRGB to sRGB with perceptual rendering. The required gamut compression could be performed mathematically rather than derived from a lookup table.

Steve Upton discusses smart CMSs in a white paper. He describes the current situation as "smart profiles, dumb CMSs". Dumb CMSs do not even look at the colors actually present in the image and perform a fixed amount of compression when doing perceptual rendering even if the image contains no out of gamut colors in the source space. I do not know if the Microsoft WCS can perform an intelligent perceptual rendering from ProPhotoRGB to sRGB without lookup tables. However, the task should be possible with a sufficiently smart CMS.

Another way to perform the perceptual rendering would be for some enterprising color expert to make a set of lookup tables for the above purpose.

Some readers might find this thread on Photo.net interesting. It discusses some of the above, but reaches no conclusion.

Bill

Yes and perhaps with a smatter CMM, pigs could fly too.

If you feel better if I say "with the current CMM, its not possible", fine. I'd hate to mince words with you lurking around....

calm down men.

On ICC web site there is a V4 sRGB profile (beta version).

Jacopo

Yup, and I have access to other working space profiles that follow this too, providing now other options. No need for Uber flying pig CMM's. But today, with V2 profiles, you can have any rendering intent you wish from simple matrix profiles, as long as its Colorimetric.

Now what would be a useful question for Eric, if he can speak about this is, when we might see the one application that would move V4 profiles forward, Photoshop? If and when the more common working space profiles are installed as V4 profiles, only then will they take off in any meaningful way.

This subject was heavily discussed back in 2004/06 when ProPhoto RGB became popular. Just went over a couple of saved threads, and there are essentially two questions which seem to remain unsolved:

Would we like “Perceptual“ at all, if available say for ProPhoto RGB to sRGB conversion ?

/> There was Oscar Rysdyk’s proposal for a CMM based color clipping algorithm rather than channel clipping:
http://www.theimagingfactory.com/excalibur/clipping.htm

/> There was ICC3D from a graduate of the Norwegian Color Research Laboratory:
http://www.colorlab.no/icc3d

/> Not to forget PhotoGamut RGB which is a Lut-type RGB working space:
http://www.photogamut.org/E_ICC_profile.html

/> Fwiw: here’s another proposal on this (post #24):
http://luminous-landscape.com/forum/index....pic=10883&st=23

and in addition there are many different ways for manually operated editing and a selective reduction of color saturation towards & inwards a tiny target space such as sRGB. All in all I’m staying unconvinced.


Another fundamental question is about the relevance with regard to real-world images. How to quantify the degree of image degradation due to RelCol conversion ? Often enough, image details seem to bear sufficient differences on the lightness channel to survive a reduction of chroma contrast as introduced by the RelCol intent. For sure, the amount of channel clipping as indicated by the RGB histogram is quite meaningless.


That said, here’s interesting quote about the capabilities of color engines:

“Devices such as digital cameras and printers perform embedded (typically proprietary) perceptual renderings to and from standard color encodings like sRGB. … Finally, a color management system (CMS) may offer color rendering or re-rendering capabilities beyond that built into any source and destination profiles.”
http://www.color.org/ICC_white_paper_2_Per...g_use_cases.pdf


Peter

--

Personally, I would rather leave the perceptual mapping defined by the profile rather than the CMM, because:

- it allows multiple perceptual mappings (each one stored in a separate profile) to be available, giving the user a choice as to which one to use for a particular image, and

- it allows all such perceptual mappings to be shared across CMMs

As an analogy, Bill Atkinson has several profiles available for the 9800, built from the same measurement data but using different software & software options. They can be used across CMMs. For a given image, the user can decide which profile produces the most pleasing perceptual rendering.

Andrew, sorry I don't any answer to you for your specific question. I am actually not that familiar directly with PS plans, since I don't interact with that group directly.

No worries. I think it might be some time before V4 Working space profiles are ready for prime time (or for Adobe to install them).

>> Peter, … I'm not really a believer in Perceptual rendering, at least in the ICC implementation. A perceptual rendering that handles all images identically seems guaranteed to fail on a majority of them, and that has pretty much been my experience. Maybe if we had a much smarter CMM that actually looked at the image rather than the space in which it resides, we could do adaptive perceptual renderings that actually worked, but I'm the last person on the planet to try to convince Tom Knoll that he needs to introduce systematic errors in ACR's colorimetry. He seems to feel pretty much the same way I do about perceptual rendering anyway.<<

Cited from a RG forum discussion, August 2005, by Bruce Faser
(sorry, the link doesn’t work anymore).

Peter

--

At this point I think we're getting into the semantics. Either we would have (1) a bunch of profiles generated offline and then pick the one at runtime that we want to use for a given image, or (2) have a CMM that will generate image-dependent profiles on-the-fly, provided this could be done fast enough.

Image-dependent gamut-mapping has been covered in the research literature but hasn't found its way to market in a standardized form yet.

(1) not sure if I want to see a bunch of different profiles for standard encodings such sRGB or Adobe RGB, respectively, as for the target space.

(2) a smart CMM would selectively treat those oog colors which are really given in an image, rather than trying to compress the whole source space such as ProPhoto RGB, this or that way, into a smaller target space. Can’t see how to realize this with (1). Even if we go for a smaller source space assumption with the Lut for perceptial compression, there’s no differentiation by color range & hue angle.

Nonetheless, the key challenge I see is to improve RelCol at all. This might require a very smart CMM which recognizes what we perceive as posterization – very color range selective, very dependent on the image content and very smooth regarding the degree of moving colors “inwards”.

Peter

--

Actually, RelCol should need no tweaks, its a colorimetric intent. All profiles, in theory should produce the same values using this intent, unlike Perceptual, which is supposed to have some secrete sauce built into it by the profile building software (hence the reason we have no less than three options in ProfileMaker Pro for doing this). Every manufacturers Perceptual rendering can be, and probably IS different. I'm not suggesting this is an elegant solution, but a colorimetric intent should be a strictly defined process.

What is a "matrix profile"? Is Epson printer's media profile one?

I recall reading somewhere that while there are definitions for intents, the profile vendors can build profiles according to their whims. And don't tell you exactly how they do it.

A matrix profile is a profile that include a matrix to go from RGB to PCS (XYZ or Lab) and back.
In other words RGB are linear combination of PCS coordinates.

Every synthetic color space (sRGB,Adobe 1998, ProPhoto,....) is generate from XYZ fixing the Red,Green,Blue,White and gamma.

Printing profile are Lut profile.
A lut profile has up to 3 tables that correlate RGB values to PCS coordinates.
This is a semplified schema: you can have a mix of lut and matrices.

ICC specs fix a framework and rules for profiles, but the true profile creation is vendor specific.

Jacopo

It is usually wise to to a Google search:

http://www.ppmag.com/reviews/200501_rodneycm.pdf

So any conversion involving an origin or destination matrix profile cannot be applied using other than Relative Colorimetric? or that's only for the origin? or that's only for the destination?

e.g.: from sRGB to a printer table based ICC profile?
from a camera table based ICC profile to sRGB?
any of those can be Perceptual or none?

Thanks for the link Bill

No.

When you transform colors from an original color space into a different color space, 2 profiles are involved: the original (colorspace1) and the detination profile (colorspace2).

2 steps are performed:
- step1: from colorspace1 to Lab (or XYZ) D50
- step2: from Lab (or XYZ) D50 to colorspace2

The Lab (or XYZ) D50 is the PCS (Profile Connection Space) fixed by ICC

So, if you go from sRGB to printer profile, the following steps are perfomed:
- step1: from sRGB to XYZ D50 (relative)
- step2: from XYZ D50 to printer color space (perceptual or relative,depending on user selection)

Jacopo

And a conversion from a table colour space (like a camera calibration profile for instance) into a matrix colour space (like sRGB) would also allow a real Perceptual conversion in the step 1 from camera to XYZ, and relative in step 2 from XYZ to sRGB?

BR

Yes, if camera profile has a perceptual intent embedded.

But camera profile does not knows the destination color space, so I think it is useless.

Jacopo

Yes, but how? There are an infinite number of ways to perform this transformation. No single method is perfect for all images. As Andrew said, every profile-building software has its own secret sauce for creating perceptual mappings. It all depends on the color optimization metric being used.

A smart CMM that picks one particular method of performing perceptual mappings would be great as long as you agreed that its results were good for your images. But it wouldn't be so great for someone else who doesn't like its results.

To get around this issue, a smart CMM could offer multiple options for doing perceptual mappings, letting the user choose on an image-by-image basis which one works best. But that is not that different from having multiple pre-baked perceptual profiles in the first place. That was the point I'm trying to make.

One could apply perceptual rendering in step 1, camera space to XYZ, but it would not make sense. The purpose of perceptual rendering is to map out of gamut colors in a larger color space into a smaller space. Since XYZ is a large space and it contains all the colors that humans can see, there is no need to map the camera space into XYZ.

As Bruce Fraser explains in this link on the Adobe forum, the current dumb perceptual rendering has no knowledge of the source space or how much of it is populated by colors actually in the image. It merely compresses the source colors by a predetermined amount whether such compression is needed or not. If the source contains no out of gamut colors, this is not desirable.

" Given the many limitations of perceptual rendering (ignorance of source space, ignorance of how much of the source space is actually populated by the image, treating a black cat in a coal cellar and a polar bear on an ice floe identically, etc), I generally find that when a straight relcol conversion from PPRGB to sRGB fails in some regard, it's easier to simply edit the file than to come up with a magic rendering that works for all images."

With Camera Raw many use ProPhotoRGB as their default color space. If you need the final image to be in sRGB, it would probably be easier to use the ACR controls to map the colors into the sRGB space without clipping rather than initially rendering into ProPhoto and subsequently editing the image in Photoshop.

If you are working in Lightroom, the clipping display is for ProPhotoRGB (actually Mellisa), you don't have this option. The clipping will occur when you export the image to sRGB.

Bill

Sounds like a wonderful and reasonable idea. Are there any profile vendors who offer "multiple pre-baked perceptual profiles"?

Like many tools (sharpner, noise reducer, stitcher), to get the best results from them, different image types need different settings/tweakings. One size does not fit all.

ProfileMaker Pro offers three "tweaks". Only one I find useful (Colorful).

> Are there any profile vendors who offer "multiple pre-baked perceptual profiles"?

Practically all packages make a silent assumption on source color space.
The free Argyll CMS (command line based) allows you to specify the source color space (sRGB, aRGB etc.) when creating the perceptual intent.

The analogy here is the one I posted earlier in the thread: Bill Atkinson providing several profiles for the printer/paper combos he's profiled. For example, consider the Epson 9800 with Premium Luster. He put a lot of effort into getting a set of solid, clean measurements, then used that data to generate several profiles, using different software & software options. He calls this a "bouquet" of profiles. So when it comes to making a print, you turn on soft proofing and flip through the profiles and pick the one that works best for that image.

Bill, I was looking into DCRAW's source code but I feel a bit lost to answer this: DCRAW uses Camera -> XYZ matrices (provided to Coffin by Adobe), and then another transformation XYZ -> output colour space used. In fact both matrices are multiplied in advance to do Camera -> output colour space in just one step.

The question is: is it possible that the exposure level of a given pixel has an influence to determina whether it will fall inside or outside the output colour profile space?

Think of a pixel in a scene captured with RGB levels=(10,22,45), if it was shot 1 f-stop more exposed, for sensor linearity it would be coded as (20,44,90).
Is it possible that (10,22,45) when converted to the output colour space falls into sRGB gamut, but (20,44,90) gets clipped in sRGB?

I want to believe then that if (20,44,90) clips in the output colour profile but (10,22,45) doesn't clip, is just for saturation (luminosity) reasons, not because the Hue determined by the pixel of the scene can alternatively belong to or not belong to the output profile gamut. Right?

If the answer to all that is yes, it means the degree of exposure of the RAW data will affect the possibility of converting levels on a pixel to a given output colour profile, so the Exposure slider in ACR is a good tool, not only to cancel the effect of the white balance, but also to avoid clipping due to excesive input exposure.

Am I right?

BR

Guillermo,

Yes, the exposure can affect saturation clipping as shown in this example. This composition was given two exposures differing by one f/stop. With the greater exposure, the red channel exhibits saturation clipping in sRGB and this is eliminated by giving one stop less exposure. However, the picture is too dark. One can achieve the same effect by using -1 EV exposure compensation in ACR (not shown). In this case, it is better to use ProPhotoRGB in the properly exposed image.

Clipping in red channel
Click to view attachment

Clipping display in ACR
Click to view attachment

Image with 1 EV less exposure in camera
Click to view attachment

ProPhotoRGB, proper exposure
Click to view attachment

Examination of the raw file of the properly exposed image shows that none of the channels are clipped in the raw file. The RGB multipliers for white balance are RGB 2.648, 1.0, 1.356 as shown by DCraw.

Raw histogram:
Click to view attachment

Good example of the use (and need) of large work spaces for certain pictures. This makes me think that all those endless discusions about sRGB vs AdobeRGB vs ProPhoto RGB simply have no general answer since the appropiate work space will depend on input scene and output application gamuts.
And we have to add to that tradeoff the fact that there is currently not a proper Perceptual conversion implementation.

Thanks Bill.

GLuijk, in principle you would want to use the smallest working space that holds all the colors you need for the given image. So in that sense you are correct, it's image-dependent. In practice it's easier in a photographer's workflow to pick one, so which one? We all know the drawback of a small space is tendency to clip colors, and the drawback of a large space is potentially insufficient precision to get smooth tones. So my general recommendation is to decide for yourself which of these two is the lesser evil. In a final print, can you tell the difference between images processed identically but using different working spaces?

The final print made on a printer of 3 years past, today or one we'll use in a year? We've seen how the gamut capabilities of just Epson inks has changed over the course of a very few years, most users want to revisit an image they worked on and maybe reprint it later. That said, I want a big honking working space!

This by article by Steve Upton implies that the new color management system in Windows Vista may alleviate some of the problems with perceptual rendering. Unfortunately few graphic artists use Windows and few Windows users run Vista. Perhaps someone can comment.

Bill