Yes I have tried that and what would have clipped with AdobeRGB was clipping in ProPhoto anyway (Epson 1290 Premium Photo Glossy and a bit less in heavy matt).

SO not an issue with the current printer. I guess it may be an issue for future printers.

Thanks for the links everyone, I will study these.

Jonathan, from my posts above - based on what I've heard at seminars and read about this matter we're on the same wave length about using proPhoto, but the thing that really intrigues me is how relatively small are the color gamuts of our printers  - seemingly ALMOST to the point that differences in gamut shape could still have some effect for some hues, but perhaps with very low probability of occurrence - oh, and by the way, next time I need expert advice on the anatomy of a weasel I'll know where to turn.

Why are you so scared to get lost Paul ;-) ? You probably didn't get lost in aRGB and you won't in ProPhoto (as long as you edit sensibly, which of course applies to aRGB too).

I also would like to add 2 comments that Bruce Fraser wrote on the Adobe forums.

Comment 1:
- adds info to DigiDog's comment "As for the idea of a wider space only being useful for very saturated colors, there’s more to it than that"
- addresses clipping



Comment 2 on bit depth:



Herman

-->To comment on my question:  Yes, those silent assumptions exist, but ... “That is closely held secret by GMB. Likewise with Monaco/X-Rite. The color space assumptions in ProfileMaker differ based on the parameters used when the profiles are construed.” (by Ethan Hansen).
If anyone knows more, please post.

By the time an output profile “gets” data, it’s gone through the PCS and is in LAB. So if I’m understanding where you’re coming from, I'd say again that the output profile has no real idea what the incoming data is as far as the original RGB color space (sRGB, ProPhoto etc). The conversion takes place like this; working space (let’s say sRGB for one file, ProPhoto for another) converted to LAB by the CMM. That’s the device independent color space used by the PCS. LAB to output profile now takes place. So the output profile has no idea if the LAB data came specifically from sRGB or ProPhoto RGB. Yes, the data is different for obvious reasons and yes, with some imagery, the smaller color space CAN be somewhat beneficial. But the CMS as yet has no provisions to know this. The output profile is simply getting LAB values to work with.

The opposite is the case with device links. I’ve never seen one that works RGB to RGB but haven’t really looked or tried to build an RGB device profile since I don’t know what that would bring to the party (and Photoshop and many other ICC aware applications can’t handle Device Links). But with a device link, the advantage is you can produce a CMYK to CMYK conversion without a trip into LAB; there’s no PCS in the process. This is useful when doing CMYK to CMYK conversions because you can retain the black generation. When you do this using ICC profiles, there’s a trip into LAB, the black generation is hosed. So with device links, there’s a direct relationship between source and destination but for a specific reason.

-->Today’s printer resp. printer profiles are not prepared for the case the we come along with a heavy-loaded file in ProPhotoRGB.

I don’t see it that way. It really doesn’t matter. The printer has a fixed gamut. The original data has a fixed gamut. You want (or maybe you don’t want but I do want) all the color the capture device was capable of producing. Printer A may be able to use 80%, printer B may only be able to use 60%. That’s just the facts of life and you either have a source space that contains the colors or you don’t. This isn’t going to affect the printer; a smaller source isn’t going to allow you do reproduce any more colors (only less). So I don’t see why originally containing less colors versus more is any way a factor here.

-->The mantra "use ProPhotoRGB to avoid channel clipping“ is akin of self-fulfilling prophecy, because ACR doesn’t support any other rendering option (yet). Hence, all the burden of a perceptual de-saturation is imposed either to the operator or to the printer profile….

There’s only one rendering intent (actually one table, two intents) you can use with matrix profiles (Adobe RGB (1998), ProPhoto etc) and that’s colorimetric. If you’re asking for some kind of protectoral option, I guess that’s reasonable and I don’t know enough to say if that’s doable or useful. But the facts are, we have capture devices that can produce a very wide gamut of colors and tones we probably can’t output today and maybe never will.

-->Could the industry please kindly sort this out without involving us customers. Not everyone loves to fiddle with the Hue&Sat.-tool or the Channel Mixer to tame out-of-gamut colors.

Out of gamut colors are a fact of life and users need to decide how they wish to handle them. There is no one-size fits all conversion. That’s why we have different rendering intents, soft proofing and tools like Photoshop to attempt to produce a reproducing on a smaller gamut, lower dynamic range output device to fit our idea of what the image should look like.

We’ve never been able to reproduce the gamut and range of a transparency on print but that didn’t stop people from making beautiful representations of the film for years.

-->“Devices such as digital cameras and printers perform embedded (typically proprietary) perceptual renderings to and from standard color encodings like sRGB.

I’m not sure what that brings to the discussion. I suggest you read the white paper there (which I co-authored) which discusses the processes of in camera rendering and encoding.

http://www.color.org/ICC_whi....ics.pdf

Jeff,

Two questions please; one technical and one workflow-related.

The Color Range tool offers an option to select “Out Of Gamut” colors.  Which target profile does it refer to?  It seems that the selection differs considerably from the SoftProof / out-of-gamut marks.


After you’ve processed a file through Camera Raw (ProPhotoRGB, 16 bit), do you instantly enable the SoftProof to the printer/media profile, or is there an editing step in-between based on “normal” presentation on screen?

Peter

--

pom, of course you're joking.........no way I would let these arcane esoterics deprive me of the benefits of digital.

Peter - fine, the same thing with added detail, but so what? The bottom line is that anyone claiming a significant downside to working in Prophoto color space needs to demonstrate in normal photographic prints that rendering intents have a differentially negative impact on posterization as you move from smaller to larger embedded or working color spaces relative to the (fixed size) output color space. It is not clear in principle and where is the practical real-life evidence?

The sat slider of the PS hue/sat tool required less adjustment to remove all of the grayed-out areas (-68 for sRGB as opposed to -71 for the ARGB image and -62 for PP), all in relation to the Bill Atkinson Prem Gloss profile.

No, I was referring to the Gamut Warning option in the same menu that places an ugly gray (by default) mask over out of gamut colors. That’s not the same as using the Soft Proof with an output profile.

Yes Ray, I think we have all been through that stage!!!

I appreciate your observations on predictability of shadow detail using Gamut Warning vs Soft Proof when switching rendering intent. I haven't made this exact comparison, so it will be interesting to see Andrew's comment on this.

Does anyone use the 'saturation' intent for photos, as opposed to graphics? I find that with some images, perceptual or relcol produces a significant dulling effect with proof colors (on screen) but not with 'saturation'.

Okay! So it's 281 British billion. That's an even more unrealistic figure. You'd need a Supercomputer and a lot more than Photoshop to handle an image containing all those colors. Does a few billion make any difference in such circumstances, apart from slowing everything to a crawl.

Which is approximately 135x the maximum size the TIFF file format can support.  :D

Is anyone out there using ProPhotoRGB instead of AdobeRGB?

I notice I get a lot less trouble with clipped coloured  highlights in ACR using the wider ProPhoto.

What's the pro's and con's?

Maybe he’s photographing canaries and doesn’t mind huge steps in color tone. All you get is 256 tones REGARDLESS of the color space (sRGB, Adobe1998, or ProPhoto). Stretch 256 tones over a large color gamut and banding could be troublesome. Depends on the photo. Further, your eye is more sensitive to color contrast than to absolute color. Your eyes adjust just fine to tungsten light even though the full spectrum colors are way off. A smooth transition in a sunset spectrum or the iridescence in a feather is more pleasing than a blotchy long jump to the next shade.

The academic argument for ProPhoto is far from a decided issue. In the end, it’s all in the print.

If you load a soft proof of your output device and then in the Info palette use Proof Colors, you can see the effect on that device (not SWOP).

As for the idea of a wider space only being useful for very saturated colors, there’s more to it than that. Due to the simple shape of these synthetic working spaces, many, especially those that are not real large don’t produce a good fit for the output device gamut, especially saturated colors in the output space that are very dark. If you look at good 3D maps, you see this. So in order to fit these colors, the primaries are (like ProPhoto RGB) stretched out to accommodate these areas. That’s one reason when you look at even a 2D plot of ProPhoto you see the Blue falling outside the CIE chromaticity diagram (it’s by design of course).

Hermi, You are right! That's exactly my point. Only working in Adobe1998 you have less room to get lost in compared to ProPhoto.

I actually went to read up on this article and without going to far, found this:

-->All colour spaces of the same bit depth (typically 8 or 16 bit) have the same total number of tones. That is, a bigger colour space does not mean there are more colours in total!

That’s not really so. This is a fundamental misunderstanding of what a color space is. So I’ll do a quick copy and paste from some text I wrote:

What is a color space? Think of it this way: suppose I supply a recipe for chocolate chip cookies but do not provide the unit for each ingredient in the recipe. The recipe provides each ingredient followed by a number. Without units you can’t make the cookies. The numbers alone are not enough information to describe how the cookies that will be produced. Likewise, R78/G103/B23  or C23/M98/M123/K6 is not enough information to reproduce that color.

Going back to the chocolate chip cookie analogy, suppose a color model is a cookie recipe with only three ingredients. I give you this recipe, which simply calls for 1-flour, 8-butter and 2-chocolate chips. You don’t have enough information to make the cookies. However if I provide you the recipe with a specific scale—1 cup of flour, 8 tablespoons of butter, and 2 cups of chocolate chips—I’ve provided the necessary information, the scale, to make a dozen chocolate chip cookies. I can give you the cookie recipe in the metric scale such as liters and grams and you can still makes the same cookies even though the numbers are different. A color space is a color model that has a known reference and scale, in this case primaries (the ingredients) and scale (specific quantities of these ingredients).

Suppose I specify a color as R10/G130/B50 and specify a color reference by saying the color space is Adobe RGB (1998), which defines the scale of the RGB primaries; the color coordinates of this color space. The R10/G130/B50 set of numbers can now reproduce a color by anyone with the proper tools since the reference and scale have been defined. Different RGB color spaces use a different scale of red, green, and blue primaries. Adobe RGB (1998) and sRGB  are different color spaces, however both are based on the RGB color model using RGB primaries. Although each color space uses the same three primary ingredients (R, G, and , the specific colorimetric scale of each color space is different. The maximum of red, green, and blue are more saturated in the Adobe RGB (1998) color space than the sRGB color space. Even though R0/G255/B0 is the greenest green ingredient in both Adobe RGB (1998) and sRGB, knowing that the scale is different in both color spaces explains why this green value is more saturated in Adobe RGB (1998). This also illustrates how R0/G255/B0 alone can’t tell us what green.

An ICC profile simply defines this scale and gives the numbers a meaning allowing us to reproduce the color using something far more concrete than using the English word "Green" or a set of numbers which alone is far too ambiguous to produce a specific color appearance.

-----

So going back to “That is, a bigger colour space does not mean there are more colours in total” the issue here is saturation of the primary colors (RGB in this case). Yes, R255 in sRGB and ProPhoto RGB share the same number but most certainly not the same scale.

Mark,

Referring to point (b.), there are two different mechanisms involved:

Posterization is supported by large spaces with high gamma at low bit depth.  For me, it’s a non-issue with ProPhotoRGB at 16-12 bit/ch.

Posterization is a real-world threat (IMO), when you convert a large space such as ProPhotoRGB (including rich colors) to a printer/media profile.  All the color space volume in-between the source and the target space is collapsed on surface of the latter one.  It’s often easily obvious from the print that exactly those out-of-gamut colors why we like to use a large working space have lost details.

Therefore it seems to be required to edit & de-saturate said out-of-colors by hand “into” the printer/media space.

Peter

--

The last time I tried to do some comparison print tests between perceptual and relative colorimetric with an image with out of gamut colors, I couldn't see any differences. The explanataion at the time was (about a couple of years ago) that unless the paper/printer profile you are using addressed such issues when it was built, then you won't see any difference.

My general feeling is, there's a lot of stuff that's supposed to have an effect in theory, but in practice the effect can be either insignificant or completely dwarfed by other greater influences.

That's why it's necessary to test things for yourself. Don't take anything on trust  :) .

Assigning the profiles would of course change the color appearance from prior to the assignment. The soft proof would look different as well. When you Assign a profile, you change the meaning of the numbers so Photoshop updates the preview based on those new definitions (even though the numbers are the same).

I’m not sure what you mean “the sRGB image required less desaturation”.

No - you could NOT have been referring to the Gamut Warning in that sentence, or you put that sentence in the wrong paragraph, or I don't understand. Please re-read your paragraph in which you have that sentence I quoted about converting in one step, then please re-read my question and let me know if you would like to revise that answer.

It sure does if you want to save ink and paper. I've been through the stage of wasting lots of that.

I'll give you an example from the last time I tried comparing 'perceptual' and 'relcol'. I was using Epson's profiles for Premium Gloss and Photopaper on the 1290. I knew premium gloss claimed to have a wider gamut than photopaper, and the gamut warning showed it in proof setup. The images on screen looked very similar for both profiles, but the gamut warning showed heaps of gray blotches in the shadows with proof setup set to the Photopaper profile. With the Prem Gloss profile, there was just the barest hint of gray specks. This out-of-gamut warning was confined to the shadows and I was interested to see how the different rendering intents of preceptual and relcol would handle this.

I could see no significant differences in the two rendering intents, but there sure was a big difference in shadow detail in the two prints.

Premium Gloss produced shadows with good detail as seen with proof colors on screen. The same image printed on Photopaper showed blocked up shadows. The Photopaper print was a waste of ink and paper, yet there was nothing I could see using proof setup, apart from the gamut warning, that would indicate I would possibly get blocked shadows.

I'm simply asking Andrew, in this situation I've described, how could I forsee that the shadows on Photopaper might be blocked up, without using the gamut warning. What's the alternative technique?

Depending on the profile (how it’s built, the package that built it), it can work well. So I would not dismiss it outright.

Interesting discussion. I shall now stick my head out - by sticking my two-cents-worth in. I have no doubt I shall be summarily corrected if I am wrong. My understanding is that a color space is not measured in the same way a digital image is measured. A color space is measured by its CIExy co-ordinates. It is device independent and has nothing to do with pixels and number of discrete HSB values in a digital image file.

Turning to capture devices, the maximum number of individual HSB values any pixel represented by the photosites in the sensor can capture depends on pixel bit depth. For example, a Canon 1Ds has a sensor of bit depth = 12, hence each pixel can theoretically contain any one of 68.7 billion hues [(2^12 per channel)^3 channels]. But since there can be only one HSB value per pixel, the maximum number of different HSB values the image will contain depends approximately on the sensor's pixel dimensions: e.g. on the Canon 1Ds 11.1 MP.

See Blatner/Fraser Real World Photoshop page 171, where it is explained aproximately as follows: if image capture is in 8 bit mode there are 256 possible values per channel, regardless of the working space. The larger the color space the more these values get stretched over that space and the higher the risk of banding from image adjustments that reduce levels. A 16 bit image virtually eliminates that danger because there are exponentially more color values, hence exponentially less stretching of those color values over the color space whatever the CIExy contours of the color space. They advise selecting the working space that is an appropriate balance between gamut size and editing headroom, noting that with 16 bit images there is no issue.

I conclude from this little assembly of information that I can happily work in ProPhoto color space with my 16 bit files, but if I worked with 8 bit images that need major editing, I could be safer using something smaller such as ARGB98.

I’d say so, most certainly!

Take a look on the Adobe forums e.g.:

http://www.adobeforums.com/cgi-bin....bb5f89c

http://www.adobeforums.com/cgi-bin....bbabc37

See also Mike Chaney (Qimage) and Andrew Rodney (Digital Dog):

http://forums.dpreview.com/forums....3979411

Andrew Rodney's reply is key here:

"Yup, if in ACR I see clipping in say Adobe RGB (1998), I'll go directly to ProPhoto."

Herman

The bottom line is that if editing sensibly in 16-bit mode (not doing ridiculous saturation boosts, etc) there is no real disadvantage to ProPhoto. You're pretty much guaranteed to be able to use 100% of the gamut of any output device, something which is not true for any other color space in common use.

And 30,000 is the number of hairs on the average newborn weasel.  :angry:

Ray.... "Is this what you're getting at, Paul"

Yes.. but you changed my test some what. I made a 10x10 pixel file of R=255 in ProPhoto. Another of R=254 in ProPhoto, and another of R=253 in ProPhoto. I then did a print to file using my Epson 4000 HahnRag printer/paper profile. The files are the same.

You can also do a convert to profile (ProPhoto > HahnRag) for each and you will find the Lab values for all three patches are the same. I.e., the print is the same even though in ProPhot they are different files. It looks like ProPhoto sat. red doesn't come into HahnRag gamut until about 170. And yes, I understand the printer receives some mix of ink values in an attempt to reach ProPhoto sat. red.

My point is fiddling with out gamut colors (printer/paper gamut) is a stumbling art at best. Occasionally a "fine art" in the right hands. Jeff and Rodney live and breathe this stuff 24/7. They know how to work within the limitations of the technology. Those who pooh pooh the J. Daalder reasoning haven't read it or don't understand it. By the way, Mac Holbert says the same thing. He recommends a tight color space with respect to your print space. Holbart used ColorMatch on Ep2200.

Peter, except for the camera colors that ProPhoto RGB retains, aRGB clips, and can be printed, what's the practical difference between:

Workflow A: Working space is aRGB.
- All out-of-gamut camera colors are clipped along the edge of aRGB
- When converting to a printer profile, all out-of-gamut aRGB colors (this means INCLUDING clipped camera colors) are clipped/compressed (depending on rendering intent) along the edge of the output space.

Workflow B: Working space is ProPhoto.
- There are no out-of gamut camera colors.
- When converting to a printer profile, all out-of-gamut ProPhoto RGB colors are clipped/compressed (depending on rendering intent) along the edge of the output space.

In workflow A camera colors are clipped in 2 steps, in workflow B in one step.

Herman

Personally I don’t see any real downside other than you’re dealing with one space that could contain a lot more colors you can’t see on screen compared to the other. However, you can also see how the mapping from a very large space compared to a smaller space is being affected by your output profile (since ultimately we need to print the thing).

Yes, ignore it. It’s totally legacy and yes, it’s totally useless. They also supply the “Classic” CMYK engine which expect for old farts in Prepress, is useless. If they pulled it (which they would love to do), a small vocal group would go nuts.

Look at this warning. It places an ugly gray (by default) mask over your image, you can’t see a thing. Then you’re supposed to manually desaturate the image to make it go away, indicating in the crudest fashion that those colors are now “in gamut”.

Or you can setup a soft proof with your output profile and rendering intent. The profile has far more robust control over gamut mapping (compression or clipping) and it shows you EXACTLY the mapping and gamut reduction without an ugly, useless overlay. When you convert (one step), that’s EXACTLY what you get.

You’d rather use a sponge tool and do this manually, slower and far less accurctly? The gamut warning overlay is about as useful as retouching blemishes with the pencil tool!

Use the soft proofing functionality in Photoshop!

Ray, the options you quote from Andrew is actually his clearest post in the whole thread. I think he is right, but I see where you are coming from.

What I think it boils down to is that Photoshop will do a better job of dealing with out-of-gamut colours than you or I can. If optimal results could be achieved simply by tweaking the saturation slider, it is unlikely Adobe's engineers would have put the time and effort they have into the conversion process from working space to output profile. One needs to presume that Photoshop's mathematics have been designed to handle all this under the hood much more intelligently than you or I can achieve with one simple tool.

It is true that you do not see everything that is going on until it is done, but that hardly matters; if you don't like a soft-proofed image you still have two options: (i) further tweak any image adjustment tool you like with the soft proofing active (in fact, I make luminosity and color balance adjustments with soft-proofing active), and/or (ii) change the rendering intent to see whether for a particular image a departure from your usual rendering intent works better. With good soft-proofing you come awefully close to WYSIWYG (provided your monitor is properly calibrated and profiled), and after all, isn't that the objective?

Interesting idea, may be worth giving it a whirl, despite what Blatner/Fraser say about it on page 142 of Real World Photoshop CS:

"The saturation intent maps fully-saturated colors in the source to fully-saturated colors in the target without concerning itself with hue or lightness. It's good for pie charts and such, where you just want vivid colors, but not much else."

I just can't understand that statement. I have an sRGB 24 bit 50MB image that contains every combination of the 255 levels of red, green and blue; ie 16.7 million colours, each pixel representing a different colour. (Give or take a few hundred or thousand, Jani  :D ).

I convert the image to the bigger ProPhoto color space. I've still got 16.7 million colors. If I were to get more, the file size would have to increase. I've never noticed that happen, have you?

If I say the colors have changed in character; that some of them are more saturated than they were in the sRGB space, then that is a different statement to saying I have more colors. Let's try to be logical here. More colors does not mean more color, if English is your first language. If you think it does, then thats the source of the confusion. By 'more colors', I mean 'a greater number of discrete shades of color'.

Well, it needs clarifying doesn't it. I get the impression some folks reading this might think a wider range of colors between extremes of saturation translates to a greater number of colors.

Perhaps you mean, the bigger the color space, the wider the gap between a given number of colors and the greater the possibibility of the eye being able to distinguish between the different shades. I would think that the difference amongst 50 shades of red evenly spaced between 1,0,0 and 255,0,0 in Prophoto would be slightly more noticeable than 50 shades of evenly spaced red in sRGB.

Yup, if in ACR I see clipping in say Adobe RGB (1998), I’ll go directly to ProPhoto.

Read the link white paper. The triangle you point to is discussed, thus:

"What on earth does this have to do with ProPhoto? Well, I'm glad you asked. It has to do with the gamuts of current output devices. They're not that big. Certainly, in volume terms, they are ALL pretty much smaller than even AdobeRGB. This includes - Lightjets, Lamdas (see Figure 5), Thetas, Pegasusses (Pegasi?), Canon, HP and Epson inkjets (see Figure 4), Dye Subs, and You-Name-Its. Not one of them has a gamut larger than AdobeRGB in total. However, some (many) do have gamuts that do not completely overlap AdobeRGB. In some case, as much as 5 to 10% of their gamut may be out of Adobe RGB. Typically, it is saturated yellows that are the culprits (sometimes very saturated cyans and magentas, too, although this is less common)."

"So, unless you are shooting canaries (or more realistically, very unusually intense sunsets - see Figure 6), almost all of the tones you can print or are likely to be able to print in the short to mid term future, are nicely contained within AdobeRGB. So working in Adobe RGB rather than ProPhoto RGB makes more sense (you'll see why in a moment). Of course, for those images that DO contain out of Adobe RGB gamut colours that ARE printable, you probably would choose ProPhoto. But you'd be doing so for a sensible, distinct reason."

To comment on my question:  Yes, those silent assumptions exist, but ... “That is closely held secret by GMB. Likewise with Monaco/X-Rite. The color space assumptions in ProfileMaker differ based on the parameters used when the profiles are construed.” (by Ethan Hansen).
If anyone knows more, please post.
----


My claim is straightforward and quite fair:  Today’s printer resp. printer profiles are not prepared for the case the we come along with a heavy-loaded file in ProPhotoRGB.

If you really have those colorful flowers
– which are well preserved in a ProPhotoRGB container -
many colors will posterize at the border of the printer/media-space
independent whether you choose RelCol or Perceptual.
Just try it.

The mantra "use ProPhotoRGB to avoid channel clipping“ is akin of self-fulfilling prophecy, because ACR doesn’t support any other rendering option (yet). Hence, all the burden of a perceptual de-saturation is imposed either to the operator or to the printer profile….

Could the industry please kindly sort this out without involving us customers. Not everyone loves to fiddle with the Hue&Sat.-tool or the Channel Mixer to tame out-of-gamut colors.

Peter
---


Here’s an interesting reference (ICC White Paper #2 from www.color.org):

“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.”

---

Peter, I don't think that is correct. Firstly we are not converting a color space to a printer profile. As I mentioned above the printer profile measures and corrects differences between the file data and how the printer reproduces that data.

The color space the printer can reproduce is smaller and most importantly shaped differently than say the prophoto or ARGB98 working color space in Photoshop. The rendering intent selected in Photoshop determines how those out of gamut colors are dealt with, and consequently the impact on the appearance of the soft-proof or the print.

I would be interested to see photographs (not gamut diagrams) made from 16 bit files where there is more banding or posterization as a result of the operation of the same rendering intent in ProPhoto versus ARGB98. Personally I have NEVER YET had to rescue an image from banding or posterization by hand because I am working in ProPhoto.

But seriously, just how many discrete colors are there in the average 24 bit 33MB 1Ds image? Maybe not 30,000, although I bet some images would have no more than that. 100,000 perhaps? Certainly less than 1 million.

Andrew, fine. But what is the relevance of this information to the issue of whether there is downside risk (in terms of visible degradation of print quality) when using ProPhoto rather than ARGB98 as one's default colour space?

Andrew, the softproofing you describe in your last post above is what I have been doing but the phrase I quoted confuses me. I have the softproof set-up the way you say, and to activate it I click "CTRL Y" (Windows XP) which I understand doesn't change anything in the image file - it "simply" renders a monitor image simulating what the printed output will look like - and it does so pretty well. When I click CTRL Y again the simulation disappears. Is this what you mean in the above quote from your post, or do you mean that once I click "PRINT" Photoshop remaps the file data to the output profile for printing (but doesn't retain the remapped data thereafter) or do you mean something else?

Well, you guys have got me completely confused. I see only one way of knowing which colors are out of gamut and that's by ticking the gamut warning under 'proof colors' which places a gray mask over the saturated colors.

Perhaps there's something very obvious that has escaped me, but if I don't see the gray mask, how do I know the colors might be too saturated for the paper/printer?

I understand the point that Adobe's gamut warning might be hoplessly inaccurate and that it's better to let the rendering intent (perceptual or whatever) remap the colors so one can be sure one is getting the maximum saturation of a particular color on the paper, if that was the idea when editing, ie. maximum impact of that yellow flower without losing detail.

But 'not knowing' that the colors are going to be remapped, that some of the hues are going to be changed in subtle ways and possibly some of the shadows blocked up because of dark, out-of-gamut shades, seems to me less than ideal.

What's the more precise alternative to the gamut warning, Andrew? This is not clear in your above statements.

We’re in agreement. On page 35 of my book:

The saturation rendering intent was at one time recommended for solid graphics like logos or pie charts (sometimes referred to as business graphics) and the gamut mapping is weighted to produce the most vivid saturated colors (hence the name). For this reason, using this intent on images can produce less than desirable results. However, depending on the profile and how it was built, the saturation intent might be fine for some images so don’t dismiss it outright. In most cases, this intent really is going to be best used for files that don’t contain images and for use on business graphics and similar types of imagery.  Like the perceptual rendering intent, there are no specifications for how this intent should be applied, so various profiles from different manufacturers will produce differing results.

NO image could contain that color. Even if it could, we could see a tiny fraction of those colors (we can’t even see anything close to 16 million color simultaneously). This is all math being used to define a possible but unfortunately impossible human experience. Don’t forget, there’s math that says a bumblebee can’t fly.

An image can contain an infinite number of colors (unless you mean to imply that wavelengths of light exist only in a finite, discrete set), but there are limits to what you can capture.

A pixel can only have one RGB value, and the limit of discrete colors in a pixel-based image therefore depends on the number of uniquely colored pixels in it.

To create an image with 281 474 976 710 656 different colors, you only need to create an image with as many pixels, all with different RGB values.

As for Ray's point about supercomputers and whatnot, the fact that we deal with RGB values per pixel indicates that an 48-bit color image's uncompressed size in memory should be:

48 bits * width in pixels * height in pixels

E.g., a 300 000 * 300 000 pixel image (Photoshop CS's maximum, right?) could be:

48 * 300 000 * 300 000 = 4 320 000 000 000 bits = 540 000 000 000 bytes.

Plus overhead.


Really? Please show and tell. As far as I know, this is only a popular urban legend, of the kind that is told to ridicule engineers/mathematicians/scientists. There is another, apocryphal story explaining how this misunderstanding could have spread, and it's told here:

http://www.ilr.tu-berlin.de/WKA/technik/bumblebee.html

The only con to ProPhoto is a slightly greater chance of posterization or banding if editing in 8-bit mode. But if you use 16-bit mode (which you should be doing anyway) this is irrelevant and there is no real downside to ProPhoto.

No, I bring the RAW into Photoshop in high bit (more than 8-bits per color). Photoshop calls all files with more than 8-bits per color “16-bit” (it’s actually 15 bits).

The tones I have had clipped in AdobeRGB were yellows and blues in flowers. One way around this is to reduce saturation or 'brightness' in ACR, not that nice in terms of over all image.

However some clipping might be acceptable, and as pointed out these will get clipped at output or desaturated by perceptual rendering it seems.