A Workflow with Beta RGB

[Simon Garrett]

The question is, do you think, like Jeff Schewe, that it's totally fine to work in ProPhoto and that I am over-concerned about OOG colors? ... or do you think, as I do, that there is a real risk of damage to the image in the final conversion to the destination, and that the larger your working-space the greater the risk?  That's your call of course ... and what you decide certainly makes no difference to me.

Thinking about the OOG issue, both Beta RGB and ProPhoto RGB are bigger colour spaces than any likely real device.  They're also probably larger than the effective colour space of the camera sensor (yes, I know camera sensor data doesn't have a colour space, I'm talking about the capability of the sensor to capture colour, once converted to a colour space).  So both colour spaces can correctly represent all colours out of the camera, and any conversion issues resulting from conversion to the smaller colour space of a real device will be the same in both cases.  This is because, although the colour spaces are different, the colours being represented are the same.  Just different numbers. 

Of course, in processing it's possible to introduce new colours outside the camera sensor's gamut.  For example, if you work in either Beta RGB of ProPhoto RGB and screw the saturation right up, you can end up with colours that the sensor could not have created.  You won't be able to see them on the monitor either, as few monitors go much wider than Adobe RGB.  So to that extent, if one gets a bit too liberal with the saturation (or similar) controls, then one can create colours further out of gamut in ProPhoto RGB than in Beta RGB. I think one would have to have a Ken Rockwell liking for uber-saturated colour for that to be a significant danger. 

I'm struggling to see how the choice of two working spaces, both larger than that of any real device, and larger than the capability of the camera sensor, makes a significant difference. 

[Robert Ardill]

You're not wasting our time, that's what we're all here for - to debate and learn.

My thoughts are that you might be wasting your time. 

If the image goes through Lightroom, it gets converted to ProPhoto RGB on the way.  This conversion - any conversion - introduces a small amount of quantisation noise arising from the quantisation levels in the destination colour space, and simply the action of changing from one colour space to another.  However, the image starts in 12 or 14 bits raw and already has other sources of noise probably at least as large as the 12 or 14 bit quantisation noise.  The quantisation noise introduced by conversion to 16-bit ProPhoto RGB, even though greater than that of Beta RGB, is likely to be significantly lower than the SNR already in the image data, and so is unlikely to be perceptually discernable. 

Converting then from ProPhoto RGB to Beta RGB is another conversion, introducing another processing step, and another (small) source of noise.  Again, not likely to be significant, but the conversion can't undo any (small) quantisation noise introduced by the conversion to ProPhoto RGB introduced by Lightroom. 

Further noise introduced by processing in Photoshop might be a bit lower if the processing is done in Beta RGB as compared to ProPhoto RGB, and I'd be interested to see any tests that show if this can be discerned in the image.  Personally I doubt it's significant, but I'm open to being shown otherwise. 

As others have said, I can't follow the logic of any benefit of Beta RGB with regard to colours out-of-gamut for real devices. 

Hi Simon,

I hope I answered you in my post that overlapped with yours!  It's unfortunate that I mentioned quantization errors because that's a complete red herring (a case of TMI!).  Sure, there probably is some (no doubt insignificant) additional rounding-type errors when we use a larger working space and perhaps this is of interest to people like Bruce Lindbloom, but it isn't to me because I probably couldn't measure it and I for sure can't see it.

My post had to do with the potential problem of working in a very large working space from a gamut-mapping perspective.  I think I demonstrated one aspect ... Perceptual mappings to the destination space ... above. Another issue is that it's very easy to push some colors OOG in any working space, but the larger the working space, the further you can push the colors OOG, and so the more the clipping that may occur on conversion to the destination.

Going to a smaller space like Beta RGB limits the problem but it doesn't make it go away.

I like to keep things contained and not to have to spend too much time watching Gamut Warnings, and then sometimes having to fix the OOG colors because they look bad on output. But that's just a preference ... if you prefer to do it the other way then fine, it's just as valid a way of working.

What I didn't mention is that my final working space is the print space.  So I convert to Beta RGB first and ready the image for print; then I convert to the print space and do the final edits in that space.  That way I can see the potential problems (I also turn gamut warning on for my monitor, so I know that I'm seeing what is going to go to the printer) and any edits I do are automatically constrained to the print space.  I know you can achieve something similar with soft-proofing, but soft-proofing doesn't limit you, whereas the working space does. Again, this is just a question of preference.

I do appreciate your concern that I might be wasting my time, and perhaps you're right .  However, how much time does it take to convert an image from one working space to another?  Once this step is in one's workflow the additional time taken is really insignificant (especially if you set the workspace in Photoshop to Beta RGB ... or whatever workspace you like) - and it would be completely insignificant if Lightroom allowed one to open the image in Photoshop using profiles other than sRGB, Adobe RGB or ProPhoto RGB.

Robert

[Robert Ardill]

Thinking about the OOG issue, both Beta RGB and ProPhoto RGB are bigger colour spaces than any likely real device.  They're also probably larger than the effective colour space of the camera sensor (yes, I know camera sensor data doesn't have a colour space, I'm talking about the capability of the sensor to capture colour, once converted to a colour space).  So both colour spaces can correctly represent all colours out of the camera, and any conversion issues resulting from conversion to the smaller colour space of a real device will be the same in both cases.  This is because, although the colour spaces are different, the colours being represented are the same.  Just different numbers. 

Of course, in processing it's possible to introduce new colours outside the camera sensor's gamut.  For example, if you work in either Beta RGB of ProPhoto RGB and screw the saturation right up, you can end up with colours that the sensor could not have created.  You won't be able to see them on the monitor either, as few monitors go much wider than Adobe RGB.  So to that extent, if one gets a bit too liberal with the saturation (or similar) controls, then one can create colours further out of gamut in ProPhoto RGB than in Beta RGB. I think one would have to have a Ken Rockwell liking for uber-saturated colour for that to be a significant danger. 

I'm struggling to see how the choice of two working spaces, both larger than that of any real device, and larger than the capability of the camera sensor, makes a significant difference. 

Well, to quote Andrew Rodney on Photo.net (just checking on sensor 'gamuts'): "... These arbitrary gamut boundaries do not necessarily and often don't get close to defining the gamut possibilities of the sensor (if we have to use the word gamut) ".  As usual, Andrew is a bit above my head, but I think he means that more colors can potentially be recorded by a camera sensor than will fit in many color spaces (thus the choice of ProPhoto for raw processing).

I don't think it's hard at all to get colors that fall outside the destination gamut in large workspaces like ProPhoto.  Here is a typical example. The top image is in Beta RGB, the bottom one in ProPhoto.  Gamut warning is turned on for the print destination for both. 






As you can see, there are colors in the ProPhoto version that are OOG, but not in the BetaRGB. 

OK, this is a sunrise, so perhaps the colors are a bit extreme.  But what about quite dark colors, greens for example, that appear quite unsaturated, but in fact are pushed out beyond the print capability? What happens to them when you print? Same thing, right? They are going to have to be clipped if you print using Relative Colorimetric (which I almost always do).

Robert

[fdisilvestro]

then I convert to the print space and do the final edits in that space.  That way I can see the potential problems (I also turn gamut warning on for my monitor, so I know that I'm seeing what is going to go to the printer) and any edits I do are automatically constrained to the print space.  I know you can achieve something similar with soft-proofing, but soft-proofing doesn't limit you, whereas the working space does. Again, this is just a question of preference.

Just bear in mind that output color spaces are not necessarily gray balanced (r=g=b =/= neutral) nor perceptually uniform, so your edits might have unintended consequences (except OOG colors). Additionally, if you need to adjust white balance, then you would be much better off working with a large space and softproofing.

[fdisilvestro]

OK, this is a sunrise, so perhaps the colors are a bit extreme.  But what about quite dark colors, greens for example, that appear quite unsaturated, but in fact are pushed out beyond the print capability? What happens to them when you print? Same thing, right? They are going to have to be clipped if you print using Relative Colorimetric (which I almost always do).

Robert

You might have to work with individual masks, individual channel saturation, vibrance, etc. if you want optimal results. Just relying on color space conversion and rendering intents is sub-optimal

[Robert Ardill]

Just bear in mind that output color spaces are not necessarily gray balanced (r=g=b =/= neutral) nor perceptually uniform, so your edits might have unintended consequences (except OOG colors). Additionally, if you need to adjust white balance, then you would be much better off working with a large space and softproofing.

True about the gray balance and perceptual uniformity ... and I am aware that what I'm seeing is not what goes to the printer, but is an AtoB mapping back to the PCS/ Working Space / Monitor.  If all is well, it should be close to the output, but of course it won't be exact.  

This is also true of soft-proofing.

Still, I'm not entirely sold on the idea of doing the final (small) edits in the destination space.  It's just something I'm playing around with. Graeme Gill's comment on this way of working was: "It's a reasonable approach, if you know what you are doing.". At this point I'm not quite convinced that I know what I'm doing ... yet.

Robert

[Robert Ardill]

You might have to work with individual masks, individual channel saturation, vibrance, etc. if you want optimal results. Just relying on color space conversion and rendering intents is sub-optimal

Yes ... well working with individual masks, channels etc., is exactly what I'm trying to avoid having to do.  In my experience (and this may have to do with my lack of skill) these edits often end up with a worse result than letting the CMM do the mapping.  What I'm trying to do is to make the CMM's job easier and more likely to be effective: break down its task into smaller chunks and make the overall  task smaller ... that sort of thing.

Robert

[Robert Ardill]

It's a problem but there isn't a thing we can do about it. Those simple triangular shapes are due to the color spaces being simple and theoretical. Output (and capture) color spaces are far different in shape and that mushing of shapes is just a fact of life. Toggle a couple rendering intents, pick the one that looks best, maybe do some minor tweaks (there's only so much you can do while soft proofing the destination color space). Move on.

Good advice.  I'm happy with my workflow and it works for me, so move on I shall

[digitaldog]

As other's have stated, in an Adobe raw workflow, you're using ProPhoto RGB gamut whether you like it or not. There's some assumed camera primary values that get converted to ProPhoto primaries, that's that. I susect this is true of all raw processors (expect camera primaries to internal color space isn't always ProPhoto primaries and gamut, Aperture uses Adobe RGB (1998)).
That being the case, it's rather ponintless to convert from ProPhoto or anything you can select in LR/ACR to Beta RGB. It might help you in the OOG department but cause issues elsewhere. And you're still stuck with a big triangle shape that's a poor fit for other output spaces. Fact of life. I can only speak for my images and output, OOG isn't a big deal. I'm more concerned with what I can't see on my wide gamut display to be honest. I could be editing colors I can't see (scary). For output, I pick an RI from the soft proof and with rare exceptions where I do a tad of output specific tweaks, I'm done. There are far, far more issues with color management and workflow IMHO than OOG colors.

As you can see, there are colors in the ProPhoto version that are OOG, but not in the BetaRGB.

I see an ugly red blob which obviously isn't what I"ll see on the print. What I can't see is what the affect of the RI and conversion has on the actual print and that's really all I care about.

In my experience (and this may have to do with my lack of skill) these edits often end up with a worse result than letting the CMM do the mapping.

Exactly! It's probably not a lack of skill.

[bjanes]

So, you know for a fact that ProPhoto RGB is "too big"? You've actually seen "quantization errors" using ProPhoto RGB? Or is what you "believe" based upon your internet reading?

I ask because I've never seen any quantization errors when working in a ProPhoto RGB color managed workflow...

If you were on Bruce Lindbloom's web site reading about it, you should note that page was last updated on Sun, 20 Apr 2003 09:06:14 GMT which was about the time that Adobe released Camera Raw v1. There is a reason why Thomas Knoll chose ProPhoto RGB and linear gamma as the internal working space for ACR and then LR.

The fact that Bruce's post on BetaRGB is old does not necessarily mean that it no longer applicable -- physical constants do not change. There is a concept of Real World Surface Colors (see this thread and the link to the Norman Koren site further discussing the matter). Whatever space one is using for editing, it should include these colors. According to Mr. Koren, AdobeRGB includes most of these and the eye is not extremely sensitive to chroma differences in highly saturated colors, suggesting that AdobeRGB might be adequate for most work. A wider space would include more colors, but there may not be much perceivable difference in the outputs with real world scenes.

Lindbloom's reference color set used in choosing the primaries for BetaRGB seems to consist primarily of the colors found in photographic films and printing paper, and may be out of date in the digital age where we are using digital sensors and inkjet printers. The extent that this color set includes these real world surface colors is not documented.

My own take is that BetaRGB may make sense if one is using an 8 bit color depth, but with a 16 bit color depth, quantization errors with ProPhotoRGB are negligible and not perceptible and the increased gamut may be useful in some situations. For my own work with Adobe applications I use 16 bit ProPhotoRGB since these applications use ProPhoto primaries and out of gamut colors in printing are not a significant problem when one uses reasonable editing.

Bill

[Robert Ardill]

As other's have stated, in an Adobe raw workflow, you're using ProPhoto RGB gamut whether you like it or not. There's some assumed camera primary values that get converted to ProPhoto primaries, that's that. I susect this is true of all raw processors (expect camera primaries to internal color space isn't always ProPhoto primaries and gamut, Aperture uses Adobe RGB (1998)).
That being the case, it's rather ponintless to convert from ProPhoto or anything you can select in LR/ACR to Beta RGB. It might help you in the OOG department but cause issues elsewhere. And you're still stuck with a big triangle shape that's a poor fit for other output spaces. Fact of life. I can only speak for my images and output, OOG isn't a big deal. I'm more concerned with what I can't see on my wide gamut display to be honest. I could be editing colors I can't see (scary). For output, I pick an RI from the soft proof and with rare exceptions where I do a tad of output specific tweaks, I'm done. There are far, far more issues with color management and workflow IMHO than OOG colors. I see an ugly red blob which obviously isn't what I"ll see on the print. What I can't see is what the affect of the RI and conversion has on the actual print and that's really all I care about.Exactly! It's probably not a lack of skill.

I agree ... often OOG isn't a big deal and the CMM handles it just fine. As you say, pick the RI that you like best and it's usually fine.

But if you are trying to get the best from your image and you want a Perceptual mapping because you think it looks better than a Relative mapping, then you will get a better result if you first go Relative to a smaller color space and then do the Perceptual mapping.  That is a fact, simply because Perceptual squeezes the whole source gamut to the destination gamut, so the smaller the source gamut the less the squeeze, and the less the squeeze the less impact on all colors, but the most saturated the least.

You can see it with the test image I posted earlier:



The top one is a 2-step mapping, the bottom 1-step. Both the oranges and yellows are flattened in the bottom image, and in some places the yellows have even merged into the oranges.  It may not be all that easy to see on the sRGB crop here, but if you would like to see it better, here is the tif crop (top layer is the 2-step mapping): http://www.irelandupclose.com/customer/LL/W58825.tif

My question is this: if a really simple step like this yields some improvement (even if it's not much) ... why not do it?  OK, it takes an extra few seconds, but you can still work in ProPhoto up to the end if you want to and any damage to the file going from ProPhoto to Beta RGB or Adobe RGB (or whatever) is absolutely minimal ... so why not do it?

Robert

[Tim Lookingbill]

I'm not in the least interested in arguing about this or anything else with you or 'folks knowledgeable and experienced in both post processing and background history of the technology'. My interest is to learn, and because my experience of color management and post processing is quite limited, there is a lot that I still have to learn ... and already this forum has helped me a lot, for which I'm very thankful.

If I am wasting your time then I'm truly sorry.

Robert

Hi Simon,

The conversion to Beta RGB or Adobe RGB or any smaller space isn't going to improve things in itself, of course (and as you say, any conversion will most likely introduce some small errors) so it would be a pointless thing to do unless there was some benefit down the line.

Argumentative AND speculative seeing you're just learning and aren't quite knowledgeable about this technology as you've professed. And no, I don't know what answer to give you in order to learn and/or teach because you've setup a complicated workflow scenario where you've found some tiny aspect of the behavior of the software that in the time to figure it out anyone reading this and trying to learn already edited several images and printed with no problems.

You want to learn something? Here's a teaching moment.

Post the best looking image you created with edits in your favorite imaging software and tell us how long it took you to turn into a print and all the difficulties you faced. That's all that matters. I and many others reading this thread will in turn learn from your experience.

Keep in mind the preview you see on your display is a fantasy that was formed by so many variables under the hood not just with imaging software but with your display and the OS that it's a miracle it works as good as it does without trying to speculate how the math is being manipulated in forming the preview. You're never going to know for sure in order to develop a more consistent and efficient workflow. That's the goal!

The work has already been done in the software you paid dearly, so there's no point in reverse engineering with speculative suppositions regarding working spaces/OOG, bit depth, dithering all of which clearly don't help anyone create a better looking image>print a lot quicker than their current setup.

[Tim Lookingbill]

But if you are trying to get the best from your image and you want a Perceptual mapping because you think it looks better than a Relative mapping, then you will get a better result if you first go Relative to a smaller color space and then do the Perceptual mapping.  That is a fact, simply because Perceptual squeezes the whole source gamut to the destination gamut, so the smaller the source gamut the less the squeeze, and the less the squeeze the less impact on all colors, but the most saturated the least.

Robert

It's not a fact if it doesn't work that way on every image on a consistent basis especially when using the subjective term "looks better".

To drive home the point even further that the digital image and its processing is a fantasy and not some precision scientific endeavor that can be controlled and measured on a consistent basis using hardware and software whose low pricing doesn't reflect precision,predictability and consistency, I submit the image below and ask how do you determine the color gamut capture capability of my DSLR camera shooting Raw compared to its incamera processing.

The answer is that there are too many choices, options and methods that get in the way in allowing anyone to know precisely what the gamut is at least on level that's predictable and controllable. So what's the point in trying to figure all this out even if you now understand what it is. It's still not useful in making a better looking image and print far much faster and consistently.

[Jack Hogan]

According to Mr. Koren, AdobeRGB includes most of these and the eye is not extremely sensitive to chroma differences in highly saturated colors, suggesting that AdobeRGB might be adequate for most work. A wider space would include more colors, but there may not be much perceivable difference in the outputs with real world scenes.

Hi Robert,

I kind of agree with you: use as big a space as you need but no bigger.  How big of a space?  How about your camera's?  If you don't know how big your camera's space is then go for the output device.  Most monitors (and many printers) cannot do more than some variant of AdobeRGB.  Come to think of it my monitor and 55 incher TV only do AdobeRGB, as does my printing service.  So I guess you know what my working color space is.

Some people want to future proof their files, I am not one of them.  99% of images get seen in sRGB, so I convert them to that from raw before sending them off.  A few get printed.  Every time I print one of my images, old or new, I like to re-work them from raw with all the latest and greatest toys I've collected and with the new skills I've developed - it's amazing how differently I process images today than I did just five years ago - and I do that while choosing the appropriate color space for the output device at hand at that time.

So no need for cavernous color spaces where colors get lost in.  Small (well, relatively) is beautiful, start from raw and just use what you need at the time.  If you don't know what you need, go for s or aRGB depending on your monitor.

Jack

[Robert Ardill]

Hi Robert,

I kind of agree with you: use as big a space as you need but no bigger.  How big of a space?  How about your camera's?  If you don't know how big your camera's space is then go for the output device.  Most monitors (and many printers) cannot do more than some variant of AdobeRGB.  Come to think of it my monitor and 55 incher TV only do AdobeRGB, as does my printing service.  So I guess you know what my working color space is.

Some people want to future proof their files, I am not one of them.  99% of images get seen in sRGB, so I convert them to that from raw before sending them off.  A few get printed.  Every time I print one of my images, old or new, I like to re-work them from raw with all the latest and greatest toys I've collected and with the new skills I've developed - itìs amazing how differently I process images today than I did just five years ago - and I do that while choosing the appropriate color space for the output device at hand at that time.

So no need for cavernous color spaces where colors get lost in.  Small (well, relatively) is beautiful, start from raw and just use what you need at the time.  If you don't know what you need go for s or aRGB depending on your monitor.

Jack

Thank goodness ... I'm not entirely alone any more (just joking, I know that the discussion so far has been mostly constructive and helpful ... and it hasn't all been disagreement).

Yes, AdobeRGB is just fine for me ... I just feel that it's a little tight, that my printer can print outside of it ... bla bla.  But in reality I would be very happy to stay within that space and I VERY much doubt I would see any difference if I go to a bigger space.

I also agree that (as long as we keep our raw images) that we are quite future-proofed enough ... and as you say, if we have to redo the image in 5 years time to fit into what may then be a wider gamut ... well, hopefully our skills will have improved and we will end up with a better image, and not just because of the wider gamut.

As you point out, small(ish) is beautiful (literally, when I think of some of the 'HDR' images I've seen in the past few years!!).

Robert

[Simon Garrett]

Thank goodness ... I'm not entirely alone any more (just joking, I know that the discussion so far has been mostly constructive and helpful ... and it hasn't all been disagreement).

Actually, I sort of agree with you too!  sRGB is an underrated colour space.  By that I mean that most pixels in most images have colours within sRGB.  I have two monitors: one with a gamut wider than Adobe RGB, and one approximates to sRGB colour gamut.  Both are calibrated and profiled, and when I use Lightroom (which uses Adobe RGB for previews), I can see no difference between the rendering of colour on the two monitors on most of my 35,000 plus raw images.  In other words: few pixels outside sRGB on most of my raw images.  Of course, I can create blobs of 100% saturated colour in ProPhoto RGB, and the difference between the two monitors is very, very obvious.  But not for most real raw images.  sRGB is a perfectly satisfactory colour space for most purposes.  

My reason for disagreeing with your workflow, slightly, is that I take the view that if you start in a wide-gamut, you might as well stay there until the last stage, when you convert to the output colour space (or to sRGB if it's for the web).  Lightroom uses ProPhoto RGB as its working space - no choice about that - so I stay there until the that last stage.  

I also go with the future-proof argument.  If the image is in ProPhoto RGB, there is virtually no chance that any future device will have a larger colour space (even if relatively few images need more than sRGB).

[digitaldog]

sRGB is an underrated colour space.

How so?

By that I mean that most pixels in most images have colours within sRGB.

It is the image data that have colors outside sRGB we can output that's, far more prevalent.
There's only one actual device that sRGB defines and it's an old CRT of which that space was designed to mimic. What's underrated about that one theoretical device?

[Robert Ardill]

Actually, I sort of agree with you too!  sRGB is an underrated colour space.  By that I mean that most pixels in most images have colours within sRGB.  I have two monitors: one with a gamut wider than Adobe RGB, and one approximates to sRGB colour gamut.  Both are calibrated and profiled, and when I use Lightroom (which uses Adobe RGB for previews), I can see no difference between the rendering of colour on the two monitors on most of my 35,000 plus raw images.  In other words: few pixels outside sRGB on most of my raw images.  Of course, I can create blobs of 100% saturated colour in ProPhoto RGB, and the difference between the two monitors is very, very obvious.  But not for most real raw images.  sRGB is a perfectly satisfactory colour space for most purposes.  

My reason for disagreeing with your workflow, slightly, is that I take the view that if you start in a wide-gamut, you might as well stay there until the last stage, when you convert to the output colour space (or to sRGB if it's for the web).  Lightroom uses ProPhoto RGB as its working space - no choice about that - so I stay there until the that last stage.  

I also go with the future-proof argument.  If the image is in ProPhoto RGB, there is virtually no chance that any future device will have a larger colour space (even if relatively few images need more than sRGB).

That's fair enough.  There certainly are good arguments for staying in the big space until the end, especially if one knows what one is doing and especially if one is careful.

One of the nice things about using a raw smart object in Photoshop is that you can convert it back and forth from ProPhoto to sRGB to AdobeRGB etc, so that you are not stuck in one working space (admittedly this involves duplicating the image, converting the smart object on it's own, copying the adjustment layers over ... a bit messy, but do-able).  Apart from the flexibility of being able to (relatively) easily have variants for print and web, it's also a pretty good way to future-proof yourself (assuming smart objects don't vanish into the Creative Cloud in some foggy future!).

Robert

[Robert Ardill]

How so?
It is the image data that have colors outside sRGB we can output that's, far more prevalent.
There's only one actual device that sRGB defines and it's an old CRT of which that space was designed to mimic. What's underrated about that one theoretical device?

I'm sure Simon is well capable of answering this himself, but I'll throw in my take on it. The reason sRGB is underrated is that many of us think it's inferior because it's smaller ... whereas, in reality, its gamut is quite large enough for most of our images.  That pretty much fits under the definition of 'underrate' I think.

We think it's OK for the web, because there's no choice really, but, sure, it's not good enough for printing, is it?

Robert

[digitaldog]

The reason sRGB is underrated is that many of us think it's inferior because it's smaller ... whereas, in reality, its gamut is quite large enough for most of our images.

No my images It's far too small. Even output to CMYK (SWOP V2), sRGB clips colors. Did you see my video on gamut?

We think it's OK for the web, because there's no choice really, but, sure, it's not good enough for printing, is it?

It's OK for web because of how it's based. It's not ideal for print, there are no sRGB printers. If you are concerned with gamut clipping, sRGB isn't the space you'd ever consider using for anything but posting to the internet. And someday, should wide gamut displays be the norm, we'll point towards Adobe RGB (1998) instead of sRGB.