Pages: 1 [2] 3 4 ... 8   Go Down

Author Topic: ProPhotoRGB  (Read 44224 times)

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
ProPhotoRGB
« Reply #20 on: August 10, 2005, 12:26:47 pm »

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.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

Ray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 10365
ProPhotoRGB
« Reply #21 on: August 10, 2005, 11:42:22 pm »

Quote
Quote
It is true that you do not see everything that is going on until it is done, but that hardly matters;

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?
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20614
  • Andrew Rodney
    • http://www.digitaldog.net/
ProPhotoRGB
« Reply #22 on: August 14, 2005, 10:19:41 am »

Quote
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'.
Depending on the profile (how it’s built, the package that built it), it can work well. So I would not dismiss it outright.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
ProPhotoRGB
« Reply #23 on: August 17, 2005, 12:38:15 pm »

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.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20614
  • Andrew Rodney
    • http://www.digitaldog.net/
ProPhotoRGB
« Reply #24 on: August 17, 2005, 09:23:11 am »

Quote
A bigger space DOES mean more colors.
With "A bigger space DOES mean more colors.", I meant more colors in the sense of a larger volume/scale in LAB (more saturation etc.).
I’d say so, most certainly!
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Hermie

  • Full Member
  • ***
  • Offline Offline
  • Posts: 207
ProPhotoRGB
« Reply #25 on: August 03, 2005, 03:43:57 pm »

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
Logged

Hermie

  • Full Member
  • ***
  • Offline Offline
  • Posts: 207
ProPhotoRGB
« Reply #26 on: August 04, 2005, 02:43:45 am »

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
Logged

Jonathan Wienke

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 5829
    • http://visual-vacations.com/
ProPhotoRGB
« Reply #27 on: August 05, 2005, 02:34:55 am »

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

paulbk

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 528
ProPhotoRGB
« Reply #28 on: August 06, 2005, 08:59:15 am »

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.
Logged
paul b.k.
New England, USA

Hermie

  • Full Member
  • ***
  • Offline Offline
  • Posts: 207
ProPhotoRGB
« Reply #29 on: August 07, 2005, 11:29:45 am »

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

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
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20614
  • Andrew Rodney
    • http://www.digitaldog.net/
ProPhotoRGB
« Reply #30 on: August 09, 2005, 12:55:12 pm »

Quote
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?
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).
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20614
  • Andrew Rodney
    • http://www.digitaldog.net/
ProPhotoRGB
« Reply #31 on: August 10, 2005, 10:16:38 am »

Quote
So now you tell me  ! What is Adobe doing providing a useless gamut warning? I've been relying on that gamut warning to fine tune my images before printing.

Are you saying I should just ignore this gamut warning, switch it off and make the colors as bright and saturated as I like?
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!
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
ProPhotoRGB
« Reply #32 on: August 10, 2005, 10:17:34 pm »

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?
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
ProPhotoRGB
« Reply #33 on: August 14, 2005, 10:23:33 am »

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."
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."

Ray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 10365
ProPhotoRGB
« Reply #34 on: August 17, 2005, 09:59:28 am »

Quote
Quote
A bigger space DOES mean more colors.
With "A bigger space DOES mean more colors.", I meant more colors in the sense of a larger volume/scale in LAB (more saturation etc.).
I’d say so, most certainly!
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'.
Logged

Ray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 10365
ProPhotoRGB
« Reply #35 on: August 17, 2005, 10:26:29 am »

Quote
Now if you want to debate that the max red in one color space which is more saturated than another isn’t really “more colors”, OK.
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.
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20614
  • Andrew Rodney
    • http://www.digitaldog.net/
ProPhotoRGB
« Reply #36 on: August 03, 2005, 04:53:12 pm »

Quote
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?
Yup, if in ACR I see clipping in say Adobe RGB (1998), I’ll go directly to ProPhoto.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

paulbk

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 528
ProPhotoRGB
« Reply #37 on: August 04, 2005, 02:40:50 am »

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."
Logged
paul b.k.
New England, USA

PeterLange

  • Guest
ProPhotoRGB
« Reply #38 on: August 06, 2005, 01:10:29 pm »

Quote
Quote
Quote
Quote
First, with rendering intents to output spaces, you have to decide if you’ll clip the colors or compress them. ...
Just a friendly question:
 
Are there any printer profiles
which support Perceptual rendering in way
which assumes that the source space was ProPhotoRGB?

Peter

--
No. Output profiles don’t have any idea when built what the source color space will be.
 

Doesn’t the profiling software implement the Perceptual intent
and its non-linear transforms
based on a on a silent assumption about the source color range?

Peter

---

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

---
Logged

Mark D Segal

  • Contributor
  • Sr. Member
  • *
  • Offline Offline
  • Posts: 12512
    • http://www.markdsegal.com
ProPhotoRGB
« Reply #39 on: August 07, 2005, 09:21:52 am »

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.
Logged
Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....."
Pages: 1 [2] 3 4 ... 8   Go Up