A Workflow with Beta RGB

[Tim Lookingbill]

It is the image data that have colors outside sRGB we can output that's, far more prevalent.

And that image data can only be seen on a device that can reproduce them and currently that being wide gamut displays but there are limits to that as well. It would be helpful for many photographers to understand when to know what colors they're shooting in the real world that needs future proofing.

I've already had a real world experience printing a shot of a turquoise rayon dress and printing on a Fuji Frontier drylab whose gamut in the cyans & turquoise extend beyond AdobeRGB but couldn't be seen on my sRGB display, but that is the exception rather than the norm and so far is the only evidence of a color captured that needs future proofing I've come across in the five years I've been processing Raw. Most of my Raw captures I can make look as they appeared no matter the saturation level, but of course it requires a luminance hit like the orange flower example posted above.

Has someone measured or determined by other methods real world colors that can't be seen in a digital capture due to limitations of current display gamut or even printer gamut but can be captured by the digital sensor and passed onto image editing software in the future for devices that can show them?

[Robert Ardill]

No my images It's far too small. Even output to CMYK (SWOP V2), sRGB clips colors. Did you see my video on gamut? 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.

Hi Andrew,
I'm not suggesting that sRGB is the best working-space for print.  I was simply agreeing with Simon that for many images it's quite adequate and with a bit of tweaking, images in sRGB will look fine, whether they are printed or viewed on a monitor.  Having extra gamut doesn't necessarily make a better image!

Also, sRGB won't cause any clipping on output.  The clipping occurs because the destination gamut is smaller than the working space, not the other way around (as you know, of course).  In fact if you want to avoid clipping on output you are much better off working in sRGB than in Adobe RGB, Beta RGB, ProPhoto RGB or any of the working spaces that may be bigger than the output gamut.

Robert

[Robert Ardill]

Has someone measured or determined by other methods real world colors that can't be seen in a digital capture due to limitations of current display gamut or even printer gamut but can be captured by the digital sensor and passed onto image editing software in the future for devices that can show them?

No, I haven't seen any analysis of this kind, but it would be interesting to know the capture range of a typical modern sensor, considering its response to the different light wavelengths, the effect of noise etc. 

But in relation to monitors ... well the best monitors can only do a bit better than Adobe RGB, and printers not a whole lot better: current camera sensors can certainly capture more than that.  So there's plenty of head-room for what could be done in the future.

Robert

[digitaldog]

I'm not suggesting that sRGB is the best working-space for print. 

It isn't by a long shot! It's only ideal for one use, the internet.

I was simply agreeing with Simon that for many images it's quite adequate and with a bit of tweaking, images in sRGB will look fine, whether they are printed or viewed on a monitor.  Having extra gamut doesn't necessarily make a better image!

I disagree with both ideas. First, it's not ideal, it's suboptimal for print output. The output may be 'fine' whatever that means but it's not the best output that can be achieved all things being equal (capture color space and output gamut). The sRGB JPEG's your camera produces are fine too, I'll stick with the setting for raw data.

Also, sRGB won't cause any clipping on output. 

The 3D gamut maps suggest otherwise:

That red blob falling outside sRGB gamut is SWOP TR001, sRGB doesn't even have sufficient gamut space for that kind of output. Next, there are no native sRGB capture devices so whatever data you have in sRGB, it was converted to that gamut and I'll bet you dollars to doughnuts that native gamut was larger. The clipping DID happen when you converted to sRGB, I submit that unless the output is to the internet, you shouldn’t have done that conversion.

The clipping occurs because the destination gamut is smaller than the working space, not the other way around (as you know, of course).

 
The clipping occurred because you selected sRGB from some larger color space! Again, did you see my video on gamut?

In fact if you want to avoid clipping on output you are much better off working in sRGB than in Adobe RGB, Beta RGB, ProPhoto RGB or any of the working spaces that may be bigger than the output gamut.

I started with raw data, or a scan in scanner RGB. I end up by your suggestion in sRGB. There was no gamut clipping? The red in SWOP gets clipped going from sRGB to CMYK because sRGB is a shitty sized working space. The data got clipped before it became sRGB too!

Everything you thought you wanted to know about color gamut:

A pretty exhaustive 37 minute video examining the color gamut of RGB working spaces, images and output color spaces. All plotted in 2D and 3D to illustrate color gamut.

High resolution: http://digitaldog.net/files/ColorGamut.mov
Low Res (YouTube): http://www.youtube.com/watch?v=n0bxSD-Xx-Q

[bjanes]

It isn't by a long shot! It's only ideal for one use, the internet.I disagree with both ideas. First, it's not ideal, it's suboptimal for print output. The output may be 'fine' whatever that means but it's not the best output that can be achieved all things being equal (capture color space and output gamut). The sRGB JPEG's your camera produces are fine too, I'll stick with the setting for raw data.
 
The 3D gamut maps suggest otherwise:

That red blob falling outside sRGB gamut is SWOP TR001, sRGB doesn't even have sufficient gamut space for that kind of output. Next, there are no native sRGB capture devices so whatever data you have in sRGB, it was converted to that gamut and I'll bet you dollars to doughnuts that native gamut was larger. The clipping DID happen when you converted to sRGB, I submit that unless the output is to the internet, you shouldn’t have done that conversion.  
The clipping occurred because you selected sRGB from some larger color space! Again, did you see my video on gamut? I started with raw data, or a scan in scanner RGB. I end up by your suggestion in sRGB. There was no gamut clipping? The red in SWOP gets clipped going from sRGB to CMYK because sRGB is a shitty sized working space. The data got clipped before it became sRGB too!

Everything you thought you wanted to know about color gamut:

A pretty exhaustive 37 minute video examining the color gamut of RGB working spaces, images and output color spaces. All plotted in 2D and 3D to illustrate color gamut.

High resolution: http://digitaldog.net/files/ColorGamut.mov
Low Res (YouTube): http://www.youtube.com/watch?v=n0bxSD-Xx-Q

For a real world example, I rendered an image of a tulip into ProPhotoRGB using ACR with the AdobeStandard profile, using no saturation boost (default settings). The following images are in sRGB for web display.

One can use the gamut warning in Photoshop with AdobeRGB as the target. Many colors are out of gamut, but the extent of OOG is not determined with this type of warning.



One can use Colorthink to calculate a color list and determine the DeltaEs (as per the DigitalDog's movie). A DeltaE of 2 or less is minor, whereas a DeltaE of 2 to 8.5 is moderate, and a DeltaE of greater than 14 is major.



For printing, I used the Epson 3880 with Premium Glossy as an example. Many of the yellows and reds are out of gamut of both AdobeRGB and the printer gamut. However, if one uses AdobeRGB as the working space, there are relatively few colors that the printer is capable of printing that are outside of the AdobeRGB gamut so that one does not lose much if he is using AdobeRGB rather than ProPhotoRGB as the working space. The printer gamut for mid luminance greens and teals is considerably wider than AdobeRGB, but these colors are not in the current image.



Bill

[digitaldog]

For printing, I used the Epson 3880 with Premium Glossy as an example. Many of the yellows and reds are out of gamut of both AdobeRGB and the printer gamut. However, if one uses AdobeRGB as the working space, there are relatively few colors that the printer is capable of printing that are outside of the AdobeRGB gamut so that one does not lose much if he is using AdobeRGB rather than ProPhotoRGB as the working space.

On this image, I'd agree. Be useful to see something representing very saturated greens and blues. Atkinsion's Lab test image (from Tango scans), Roman 16's (we need something from a camera)?
Be nice to have a super computer to run ColorThink on

If the source is raw with an Adobe raw process, you're getting ProPhoto RGB primaries, why ad another conversion prior to output?

[Robert Ardill]

No one is arguing that sRGB has a wider gamut than Adobe RGB (and I assume that no one is arguing that Adobe RGB has a wider gamut than Beta RGB and Beta RGB a wider gamut than ProPhoto RGB etc., etc).

Here it is: Adobe RGB is the wider gamut, sRGB the smaller one:


No one is arguing that saturated colors in ProPhoto will not get clipped when going to sRGB.

No one is arguing that print gamuts often are wider than sRGB.

That does NOT make sRGB a 'shitty sized working space', to quote you Andrew.  It just makes it a smaller working space.

It's the wrong working-space to use if your image has colors that are outside it, full stop.  If all the colors in your image are within its gamut, then it's as good, or possibly better, a working space to use than one that has a larger gamut. Using a larger gamut will gain you nothing when going to print, because the colors are not there.

If your image has colors outside of sRGB then of course you should use a working space that can accommodate them.  But if your image has colors that are within your larger workspace, but outside the gamut of your destination, well then all you've done is to create a problem for yourself ... and you can either fix the image or let the CMM do it for you ...but either way the image IS going to get squashed or clipped on its way to output.

So it's horses for courses ... there are pros and cons, but it is simply not true to say that sRGB is a bad workspace: limited, yes, bad, no.

Robert

[Robert Ardill]

If the source is raw with an Adobe raw process, you're getting ProPhoto RGB primaries, why ad another conversion prior to output?

Very simple: if you do a Perceptual mapping to the destination from ProPhoto you are squeezing the whole of ProPhoto into your destination gamut.  If you do a conversion to a smaller workspace first (it will be a Relative conversion) then the subsequent Perceptual mapping is less drastic (so that saturated colors will get flattened/desaturated less).  Of course there is the possibility of clipping when converting from the larger working space to the smaller one, so the choice of intermediate working space (or whether to use one at all) is something that needs to be considered.

[bjanes]

Very simple: if you do a Perceptual mapping to the destination from ProPhoto you are squeezing the whole of ProPhoto into your destination gamut.  If you do a conversion to a smaller workspace first (it will be a Relative conversion) then the subsequent Perceptual mapping is less drastic (so that saturated colors will get flattened/desaturated less).  Of course there is the possibility of clipping when converting from the larger working space to the smaller one, so the choice of intermediate working space (or whether to use one at all) is something that needs to be considered.

That you are sqeezing the whole gamut of ProPhoto into the printer space with perceptual rendering is false. Current CMMs are dumb in that they do not look at the colors that are actually in the image but merely squeeze the image by some arbitrary value, which usually leaves OOG colors after the perceptual rendering. Even if there are no OOG colors in the original image, the arbitrary fixed compression is applied. See this article by Mike Chaney.

Bill

[Jim Kasson]

Very simple: if you do a Perceptual mapping to the destination from ProPhoto you are squeezing the whole of ProPhoto into your destination gamut. 

Boy, I don't think so, if what you mean is some kind of linear 3D compression. Including the parts of PPRGB that aren't visible? That would be a pretty crazy way to write a perceptual 3D LUT. Do you have any evidence that people populate the look-up tables that way?

Jim

[Robert Ardill]

That you are sqeezing the whole gamut of ProPhoto into the printer space with perceptual rendering is false. Current CMMs are dumb in that they do not look at the colors that are actually in the image but merely squeeze the image by some arbitrary value, which usually leaves OOG colors after the perceptual rendering. Even if there are no OOG colors in the original image, the arbitrary fixed compression is applied. See this article by Mike Chaney.

Bill

Actually the CMM only does what the mapping table (or matrix) tells it to do, and the mapping table depends on the algorithm used, and the algorithm is up to the author of the profile (because the ICC does not specify exactly how it should be done).  The 'arbitrary' value is the difference between the larger color space and the smaller one (there is no squeezing or stretching if the destination space is larger than the source in the case of a Perceptual mapping). There should be NO OOG colors after a perceptual mapping, but there may be after a saturation mapping (in order to force as much saturation in the output as possible).

Boy, I don't think so, if what you mean is some kind of linear 3D compression. Including the parts of PPRGB that aren't visible? That would be a pretty crazy way to write a perceptual 3D LUT. Do you have any evidence that people populate the look-up tables that way?

Jim

Well not some sort of linear 3D compression, obviously ... but a 3D compression, yes, absolutely.  Directly from Graeme Gill of ArgyllCMS, and if he doesn't know what a Perceptual mapping does, then I don't know who does.  Also, have a look at this excellent tutorial: http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm (although the section on Absolute Colorimetric is misleading).

Robert

[Tim Lookingbill]

I can see Robert has learned quite more than he lets on to be able to counter to folks in this thread with knowledge of how CMM algorithms map color data from one space to another. What's your thoughts on Euclidean math, Robert? Have you looked into that aspect of the math that operates under the color management hood?

It wouldn't matter if you knew or not because as usual in discussions of this sort none of the information is of any practical use in helping photographers make better pictures.

It's sort of like folks who seem to practice shade tree math and color science relying only on graphical analyzers to make them come across as if they know how the map was drawn, understand the map intimately and know the code and gps coordinances that function under the hood but never seem to go anywhere or help others to their destination.

[digitaldog]

That does NOT make sRGB a 'shitty sized working space', to quote you Andrew.  It just makes it a smaller working space.

I think it does based on it's gamut size which is what separates the men from the boys in terms of a working space. A working space only has three attributes. The TRC gamma and white point are pretty immaterial in color managed app's for which such spaces are designed. It's the primaries and thus gamut that make the big differences here. There's one useful end point for sRGB, I've told you what that is. It's inferior/sub optimal for just about anything else one would convert to for output from the wide gamut master. It's actually inferior for output to something we expect not to have a wide gamut (SWOP CMYK)! That is, if you have any hope to reproduce the colors you have that the output device could reproduce.

[Robert Ardill]

It wouldn't matter if you knew or not because as usual in discussions of this sort none of the information is of any practical use in helping photographers make better pictures.

Actually, Tim, it is very much of practical use.  You surely can't be serious when you say that there is no value in understanding what happens when an image is mapped from one color space to another?  Or perhaps I've misunderstood you.

If you prefer to work entirely by experience then that's totally fine: it is another and entirely valid way of finding out what works and what doesn't.  Experience cannot be replaced by theory - I don't dispute that. But why knock an attempt to understand what actually happens when A gets transformed to B?

Robert

[Robert Ardill]

I think it does based on it's gamut size which is what separates the men from the boys in terms of a working space. A working space only has three attributes. The TRC gamma and white point are pretty immaterial in color managed app's for which such spaces are designed. It's the primaries and thus gamut that make the big differences here. There's one useful end point for sRGB, I've told you what that is. It's inferior/sub optimal for just about anything else one would convert to for output from the wide gamut master. It's actually inferior for output to something we expect not to have a wide gamut (SWOP CMYK)! That is, if you have any hope to reproduce the colors you have that the output device could reproduce.

Yes, Andrew, I agree with you when you say "That is, if you have any hope to reproduce the colors you have that the output device could reproduce".  This assumes that you want to make full use of the output gamut, and the only way you can do that is for your working-space to fully encompass the output gamut: no debate there!  However, I will repeat, perhaps using slightly different words in order to make myself clear, that for an image whose gamut is within sRGB , there is NO advantage to using a working space with a larger gamut and there may well be an advantage (particularly if you use a Perceptual mapping to the output) in using the smaller sRGB space.

If we are to choose only one working space, should that working space be sRGB? Well, of course not, not unless all our output is going to the web.  If we prefer to use only one working space then surely our preference will lead us to Adobe RGB or larger.  But if we are happy to use different working spaces for different images ... well then sRGB could be a perfectly excellent choice for some images (but surely not for all).

Robert

[digitaldog]

This assumes that you want to make full use of the output gamut, and the only way you can do that is for your working-space to fully encompass the output gamut: no debate there!

That's what I want. I don't think giving my data a sloppy sex change operation is best practice. If the output is the internet, it's sRGB. Anything but that, it's different.

If we are to choose only one working space, should that working space be sRGB?

No, ProPhoto RGB. One can convert to sRGB from there, not the other way around (that be pointless). Remember what a working space really is (an output agnostic editing space primarily). If every means of previewing image data on the internet were indeed color managed, we'd have zero need for sRGB.
http://www.adobe.com/digitalimag/pdfs/phscs2ip_colspace.pdf
There are no prefect RGB working spaces.

Edit: typeface repaired.

[Robert Ardill]

Andrew, if you quote me I would appreciate you not adding bold to what I've written or quoting only part of a comment: that's not cricket, as the Brits would say.

Robert

[Simon Garrett]

If I were to choose only one working space it would be ProPhoto RGB, no question.  Actually that is the only working space I use!

I'm suitably awed by all the 3-D diagrams showing how sRGB is sh... well not at big as other colour spaces.  I've also seen elsewhere countless posts showing myriad dots of pixels way outside sRGB colour space.  

Only, I come back to the fact that most of my images don't look very different on my larger-than-Adobe-RGB gamut monitor compared to the sRGB monitor that sits right next to it.  Both are calibrated and profiled, and I can clearly see the difference between fully-saturated Adobe RGB colours on the two monitors.  Sure, if I take pictures with bright colours, I can open the raw in Photoshop, and with soft proofing set to sRGB, the gamut warning will show me areas of OOG colours (usually quite small areas), but the difference is barely visible on the images.  And yes - I do have normal colour vision.  

That's why I think sRGB is by no means ideal, but not quite a disaster.  

And quite often my stuff ends up on the web, or is sent electronically to people with monitors not profiled or calibrated, and has to be in sRGB anyway.

[digitaldog]

No one called it a disaster, it's just shitty as a working space (hence the s in the name  ). It's just great for viewing on the media it was designed for, that's not print.

Simple matrix profiles of RGB working spaces like sRGB when plotted 3 dimensionally illustrate that they reach their maximum saturation at high luminance levels. They are based on an emissive device. The opposite is seen with print (output) color spaces. Printers produce color by adding ink or some colorant, while working space profiles are based on building more saturation by adding more light due to the differences in subtractive and additive color models. To counter this, you need a really big RGB working space like ProPhoto RGB due to the simple size and to fit the round peg in the bigger square hole the output device space encompasses.Then there is the issue of very dark colors of intense saturation which do occur in nature and we can capture with many devices. Many of these colors fall outside Adobe RGB (1998) and when you encode into such a space or smaller, you clip the colors to the degree that smooth gradations become solid blobs in print, again due to the dissimilar shapes and differences in how the two spaces relate to luminance. So the advantage of ProPhoto isn't only about retaining all those out-of-gamut colors it's also about maintaining the dissimilarities between them, so that you can map them into a printable color space as gradations rather than ending up as blobs. 


[Simon Garrett]

Understood, Andrew, and I agree with that point.