ProPhotoRGB

[Hermie]

> What’s amusing are those who say they are preserving colors by working ProPhoto even though they know they can’t print the colors they are “preserving.”

and funny enough the same statement (although to a lessor degree) is true for Adobe RGB.

Herman

[digitaldog]

You realize that when a photo file color doesn’t map into your print space the rendering process does it for you. In other words, what you see is NOT what you get. You get whatever the rendering process gives you. That’s why in 2005 we still hover over the printer with a fair bit of apprehension to see what it will hatch. We don’t do that with text printers any more because technology has taken the mystery out of it. Back in the DOS days of 6 pin dot-matrix printers it wasn’t so deterministic. Some day fine art printing will be as deterministic as laser jet text is today. But it won’t be tomorrow.

First, with rendering intents to output spaces, you have to decide if you’ll clip the colors or compress them. Also keep in mind that current color management technology only looks at individual pixels and the math involved to do this gamut compression/clipping based on what is basically a solid color (that single pixel). It doesn’t see the image in context. Photoshop and for that matter all color management is just a big calculator that has absolutely no idea about images. An ICC profile simply describes a devices behavior. It “sees” all images the same way (it doesn’t actually see anything but you get the point).

On to soft proofing. You’ve got a emissive display and a reflective print, the dynamic range (contrast ratio) may be totally different, you have an illuminant underwhich you are supposed to view the print (the CMS assumes some viewing illuminant). This stuff is WAY more complex than looking at a page of black text and hoping to see it look exactly like that on a screen (and it will not exactly for reasons I’ve already discussed).

The technology in which color management is based was developed in the 1930’s well before anyone, even science fiction writers had any idea about digital imaging. It looks at how closely two colors match based on how we humans (the standard observer) sees colors. It’s pretty amazing the technology works as well as it does with something as complex as a color image. But it’s far from perfect. We could get closer but users would not be happy if the process was 10X or maybe 100X slower using today’s processors.

Photographers would do far better actually viewing those prints after them come off a printer under a 5000K light box. This would go a long way to helping the color matching issues. When I speak and ask for a show of hands of how many photographers have 5000K boxes for transparencies, I see a lot of hands. When I ask about reflective light boxes, preferably with a dimmer to match the luminance to a display, there are very few. Point is, we can get caught up in all kinds of tiny details about the technology (and the working space) but there are some fundamental simple processes we can all do to get a closer match (like calibrating our displays and doing it correctly). Compared to colors in a working space that fall outside display gamut, this is a MUCH bigger issue to tackle and one anyone with the desire can do.

[Ray]

A)  Make a 1 inch square filled with ProPhoto SATURATED red, R=255, G=0, B=0.
  Send it to the printer using relative rendering intent. It probably doesn’t matter.
C)  You get a 1 inch square of saturated print space red. Not (A) above.
D)  Make a 1 inch square filled with ProPhoto ALMOST saturated red, R=254, G=0, B=0.
E)  You get a 1 inch square of saturated print space red. Not (D) above.
F)  Make a 1 inch square filled with ProPhoto NEARLY saturated red, R=253, G=0, B=0.
G)  You get a 1 inch square of saturated print space red. Not (F) above.

(1) Make a 1" square filled with ProPhoto out-of-gamut saturated red, 255,0,0.

(2) Reduce the saturation till it's just in gamut in relation to, say Epson Premium Glossy with a Bill Atkinson profile.

(3) Read the proof RGB values on the info pallette and you'll find that 255,0,0 has been transformed into something like 255,46,139.

This is the maximum red saturation that the printer/paper/profile combination can sustain and it's a slightly magenta-ish red as opposed to the more yellowish ARGB maximum red.

Is this what you're getting at, Paul   .

[PeterLange]

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). ...
  

That is correct and completely understood.  The final printer/media profile is “ignorant“, but the guys who construed the profiling SW + the implementation of the Perceptual intent are certainly not.

PCS Lab is huge, whereas printer/media profiles are small (deltaE3-wise).  If you’d just scale down / compress the whole volume of CIE Lab into such a “poor” output space, all in-gamut colors would get altered and de-saturated in an unacceptable way.  Therefore a nifty non-liner algorithm for compression is required.

In this context an assumption about the most likely source space is made (could also be more than one) by these guys.  While collecting the colors from PCS Lab, all colors outside the range of this assumed source space are somehow clipped & merged in a RelCol manner.  All colors ranging in-between this assumed source space and the output profile are gently squeezed in … AFAIK.

So my initial question was not rhetoric at all.  If the Perceptual intent of a printer profile was not prepared for ProPhotoRGB, results are not much different compared to RelCol.

That’s at least what I see when working with quite saturated colors in a large working space.  In both cases, Softproof as well as print show a lack of details due to posterization (unless some time is invested to tame these out-of gamut colors).

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

That is correct, but can be misleading.  It is the reason why I added above reference to ICC White Paper #2 http://www.color.org/ICC_whi....ses.pdf
(of course I know yours, too).

A proprietary color management system (CMS) can / could anytime realize a Perceptual compression between two matrix spaces, such as the input profile of a Camera and the preferred output space like Adobe RGB.  In all probability, that’s what happens “in-camera” when you shoot sRGB/aRGB/JPEG/TIFF … AFAIK.

I see no restriction in principle why a Raw converter shouldn’t offer such a perceptual rendering option (optionally).  Minor tradeoffs would be acceptable if this saves me time.  Current philosophy of “preserving everything in ProPhotoRGB” leaves the whole down-sizing / de-saturation to the operator or the printer profile.  And here we are moving in a circle………


However, maybe we can develop something practical here.  Would you have a suggestion how to deal with said out-of-gamut colors prior to print?

/> De-saturation by means of the Hue&Sat.-tool (in RGB mode) reduces brightness, too.
/> De-saturation by means of the Hue&Sat.-tool (in Lab mode) changes the hue.
/> The Channel Mixer was recommended elsewhere, but I'm not sure how to use it properly for that purpose.

Any “best practice” how to proceed?

Peter

--

[Schewe]

By that I mean for those images where there is a large shakedown of contrast and saturation moving from the non-proofed to the proofed version on screen, the print definitely prints in the ballpark of the proofed image, but quite often the shake-down in the print is not quite as dramatic as the soft-proofing indicates it will be. This means that when I, say, tweak Curves at the softproofing stage I do need to be a bit careful not to over-compensate. Questions: (i) do you know whether this kind of experience sounds about right for this Epson profile, and (ii) who makes first-class profiles going foreward and in reverse?

Greytag & Monico/X-rite (the current software packages) both produce pretty good profiles that go both ways well.

If you are finding that the softproofed image using the absolute colormetric method (paper white/ink black) are not accurate, then I suspect you are not yet skilled in using softproofing, or your profiles' reverse tables (the part that is used when softproofing) aren't great.

One factor that is critical to accurately using softproofing is that your entire display environment is controled and accurate and that you have a good print viewing device.

My entire computer imaging area follows the ISO 3664 standar for viewing conditions for graphic technology and photograpy. Sorry, since it's an ISO copyrighted PDF, I can't share it, but basically, the viewing requires a specific ambient luminance, neutral sounds, specific D65 white point of the display, and a specific luminance of the display.

Once you achieve that, and presupposing and accurate display profile correctly used, the softproofing environment pretty much requires that you work in Photoshop in a full screen mode with all the interface of Photoshop hidden by the tab key. This important so that the non-image portions of the display do not influence your eyes.

The viewing device also needs to be to a stanard-I use a digital GTI viewing box set at a 90 degree placement from the display so O can't see both the display and the viewing box at the same time-it forces you to visually toggle between the display and the print.

Properly set up and deployed, the softproofing in Photoshop is scarey accurate for both inkjet as well as halftone proofing.

It works, and works very well to accurately predict, on screen, what your print will look like-regardless of the original color space.

[Hermie]

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."

Paul, my point is, and that is I believe what Rodney says, it depends on the image. I don't disagree on that.

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.

That is why you should work in 16-bit with ProPhoto RGB. That way there are 4096 tones stretched over the wide ProPhoto gamut (with a camera capturing 12-bits). When converting this 16-bit (actually 12-bit) image to a printer profile the risk of banding is far less.

Herman

[Mark D Segal]

Paul, thank you so much for that link to Dry Creek's model. It is indeed most cool, and does give food for thought about how much difference these color spaces make by the time you get to the printer. I think I remember once posting something on one of these threads in LL to the effect that printing remains the determinative weakest link in our digital imaging chain, despite the impressive quality we can get from the most recent generations of inkjet printers.

[Ben Rubinstein]

Just had a look at that program. How utterly horrible. Not the program but how little of my Canon 1Ds colour space the Fuji Frontier printing on their pro paper (which I use) can print, infact I would say plenty less than 50% OUCH!
It doens't measure up that well against the sRGB gamut either.
The epson doesn't seem that much better, not good enough to be worth the time, bother and expense.

Based on that premise, maybe my above post does'nt make that much sense, if I'm losing that much anyway from the camera through to print, I may as well work in ProPhoto and convert at the end, a conversion is taking place anyway so why not give it the maximum amount of information to convert down?

[Ben Rubinstein]

Bloody ####, I'm going back to film, I was happy enough in those days....

[Mark D Segal]

Hi Peter - I never assumed you had any marketing mission, and neither do I. This is just an interesting technical discussion that should help us better understand what we are doing.

I did have a second look at page 7. What I see there is that between Andrew Rodney and Jeff Schewe your points have been addressed, and nothing yet really responds to my last post that you quoted; however, to my way of thinking, that is the nub of the matter in this thread.

Andrew's response to Ray to-day is very sensible, but it deals with varying impacts of different rendering intents, whereas the issue at stake in this discussion thread is whether there is a differentially worse impact from the use of whatever rendering intent when the working space is Prophoto rather than ARGB98. (Remember this whole debate "gathered steam" over the question of whether there are "downsides" to working in ProPhoto!)

[Ray]

The paper doesn’t really matter, however, the scenario is clearer because the sRGB JPEG file is completely in-gamut now.  Whereas the ProPhotoRGB file shows many many out-of-gamut marks with regard to the printer profile.

Do I take it this is how you printed both images (or would print both images), one out of gamut, the other in-gamut?

Any image with out-of-gamut colors is likely to lose detail within those particular shades that are out-of-gamut. The question here of main interest to me is, having brought those bright yellows (just) into gamut in both images, sRGB and PP, how do the yellows compare when printed?

I don't like printing images when I know they are out-of-gamut. I don't trust either perceptual or relcol to do the right thing, but I might do some further experimentation with these rendering intents when I get back to my printer.

[digitaldog]

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

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.

That gamut warning is useless. There’s no reason for you to be messing with hue/sat with this overlay. It predates Photoshop’s use of ICC profiles. The profiles will handle the gamut remapping. Using a desaturation technique like this is in comparison like using a kitchen knife as a screw driver.

Is it me or is the server running these forums really dog slow???

[Ray]

As the author of the original article I just want to clarify one thing:

Andrew Rodney wrote:

-->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:

<here follows a recipe for a cookie>

I'm afraid it isn't a misunderstanding, actually a mis-reading.

Far be it from me to argue with someone far more qualified but I'm actually correct here.  I don't really know how to put it in clearer terms - the maths is quite clear.  Each 16 bit colour space has the same total number of tones in it.  What those tones mean is, however, highly variable.  (The 'scale' in your recipe).  

A colour space is simply a definition of the boundaries and they can be as wide or as narrow as you choose - but the number of items contained within these boundaries never changes unless you change the bit depth representing each item.

The rest is up for (seemingly endless) debate but unless I misunderstand binary, the above is just fact.

I don't want to wilfully disagree, and I don't even want to be that involved in the discussion, but I don't think I suffer from any fundamental misundertstanding.  In this case, anyway!

I'm not sure what the point is that's being made here. It's clear that changing the bit depth from say 8 bit per channel to 16 does not increase the maximum saturation of any particular color (and therefore does not change the gamut)but it does allow for the possibility of a greater number of tones. It's just that the increment between one tone and the next can be made smaller, but it doesn't have to be smaller. A 48 bit image has the possibility of several billion colors instead of the mere 16.7 million limitation of a 24 bit image. But those are maximum numbers. The actual number of discrete tones in a real world image is likely to be considerably less than 16.7 million whether it's a 24 bit or 48 bit image.

[Jonathan Wienke]

Why should any one edit using colors they can not print, today?

Let's turn it around: What's the point of deliberately crippling an image with the limitations of a print technology that may be irrelevant tomorrow? It makes much more sense to edit an image to what you want it to be, and dumb it down to the output device on a case-by-case basis (making an output-device-specific copy if necessary) rather than editing within the constraints of one particular output device and having to re-process from the RAW if a better printer comes along.

[Mark D Segal]

OK, in an indirect way you've answered my question in the first line. At the soft-proofing evaluation stage we are only talking about viewing, not converting data in any final sense of the term. Thanks. And I much prefer this to Gamut Warning too.

[digitaldog]

What’s the point of seeing via an ugly mask showing you what you can’t print when you can see via a soft proof exactly what you’ll get?

Even if you were so skilled and patient to desaturate the mask (out of gamut colors) to the degree you’d be able to with the output profile (doubtful) you’d be in the same position; an image with a gamut mapped to the printer. Using a good profile/rendering intent or scrubby with a sponge tool, the out of gamut colors can’t be printed! This isn’t like Spinal Tap; there’s not 11 on the volume control.

[jani]

A 48 bit apple can be cut up into 68 billion pieces (is that the right figure?),

No, that's not the right figure.

2 to the power of 48 is:

281 474 976 710 656

Quite a bit more than 68 billion, regardless of whether you're British or not. ::

Edit:

2 to the power of 36 is approximately 68 billion, though.

[Hermie]

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.

Digital camera's (except those equiped with Foveon sensors, e.g. Sigma/Polaroid) do not capture colors. They capture/measure light intensity in a linear fashion. The colored filters on top of the sensor pixels filter colors (e.g. red filter absorbs cyan (=green+blue) and only red passes through). Color (RGB values) is reproduced through interpolation (demosaicing). So a camera with a 12-bit A/D converter is capable of capturing 2^12= 4096 tones per sensor pixel. Thats is why the image size of raw files is approximately 1/3 of normal RGB image. In the raw file there's only one channel of information (intensity).

Herman

[paulbk]

giles, thank you! The link article you point to is excellent.
Everyone should read this:
ProPhoto or ConPhoto?

Try this. -- Pick a file with a wide color range with some colors known to be out of gamut. If the file is not already in ProPhoto then “Assign it” to ProPhoto and do a soft proof using the printer profile you plan to use and turn on Gamut Warning. Observe. Now Assign the same file to MatchColor. Much less out of gamut colors.

I did this with Bruce Lindbloom’s 16 million color tif file using a professional Hahnamühle Rag printer profile. You will be amazed how much is out of gamut using ProPhoto.

Clipping during RAW conversion is a judgement call. It may be better to clip once and work in a color space the fits your output device than to suffer the *compounding problems* Jeremy Daalder points out in the linked paper.

[Ben Rubinstein]

I'm wondering whether I will see any difference now, I can always change the settings late I know.  I ran a comparison just now of a typical picture that I take, a bride next to some bright orange and red flowers. I opened one as sRGB 8bits which is what I usually use for proofs, the other at Prophoto 16bit, converted in PS to sRBG 8bits. Yes there is a difference, whether it's enough to bother with, that I have to do more testing for. What worries me is that the entire picture looks different in terms of highlight 'brightness' and contrast/saturation. What I am seeing in ACR when using prophoto is not what I'm seeing in PS once the picture is converted to print.
Soft proofing means that I edit in one colour space, work in the same space in PS, convert to a printable colour space, soft proof and spend time making it look like it did before.
I might as well do the whole thing in the printable colour space so that when it is right, it's right  and I don't need to tweak the picture again after having spent hours getting everything just right. Especially as you can't sharpen as an adjustment layer  :p  Futhermore Soft Proofing may be a solution for the fine art landscape photographer. For everyone else who does 90% of the post work in ACR and batches the rest it is not a viable option, I want my final product to look like it did on screen. At present I do get that....