AdobeRGB question

Iliah Borg said:

knickerhawk said:

There seems to be an awful lot of feathering or thresholding going on in the way the OOG color range selection works.

Click to expand...

L* 70

That's a slice at L* 70, the leftmost image vs. sRGB gamut; and it's not looking like Photoshop is way off, selecting borderline colours.

Click to expand...

That looks like a lot of yellow, which would be mostly from the bowl, I presume. Our little sidebar discussion here has been about the red bow, which doesn't appear to have anything much above L*55. By the way I deliberately picked a shot and performed processing that would push the limits of sRGB, so I'm not surprised that a lot of colors are "borderline," but I remain unconvinced that the OOG selection from the color range tool is an accurate method for identifying the truly OOG pixels.

Iliah Borg said:

You might want to take this discussion to e-mail.

Click to expand...

I've found this discussion to be useful and I think it is educational to others (and not just me). If I'm being dense and misunderstanding things, please don't hesitate to give it to me with both barrels. However, feel free to PM me here at DPR if you prefer. Thanks!

knickerhawk said:

Iliah Borg said:

knickerhawk said:

There seems to be an awful lot of feathering or thresholding going on in the way the OOG color range selection works.

Click to expand...

L* 70

That's a slice at L* 70, the leftmost image vs. sRGB gamut; and it's not looking like Photoshop is way off, selecting borderline colours.

Click to expand...

That looks like a lot of yellow

Click to expand...

Point here is that Ps's estimate isn't way off, not how the colours look on a _graph_

Ps warns, as it IMO should, of _potential_ problems that the operator needs to address, or at least take a closer look into.

I set L* to 70, not to 50 or 25, on purpose. 70 is above of what saturated sRGB reds reach. The diagrams at 50 and below are more worrying.

knickerhawk said:

knickerhawk said:

You might want to take this discussion to e-mail.

Click to expand...

I think it is educational to others

Click to expand...

Hardly, there is too much jumble as it is.

knickerhawk said:

things

Click to expand...

The question of clipping is not the thing, the question that _is_ the thing is gamut and what happens around the gamut border, at different L* values.

I find PMs inconvenient for discussions.

--
http://www.libraw.org/

IvankoPetro said:

Pretty good explanation here, if you consider for editing purpose.

Click to expand...

Actually, I did eventually look at the video ... and I think that explanation is worse than saying nothing at all.

The section from 1:36 to 2:18 sets up a grossly misleading analogy about 3 colors (sRGB) vs. 100 colors (Adobe RGB). Then the guy admits how ridiculously exaggerated that analogy is, although he's already planted the image in the viewer's mind.

And then he says this:

'Adobe RGB has more colors available - they say it's about 35 times as many - as sRGB.'

Where in the known universe does a statement like that come from?

Then at around 2:54 he admits that in many cases you won't really be able to see a difference. The next few minutes are devoted to confirming that sRGB is fine for lots of purposes while wider color spaces are probably best for special purposes like printing.

Someone hoping to learn the facts about it all could get whiplash from his contradictions.

knickerhawk said:

Michael Fryd said:

...

Click to expand...

Click to expand...

knickerhawk said:

knickerhawk said:

The disadvantage of a wide gamut colorspace is that the gamut may be much wider than the gamut of the final output device (be that a monitor or a printer). That means that at some point the wider gamut colorspace will need to be mapped into the smaller gamut of the output device. Unless you are handling that conversion, you have no control over it. Suppose the colors in your image easily fit into sRGB, but you deliver them in a ProPhoto RGB file. The final rendering may involve squeezing the entire ProPhoto colorspace into sRGB.

Click to expand...

There's that awful word again ("squeezing"). There's no need for "squeezing" if the colors were already inside the sRGB gamut. Just use relative colorimetric as your rendering intent (which will happen anyway if you're simply converting to sRGB instead of a printer profile even if you pick perceptual as your rendering intent). Since you specified that there were no colors outside of sRGB in your example image, there's nothing to be "squeezed" with relative colorimetric applied.

Click to expand...

The problem is that if you are not the one who is making the final transformation to the smaller gamut colorspace, you can't control what rendering intent is used. If a rendering is used that smoothly maps the entire source colorspace into the destination colorspace, then you get color shifts. You are correct in that in many case this can be avoided by picking the right rendering intent, but you may not have control over that.

By delivering a file in a smaller gamut colorspace, you reduce the harm from someone choosing a less than ideal rendering intent.

knickerhawk said:

knickerhawk said:

These can cause the colors in your image to shift, even thought it was unnecessary.

Click to expand...

This is far less of a practical risk when going from an overly wide to a narrow gamut than when converting to the narrow gamut early on and then continuing to edit in that narrow space.

Click to expand...

The issue is that you have control over the mapping when you do the conversion. If you want a color that isn't in your destination colorspace, you need to decide how to handle it. By working in the destination colorspace, you have made that decision early on, and all of your color adjustments take that into account, If you are working in a wide gamut colorspace, you may have colors that are not in the destination colorspace. All of your careful fine tuning may be based on colors in your image that will shift when you move to the smaller gamut colorspace.

knickerhawk said:

knickerhawk said:

The other disadvantage of a wide gamut colorspace is that the addressable points in the visual colorspace are spaced further apart. This means that you are more likely to get banding if you edit the image.

Click to expand...

This is a bogeyman argument with respect to color quantization errors caused by the conversion from a wider color space to a narrower one. Luminance banding is a real possibility when editing in 8-bit mode and this is true regardless of which color space you're editing in. Color banding simply because you're working in a wide color space like ProPhoto, is very unlikely to ever show up in any real photograph (i.e., not a synthetically generated image), even in 8-bit editing. Of course, it's better to edit in 16-bit mode regardless and then just wait to convert to 8-bit at the output stage. If you pursue that simple strategy, you'll never run into banding (luminance or color) in any reasonable real-world scenario.

Click to expand...

Yes, working in 16 bits per channel avoids the issue with banding. However, if you don't have as much memory, storage, or processor power as you would like, you may find your computer more responsive when working in 8 bits per channel.

Where banding is mostly a concern is in situation when the original RGB image is very dark, or very bright. In such situations you need major changes to the stored values. Obviously, if the changes are very large, you need 16 bits, no matter the colorspace. however, with smaller gamut colorspaces, you can get by with a little bit more change before 16 bit becomes important.

Yes, the difference may not be important to some, but then for some the color palette offered by sRGB is more than enough. It's a question of what's more important to you.

knickerhawk said:

knickerhawk said:

A common strategy is to use 16 bit per channel files instead of 8 bits per channel. These files are twice as big, but you have so many addressable points, that even though there are further apart in a wider gamut colorspace, there are still close enough together to avoid issues.

Click to expand...

Click to expand...

P22 phosphor, 9300 K, and CRT displays are a thing no more, it's 2023.

Iliah Borg said:

knickerhawk said:

Iliah Borg said:

knickerhawk said:

There seems to be an awful lot of feathering or thresholding going on in the way the OOG color range selection works.

Click to expand...

L* 70

That's a slice at L* 70, the leftmost image vs. sRGB gamut; and it's not looking like Photoshop is way off, selecting borderline colours.

Click to expand...

That looks like a lot of yellow

Click to expand...

Point here is that Ps's estimate isn't way off, not how the colours look on a _graph_

Ps warns, as it IMO should, of _potential_ problems that the operator needs to address, or at least take a closer look into.

Click to expand...

It all depends on how you define potential problems with respect to how useful or misleading the OOG warning is. The OOG warning in Photoshop's View>Proof Setup is well known to have limitations and bugs. That I was aware of already, but not ever having really used the OOG warning in the Color Range selection tool, I was struggling to understand how it was operating. To me, it was clearly NOT doing a particularly good job of identifying the "potential problems" I was concerned about for this specific use case at least. I found its selection to be rather baffling. I did some more experimenting and discovered that even when I converted the original image of the toddler in ACR to Lab and continued with Lab as the working space in PS, running the OOG option in the Color Range Selection tool selected much of the bow and did so even before any edits including the Multiply Blend Mode edit I performed in my original comparison. That made no sense to me! How can there be OOG pixels in Lab? How can those "potential problems" be legit in Lab???

So knowing that something is clearly not as expected here, I did some Googling and stumbled across a post on the Adobe support forums that indicated that the OOG Color Range selection is based on the default CMYK profile selected in the PS Color Settings menu. I did a little testing, and that seems to be the case. Change the CMYK setting in Color Settings and the OOG Color Range selection also changes. So...now it makes sense to me! And now that I know that the "potential problems" the use of this tool displays is based on your CMYK profile default and NOT the current working RGB space, its potential benefits and limitations are clearer to me.

Iliah Borg said:

I set L* to 70, not to 50 or 25, on purpose. 70 is above of what saturated sRGB reds reach. The diagrams at 50 and below are more worrying.

Iliah Borg said:

Iliah Borg said:

You might want to take this discussion to e-mail.

Click to expand...

I think it is educational to others

Click to expand...

Hardly, there is too much jumble as it is.

Click to expand...

I'll agree that there's too much jumble (much of it due to my own stumbles), but I've definitely learned something useful from this little side discussion.

knickerhawk said:

Iliah Borg said:

Point here is that Ps's estimate isn't way off

Ps warns, as it IMO should, of _potential_ problems that the operator needs to address, or at least take a closer look into.

Click to expand...

It all depends

Click to expand...

Please allow me to repeat my point: "Ps's estimate isn't way off".

In other words, direct calculations, with and without ready-made CMM libs (the graph in one of my prev. posts was obtained that way), show that at pretty much any reasonable L* value gamut borders are problematic; and that agrees with Ps's estimate.

knickerhawk said:

on how you define potential problems

Click to expand...

Sigh.

Not how, and not me.

Nothing further.

Iliah Borg said:

knickerhawk said:

Iliah Borg said:

Point here is that Ps's estimate isn't way off

Ps warns, as it IMO should, of _potential_ problems that the operator needs to address, or at least take a closer look into.

Click to expand...

It all depends

Click to expand...

Please allow me to repeat my point: "Ps's estimate isn't way off".

Click to expand...

I never claimed it was "way off" (in this particular instance). I just observed that many pixels selected as OOG didn't seem to be actually OOG. I speculated that there was some sort of feathering/threshold setting going on. As it turned out, the real explanation is different - the gamut warning is based on the user's default CMYK setting. How close or "way off" the Color Range OOG selection is will vary quite significantly depending on the specific image, which CMYK profile is the default and, of course, which working color space is in effect. For this shot the specific CMYK profile in use makes a difference. All four renderings below are screen grabs from the ProPhoto processed version. Note the differences in the bowls and bows in the bottom two:


Top Left=Proofing set to sRGB; Top Right=Proofing set to CMYK US Web Coated (SWOP) v2; Bottom Left= Proofing set to Japan Color 2001 Coated; Bottom Right=Proofing set to US Sheetfed Coated v2

Way off? Well, it depends, and I'm glad I'm now aware of the reason why it depends. Others might be interested as well.

Iliah Borg said:

In other words, direct calculations, with and without ready-made CMM libs (the graph in one of my prev. posts was obtained that way), show that at pretty much any reasonable L* value gamut borders are problematic; and that agrees with Ps's estimate.

Click to expand...

I appreciate the effort you went to, but I'm not really sure how this OOG analysis even addresses the issue that Mako2011 and I were discussing when you introduced the OOG analysis. As a reminder, Mako2011 posted:

When I do that in Photoshop...I see obvious areas of the red channel clipping in the bow as indicated by the text. Makes me think you're Photoshop defaults may be at play

The claim was red channel clipping in the bow. It was not necessary to resort to a convoluted means of estimating gamut problems to respond to that claim. Here's the red channel clipping as shown by opening the red channel in ACR with clipping warning turned on:



Mako2011 can chime in here, but I see only a small spattering of blown pixels in the red channel.

Iliah Borg said:

Iliah Borg said:

on how you define potential problems

Click to expand...

Sigh.

Not how, and not me.

Nothing further.

Click to expand...

knickerhawk said:

The version with text is IvankoPetro’s version grabbed from his screen. As I explained, the obvious clipping in it is due to his monitor settings. My version is what I posted upthread. It isn’t clipped.

Click to expand...

Screenshot is not grabbed from the screen, its windows thing. Monitor only outputs what windows shows, and no its not even a screenshot i imported your original image added text and saved.

For ease of visibility i adjusted "levels" slider



Okay i admit third image is not not so much "clipped", but first one is a lot.
It does have different color values so technically its not "clipping", but its all looks like same shades of color red to me.

If you color sample pixels from left side of the red band on first image (#1 above) (one on the left in your original photo) most of red pixels are in the very edge of the red spectrum.



While in the middle image (#2 above) its more towards middle (like 75% of saturation)





What monitor model do you use knickerhawk perhaps if you have some mega expensive HDR PC monitor it will show color shades more clearly, because when i look on phone Galasy S20+ HDR monitor i do see no clipping in your original image, but my desktop monitor is showing clipping.

IvankoPetro said:

knickerhawk said:

The version with text is IvankoPetro’s version grabbed from his screen. As I explained, the obvious clipping in it is due to his monitor settings. My version is what I posted upthread. It isn’t clipped.

Click to expand...

Screenshot is not grabbed from the screen, its windows thing. Monitor only outputs what windows shows, and no its not even a screenshot i imported your original image added text and saved.

For ease of visibility i adjusted "levels" slider



Okay i admit third image is not not so much "clipped", but first one is a lot.
It does have different color values so technically its not "clipping", but its all looks like same shades of color red to me.

If you color sample pixels from left side of the red band on first image (#1 above) (one on the left in your original photo) most of red pixels are in the very edge of the red spectrum.



While in the middle image (#2 above) its more towards middle (like 75% of saturation)



What monitor model do you use knickerhawk perhaps if you have some mega expensive HDR PC monitor it will show color shades more clearly, because when i look on phone Galasy S20+ HDR monitor i do see no clipping in your original image, but my desktop monitor is showing clipping.

Click to expand...

Okay i figured out my problem was i ICC profile for monitor that was too bright changed to standard profile and it does not look overexposed anymore.

IvankoPetro said:

IvankoPetro said:

knickerhawk said:

The version with text is IvankoPetro’s version grabbed from his screen. As I explained, the obvious clipping in it is due to his monitor settings. My version is what I posted upthread. It isn’t clipped.

Click to expand...

Screenshot is not grabbed from the screen, its windows thing. Monitor only outputs what windows shows, and no its not even a screenshot i imported your original image added text and saved.

For ease of visibility i adjusted "levels" slider



Okay i admit third image is not not so much "clipped", but first one is a lot.
It does have different color values so technically its not "clipping", but its all looks like same shades of color red to me.

If you color sample pixels from left side of the red band on first image (#1 above) (one on the left in your original photo) most of red pixels are in the very edge of the red spectrum.



While in the middle image (#2 above) its more towards middle (like 75% of saturation)



What monitor model do you use knickerhawk perhaps if you have some mega expensive HDR PC monitor it will show color shades more clearly, because when i look on phone Galasy S20+ HDR monitor i do see no clipping in your original image, but my desktop monitor is showing clipping.

Click to expand...

Okay i figured out my problem was i ICC profile for monitor that was too bright changed to standard profile and it does not look overexposed anymore.

Click to expand...

Good find! Another thing to bear in mind: as you drive levels down, saturation will generally increase and the non-dominant color channels in an extremely colorful area such as the red bow will be driven toward blocking (i.e., zeroing out). As you increase levels, saturation goes down but the dominant color channel may be driven toward clipping. Also, I didn't intend my original response to you to mean that the left example is problem-free. It was intentionally pushed to the limits and as Iliah confirmed there are problematic areas where the saturated colors are right at the border of the sRGB gamut. Plus the other two examples aren't far behind either. They have their own sets of issues. So, it's no surprise that it doesn't take much of a push either by subsequent edits or application of an aggressive monitor profile to make the comparison image look clipped.

IvankoPetro said:

Okay i figured out my problem was i ICC profile for monitor that was too bright changed to standard profile and it does not look overexposed anymore.

Click to expand...

It's more than just your monitor space, the image you posted has altered colours. You're either opening it in a mismatched colour space, or converting it, then saved it untagged. Anyway the image you re-posted differs considerably from the original.

Andrew564 said:

IvankoPetro said:

Okay i figured out my problem was i ICC profile for monitor that was too bright changed to standard profile and it does not look overexposed anymore.

Click to expand...

It's more than just your monitor space, the image you posted has altered colours. You're either opening it in a mismatched colour space, or converting it, then saved it untagged. Anyway the image you re-posted differs considerably from the original.

Click to expand...

Yeah, the first time he posted his version of the comparison image, it was untagged. This second time, it's tagged as an sRGB image, but that doesn't necessarily tell us how he got there with respect to the gathering of the three examples and editing them. Bear in mind that he applied a levels adjustment as well, so that alone will account for a lot of the difference.

[No message]