Pages: 1 2 [3] 4 5   Go Down

Author Topic: sRGB, Adobe RGB, and ProPhoto RGB - Exploring the Gamut Limitations of Printing  (Read 19408 times)

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2169

I understand that and see no reason why that would be at all useful. Why funnel everything to the least usable RGB working space which is only appropriate (today) for one use: internet/mobil device viewing?
The ONLY reason I'd cross render my Epson to match a smaller gamut like SWOP V2 is if I wanted to make a proof to simulate that output before going to a press that conforms to SWOP V2. Why cripple the output to print to something lesser than it is? And again, the sRGB representation you see on your display could and often does look vastly different than what someone else would see from the same numbers on a web page? It's impossible to proof and pointless too. I'm still struggling to understand what your technique does other than cripple the print output.
It doesn't affect the print output, let alone cripple it. It is only useful for more closely representing in sRGB an image that is printed from ProPhoto RGB or any suitable space that encloses the original image. In no way does it interact with the printing of an image.
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 19773
  • Andrew Rodney
    • http://www.digitaldog.net/

It doesn't affect the print output, let alone cripple it. It is only useful for more closely representing in sRGB an image that is printed from ProPhoto RGB or any suitable space that encloses the original image. In no way does it interact with the printing of an image.
Again, I have no idea why this is useful. Sorry, I'm really trying to understand the practical benefits here. I need ProPhoto RGB for the reasons already expressed for output. I need sRGB only to post the same images to the web or mobile devices. And doing so is a huge crap shoot so I'm not going to spend very much time doing so, perhaps other than using a V4 LUT based sRGB profile.
Can you explain what you're trying to accomplish? Based on private emails, I'm not the only one confused.
Logged
Author “Color Management for Photographers" & "Photoshop CC Color Management" on pluralsight.com

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2169

Again, I have no idea why this is useful. Sorry, I'm really trying to understand the practical benefits here. I need ProPhoto RGB for the reasons already expressed for output. I need sRGB only to post the same images to the web or mobile devices. And doing so is a huge crap shoot so I'm not going to spend very much time doing so, perhaps other than using a V4 LUT based sRGB profile.
Can you explain what you're trying to accomplish? Based on private emails, I'm not the only one confused.

It's unclear what you find confusing. Based on the above I take it that you believe that the variation between web/mobile devices is so great that it overwhelms large printer to sRGB gamut reduction distortions and hence isn't worth spending any time doing.  You may well be right for the majority of devices out there, especially mobile ones. Not as much for people trying to get an idea what a print they might purchase would appear like and have a monitor that does a reasonable job rendering sRGB.
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 19773
  • Andrew Rodney
    • http://www.digitaldog.net/

It's unclear what you find confusing. Based on the above I take it that you believe that the variation between web/mobile devices is so great that it overwhelms large printer to sRGB gamut reduction distortions and hence isn't worth spending any time doing. 
They are different devices with different needs. I don't expect them to match and they can't. It's like suggesting one can and should make root beer task like beer. Why? If you want root beer, get some and drink it, same with a nice dark beer. What's the point of polluting one to do the impossible, make it be the other?
Quote
You may well be right for the majority of devices out there, especially mobile ones. Not as much for people trying to get an idea what a print they might purchase would appear like and have a monitor that does a reasonable job rendering sRGB.
I don't believe there's any debate that the web is the wild west in terms of color consistently. Heck, we've still got browsers people use that don't have a lick of color management!
If I want an idea of what a print might look like, I'll soft proof and of course make the print. The proof is in the print. So I'm still completely lost as to what you propose as being useful; we've got two vastly different output conditions and devices.

The title of your post is: Exploring the Gamut Limitations of Printing. The limitations are the sRGB color space and it's intended output: the web and mobile devices.
Logged
Author “Color Management for Photographers" & "Photoshop CC Color Management" on pluralsight.com

bjanes

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 3387

See the post on soft proofing workflow if you haven't already: http://forum.luminous-landscape.com/index.php?topic=106264.0;topicseen
The point is, few of us know when or where we will output or master files as Jeff correctly calls them. It might be a Frontier today, an Epson P800 tomorrow. Depending on the raw processor, the gamut potential will be ProPhoto RGB. So expect in rare or special cases, most of us don't know what output device an image might land upon and ProPhoto RGB makes the most sense (to me and others) as the working space for the master image.

Agree 100% here.

I can't speak specifically to that profile's gamut or the printer of course. But I've provided gamut maps from devices I have measured and they exceed sRGB gamut enough that sRGB isn't an optimal working space for those devices. Output to the web or mobile devices, fine.
Here's a plot of a LightJet on Fuji MATT paper versus Adobe RGB (1998) and as you can see, the LightJet is larger in gamut in some areas. Why clip those colors?

Here's a Frontier I again profiled (using ProfileMaker Pro like the above profile) again compared to Adobe RGB (1998), again, some clipping albeit as you suggest, not much.

Again, I can't speak to the gamut plots you've produced, only the ones based on profiles I've built and they appear to show that even Adobe RGB (1998)'s gamut isn't large enough to totally encompass those output devices. I'd be happy to send you the profiles if you wish.

Based on what I see above, based on how I process my raw data and with the product I use, based on I might output a master image I've spent hours working on, I'm sticking with encoding into ProPhoto RGB.

Thanks for your comments and the offer to send me your profiles. While I don't doubt their accuracy, they wouldn't be of much use to me when using my local Costco. The Drycreek profiles are generally accepted as reasonably reliable, and when I plotted the gamut of the recent profile for my local Costco's Frontier printer, I was surprised at how small the gamut was. I haven't saved their old profiles, but memory is that they were not so puny. I don't really know what is going on, but for important images I print on my 3880 from ProPhotoRGB. Costco with sRGB seems OK for making 4*6 inch prints for scrapbooks, etc.

Regards,

Bill
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 19773
  • Andrew Rodney
    • http://www.digitaldog.net/

Thanks for your comments and the offer to send me your profiles. While I don't doubt their accuracy, they wouldn't be of much use to me when using my local Costco.
None whatsoever. We have no idea how the two labs differ, paper, calibration etc. Just thought you'd want to plot them.
Drycreek is top notch, no reason to believe there's anything deficient in their profiles, just different from the single lab I profiled.
Logged
Author “Color Management for Photographers" & "Photoshop CC Color Management" on pluralsight.com

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2169

They are different devices with different needs. I don't expect them to match and they can't. It's like suggesting one can and should make root beer task like beer. Why? If you want root beer, get some and drink it, same with a nice dark beer. What's the point of polluting one to do the impossible, make it be the other? I don't believe there's any debate that the web is the wild west in terms of color consistently. Heck, we've still got browsers people use that don't have a lick of color management!

Yeah, tell me about it. Probably hasn't improved because human color adaption is so incredibly powerful and complex that standardizing it and/or providing decent color management doesn't offer enough financial incentive for large companies to bother.

As for me, I'm enough of a color nitpicker that when I noticed how defective the standard, matrix to matrix down conversions are I wanted to see just how defective it was and this simple experiment shows them to be quite defective indeed.

That most devices that render sRGB have large errors is no excuse for using conversion techniques that introduce unnecessary conversion.

Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2169

BTW, the larger implication of this is just how bad even proper, complete, color managed workflows are impacted when the monitor has a small gamut because the internal conversions done to render to a monitor are almost always matrix based. While it works great when your image is in gamut, when it's outside the monitor's gamut WYSINWYG and it's a lot worse than it needs to be.
Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2169

Andrew suggested taking a look at the V4 sRGB profiles at ICC in color.org.

They do have 3D LUTs (necessary to avoid matrix clipping induced errors) but their internal mapping of out of gamut colors is horrible in Perceptual mode. And that's not an exaggeration.

They did not have to make the out of sRGB gamut mapping that bad. The should take a clue from the printer profile software makers about how to handle out of gamut color.

Here it is, blech:
Logged

fdisilvestro

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1766
    • Frank Disilvestro

Let me see if I understand Doug's point (which I think is useful)

- edit a photo in ProPhoto RGB (or your preferred colour space)
- make a print for a client (with a specific output profile)
- send the client also a digital file that resembles as close as possible the print you made for that client. This digital image will be in sRGB

Two options to make this digital version in sRGB
a) convert directly from your original space (ProPhotoRGB) to sRGB
b) convert first to print output profile and then convert to sRGB

Option b is closer to the print than option a
The client gets a digital file that look almost identical to the print regardless of how different they are from the original ProphotoRGB

Did I understand?

Regards

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 19773
  • Andrew Rodney
    • http://www.digitaldog.net/

The client gets a digital file that look almost identical to the print regardless of how different they are from the original ProphotoRGB
How can that be? The print from ProPhoto RGB is vastly more saturated and falls outside the gamut of the display and sRGB. You either make a print using sRGB and try to simulate that with an sRGB version for display, or you use the full gamut capacity of the printer which isn't something you can show on-screen in sRGB.
Again, cross rendering isn't anything new. It would be easy to make an Epson printer with a vastly wider gamut than say a Lightjet, more closely match that Lightjet by cross rendering. You view the two prints together, they hopefully appear to match. That's a far cry from providing an sRGB image on the web and getting any kind of match. FWIW, you want what your client to see on-screen and you to match? Get a color reference display like a SpectraView, calibrate both to the same target calibration and of course, view the sRGB data color managed.
Logged
Author “Color Management for Photographers" & "Photoshop CC Color Management" on pluralsight.com

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2169

Let me see if I understand Doug's point (which I think is useful)

- edit a photo in ProPhoto RGB (or your preferred colour space)
- make a print for a client (with a specific output profile)
- send the client also a digital file that resembles as close as possible the print you made for that client. This digital image will be in sRGB

Two options to make this digital version in sRGB
a) convert directly from your original space (ProPhotoRGB) to sRGB
b) convert first to print output profile and then convert to sRGB

Option b is closer to the print than option a
The client gets a digital file that look almost identical to the print regardless of how different they are from the original ProphotoRGB

Did I understand?

Regards
Yes. That is precisely correct. I think the deltaE2000 histograms demonstrates just how close option b actually is.
Logged

Peter_DL

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 543

…the way gamut clipping is done by Photoshop et al from a matrix based color space to a smaller matrix based color space is so simple it was likely not optimal. Levels after matrix conversion are just simplistically clipped at 0 and 255. Out of gamut conversions from ProPhoto RGB to sRGB should try to use a technique that comes closer to the sRGB gamut boundary.

post #30 >>Ideally, rather than converting directly to sRGB with the flawed and simplistic matrix math clipping I described earlier perhaps someone can create a standard 3D LUT profile for sRGB.<<

post #18 >>Let's look at the details. PP(7,255,7) is, in XYZ (PCS working space for matrix profiles) is 13.6, 71.2, .128.  Running the matrix conversion to sRGB and scaling to sRGB's almost 2.2 gamma yields  sRGB(-221, 279, -108). Since us mortals, and Adobe, can't deal with RGB values beyond [0:255] they are simply clipped to sRGB(0,255,0). That's a big haircut.<<

This matrix clipping is however a quite efficient way to move out-of-gamut colors to the sRGB boundaries. The only downside I'm aware - strictly referring to the clipping mechanism, and not to the nature of RelCol to a smaller matrix space - are Hue shifts. The extreme PP-green in your example above gets considerably shifted towards yellow. But then, the effect is typically less pronounced with real-world images, and finally the Hue can be readjusted in Photoshop.

So aside from avoiding Hue shifts, what precisely should RelCol with a Lut-based-sRGB do better ?

--
Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2169

This matrix clipping is however a quite efficient way to move out-of-gamut colors to the sRGB boundaries. The only downside I'm aware - strictly referring to the clipping mechanism, and not to the nature of RelCol to a smaller matrix space - are Hue shifts. The extreme PP-green in your example above gets considerably shifted towards yellow. But then, the effect is typically less pronounced with real-world images, and finally the Hue can be readjusted in Photoshop.

So aside from avoiding Hue shifts, what precisely should RelCol with a Lut-based-sRGB do better ?

--

As a start, a RC 3DLUT based s-RGB profile should map to the closest colors, using dE2000, to the sRGB gamut. For colors that are in sRGB they should just map precisely.

Clipping occurs both at zero and above 255. Both of these change Luminance. Any color clipped at 0 increases luminance, any color clipped to 255 decreases luminance. Saturation in addition to hue is also modified. Saturation reduction, of course, is a given.
Logged

Peter_DL

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 543

As a start, a RC 3DLUT based s-RGB profile should map to the closest colors, using dE2000, to the sRGB gamut.
Ok,
- attached below is an schematic drawing found in the world wide web,
however, unfortunately no real-world examples vs. matrix math clipping.


Quote
For colors that are in sRGB they should just map precisely.

That's always the nature of RelCol, independent from the clipping algorithm.


Quote
Clipping occurs both at zero and above 255. Both of these change Luminance. Any color clipped at 0 increases luminance, any color clipped to 255 decreases luminance. Saturation in addition to hue is also modified. Saturation reduction, of course, is a given.

Luminance changes occur with dE-clipping as well.
For example, the supersaturated PP-green with your initial example gets quite dark upon straight RelCol to your printer profile (L* 88 to 60). This is what I see with real-world out-of-gamut colors and other printer profiles as well. For example, with the profiles for a Fuji Frontier printer in so-called sRGB-mode (which are gamut-wise somewhat close to sRGB). RelCol from ProPhotoRGB darkens bright-out-of-gamut colors.

Not sure, if I would want to have this balance of -luminance/-saturation as the default for a ProPhotoRGB to sRGB conversion, if it is per see better than the matrix math clipping (?).

--
Logged

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2169

Ok,
- attached below is an schematic drawing found in the world wide web,
however, unfortunately no real-world examples vs. matrix math clipping.
Thanks for the link. Interesting variations. I wonder what approach the printer profile makers take. Of course this isn't documented but I suppose I could examine the profile to see what it is.
Quote
That's always the nature of RelCol, independent from the clipping algorithm.
Of course and ICC has made that clear in the V4 spec. There are, unfortunately, some profiles out there that do not follow that though PM5 and I1Profiler does. It's essential that be the case for the technique proposed to work.
Quote
Luminance changes occur with dE-clipping as well.
For example, the supersaturated PP-green with your initial example gets quite dark upon straight RelCol to your printer profile (L* 88 to 60). This is what I see with real-world out-of-gamut colors and other printer profiles as well. For example, with the profiles for a Fuji Frontier printer in so-called sRGB-mode (which are gamut-wise somewhat close to sRGB). RelCol from ProPhotoRGB darkens bright-out-of-gamut colors.

Not sure, if I would want to have this balance of -luminance/-saturation as the default for a ProPhotoRGB to sRGB conversion, if it is per see better than the matrix math clipping (?).

Right. The goal here was to most closely create a rendering in sRGB that would render to a printer how ProPhoto would render without clipping to sRGB first which produces a less faithful rendering due to RGB matrix math clipping. There certainly could be other goals.
« Last Edit: December 06, 2015, 01:39:03 pm by Doug Gray »
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 19773
  • Andrew Rodney
    • http://www.digitaldog.net/

Of course and ICC has made that clear in the V4 spec. There are, unfortunately, some profiles out there that do not follow that though PM5 and I1Profiler does.
Depends on what part of the spec you're viewing and think is important. Neither product, nor any I know of, produce V4 profiles that support the PRMG!
Logged
Author “Color Management for Photographers" & "Photoshop CC Color Management" on pluralsight.com

Doug Gray

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2169

Depends on what part of the spec you're viewing and think is important. Neither product, nor any I know of, produce V4 profiles that support the PRMG!

PRMG relates to Perceptual rendering and has no effect on Relative which is the part we have been discussing. While a person can choose either when rendering initially from ProPhoto, the mechanism to optimize sRGB rendering per the discussion only involves Relative colorimetry. Perceptual rendering continues to be ill defined or rather, it's still undefined not withstanding attempts to define a PRMG.
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 19773
  • Andrew Rodney
    • http://www.digitaldog.net/

PRMG relates to Perceptual rendering and has no effect on Relative which is the part we have been discussing. .
Correct therefore, what is in the V4 profile which is really a V2 in sheep's clothing, that you find at all useful?
Quote
While a person can choose either when rendering initially from ProPhoto, the mechanism to optimize sRGB rendering per the discussion only involves Relative colorimetry. Perceptual rendering continues to be ill defined or rather, it's still undefined not withstanding attempts to define a PRMG.
I don't see how the statement has any basis in fact considering both a Perceptual rendering is up to the manufacturer of the profile and it doesn't support the PRMG! It's possible such profile would 'solve' whatever issue you're chasing here.  ;)
Logged
Author “Color Management for Photographers" & "Photoshop CC Color Management" on pluralsight.com

Peter_DL

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 543

Right. The goal here was to most closely create a rendering in sRGB that would render to a printer how ProPhoto would render without clipping to sRGB first which produces a less faithful rendering due to RGB matrix math clipping.

Yes, I see the point of your suggested approach, and no doubt it can be useful right in the context as described in post #49 by FranciscoDisilvestro.

But then it elevates the conversion from ProPhotoRGB to the printer profile - and its presumably more advanced gamut mapping / clipping algorithm - to a kind of general reference. Below is an example where I think it doesn't work out.

… since we were also talking about Fuji Frontier Printer along this thread:

--
Image #01:  was kept in ProPhotoRGB with out-of-sRGB marks, just to illustrate that there is a bunch out-of-sRGB colors/pixels to deal with.

Image #02:  was obtained by straight conversion from ProPhotoRGB to sRGB. As expected, and visible on my screen, the Hue gets slightly shifted towards yellow/orange, the red channel is clipped and fine details are getting somewhat blurred. That's not ideal, but we will see this is not the worst case.

Image #03:  was obtained by ReCol conversion from ProPhotoRGB to one of the Frontier Printer media profiles which Fuji Europe offers here for the Frontier Printer in so-called sRGB-mode.  Next, the image was converted RelCol to sRGB to ensure the comparability with the previous image #02.  This second conversion does not do a lot. The deterioration of the image happens with the first conversion.

Conclusion:  whatever RelCol-gamut-clipping-algorithm this printer profile uses, it is apparently worse here than the simple matrix math clipping. Image #03 is quite dark and the fine details got largely blurred. Further, I also tried one of the Fuji Frontier profiles from Dry Creek Photo, and the results are not really better.

Image #04 provides a cross check. The sRGB image #02 is converted RelCol to the Frontier Printer profile. Again the results are better than bumping into the printer profile directly with the ProPhotoRGB colors.

Image #05 shows the "semi-color-management approach" which Fuji once suggested in a corresponding paper (which is unfortunately not available on their site anymore).  The image in sRGB, #02, is soft-proofed to the printer profile with Preserve RGB Numbers enabled.  It was suggested to edit the sRGB image under this soft-proof before sending it to the lab.  This approach may sound strange, but it is not wrong, under the premise a) that the printer's gamut is somewhat close to sRGB, and b) that the printer/lab do not run any ICC-type color space conversion before feeding the RGB data into the printer.
 
Logged
Pages: 1 2 [3] 4 5   Go Up