Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: Doug Gray on November 30, 2015, 06:38:13 pm
-
Often there is discussion of gamut clipping when printing images in sRGB or Adobe RGB from ProPhoto RGB and Lab. There are occasionally very significant shifts in color and luminosity associated with these processes and, in general, differences are chalked up only to limitations of the working space gamut being unable to exploit the entire printer gamut. While this is true, there are other differences as well.
The other factor discussed is just how often sRGB or aRGB gamuts are exceeded by non-synthetic images. But the a more immediate issue is whether the image gamut in Lab or ProPhoto RGB, as mapped into the printer, exceeds sRGB or Adobe RGB. It can be interesting to print an image with the full gamut a printer can deliver then print the same image clipped to, say, sRGB and compare them side by side. The obvious and simple approach is to convert the ProPhoto image to sRGB then print and compare this to one printed directly from the ProPhoto space. The differences in the two prints would be presumed to reflect limitations in the sRGB gamut. It makes the differences look larger than they are. This simple approach is flawed because converting to sRGB from a larger RGB space prior to printing clips all colors, whether printable or not, that are outside the smaller space. Clipping can change the luminance and hue, not just the saturation. Colors clipped to sRGB but that are outside of the printer's gamut (a large number of sRGB colors are outside print gamuts) undergo two conversions prior to printing. First to the smaller RGB space then to the printer's gamut. Traditionally, RGB spaces are converted to other RGB spaces by matrix math with the result being clipped at 0 and 255 forcing the image to the target gamut. OTOH, printer profiles are LUT based and color engines convert RGB to Lab which then uses the LUTs to estimate the printer's RGB levels. At least for an RGB input based printer. There is quite a bit of variation in how profile software vendors set the LUT values when outside the printer's gamut and this creates many of the differences between prints using these two processes beyond those caused by the printer's limited gamut.
So here's a process that will allow testing of prints where the only gamut clipping is that of the ProPhoto RGB to a smaller space. It presumes one has an accurate printer profile, typically a custom profile.
Assuming the test image is in 16 bit ProPhoto.
1. Convert the image to the printer's profile using Perceptual or Relative Colorimetry with or without BP correction using the settings normally used to print.
2. Then convert that image to ProPhoto RGB using Relative without BP correction. (this is critical, AtoB BP correction will not replicate colors correctly)
3. Print the ProPhoto RGB image using Relative Colorimetry w/o BP correction.
4. Convert this image to sRGB (or Adobe RGB) and print again using Relative Colorimetry w/o BP correction.
Step 2 assures that all the colors now in ProPhoto RGB are within the printer's gamut. The only differences between the two prints are now due to conversion of these colors and not from vagaries of a profile s/w coder's notions.
One of the interesting changes is the much smaller shifts in Andrew's "Printer Gamut Test File's" saturated spheres. However, since much of that image is out of gamut for both aRGB and sRGB it makes for an interesting comparison between these three prints from a single image that has been limited to a printer's gamut first. The shift from aRGB to sRGB is very noticeable, from ProPhoto RGB to aRGB, not nearly as much.
-
The other factor discussed is just how often sRGB or aRGB gamuts are exceeded by non-synthetic images.
I haven't had much difficulty finding such real world images I've captured. Certainly lots do not fall into this camp.
The obvious and simple approach is to convert the ProPhoto image to sRGB then print and compare this to one printed directly from the ProPhoto space. The differences in the two prints would be presumed to reflect limitations in the sRGB gamut. It makes the differences look larger than they are. This simple approach is flawed because converting to sRGB from a larger RGB space prior to printing clips all colors, whether printable or not, that are outside the smaller space.
If the workflow is to move from raw data to some RGB working space, how do we avoid this? We have to select some RGB working space for encoding. We may have no idea when, where or how the image might be printed or the printers gamut.
Clipping can change the luminance and hue, not just the saturation. Colors clipped to sRGB but that are outside of the printer's gamut (a large number of sRGB colors are outside print gamuts) undergo two conversions prior to printing. First to the smaller RGB space then to the printer's gamut. Traditionally, RGB spaces are converted to other RGB spaces by matrix math with the result being clipped at 0 and 255 forcing the image to the target gamut. OTOH, printer profiles are LUT based and color engines convert RGB to Lab which then uses the LUTs to estimate the printer's RGB levels. At least for an RGB input based printer. There is quite a bit of variation in how profile software vendors set the LUT values when outside the printer's gamut and this creates many of the differences between prints using these two processes beyond those caused by the printer's limited gamut.
Agreed, all limitations that we often have no control over.
Assuming the test image is in 16 bit ProPhoto.
Again, if that's the case, that's the case. The question is, what about those who state: always encode in sRGB? Or even Adobe RGB (1998)?
-
I haven't had much difficulty finding such real world images I've captured. Certainly lots do not fall into this camp.
I suspect it's more common to see images from commercial packaging, flowers, and such well outside sRGB but some others can surprise and be outside sRGB as well. Somewhat fewer are also outside of Adobe RGB. What some don't realize is that the modifications made to colors as part of rendering from scene reference to output reference almost always involve increasing saturation. It's simply a byproduct of increasing contrast and is what people expect to see in pleasing photos.
If the workflow is to move from raw data to some RGB working space, how do we avoid this? We have to select some RGB working space for encoding. We may have no idea when, where or how the image might be printed or the printers gamut. Agreed, all limitations that we often have no control over.
Again, if that's the case, that's the case. The question is, what about those who state: always encode in sRGB? Or even Adobe RGB (1998)?
I don't know why people say that. Work in whatever space you understand and have the tools to utilize. At times, for customers that require sRGB workproduct then it may make sense to use that start to finish. Otherwise, it's a harmful simplification.
The last part of my post deals with the very large difference when using ProPhoto to print or converting the same image to sRGB, or aRGB then printing. Take your Gamut Test File, The differences are quite noticeable and most of them are due to the conversions between ProPhoto and either aRGB or sRGB and not from a fundamental printer gamut limit.
Using Glossy on a 9500 II, I printed the Gamut test directly from the ProPhoto space using RC w/o BP correction. I then converted to sRGB and printed the same. These have fairly large differences in appearance as one would expect.
But I also tried an alternative path. I converted the original to the printer profile space selecting BC and RC, Then converted back to ProPhoto using RC w/o BC. This represented the actual ProPhoto RGB colors that are in the printer's gamut and will create the same image when printed directly using RC w/o BP. It's essentially a symmetrical roundtrip. When this image was converted to sRGB, making the entire image fall within sRGB and the printer's gamut, and then printed using RC w/o BP the results were much closer to the original print that came directly from ProPhoto RGB space.
When the same process was repeated with aRGB instead of sRGB, the two prints appear the same side by side where as converting the original to aRGB then printing still makes a print that differs noticeably.
Here are some Lab measurements at the bottom of the vertical green stripe: in L*, a*, and b*.
Printed directly from ProPhoto (ref): 60.11, -66.95, 56.07
Printed after converting to sRGB: 72.48, -53.37, 66.8 (DeltaE from ref:21.3
Printed after converting to sRGB using roundtrip from printer space: 61.27, -59.02, 57.49 (DeltaE from ref: 8.1)
Printed after converting to aRGB using roundtrip from printer space: 59.88, -68.22, 55.49 (DeltaE from ref: 1.41)
So perhaps, if one has to absolutely deliver an image in either sRGB or aRGB, using this protocol would produce images in those colorspaces that more closely match the direct print. It's much less color distortive than transitioning by first converting to either sRGB or aRGB when significantly outside of these gamuts.
-
I suspect it's more common to see images from commercial packaging, flowers, and such well outside sRGB but some others can surprise and be outside sRGB as well.
Yes, agreed, I've pointed this out by mapping images from raw data in ColorThink:
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
So we have scene gamut and then capture that only falls within sRGB, so what? We have scene gamut and captured data that exceeds Adobe RGB (1998) gamut, and requires ProPhoto RGB. Are you proposing we examine every capture to see where it falls, despite the gamut of the raw processor (in my case, ACR) using a ProPhoto RGB gamut processing color space? For what gain?
Somewhat fewer are also outside of Adobe RGB.
But they are outside that gamut. What are you proposing other than pick the next larger encoding working space?
What some don't realize is that the modifications made to colors as part of rendering from scene reference to output reference almost always involve increasing saturation. It's simply a byproduct of increasing contrast and is what people expect to see in pleasing photos.
Again, what are you proposing other than using that larger gamut encoding working space?
Work in whatever space you understand and have the tools to utilize.
What's to understand other than there are three main RGB working spaces of differing color gamut to select? You can select the largest gamut option and produce an iteration with the smaller gamut one for posting on the web. Best of both worlds. Considering we don't know the final output, what benefit would be picking the smallest or even the middle sized gamut when we both agree, some images exceed both?
At times, for customers that require sRGB workproduct then it may make sense to use that start to finish.
IOW, output only to the internet and mobile devices. That's the only output where sRGB makes sense. Oh, and those silly labs that demand sRGB for their own benefit, not yours.
The last part of my post deals with the very large difference when using ProPhoto to print or converting the same image to sRGB, or aRGB then printing. Take your Gamut Test File, The differences are quite noticeable and most of them are due to the conversions between ProPhoto and either aRGB or sRGB and not from a fundamental printer gamut limit.
Yes, they are noticeable and for a good reason. One produces a superior print compared to the others on this end. Why would I use anything but the working space that produces the best appearing print?
But I also tried an alternative path.
I don't understand what or why anyone would do this. Let's stick to workflows. We have a pile of raw images. Some will fit within sRGB, some must be encoded in ProPhoto RGB to contain color that fall outside sRGB and Adobe RGB gamut. The only way to know this would be to encode them and examine the gamut of the image, something I did in my video. It's super time consuming! So do we pick the smaller gamut working space and clip colors we capture and can output or pick the larger one and move on? I can produce a ProPhoto RGB, high resolution Master, spend X number of minutes or hours editing it and end up with a low resolution sRGB copy for the web. I can print the larger gamut image using all the color I can capture and utilize for that one printer. Again, I'm trying to understand what you're proposing I (we) do differently when some images will be outside Adobe RGB color gamut, we have a printer who's color gamut exceeds Adobe RGB (1998) and we want to make a print of that data?
-
On a side note, the colours on Kodak / Fuji films and papers fall out of Adobe RGB gamut. Even Fogra Glossy allows more than Adobe RGB encompasses. I wonder how we and our customers live(d) with that; and how that "give us the film look" plea coexists with sRGB workflow demands.
-
I don't understand what or why anyone would do this. Let's stick to workflows. We have a pile of raw images. Some will fit within sRGB, some must be encoded in ProPhoto RGB to contain color that fall outside sRGB and Adobe RGB gamut. The only way to know this would be to encode them and examine the gamut of the image, something I did in my video. It's super time consuming! So do we pick the smaller gamut working space and clip colors we capture and can output or pick the larger one and move on? I can produce a ProPhoto RGB, high resolution Master, spend X number of minutes or hours editing it and end up with a low resolution sRGB copy for the web. I can print the larger gamut image using all the color I can capture and utilize for that one printer. Again, I'm trying to understand what you're proposing I (we) do differently when some images will be outside Adobe RGB color gamut, we have a printer who's color gamut exceeds Adobe RGB (1998) and we want to make a print of that data?
There is no reason not to use ProPhoto with a good color managed process for printing. Your videos and instructional materials are excellent on this.
So why would I suggest an additional workflow, that departs from usual practice, when other customers require sRGB that matches your prints as visually close as possible?
Well, there is one fairly good reason. The largest, out of gamut, color distortion going from ProPhoto to sRGB is in the standard matrix conversion used in "export for" or "convert to" sRGB. This is particularly obvious with your Gamut Test file. The alternate workflow, which is completely automatic, provides a very good representation of the actual printed image in the smaller (sRGB or aRGB) gamut. For instance, if you are selling prints that use the full gamut a printer is capable of, and your workspace is ProPhoto RGB, then you want the sRGB images, which you may post on the web or email to potential customers, to be as close as possible to what the full gamut print looks like. Just converting from ProPhoto RGB to sRGB will wash out a lot of lot of out of gamut colors that could be better represented while still remaining within sRGB as I demonstrated above using the green vertical bars.
-
There is no reason not to use ProPhoto with a good color managed process for printing. Your videos and instructional materials are excellent on this.
Just the opposite Doug. The use of ProPhoto RGB shows improvements in the actual printed output (albeit to the printer and paper/profile combo used) compared to sRGB and Adobe RGB (1998).
The proof is in the print!
So why would I suggest an additional workflow, that departs from usual practice, when other customers require sRGB that matches your prints as visually close as possible?
sRGB is optional for one output use and suboptimal for all others. If you need sRGB, convert to sRGB from a larger color space which can be used for output to any number of printed needs.
I've got plenty of prints from plenty of images as do others that illustrate that ProPhoto RGB is providing better appearing prints. Again, the proof is in the print.
-
Just the opposite Doug. The use of ProPhoto RGB shows improvements in the actual printed output (albeit to the printer and paper/profile combo used) compared to sRGB and Adobe RGB (1998).
Read it again. The double negative threw you off.
The proof is in the print! sRGB is optional for one output use and suboptimal for all others. If you need sRGB, convert to sRGB from a larger color space which can be used for output to any number of printed needs.
I've got plenty of prints from plenty of images as do others that illustrate that ProPhoto RGB is providing better appearing prints. Again, the proof is in the print.
Apparently my point isn't getting across. If you have a ProPhoto RGB image with out of sRGB gamut parts, converting from ProPhoto to sRGB produces a great deal of unnecessary distortion that can't easily be tweaked to produce an sRGB image that closely resembles the printed image. Converting to the printer's profile using the same target profile settings the print from ProPhoto uses then converting this using RC to sRGB produces an image that much more closely resembles the original, full gamut, pleasing print.
If you then print that sRGB image it will be much closer to the original, large gamut print. As you say, the proof is in the print.
-
Read it again. The double negative threw you off.
The we are in agreement about using ProPhoto RGB for output to print.
Apparently my point isn't getting across. If you have a ProPhoto RGB image with out of sRGB gamut parts, converting from ProPhoto to sRGB produces a great deal of unnecessary distortion that can't easily be tweaked to produce an sRGB image that closely resembles the printed image. Converting to the printer's profile using the same target profile settings the print from ProPhoto uses then converting this using RC to sRGB produces an image that much more closely resembles the original, full gamut, pleasing print.
If you then print that sRGB image it will be much closer to the original, large gamut print. As you say, the proof is in the print.
Closer to what original? The original in my workflow is raw to ProPhoto RGB. Are you saying by converting that to sRGB, it's closer to sRGB? No argument. Why would I do or want that?
-
............Converting to the printer's profile using the same target profile settings the print from ProPhoto uses then converting this using RC to sRGB produces an image that much more closely resembles the original, full gamut, pleasing print.
If you then print that sRGB image it will be much closer to the original, large gamut print. As you say, the proof is in the print.
I've been following this discussion with some interest, and must say I believe I needn't worry about either workflow option if I always start from from my raw file, use Lightroom as my primary photo editor and repurpose the raw files as needed, be it for devices, or for any particular printer/paper combination. The algorithms within LR for doing these on-the-fly conversions seem to be producing coherent results, taking into account that for printing purposes one should be making final luminance and colour adjustments under soft-proof bespoke to the printer/paper combination in play. So, that's the practical aspect of interest to me. Also of interest would be to see an explanation of the principles underlying the added workflow conversion step Doug is recommending - conversion to the printer profile - before conversion to a smaller colour space. Of course each printer/paper combination has its own gamut space and all of them are smaller than ProPhoto. So the process Doug recommends essentially compresses the colour space for the image in two steps rather than one: from Pro-Photo to the Printer Profile space and from that space to sRGB. Why in principle is this better than a direct conversion from ProPhoto to sRGB? Or is it a result of empirical observation and the reason is as yet unclear?
(Typo corrected)
-
I've been following this discussion with some interest, and must say I believe I needn't worry about either workflow option if I always start from from my raw file, use Lightroom as my primary photo editor and repurpose the raw files as needed, be it for devices, or for any particular printer/paper combination.
We are in violent agreement. And if you're not using a LR workflow 100%, you do want to edit in Photoshop, I suspect you'd encode 16-bit ProPhoto RGB.
-
We are in violent agreement. And if you're not using a LR workflow 100%, you do want to edit in Photoshop, I suspect you'd encode 16-bit ProPhoto RGB.
Yes, you suspect correctly; but I would still like to hear from Doug about the basic principles underlying his deviation into the printer profile colour gamut on the way. Not that I am denying the usefulness of visual evidence, but I'd like to know whether there is a scientific (i.e. objective, verifiable, repeatable) basis for it.
-
Closer to what original?
"the original, large gamut print," That original. The print you made from ProPhoto RGB.
The original in my workflow is raw to ProPhoto RGB. Are you saying by converting that to sRGB, it's closer to sRGB? No argument. Why would I do or want that?
No, I'm saying that to obtain a closer rendering in sRGB of your actual print from ProPhoto RGB that neither converting directly from RAW to sRGB or RAW to ProPhoto RGB then to sRGB should be done. To get the best rendering in sRGB of a large gamut image print from ProPhoto do not convert to sRGB from ProPhoto. Convert to the printer space first using the desired printer settings then convert that to sRGB.
The differences on images with a lot of out of gamut colors are not subtle.
Andrew, try this test yourself and compare the three prints:
Print your Gamut Test image using whatever settings you like, perhaps Perceptual.
Then convert the test image to sRGB and print it using the same settings.
Then, take the ProPhoto test image, convert it to printer RGB space using the same rendering. Then convert it to sRGB using RC, now print it using RC.
This last print will be a much closer match that the first approach which is what people typically do.
-
Andrew, try this test yourself and compare the three prints:
Print your Gamut Test image using whatever settings you like, perhaps Perceptual.
Then convert the test image to sRGB and print it using the same settings.
I've done that already. ;D
Then, take the ProPhoto test image, convert it to printer RGB space using the same rendering. Then convert it to sRGB using RC, now print it using RC.
This last print will be a much closer match that the first approach which is what people typically do.
I can't print an sRGB image, it has to be in output color space so I'm again confused. Further, you state: This last print will be a much closer match that the first approach which is what people typically do.
I don't understand the bit about "what people typically do" either. Like Mark, I'm trying to understand the workflow and ramifications you're trying to apply but I'm still confused.
-
I've done that already. ;D I can't print an sRGB image, it has to be in output color space so I'm again confused. Further, you state: This last print will be a much closer match that the first approach which is what people typically do.
Um, really? I can't imagine what those print labs that insist on sRGB files do to actually get prints. Voodoo maybe?
sRGB, like ProPhoto RGB IS an output colorspace. Printing from sRGB is exactly the same process (matrix color adaption for differing white points - sRGB v Lab PCS and ProPhoto which already use D50 - and conversion to coefs. of the RGB primaries as printing from ProPhoto RGB.
I don't understand the bit about "what people typically do" either. Like Mark, I'm trying to understand the workflow and ramifications you're trying to apply but I'm still confused.
What people that work in larger gamut spaces "typically" do is convert from the larger space to the target space inside either LR or PS. Then they put it on the web. This works perfectly great when the image gamut is reasonably close to sRGB. The further out the image gamut, the more poorly it works in the sense that it diverges from the image that gets printed. That may, or may not look better but it is different and more different than it needs to be.
My suggested workflow addressed the issues that come up with an image far enough out of sRGB gamut that the crude gamut reduction by matrix clipping produces bad results.
-
Um, really? I can't imagine what those print labs that insist on sRGB files do to actually get prints. Voodoo maybe?
No Voodoo, sRGB gets converted to the output color space for the printer. Just as I can't send sRGB either, hence my question to you about printing sRGB. There's no such thing as an sRGB printer. However, a lab can demand an sRGB file to convert to their output color space. Which is pretty awful when the data greatly exceeds sRGB as does the printer.
sRGB, like ProPhoto RGB IS an output colorspace.
No it's not. It's an RGB working space, a special group of synthetically defined color spaces based on three simple attributes: white point, chromaticity values and gamma (TRC). How can ProPhoto RGB be an output color space when it defines "colors" (device values) that are both invisible to us and are impossible to output to any device? All about RGB working space: http://www.adobe.com/digitalimag/pdfs/phscs2ip_colspace.pdf
Printing from sRGB is exactly the same process (matrix color adaption for differing white points - sRGB v Lab PCS and ProPhoto which already use D50 - and conversion to coefs. of the RGB primaries as printing from ProPhoto RGB.
I don't again understand what you're saying. You can't print sRGB, it has to be converted to some output color space which is often (well always in every output profile I've examined) larger in some areas of color space than sRGB. Red is sRGB, colored is the gamut of the output device, those who's color gamuts one usually finds at lab's demanding all data be sent to them in sRGB:
(http://digitaldog.net/files/sRGB_vs_SilverPrinters.jpg)
What people that work in larger gamut spaces "typically" do is convert from the larger space to the target space inside either LR or PS
There's no such provision in LR it's processing pipeline is always using ProPhoto RGB primaries and thus it's gamut. One can export to a smaller gamut color space in that product and that's useful when you need sRGB for the web or mobile devices. You can't print sRGB though LR, it's not possible. As Mark pointed out, it's always sending ProPhoto RGB gamut through it's print module. If you happen to have clipped all that nice wider gamut data and have sRGB rendered data, the damage is done. None the less, IF edits are applied to the rendered image, ProPhoto RGB is used on that clipped data. And raw data isn't clipped to sRGB thankfully.
This works perfectly great when the image gamut is reasonably close to sRGB. The further out the image gamut, the more poorly it works in the sense that it diverges from the image that gets printed. That may, or may not look better but it is different and more different than it needs to be.
The web and thus sRGB are the lowest common denominator and it's kind of foolish to throw the baby out with the bath water when you intend to print that data too.
-
> The web and thus sRGB are the lowest common denominator
That's scratching the surface :)
The history of discarding colour space in browsers is no small reason why sRGB proliferated.
-
The history of discarding colour space in browsers is no small reason why sRGB proliferated.
I have to wonder if consumers, who appear to prefer 'saturated' colors will move to wider gamut displays as they become less expensive. If so, it will be interesting to see where sRGB goes in the future.
-
I've been following this discussion with some interest, and must say I believe I needn't worry about either workflow option if I always start from from my raw file, use Lightroom as my primary photo editor and repurpose the raw files as needed, be it for devices, or for any particular printer/paper combination. The algorithms within LR for doing these on-the-fly conversions seem to be producing coherent results, taking into account that for printing purposes one should be making final luminance and colour adjustments under soft-proof bespoke to the printer/paper combination in play. So, that's the practical aspect of interest to me. Also of interest would be to see an explanation of the principles underlying the added workflow conversion step Doug is recommending - conversion to the printer profile - before conversion to a smaller colour space. Of course each printer/paper combination has its own gamut space and all of them are smaller than ProPhoto. So the process Doug recommends essentially compresses the colour space for the image in two steps rather than one: from Pro-Photo to the Printer Profile space and from that space to sRGB. Why in principle is this better than a direct conversion from ProPhoto to sRGB? Or is it a result of empirical observation and the reason is as yet unclear?
(Typo corrected)
Here's the actual conversions done that demonstrates why the two step process is better when converting an image from ProPhoto to sRGB when trying to match a print made directly from Andrew's Printer Gamt Test File.
Focusing in on the Green, vertical gradient column locate a point equidistant from the bottom and left/right sides (a good location to take a verifying reading with a spectro) the ProPhoto RGB values are (7,255,7). This is, of course, an unrealizable color that can be thought of as an intense, supersaturated green. This is not even close to being reproducible in sRGB, aRGB, a print gamut, or anything in our reality.
Let's follow the two paths of color conversion.
The first is straightforward. Convert the color to sRGB then print it using either Perceptual or Relative colorimetry. Let's use Relative for simplicity noting that we could instead use Perceptual. The results in sRGB are (0,255,0) over the entire bottom third of the vertical green column. So the conversion results in clipping. 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. But does that get us close to the printer's gamut? No, it does not. Virtually all colors near sRGB's three primaries cannot be printed. Printer gamuts exceed sRGB and aRGB only along the gamut triangle's sides.
So what happens when we print sRGB(0,255,0) and compare that to printing the ppRGB(7,255,7). First the sRGB(0,255,0) is converted to PCS (Lab) then the Lab values, adapted for BPC, use the 3D LUTs to interpolate a set of RGB values to send to the printer. This process is a function of the printer profile so YMWV. Often, printer profiles simply map out of gamut colors to the closest color on the gamut boundary.
Using my printer and profiles (a custom profile with Epson PPG printed on a Canon 9500 II) RC w BPC resulted in a Lab value of 72,-53, 67 as read by a spectro.
Now let's examine what happens when the image is printed from ProPhoto directly to the printer using RC w BPC. First the ppRGB(7,255,7) is converted to PCS (Lab clipped [-128:127]) then the BPC adapted 3D lookup is output to the printer and the image is printed. On my printer this produces a Lab value of (60, -67, 56) which is very far off (Deltas E:21) from the yellowish green printed by converting first to sRGB.
By going through the convert to printer then convert back to sRGB allows one to more closely match the printer's actual image as printed from RAW or ProPhoto RGB to an image intended for the web.
The problem's encountered in this is loss of accuracy due to inaccuracies in the printer's BtoA->AtoB. Each transition can be expected to introduce error ranging from tenths of a DeltaE to several DeltaEs at the gamut boundary. So, unless an image is significantly out of aRGB or sRGB, I don't recommend this. However, it's great for images with a lot of synthetic colors such as rainbow or the grainger color gradients. It's not accurate per se since the colors are out of gamut, but it does make for a much closer match between a print image and an image in sRGB intended for the web.
-
By going through the convert to printer then convert back to sRGB allows one to more closely match the printer's actual image as printed from RAW or ProPhoto RGB to an image intended for the web.
So the goal is to make the print as desaturated as an sRGB browser viewing that image on the web? Again, I don't see why one would do that.
Your technique isn't new and is useful for print in one case I can see; proofing (make my wider gamut Epson better match a contract proof).
-
No it's not. It's an RGB working space, a special group of synthetically defined color spaces based on three simple attributes: white point, chromaticity values and gamma (TRC). How can ProPhoto RGB be an output color space when it defines "colors" (device values) that are both invisible to us and are impossible to output to any device? All about RGB working space: http://www.adobe.com/digitalimag/pdfs/phscs2ip_colspace.pdf I don't again understand what you're saying.
Terminology varies. I do like your "working space" terminology. However, matrix based colorspaces are also referred to as output referred colorspaces. Sorry for leaving off the "referred."
See Jack Holm's (HP Principal Color Scientist) description of them:
http://www.color.org/documents/AdvColMgmt_for_DP.pdf
There's no such provision in LR it's processing pipeline is always using ProPhoto RGB primaries and thus it's gamut. One can export to a smaller gamut color space in that product and that's useful when you need sRGB for the web or mobile devices. You can't print sRGB though LR, it's not possible. As Mark pointed out, it's always sending ProPhoto RGB gamut through it's print module. If you happen to have clipped all that nice wider gamut data and have sRGB rendered data, the damage is done. None the less, IF edits are applied to the rendered image, ProPhoto RGB is used on that clipped data. And raw data isn't clipped to sRGB thankfully.
This is exactly my point. Converting highly saturated images that exceed sRGB gamuts to sRGB for the Web can sometimes produce a much different image than the image that is printed using a large gamut space. Your Wide Gamut Test image is a case in point where when converted directly to sRGB messes up the image compared to what is printed. Sure the image is well outside sRGB and aRGB but that is no reason not to create an image when needed for the web that is highly distorted from what is printed.
The web and thus sRGB are the lowest common denominator and it's kind of foolish to throw the baby out with the bath water when you intend to print that data too.
Couldn't agree more. The only point I'm making is that if you need to create an image for the web that is as close as possible to what you can print converting directly from a wide gamut space to sRGB is flawed when the starting image has many large areas of color far from the sRGB space.
-
So the goal is to make the print as desaturated as an sRGB browser viewing that image on the web? Again, I don't see why one would do that.
Your technique isn't new and is useful for print in one case I can see; proofing (make my wider gamut Epson better match a contract proof).
The goal, quite simply, is when one has to have an image for the web and the source image is in a high gamut space, then this two step approach more accurately renders high saturation colors that are within sRGB. While sRGB is quite limited there is zero reason to distort colors more than is necessary and simply converting to sRGB, either in LR or PS from ProPhoto RGB is very suboptimal when the purpose is to produce an sRGB image that is as close as possible to the print image that contains colors outside of sRGB.
-
I have to wonder if consumers, who appear to prefer 'saturated' colors will move to wider gamut displays as they become less expensive. If so, it will be interesting to see where sRGB goes in the future.
Good question. The progress to date has been slower than I anticipated.
My typical work is done in 16 bit ProPhoto. Most of my output can be converted directly to sRGB if needed for some reason. The only time I use this two step process is when I need to create a universal web image that comes as close as possible to an image with highly saturated colors. It's actually rare unless I am dealing with synthetic images such as trying to create a nice rainbow effect that looks reasonably close when printed and viewed in sRGB.
-
Over the last couple days I've been archiving a bunch of old photo albums, some with pictures that are almost 100 years old. I set up the camera to shoot raw, with appropriate lighting at 45 degrees to each side. Shot a Colorchecker and created a profile for that illuminant that renders scene referenced images. The initial purpose being to capture accurately the album pages. From this I can print an image that exactly matches those the album, one of the few times Scene referred images and Absolute colorimetry is useful. It turned out the images are all within sRGB gamut so no back and forth is needed or useful. I can also share them on the web with my friend's family members who wish to have a nearly exact image of the albums.
-
Terminology varies. I do like your "working space" terminology. However, matrix based colorspaces are also referred to as output referred colorspaces. Sorry for leaving off the "referred."
The Output or 'referred' term per se isn't necessarily. The point is, RGB working space's are not output color spaces nor based on any output device other than a theoretical emissive display in a very fixed condition and environment.
See Jack Holm's (HP Principal Color Scientist) description of them:
http://www.color.org/documents/AdvColMgmt_for_DP.pdf (http://www.color.org/documents/AdvColMgmt_for_DP.pdf)
Jack and I co-authored this for the ICC so I'm familiar with Jack and the terminology: http://www.color.org/ICC_white_paper_20_Digital_photography_color_management_basics.pdf (http://www.color.org/ICC_white_paper_20_Digital_photography_color_management_basics.pdf)
This is exactly my point. Converting highly saturated images that exceed sRGB gamuts to sRGB for the Web can sometimes produce a much different image than the image that is printed using a large gamut space.
I'm far less concerned about posting images on the web than printing them! And it's not difficult IF necessary to edit images from a wider gamut to sRGB for the web. But in the end, it's a huge crap shoot anyway! How many people viewing all that hard work are viewing on calibrated displays (calibrated how to what goal?) and using color managed web browser?
It's a bit like worrying if the meat in a MacDonalds hamburger contains GMO's when it is filled with salmonella. The web and sRGB are the lowest common denominator. I'm not going to hose my files for any or all output because I need a tiny, low resolution JPEG for posting on the internet.
Your Wide Gamut Test image is a case in point where when converted directly to sRGB messes up the image compared to what is printed. Sure the image is well outside sRGB and aRGB but that is no reason not to create an image when needed for the web that is highly distorted from what is printed.
I can do that too. I simply do not understand the workflow you propose. I have the raw image data that produced those images in the Gamut Test File. Encode in ProPhoto RGB or sRGB? I need to make a print and maybe upload to the web. One encoding gives the data a permanent sex change operation and produces an inferior print. WHY would I do that?
The only point I'm making is that if you need to create an image for the web that is as close as possible to what you can print converting directly from a wide gamut space to sRGB is flawed when the starting image has many large areas of color far from the sRGB space.
Every output device is different! Every display too. I don't see how or why I need to target a print, who's gamut is hugely larger than an sRGB display viewing a web image to match. And match on ONE display at that.
-
Here's the actual conversions done that demonstrates why the two step process is better when converting an image from ProPhoto to sRGB when trying to match a print made directly from Andrew's Printer Gamt Test File.
Focusing in on the Green, vertical gradient column locate a point equidistant from the bottom and left/right sides (a good location to take a verifying reading with a spectro) the ProPhoto RGB values are (7,255,7). This is, of course, an unrealizable color that can be thought of as an intense, supersaturated green. This is not even close to being reproducible in sRGB, aRGB, a print gamut, or anything in our reality.
Let's follow the two paths of color conversion.
The first is straightforward. Convert the color to sRGB then print it using either Perceptual or Relative colorimetry. Let's use Relative for simplicity noting that we could instead use Perceptual. The results in sRGB are (0,255,0) over the entire bottom third of the vertical green column. So the conversion results in clipping. 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. But does that get us close to the printer's gamut? No, it does not. Virtually all colors near sRGB's three primaries cannot be printed. Printer gamuts exceed sRGB and aRGB only along the gamut triangle's sides.
So what happens when we print sRGB(0,255,0) and compare that to printing the ppRGB(7,255,7). First the sRGB(0,255,0) is converted to PCS (Lab) then the Lab values, adapted for BPC, use the 3D LUTs to interpolate a set of RGB values to send to the printer. This process is a function of the printer profile so YMWV. Often, printer profiles simply map out of gamut colors to the closest color on the gamut boundary.
Using my printer and profiles (a custom profile with Epson PPG printed on a Canon 9500 II) RC w BPC resulted in a Lab value of 72,-53, 67 as read by a spectro.
Now let's examine what happens when the image is printed from ProPhoto directly to the printer using RC w BPC. First the ppRGB(7,255,7) is converted to PCS (Lab clipped [-128:127]) then the BPC adapted 3D lookup is output to the printer and the image is printed. On my printer this produces a Lab value of (60, -67, 56) which is very far off (Deltas E:21) from the yellowish green printed by converting first to sRGB.
By going through the convert to printer then convert back to sRGB allows one to more closely match the printer's actual image as printed from RAW or ProPhoto RGB to an image intended for the web.
The problem's encountered in this is loss of accuracy due to inaccuracies in the printer's BtoA->AtoB. Each transition can be expected to introduce error ranging from tenths of a DeltaE to several DeltaEs at the gamut boundary. So, unless an image is significantly out of aRGB or sRGB, I don't recommend this. However, it's great for images with a lot of synthetic colors such as rainbow or the grainger color gradients. It's not accurate per se since the colors are out of gamut, but it does make for a much closer match between a print image and an image in sRGB intended for the web.
Doug,
I'm having two problems: firstly, going back to post #2, there is no viewable image file by which to see what you are getting at. Secondly, I just loaded my widest gamut printer profile (Epson 4900 printing on Ilford Gold Fibre Silk, gamut volume of 977,000, let us call it "IGFS/4900" space) into a three-dimensional representation in CTP along with the OSX System profile for sRGB and examined them. What I see - very unambiguously, not even marginal, is that the two gamut shapes are very different, such that in some areas sRGB>IGFS/4900 and in others IGFS/4900>sRGB. (Please refer to the screen grab image, wherein green is the printer profile and red is sRGB.) Quite apart from the fact that the sRGB gamut volume is smaller at 832,478, in this comparison I suspect for purposes of your approach, the relative shapes are more determinative of outcomes than the relative volumes. Hence I would expect that if I implement your intermediate step of converting from ProPhoto to the IGFS/4900, and assuming the photo contains colours exceeding both the IGFS/4900 and sRGB gamuts, I shed all the data occupying the space from from ProPhoto to IGFS/4900, implying that because IGFS/4900 < sRGB space IN SOME PARTS OF THE GAMUT, I have shed data - through the end of the workflow - that would have been retained in a straight conversion from ProPhoto to sRGB that didn't first pass through the IGFS/4900 space. So I am still puzzled about the theoretical basis of the proposed alternative workflow.
-
First, let me repeat I am totally with Andrew about not using sRGB or any smaller working gamuts than can be printed. This was an experiment to see how close one can come to representing an image in sRGB which bears the closest resemblance to a full gamut print. For instance to supply catalog images.
If anyone's interested, I can supply the matlab source code that runs this.
The image is from Andrew Rodney's printer gamut/profile test program available on his site. It consists of many highly colorful components some of which are in the full RGB space of ProPhoto. He calls it the "Printer Gamut Test File." It's particularly useful to see how out of gamut colors get printed and allows you to examine how profiles handle these colors. Some canned profiles are seriously flawed.
Attached is three images and a black and white image of the relative DeltaE in each location in the image. For these, black means DeltaE=0, White corresponds to DeltaE of 48 which occurs in locations where the ProPhoto pixel colors are extremely far from what can be rendered.
The average DeltaE was 4.3 for the modified approach (convert to printer, then sRGB) and 7.1 for the traditional approach of (convert to sRGB) before printing.
-
First, let me repeat I am totally with Andrew about not using sRGB or any smaller working gamuts than can be printed. This was an experiment to see how close one can come to representing an image in sRGB which bears the closest resemblance to a full gamut print. For instance to supply catalog images.
If anyone's interested, I can supply the matlab source code that runs this.
The image is from Andrew Rodney's printer gamut/profile test program available on his site. It consists of many highly colorful components some of which are in the full RGB space of ProPhoto. He calls it the "Printer Gamut Test File." It's particularly useful to see how out of gamut colors get printed and allows you to examine how profiles handle these colors. Some canned profiles are seriously flawed.
Attached is three images and a black and white image of the relative DeltaE in each location in the image. For these, black means DeltaE=0, White corresponds to DeltaE of 48 which occurs in locations where the ProPhoto pixel colors are extremely far from what can be rendered.
The average DeltaE was 4.3 for the modified approach (convert to printer, then sRGB) and 7.1 for the traditional approach of (convert to sRGB) before printing.
A dE measurement, as no doubt you know, needs to measure one thing versus another. Grateful if you would clarify exactly what two items of source information you are measuring, which when subtracted from each other (and using which dE calculation formula?) produce the dE?
-
A dE measurement, as no doubt you know, needs to measure one thing versus another.
Further, one sample versus the other. For more than one, we need a report like those from ColorThink Pro seen below, that provide an average and the number to produce the average is necessary and useful. For example, is 323 samples enough?
This also tells us nothing about color in context.
--------------------------------------------------
dE Report
Number of Samples: 323
Delta-E Formula dE2000
Overall - (323 colors)
--------------------------------------------------
Average dE: 2.90
Max dE: 7.91
Min dE: 0.00
StdDev dE: 1.75
Best 90% - (290 colors)
--------------------------------------------------
Average dE: 2.53
Max dE: 5.26
Min dE: 0.00
StdDev dE: 1.43
Worst 10% - (33 colors)
--------------------------------------------------
Average dE: 6.14
Max dE: 7.91
Min dE: 5.31
StdDev dE: 0.65
--------------------------------------------------
Cross rendering from a larger gamut output to a smaller one isn't a new concept.
-
A dE measurement, as no doubt you know, needs to measure one thing versus another. Grateful if you would clarify exactly what two items of source information you are measuring, which when subtracted from each other (and using which dE calculation formula?) produce the dE?
Standard Euclidean distance, CIE 1976 Delta E.
The references are the two images to the right compared to the first one which is the full print gamut.
I'm going to also produce a dE2000 histogram which is more uniform and will be more useful than the 10% - 90% reports that ColorThink reports produce per Andrew's request. Should post that shortly.
-
As expected dE2000 numbers are much smaller for both conversions since more saturated colors tend to be harder to distinguish. More telling is both the smaller size of the histogram bins and smaller max dE2000. Roughly 50% of the pixels using the conventional conversion have a dE2000 above 1 while about 25% of the alternate conversion pixel dE2000's are above 1.
Fascinating stuff but not too surprising after I noticed that the standard matrix treatment going from large spaces to smaller ones is seriously flawed. People that make printer profiles can map out of gamut Lab colors to the nearest in gamut color thanks to the 3D LUTs.
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. It's might even provide better results and it would avoid the two step process of converting to the print profile then back to sRGB.
BTW, the "sample size" used is the entire image which contains 8,415,000 pixels.
Please note that the y-axis scale is different on the two histograms due to the higher bin count of dE2000's less than 1 which caused a rescale in Matlab.
-
As expected dE2000 numbers are much smaller for both conversions since more saturated colors tend to be harder to distinguish.
That's not why dE2000 number are lower. But that's besides the point.
BTW, the "sample size" used is the entire image which contains 8,415,000 pixels.
So the original image was resampled. The original image is 7500000 pixels. How did you resample?
You do know there is a V4 sRGB LUT based profile with a perceptual table and no, it's not going to solve every issue mapping a wide gamut original to sRGB. Considering that sRGB is ideal for one use, output to the web/mobil devices and that's a enormous crap shoot due to how those devices may or may not be calibrated or color managed, I'm still not sure what you're proposing that has a practical usage.
-
No Voodoo, sRGB gets converted to the output color space for the printer. Just as I can't send sRGB either, hence my question to you about printing sRGB. There's no such thing as an sRGB printer. However, a lab can demand an sRGB file to convert to their output color space. Which is pretty awful when the data greatly exceeds sRGB as does the printer.
The web and thus sRGB are the lowest common denominator and it's kind of foolish to throw the baby out with the bath water when you intend to print that data too.
I agree that when one is dealing with a wide gamut printer such as the current Epson Pro line of printers, one should use ProPhotoRGB as the working space and print using a profile for the printer/paper combination. However, when looking at the profile of the Fuji Frontier LP7700 printer at my local Costco, the printer gamut exceeds that of sRGB by only minor amounts in the yellows and teal greens as shown here. The profile was downloaded from the Drycreek.com web site, which supplies profiles for various labs.
(https://bjanes.smugmug.com/Photography/Costco-Frontier/i-D4z5G5n/0/O/sRGBvsFrontierCostcoGlsy.png)
Using a wire frame rather than solid color for sRGB better demonstrates where sRGB exceeds the gamut of the Frontier.
(https://bjanes.smugmug.com/Photography/Costco-Frontier/i-L3n77Ck/0/O/Costco_sRGB_Glossy.png)
This gamut for the printer is smaller than the one you provided for the Frontier, perhaps a different model or with different paper. Or perhaps from a less accurate profile.
(https://bjanes.smugmug.com/Photography/Costco-Frontier/i-8K4HVMD/0/O/sRGBvsFrontierDD.png)
One should applaud Costco for providing profiles for their printers, allowing users to submit images with the printer profile after applying the preferred rendering intent rather than merely submitting the files in sRGB for printing. However, in practice I find there is little difference in results when one uses the profiles or merely submits in sRGB. In the latter instance, the lab converts from sRGB to the printer profiled space and one has no control over the rendering intent. When using this option, one must use the Autocorrect option, which performs other optimizations in addition to selecting the rendering intent.
With this Costco lab, submitting the images in sRGB has few downsides.
Comments are welcome.
Bill
-
First, let me repeat I am totally with Andrew about not using sRGB or any smaller working gamuts than can be printed. This was an experiment to see how close one can come to representing an image in sRGB which bears the closest resemblance to a full gamut print. For instance to supply catalog images.
If anyone's interested, I can supply the matlab source code that runs this.
The image is from Andrew Rodney's printer gamut/profile test program available on his site. It consists of many highly colorful components some of which are in the full RGB space of ProPhoto. He calls it the "Printer Gamut Test File." It's particularly useful to see how out of gamut colors get printed and allows you to examine how profiles handle these colors. Some canned profiles are seriously flawed.
Attached is three images and a black and white image of the relative DeltaE in each location in the image. For these, black means DeltaE=0, White corresponds to DeltaE of 48 which occurs in locations where the ProPhoto pixel colors are extremely far from what can be rendered.
The average DeltaE was 4.3 for the modified approach (convert to printer, then sRGB) and 7.1 for the traditional approach of (convert to sRGB) before printing.
This is interesting, but for analytical purposes I think one needs two kinds of measurement: firstly, what would be the dE (1976) values for all those colours that are within the gamuts of both the printer profile and the sRGB working space; secondlym what would be the dE (1976) values for all those colours that are outside the one or the other, repeating this exercise for both RelCol and Perceptual RI. I suspect, though I don't know for sure, that the first set of measurements may show very little difference, while for the second, we may find an explanation in how OOG colours get remapped.
-
But that's besides the point. So the original image was resampled. The original image is 7500000 pixels. How did you resample?
I didn't. The file is the gamut not printer test file: "Gamut_test.file_flat.tiff", 2550x3300, 300 dpi, 16 bit, Authors "Andrew Rodney."
http://www.digitaldog.net/files/Gamut_Test_File_Flat.tif
You do know there is a V4 sRGB LUT based profile with a perceptual table and no, it's not going to solve every issue mapping a wide gamut original to sRGB. Considering that sRGB is ideal for one use, output to the web/mobil devices and that's a enormous crap shoot due to how those devices may or may not be calibrated or color managed, I'm still not sure what you're proposing that has a practical usage.
Yes, thanks for mentioning that. I recall looking at that briefly some time ago but not for this reason. I'll have to see how it behaves for this purpose.
Please note that the only reason I was proposing this was as an alternative offering a closer color match when representing what a particular large gamut print process produces in web ready sRGB.
Of course your argument about the wide range of actual color rendered by real world devices that presumably were designed to approximate sRGB to some degree is on point but there is no reason to add error on top of error.
-
Hi Bill,
I see two cases:
1) Both photographer and lab know what they are doing. Post your image in any RGB that does not clip colours. Adjust colours to fit within the proofing profiles provided by the lab.
2) Photographer, lab or both don't know what they are doing, send sRGB.
sRGB works mostly. More importantly, if any part of the colour management workflow is broken sRGB is a good fallback option.
But, for best results, work with a lab that acknowledges embedded profiles and gives you an option to print without adjustments.
The lab I use has a service where they print the image as is. No manual controls. Half the price and fast turnaround time.
Best regards
Erik
Best regards
Erik
I agree that when one is dealing with a wide gamut printer such as the current Epson Pro line of printers, one should use ProPhotoRGB as the working space and print using a profile for the printer/paper combination. However, when looking at the profile of the Fuji Frontier LP7700 printer at my local Costco, the printer gamut exceeds that of sRGB by only minor amounts in the yellows and teal greens as shown here. The profile was downloaded from the Drycreek.com web site, which supplies profiles for various labs.
(https://bjanes.smugmug.com/Photography/Costco-Frontier/i-D4z5G5n/0/O/sRGBvsFrontierCostcoGlsy.png)
Using a wire frame rather than solid color for sRGB better demonstrates where sRGB exceeds the gamut of the Frontier.
(https://bjanes.smugmug.com/Photography/Costco-Frontier/i-L3n77Ck/0/O/Costco_sRGB_Glossy.png)
This gamut for the printer is smaller than the one you provided for the Frontier, perhaps a different model or with different paper. Or perhaps from a less accurate profile.
(https://bjanes.smugmug.com/Photography/Costco-Frontier/i-8K4HVMD/0/O/sRGBvsFrontierDD.png)
One should applaud Costco for providing profiles for their printers, allowing users to submit images with the printer profile after applying the preferred rendering intent rather than merely submitting the files in sRGB for printing. However, in practice I find there is little difference in results when one uses the profiles or merely submits in sRGB. In the latter instance, the lab converts from sRGB to the printer profiled space and one has no control over the rendering intent. When using this option, one must use the Autocorrect option, which performs other optimizations in addition to selecting the rendering intent.
With this Costco lab, submitting the images in sRGB has few downsides.
Comments are welcome.
Bill
-
sRGB works mostly. More importantly, if any part of the colour management workflow is broken sRGB is a good fallback option.
But, for best results, work with a lab that acknowledges embedded profiles and gives you an option to print without adjustments.
The lab I use has a service where they print the image as is. No manual controls. Half the price and fast turnaround time.
Best regards
Erik
My local Costco (wholesale big box store in the USA) offers the latter option to print the image as is and does provide profiles. Since the gamut of their Frontier/Paper combination is less than that of sRGB for most colors, one often faces the same problems as when trying to fit the gamut of a ProPhotoRGB image to the gamut of the printer. Perceptual rendering seldom accomplishes this when one is dealing with wide gamut images such as colorful red flowers. In these cases, the best solution is to use a wider gamut printer/paper combination.
Regards,
Bill
-
I agree that when one is dealing with a wide gamut printer such as the current Epson Pro line of printers, one should use ProPhotoRGB as the working space and print using a profile for the printer/paper combination.
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.
However, when looking at the profile of the Fuji Frontier LP7700 printer at my local Costco, the printer gamut exceeds that of sRGB by only minor amounts in the yellows and teal greens as shown here. The profile was downloaded from the Drycreek.com web site, which supplies profiles for various labs.
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?
(http://digitaldog.net/files/ARGBvsFujiMatt.jpg)
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.
(http://digitaldog.net/files/ARGBvsFrontier.jpg)
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.
-
This is interesting, but for analytical purposes I think one needs two kinds of measurement: firstly, what would be the dE (1976) values for all those colours that are within the gamuts of both the printer profile and the sRGB working space; secondlym what would be the dE (1976) values for all those colours that are outside the one or the other, repeating this exercise for both RelCol and Perceptual RI. I suspect, though I don't know for sure, that the first set of measurements may show very little difference, while for the second, we may find an explanation in how OOG colours get remapped.
I'm pretty sure you are right re the set of colors inside sRGB and the printer's gamut. However, the reason I started investigating whether this was possible is just the observation that 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.
-
Please note that the only reason I was proposing this was as an alternative offering a closer color match when representing what a particular large gamut print process produces in web ready sRGB.
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.
-
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.
-
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.
-
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.
-
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?
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.
-
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
-
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.
-
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.
-
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.
-
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:
-
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
-
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.
-
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.
-
…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 ?
--
-
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.
-
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.
For colors that are in sRGB they should just map precisely.
That's always the nature of RelCol, independent from the clipping algorithm.
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 (?).
--
-
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.
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.
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.
-
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!
-
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.
-
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?
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. ;)
-
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 (http://www.fujifilm.eu/eu/support/photofinishing/color-management/) 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.
-
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.
What's the old saying about 'close'? I've never seen an output profile I've built that's 'close' to sRGB. There are colors that fall outside sRGB and colors that don't. The shapes are vastly different. Anyway, a printer that doesn't run any ICC-type color space conversion still has to convert to the native output color space in some form. It might not use ICC profiles, but the printer doesn't produce sRGB. Some solutions, like ICC profiles are better than others.
-
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 (http://www.fujifilm.eu/eu/support/photofinishing/color-management/) 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.
It is entirely possible that converting first to sRGB would yield a better looking print that going direct from ProPhoto to printer. The outlined approach's only value is producing an sRGB rendering that models closely the full gamut print so it completely depends on how good the printer profile is at that. For an image already converted to sRGB, and pleasing in that space, there is no value in this additional process.
One of the issues in editing, even in a completely color managed operation, is that the monitor rendering itself, actually uses matrix conversion with clipping - an argument for the widest possible monitor gamut to more closely approximate the colors the printer profile works with.
As for the printer sRGB profile, I've not encountered that before. Seems weird.
Is the ProPhoto RGB portion available. It might be interesting to run it through my stuff here.
-
As for the printer sRGB profile, I've not encountered that before. Seems weird.
There is no such thing as an sRGB printer. The spec is based on a theoretical CRT circa 1994 or so with P22 phosphors. sRGB can be the source color space of data converted to a printer, that doesn't make that printer an sRGB printer as none exist.
-
There is no such thing as an sRGB printer. The spec is based on a theoretical CRT circa 1994 or so with P22 phosphors. sRGB can be the source color space of data converted to a printer, that doesn't make that printer an sRGB printer as none exist.
Yes, clearly, which is why I find the notion weird. The closest I can imagine is that it's a "profile," using the term loosely, that converts a large space into the narrow sRGB space in such a way that it will somehow look good when submitted as an sRGB file on their printer. That goal doesn't seem to have been met.
Many colors that are in sRGB still can't be printed on anything. Maybe it smushes them. It sounds like a mess but I haven't read their docs on what the thing is supposed to do.
-
Yes, clearly, which is why I find the notion weird. The closest I can imagine is that it's a "profile," using the term loosely, that converts a large space into the narrow sRGB space in such a way that it will somehow look good when submitted as an sRGB file on their printer. That goal doesn't seem to have been met.
Well the point of my video is that sRGB is about the worst RGB working space to use for output to a printer, worse when it's vastly wider gamut but not so hot when smaller like a Lightjet etc. Of course the image data plays a role too. But one can and should (IF possible) send the image to a lab using sRGB and maybe Adobe RGB and see the results on the print. That's the final proof of what to use when you're got saturated imagery. As seen in the gamut maps I've provided, for the devices I profiled, Adobe RGB (1998) is a 'better' fit unless you're in the mood to clip colors.
-
It is entirely possible that converting first to sRGB would yield a better looking print that going direct from ProPhoto to printer. The outlined approach's only value is producing an sRGB rendering that models closely the full gamut print so it completely depends on how good the printer profile is at that. ...
As for the printer sRGB profile, I've not encountered that before. Seems weird.
Is the ProPhoto RGB portion available. It might be interesting to run it through my stuff here.
The >> ICC Profile for Fuji Frontier Printer sRGB (http://www.fujifilm.eu/eu/support/photofinishing/color-management/) <<
which I used above was the Crystal Archive Paper Supreme HD, or, likewise with the Crystal Archive Digital Paper Type DP II.
--
-
Well the point of my video is that sRGB is about the worst RGB working space to use for output to a printer, worse when it's vastly wider gamut but not so hot when smaller like a Lightjet etc. Of course the image data plays a role too. But one can and should (IF possible) send the image to a lab using sRGB and maybe Adobe RGB and see the results on the print. That's the final proof of what to use when you're got saturated imagery. As seen in the gamut maps I've provided, for the devices I profiled, Adobe RGB (1998) is a 'better' fit unless you're in the mood to clip colors.
What I hate about print labs that only take sRGB is that you have no idea what you are going to get. You can't expect them to match a color managed print process so a carefully created Photoshop print is probably not going to turn out like you want even if it looks semi-ok in sRGB. And different labs will produce different looking prints as they will all use their own secret sauce mapping sRGB in PerCol. Useful only for snaps you don't really care about.
-
The >> ICC Profile for Fuji Frontier Printer sRGB (http://www.fujifilm.eu/eu/support/photofinishing/color-management/) <<
which I used above was the Crystal Archive Paper Supreme HD, or, likewise with the Crystal Archive Digital Paper Type DP II.
Thanks. What about the original image?
-
What I hate about print labs that only take sRGB is that you have no idea what you are going to get. You can't expect them to match a color managed print process so a carefully created Photoshop print is probably not going to turn out like you want even if it looks semi-ok in sRGB. And different labs will produce different looking prints as they will all use their own secret sauce mapping sRGB in PerCol. Useful only for snaps you don't really care about.
On that we are in violent agreement.
-
What I hate about print labs that only take sRGB is that you have no idea what you are going to get. You can't expect them to match a color managed print process so a carefully created Photoshop print is probably not going to turn out like you want even if it looks semi-ok in sRGB. And different labs will produce different looking prints as they will all use their own secret sauce mapping sRGB in PerCol.
Myabe the Dry Creek Photo (https://www.drycreekphoto.com/icc/using_printer_profiles.htm) website helps.
quote: >>Frontier and Noritsu printers do not read embedded profiles<<. Hence there is no mystic PerCol conversion.
--
-
Myabe the Dry Creek Photo website helps.
quote: >>Frontier and Noritsu printers do not read embedded profiles<<. Hence there is no mystic PerCol conversion.
Depends on the front end settings used, certainly for Frontiers. I've built profiles in the past, for labs that had such devices and could use ICC Profiles going out to a Frontier. Of course recognizing the source color space inside the image data for the conversion.
EDIT Maybe not... see:
It doesn't matter if you embed ICC profile or not, Frontiers controller is ICC profile colour blind - it only increases the file size, so that why we may want to uncheck "embed ICC profile" while saving pre converted images.
Frontier has two working modes - sRGB (above mentioned), and PD. The second mode is more interesting from our perspective, as it is something like "ICM off" "no colour correction" known from printer drivers. It doesn't seem to proceed any limiting conversion, and allows us to utilise the whole gamut of c-print emulsion. As in sRGB mode case, we have to create/download profile created in PD mode, convert the image rendered to a large colour space, and enjoy much more saturated colours from blue-emerald-phtalogreen region, and better tonality (there's only one conversion, so there's less rounding errors). If you have a wide gamut display you can check the difference switching between sRGB and PD mode profiles
http://forum.luminous-landscape.com/index.php?topic=93016.new;topicseen#new
PD mode is what was used to create the ICC profiles but the targets (Depends on the front end settings used) were of course untagged as they always are.
-
Frontier has two working modes - sRGB (above mentioned), and PD. The second mode is more interesting from our perspective, as it is something like "ICM off" "no colour correction" known from printer drivers.
....
Andrew,
Interesting. I suppose one could send them profile patch images in PD, scan and make profiles, then check the consistency. Have people done this to your knowledge? I'd trust them more but wonder how much day to day variation their process experiences. Might be a good idea to include a small patch set in an order for QC purposes.
-
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 (http://www.fujifilm.eu/eu/support/photofinishing/color-management/) 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.
I didn't use the "sRGB" profile and used the Fuji Frontier HD PD profile to run the same tests I did on Andrew's image. The initial image has some high intensity ProPhoto Reds are outside Adobe RGB and even the Mac Adam gamut for reflective surfaces so there is no way to actually print those colors on any medium now, or in the future. This is even true for the image obtained by only converting to sRGB though the clipping above 255 also reduces luminance together with a hue shift and flattening some areas.
Interestingly, the full gamut printable image is within the Adobe RGB space and only slightly outside the sRGB space. Consequently the image created by converting the original to printer space (big change) then sRGB results in almost no perceivable change from the print image. That said, printing using PerCol, instead of RelCol w BPC, produces a more pleasing print and, as with RelCol, the sRGB image of said print per the process is visually extremely close to the full gamut PerCol print image.
Here are the stats re printing using RC w BPC, dE's are in DeltaE2000:
To sRGB then to Printer Space then to sRGB Ave dE: 0.533, Max dE: 7.059
To Printer Space then to sRGB Ave dE: 0.397, Max dE: 4.545
-
If you haven’t already, I recommend downloading ALL the offered ICC profiles from the Fuji Europe link you posted earlier in this thread. If you’re going to such lengths, those profiles from those various machines using those various materials can provide very useful insight when compared against each other.
Examples:
1) If you’re so concerned about sRGB, which is emissive, hold-and-compare sRGB against the Chromira Fuji Clear profile. The clear material is about as emissive as you will find. (It’s made to be backlit.) A more apples-to-apples comparison. You might also come to the realization that a Frontier IS NOT and RGB printer. (Nobody puts Fuji Clear in a Frontier, thus no profile.) The Frontier came to market way back in the 1990s before most people heard of an sRGB profile and before Photoshop could effectively soft proof for it for lack of a $400 Kodak plugin.
2) Hold-and-compare Durst Lambda Fuji-CA-DPII_v3a against Chromira_FF_DPII_G_L. Two different printer technologies (Lambda is RGB lasers vs Chromira LED exposure system) but same media/RA4 process yet yielding very similar results on the Crystal Archive paper.
3) Hold-and-compare Fuji_Frontier_DryLab4x0_PD_v3a against any other Fuji Frontier profiles. Very different technologies altogether.
Further, you might find on the web ICC profiles offered by the few remaining shops who still operate Lightjets, Lambdas, and Chromiras. If you compare their profiles against these from Fuji, you will notice a trend that the media/process is very similar. Dare I say “close?” Commercial labs running Frontiers should show the same similarity. Costcos, maybe. Walmarts, maybe not so much. Walgreens, maybe assuredly not so much. Just due to calibration and chemistry control quality.
Lastly, because I notice your dE measurements, I can tell you the larger color shops do not entirely count on ICC profiles for all their color matching. Critical colors are specified by Pantone guides, usually. The better RIPS offer a feature to lookup color substitution recipes. If the orange flower petal against the blue sky doesn’t match the client’s orange sweater apparel for this holiday season in-store graphics within a VERY certain dE, an operator selects the flower petal and tweaks a curve to predetermined values from using a printed Pantone chart. Also, the client is experienced enough not to have manufactured a product with colors that their advertising could not reproduce.
Mother Nature, she’s more of a challenge and we’re back to the flower.
-
So, the process to produce the closest match of a print to either an sRGB or aRGB (Adobe RGB (1998)) needs to be done carefully. It assumes one is working with a good printer profile. The output of this are images in sRGB and aRGB that, when printed using RelCol w/o BPC in a color managed environment will match closely the actual original, full gamut, printed image.
These digital files can be provided to someone with a need to see what the physical printed image will be should the desire to acquire it.
1. Start with the original, image in 16 bit, high gamut space. Either L*a*b* or ProPhoto preferred.
2. Convert the image colorspace using exactly the same printer settings (PerCol or RelCol, with or without BPC) the print is or was made with.
3. Make two additional duplicates. Call them ppRGB_print, sRGB_print, and aRGB_print. Close the original image.
4. Convert ppRGB_print, using RelCol w/o BPC* to ProPhoto RGB. Save the file. This is the best representation of the actual print. Particularly if there are printable colors outside sRGB and/or aRGB.
5. Convert aRGB_print, using RelCol w/o BPC* to Adobe RGB (1998). Save the file.
6. Convert sRGB_print, using RelCol w/o BPC* to sRGB. Save the file.
To see what the actual print would look like, the person with the digital files may view them with a color managed monitor or print the file ppRGB_print, using RelCol w/o BPC in a good, color managed, workflow.
When viewing with a monitor, the closest match to the print would be the aRGB_print when using a wide gamut monitor or the sRGB_print when using an unknown or sRGB like gamut. An accurate rendition of what the print would look like requires a profiled monitor at a minimum.
The usual issues of matching proofing on a monitor to print viewing is, of course, a prerequisite for monitor viewing.
-
One of the issues in editing, even in a completely color managed operation, is that the monitor rendering itself, actually uses matrix conversion with clipping -
Doug, you've made this point several times now in this thread, and I'm not sure whether it is "necessarily" correct. There are different kinds of display profiles. It depends on what software one uses to create the profile. BasicColor creates LUT profiles, not matrix. NEC Spectraview does the latter.
-
Doug, you've made this point several times now in this thread, and I'm not sure whether it is "necessarily" correct. There are different kinds of display profiles. It depends on what software one uses to create the profile. BasicColor creates LUT profiles, not matrix. NEC Spectraview does the latter.
Good points. I've never used one but I've heard they exist. In a sense they just add another dimension to the problem. They could be better than matrix conversions or they might be worse. Ideally, a monitor profile would map out of gamut colors in a ways similar to the way printer profile makers do. Maybe they do. Wonder if someone has tested these in out of gamut applications?
-
Good points. I've never used one but I've heard they exist. In a sense they just add another dimension to the problem. They could be better than matrix conversions or they might be worse. Ideally, a monitor profile would map out of gamut colors in a ways similar to the way printer profile makers do. Maybe they do. Wonder if someone has tested these in out of gamut applications?
Well, actually, as far as I'm concerned there is no problem. The display provides a very satisfactory prediction under soft-proofing of what will come out of the printer, because I am properly colour-managed from start to finish - notwithstanding the differences in gamut shape and DMax between the two output of the two devices, one of which transmits light and the reflects it. Prlnter profiles that provide good soft-proofing handle this gap quite nicely.
-
Well, actually, as far as I'm concerned there is no problem.
Ditto, same on this end.
I'm still scratching my head what all this is about ;D .
I do think an old and famous Bruce Fraser quote might be appropriate:
You can do all sorts of things that are fiendishly clever, then fall
in love with them because they're fiendishly clever, while
overlooking the fact that they take a great deal more work to obtain
results that stupid people get in half the time. As someone who has
created a lot of fiendishly clever but ultimately useless techniques
in his day, I'd say this sounds like an example.
Bruce
-
Ditto, same on this end.
I'm still scratching my head what all this is about ;D .
I do think an old and famous Bruce Fraser quote might be appropriate:
You can do all sorts of things that are fiendishly clever, then fall
in love with them because they're fiendishly clever, while
overlooking the fact that they take a great deal more work to obtain
results that stupid people get in half the time. As someone who has
created a lot of fiendishly clever but ultimately useless techniques
in his day, I'd say this sounds like an example.
Bruce
Amusing, but there is nothing here even close to fiendishly clever or really even clever. As you pointed out numerous times - similar things have been done before. It's a form of soft proofing, or, when downloaded and printed, hard proofing.
I only looked into it because I had noticed the simplistic way matrix based RGB colorspaces converted out of target gamut colors and started wondering about how printer profiles did the same task using 3D LUTs. Knowing the approaches were radically different, I thought it interesting to see just what the differences were.
Since I'm also handy with math and computer tools it was a fun and diverting, task. Since it's orthogonal to my usual pursuits and I am under no disclosure restrictions I thought I'd share it as others may be interested.
Perhaps the thing that has most astonished me is how close sRGB images can be made to match a print that is supposedly showing off the advantages of high gamut print processing. I have yet to find an image, going from full ProPhoto RGB to printer space and back to Adobe RGB where the Adobe RGB printed image is visually different from the ProPhoto image. High saturation sRGB images still print differently but they are significantly closer. I am starting to think much of what I had chalked up as just hitting the limits of sRGB was, in fact, due to this flawed gamut conversion.
I'm a "just the facts' kind of guy. There is way too much hand waving in printing and image work.
People that work only in the limited gamut, sRGB space, but maintain a good color managed workflow aren't giving up as much as I had previously believed.
And that's just the cold, hard, numbers.
-
Amusing, but there is nothing here even close to fiendishly clever or really even clever. As you pointed out numerous times - similar things have been done before. It's a form of soft proofing, or, when downloaded and printed, hard proofing.
Cross rendering a larger to smaller gamut output to print is indeed not new. We've been over it.
I'm still lost as to why I'd do this when one output is a print, the other is a display. I can't make an sRGB preview look like a ProPhoto RGB output to an Epson any more than I can get a gallon of water to fit completely into a pint container. If I need sRGB for viewing on the web, I'll send sRGB to that media. If I need a saturated print, using the full gamut of that output device, I'll send it ProPhoto RGB. How the print and the web are connected otherwise is what I'm still not at all clear on.
How do I make an sRGB soft proof match a ProPhoto RGB print? And why would I want to?
-
Well, actually, as far as I'm concerned there is no problem. The display provides a very satisfactory prediction under soft-proofing of what will come out of the printer, because I am properly colour-managed from start to finish - notwithstanding the differences in gamut shape and DMax between the two output of the two devices, one of which transmits light and the reflects it. Prlnter profiles that provide good soft-proofing handle this gap quite nicely.
There is no problem proofing printers on a monitor because the gamut clipping path goes through the 3D LUTs first.
-
There is no problem proofing printers on a monitor because the gamut clipping path goes through the 3D LUTs first.
Doug, there can be such problems if one's profiling of both devices is not up to scratch. I've seen it, I hate being surprised by what comes out of my printer, so I'm pretty careful about profile quality, correct monitor calibration and softproofing. My wastage rate is very low as a result. Sometimes one is fooled, but not often with a good quality colour management set-up. The quality matters, especially using a high-end printer like an Epson 4900 with wide gamut media.
-
Doug, there can be such problems if one's profiling of both devices is not up to scratch. I've seen it, I hate being surprised by what comes out of my printer, so I'm pretty careful about profile quality, correct monitor calibration and softproofing. My wastage rate is very low as a result. Sometimes one is fooled, but not often with a good quality colour management set-up. The quality matters, especially using a high-end printer like an Epson 4900 with wide gamut media.
Mark,
I'm with you there. I've seen some pretty marginal printer profiles too and made some when I was first learning. GIGO.
-
I'm still lost as to why I'd do this when one output is a print, the other is a display.
A lot of people spend a lot of time trying to get their prints to match their monitors. It's not a simple job but it is completely doable providing their monitor gamut encompasses their printed image gamut. It's close to doable even if the monitor gamut is a bit narrower that that of the image.
I can't make an sRGB preview look like a ProPhoto RGB output to an Epson any more than I can get a gallon of water to fit completely into a pint container. If I need sRGB for viewing on the web, I'll send sRGB to that media. If I need a saturated print, using the full gamut of that output device, I'll send it ProPhoto RGB. How the print and the web are connected otherwise is what I'm still not at all clear on.
Your analogy to water containers is flawed. The "gallon" container is never filled. Not even close.
How do I make an sRGB soft proof match a ProPhoto RGB print? And why would I want to?
This mostly depends on how well your viewing booth is set up to match your monitor when soft proofing. Seems that people have a lot of difficulty doing this. You have to understand illuminants, possibly create a profile targeting a specific illuminant if you aren't close enough to D50. Most aren't. Then get the illuminant WP, lux and monitor WP, nit levels correct. That's the hard part in soft proofing. Sure sRGB is a pretty limited space. Only use it if you have to.
Still, knowing how limited sRGB is, I'm just rather amazed how close almost all images I've looked at so far can be rendered in sRGB to proximate a high gamut print.
Also, someone might look into making 3D LUT monitor profiles that map like sRGB inside sRGB gamut but provide a better algorithm to the gamut boundry than RGB clipping.