Luminous Landscape Forum

Raw & Post Processing, Printing => Digital Image Processing => Topic started by: Muizen on June 29, 2006, 02:28:17 pm

Title: Editing in AdobeRGB, converting to sRGB
Post by: Muizen on June 29, 2006, 02:28:17 pm
When editing in Raw and in PS it is recommended to bring in as much data as possible by a.o. using a wide color space, usually AdobeRGB or ProPhotoRGB and start with 16-bit depth.
A large color space also reduces possible clippings as shown in the RAW histogram.

I wonder what happens thereafter to the image quality obtained when for printing purposes, the image has to be converted to sRGB and 8 bit?

Does one lose the advantages of editing in large color space 16 bit after converting to sRGB?

Thanks for reply!

Harry Briels
Mechelen, Belgium
Title: Editing in AdobeRGB, converting to sRGB
Post by: Dennis on June 29, 2006, 07:51:21 pm
Quote
When editing in Raw and in PS it is recommended to bring in as much data as possible by a.o. using a wide color space, usually AdobeRGB or ProPhotoRGB and start with 16-bit depth.
No, not really. A large gamut per se helps nothing. Mor important is, how the colors are treated, are out-of-gamut (OOG) colors clipped or mapped into the working gamut. And if you do not want to do any post processing, you don't need the 16bit color depth. If you can do all corrections within your Raw conversion software, it would be ideal to convert it directly to the output profile. That's unfortunately not possible with Photoshop, so there you have to convert the image into an intermediate color space first. Due to the architecture of the RGB profiles in PS, there is no use in ProPhotoRGB as an intermediate color space, if you want to convert it to another RGB space afterwords. It only makes sense, if you convert directly from ProPhotoRGB to you printer profile and this profile (and your image!) contains a considerable amount of colors outside AdobeRGB. If this is not the case, you loose nothing converting directly to AdobeRGB. If you have to do some major postprocessing, you'll might want to go 16bit to avoid posterization. If you do only the conversion from AdobeRGB to your output profile, I am not sure if 16 bit has any significant advantages. Using ProPhotoRGB makes 16bit a must.

Quote
A large color space also reduces possible clippings as shown in the RAW histogram.
No, not really. Only, if you do not correct the exposure sliders. If your histogram is perfect, when ProPhotoRGB is the output profile, there might be some clipping switching to AdobeRGB. You have to counterbalance this with the exposure settings.

Quote
I wonder what happens thereafter to the image quality obtained when for printing purposes, the image has to be converted to sRGB and 8 bit?
That's, what you have to care for, and that's where large gamuts are really difficult to handle. A perceptive conversion from ProPhotoRGB to sRGB is not possible, so in order to prevent clipping of OOG colors, you have to carefully desaturate the colors using the soft proof function. The final conversion from 16bit to 8bit is not a problem, since you need the 16bit only as a headroom for corrections. When those are done, there's no need for 16bit anymore. As long as your output device works in 8bit, as well. There seem to be printers with 12bit output, regarding Michaels report on the new Canon printer. This of course, would be a definite reason to keep the image in 16bit.

Quote
Does one lose the advantages of editing in large color space 16 bit after converting to sRGB?
As long as your output profile is considerably smaller than your "large color space", there's only very little advantage, but big problems. There is absolutely no use in a large color space, if there are no colors using it. If the colors of your image are within AdobeRGB, a gamut like ProPhotoRGB is a waste.

With my limited knowlidge and experience, I find it more usefull, to compress the colors into AdobeRGB, than using ProPhoto and struggeling with clipped colors later. Since we in Germany have a pretty well organized CM with well supported ISO CMYK profiles (not the crap PS profile named "ISO Coated Fogra 27" but the real ISO stuff), I find it a bit annoying not to be able to choose an ECI-RGB or any printer profile directly in ACR - that would solve the whole large gamut 16bit discussion.
Title: Editing in AdobeRGB, converting to sRGB
Post by: Jonathan Wienke on July 08, 2006, 07:48:17 am
Quote
No, not really. A large gamut per se helps nothing. Mor important is, how the colors are treated, are out-of-gamut (OOG) colors clipped or mapped into the working gamut. And if you do not want to do any post processing, you don't need the 16bit color depth. If you can do all corrections within your Raw conversion software, it would be ideal to convert it directly to the output profile. That's unfortunately not possible with Photoshop, so there you have to convert the image into an intermediate color space first. Due to the architecture of the RGB profiles in PS, there is no use in ProPhotoRGB as an intermediate color space, if you want to convert it to another RGB space afterwords. It only makes sense, if you convert directly from ProPhotoRGB to you printer profile and this profile (and your image!) contains a considerable amount of colors outside AdobeRGB. If this is not the case, you loose nothing converting directly to AdobeRGB. If you have to do some major postprocessing, you'll might want to go 16bit to avoid posterization. If you do only the conversion from AdobeRGB to your output profile, I am not sure if 16 bit has any significant advantages. Using ProPhotoRGB makes 16bit a must.

I strongly disagree with most of this. There are several advantages to using ProPhoto as your editing space. First, when editing an image, there is no advantage to converting from RAW directly to a specific output device profile, and many disadvantages. Most photographers print their images on more than one printer, whether personally owned, the minilab around the corner, or an online service. You want to have at least one master version of your image that is not compromised in any way by output device gamut limitations, and then create a device-specific version for a particular press or printer only when necessary. Converting RAW to ProPhoto first, then editing for a specific device allows much greater control over how the gamut compression/reduction is done. Why cripple your master image to accommodate the current limits of rapidly-advancing printer technology?

Quote
If your histogram is perfect, when ProPhotoRGB is the output profile, there might be some clipping switching to AdobeRGB. You have to counterbalance this with the exposure settings.

This is really bad advice. The exposure slider is at best a very crude way to control color gamut. It only helps control gamut in the highlights, and has no effect on saturated colors in shadows, like green leaves or grass in the shadows of a landscape image. These colors are often more prone to fall out-of-gamut than bright colors, unless you're shooting autumn leaves or car shows or flowers or suchlike. What you're advocating will result in unnecessarily darkening the image when saturated colors are present, which means more and unnecessary adjustments later in Photoshop.

Quote
That's, what you have to care for, and that's where large gamuts are really difficult to handle. A perceptive conversion from ProPhotoRGB to sRGB is not possible, so in order to prevent clipping of OOG colors, you have to carefully desaturate the colors using the soft proof function.

That's how you should always adjust gamut to fit a specific output device; adjusting individual color ranges with the hue/saturation control, preferably with a saturation and/or luminance mask to focus the effect on the color ranges that need to be shoehorned without affecting the rest of the image any more than absolutely necessary. Wide-gamut editing spaces are only "difficult" if you don't know how to use them effectively.

Quote
The final conversion from 16bit to 8bit is not a problem, since you need the 16bit only as a headroom for corrections. When those are done, there's no need for 16bit anymore. As long as your output device works in 8bit, as well. There seem to be printers with 12bit output, regarding Michaels report on the new Canon printer. This of course, would be a definite reason to keep the image in 16bit.

Keep your image 16-bit anyway, unless sending it to a client that can't handle 16-bit images. Even if you are printing to an 8-bit device, you'll still get better results printing a 16-bit file. When converting from 16-bit ProPhoto RGB to 8-bit printer data during the printing process, all 256 levels of the color channel data going to the printer can be used; the color profile conversion is perfomed first, then the data is rounded to the nearest 8-bit value and sent to the printer. But if the source file is 8-bit, then you may be only using 100-200 of the possible 8-bit values in a color channel (think of the "toothcomb" histogram you get when doing a curve adjustment in 8-bit mode in Photoshop) and you'll have more posterization and banding in your print as a result.

Quote
As long as your output profile is considerably smaller than your "large color space", there's only very little advantage, but big problems. There is absolutely no use in a large color space, if there are no colors using it. If the colors of your image are within AdobeRGB, a gamut like ProPhotoRGB is a waste.

This is really irrelevant when working with 16-bit files. ProPhoto files are no larger than Adobe RGB, and neither are susceptible to banding/posterization in 16-bit mode.

Quote
With my limited knowlidge and experience, I find it more usefull, to compress the colors into AdobeRGB, than using ProPhoto and struggeling with clipped colors later. Since we in Germany have a pretty well organized CM with well supported ISO CMYK profiles (not the crap PS profile named "ISO Coated Fogra 27" but the real ISO stuff), I find it a bit annoying not to be able to choose an ECI-RGB or any printer profile directly in ACR - that would solve the whole large gamut 16bit discussion.

This advice is based on the limitatations of your knowledge and experience, which is why you're "struggeling with clipped colors later". Using RAW converter exposure settings and output color space choice to fix out-of-gamut colors is crude and imprecise, and leaves one with problems that must be solved later. Also, be aware that given the differences in shape between printer color spaces and editing color spaces, you need ProPhoto to use 100% of the printer gamut anyway. Many printers can print some colors that fall outside of Adobe RGB, so you're possibly cheating yourself out of some printer gamut if you use anything less than ProPhoto anyhow.

And if you start using a different printer with a wider gamut, then you have to completely reprocess your image from RAW conversion on to take advantage of it. If you have a master copy of the image in ProPhoto RGB, you only need to perform a hue/saturation adjustment on the master, convert to output profile, and save as a new copy (and even this will be unnecessary on many cases) and you will not have to redo noise reduction, sharpening, curves, compositing, cloning, and other adjustments and edits to the image. This is particularly useful if the image is a stitched panorama, an image shot with mixed lighting requiring multiple RAW conversions with different white balances to be blended together, a multi-shot high-dynamic-range blend, or has some other time-consuming processing that must be done.

Get in the habit of editing a 16-bit ProPhoto master image that is not compromised by output device limitations, and making output-device-specific variations of the master when necessary. It will save you time and hassle in the long run as printer technology improves.
Title: Editing in AdobeRGB, converting to sRGB
Post by: bjanes on July 08, 2006, 08:52:50 am
Quote
That's how you should always adjust gamut to fit a specific output device; adjusting individual color ranges with the hue/saturation control, preferably with a saturation and/or luminance mask to focus the effect on the color ranges that need to be shoehorned without affecting the rest of the image any more than absolutely necessary. Wide-gamut editing spaces are only "difficult" if you don't know how to use them effectively.

Get in the habit of editing a 16-bit ProPhoto master image that is not compromised by output device limitations, and making output-device-specific variations of the master when necessary. It will save you time and hassle in the long run as printer technology improves.
[a href=\"index.php?act=findpost&pid=70053\"][{POST_SNAPBACK}][/a]

Jonathin makes excellent points, but if the gamut of the capture fits into aRGB, I see no advantage in ProPhotoRGB and some disadvantages. If you are mapping to an output device using the controls Jonathin mentions, there is no problem. However, if you are taking the easy way and using perceptual rendering intent, there may be excessive compression of the gamut. The rendering engine (as currently implemented) does not examine what colors are in the file, but merely compresses the larger space by a predetermined amount.
Title: Editing in AdobeRGB, converting to sRGB
Post by: Jonathan Wienke on July 08, 2006, 09:05:15 am
Quote
Jonathin makes excellent points, but if the gamut of the capture fits into aRGB, I see no advantage in ProPhotoRGB and some disadvantages. If you are mapping to an output device using the controls Jonathin mentions, there is no problem. However, if you are taking the easy way and using perceptual rendering intent, there may be excessive compression of the gamut. The rendering engine (as currently implemented) does not examine what colors are in the file, but merely compresses the larger space by a predetermined amount.

Which is why I hardly ever use perceptual rendering, and use relative colorimetric instead. I've found that printing the ProPhoto master file using relative colorimetric rendering to the output profile without hand-converting delivers excellent results more than 95% of the time. Perceptual rendering often introduces color casts as well as the issue you mention. Large-gamut color spaces have no disadvantages if you use them properly and avoid sloppy processing techniques which can get you into trouble even if you use sRGB.
Title: Editing in AdobeRGB, converting to sRGB
Post by: digitaldog on July 08, 2006, 10:01:22 am
Do not pass go, do not collect $200. Go directly to Lightroom poscast #8 and listen to the geeks discuss some of these issues:

http://photoshopnews.com/2006/07/07/lightr...pisode-8-posted (http://photoshopnews.com/2006/07/07/lightroom-podcast-episode-8-posted)

The first 10 minutes will do of course, enjoy the rest if you want.
Title: Editing in AdobeRGB, converting to sRGB
Post by: Dennis on July 08, 2006, 07:22:53 pm
Quote
I strongly disagree with most of this.
And I do with most of your comments.
Title: Editing in AdobeRGB, converting to sRGB
Post by: Dennis on July 08, 2006, 07:23:29 pm
Quote
Get in the habit of editing a 16-bit ProPhoto master image that is not compromised by output device limitations, and making output-device-specific variations of the master when necessary. It will save you time and hassle in the long run as printer technology improves.
Get in the habit of doing well exposed photographs, that do only need some minor corrections, which can be done inside the raw conversion software
Title: Editing in AdobeRGB, converting to sRGB
Post by: Jonathan Wienke on July 09, 2006, 10:53:36 am
Quote
Get in the habit of doing well exposed photographs, that do only need some minor corrections, which can be done inside the raw conversion software

I have never, ever advocated sloppiness in exposure, focus, lighting, or any other photographic technique. An image well-exposed in-camera is only the first step toward a good print. Most images benefit from curves, sharpening, B&W conversion and toning, and other post-processing adjustments that are best done in Photoshop rather than the RAW converter. Limiting yourself to RAW converter adjustments, especially when adjusting color gamut to a specific output device is crude and imprecise; rather like climbing a mountain by hopping on one foot when you have two normal and healthy arms and legs.

You are also espousing a workflow that limits your images to the capabilities of whatever printer you happen to be using at the moment, with no thought to inevitable technological improvements. As new printers are introduced with greater dynamic range and wider gamut, you will have to rework your images from scratch, starting with RAW conversion and redoing all subsequent edits and adjustments, if you wish to use the capabilities of the new printer.

With the workflow I recommend, all you have to do is (possibly) redo the final gamut tweak, convert to the new profile, and save a new version of the master, and the curves, sharpening, noise reduction, compositing, and other adjustments to the image do not have to be redone. This is especially valuable when a single image needs to be output on several devices, or even using multiple paper types in a single printer, as each paper type will have a different gamut, dynamic range, and associated profile.
Title: Editing in AdobeRGB, converting to sRGB
Post by: Ray on July 10, 2006, 02:12:38 am
I tend to agree with Jonathan on these point, so he must be right   .
Title: Editing in AdobeRGB, converting to sRGB
Post by: Stephen Best on July 10, 2006, 04:16:55 am
Quote
The rendering engine (as currently implemented) does not examine what colors are in the file, but merely compresses the larger space by a predetermined amount.
[a href=\"index.php?act=findpost&pid=70058\"][{POST_SNAPBACK}][/a]

More precisely, perceptual is compressing the colours within the reference space (PCS), not the input space. The size/shape of the input space is irrelevant for the conversion. Take an image in sRGB and print it out. Convert the image to ProPhoto and print it out. Compare the two. There should be no difference. The gamut mapping diagrams are merely a simplification ... and the source of some confusion it seems.
Title: Editing in AdobeRGB, converting to sRGB
Post by: dlashier on July 10, 2006, 04:47:54 am
Quote
Get in the habit of doing well exposed photographs, that do only need some minor corrections, which can be done inside the raw conversion software
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=70109\")
I tend to agree with this, for many or most images. Examples are [a href=\"http://www.lashier.com/home.cfm?dir_cat=26101]do it in C1 or PS[/url] and River Hybrid (http://www.lashier.com/home.cfm?dir_cat=30551). OTOH there are cases (as in some of my other adjustment examples) where Photoshop is indispensible. Adobe is finally recognizing this by even producing a product such as Lightroom.

- DL
Title: Editing in AdobeRGB, converting to sRGB
Post by: bjanes on July 10, 2006, 08:05:12 am
Quote
More precisely, perceptual is compressing the colours within the reference space (PCS), not the input space. The size/shape of the input space is irrelevant for the conversion. Take an image in sRGB and print it out. Convert the image to ProPhoto and print it out. Compare the two. There should be no difference. The gamut mapping diagrams are merely a simplification ... and the source of some confusion it seems.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=70221\")

In the context of my statment, we were talking about converting into ProPhotoRGB and then mapping it into a smaller space such as a printer space or sRGB for web output, and were not considering converting from sRGB to Prophoto. Furthermore, in converting from one space to another, Photoshop does not convert the input file to the PCS (CIE LAB) and then to the output space. This would be too slow. Andrew Rodney covers this in this color management book, I think, and perhaps he will jump in here. Where CIE LAB comes in is that the RGB coordinates for the conversion are expressed in CIE LAB and a three-by-three matrix transform is done. See Pointon for an example:

[a href=\"http://www.poynton.com/notes/colour_and_gamma/ColorFAQ.html#RTFToC20]http://www.poynton.com/notes/colour_and_ga...Q.html#RTFToC20[/url]

In any case, in your example, convterting from sRGB into ProPhoto, there can be a difference in the prints. If you print the converted ProPhoto with relative colorimetric, there will be no difference, since there could be no out of gamut colors. If you used perceptual rendering, then there would be a difference, since the entire gamut of ProPhoto would be compressed by a predetermined amount, even though there are no out of gamut colors.
Title: Editing in AdobeRGB, converting to sRGB
Post by: Stephen Best on July 10, 2006, 09:03:32 am
Quote
If you used perceptual rendering, then there would be a difference, since the entire gamut of ProPhoto would be compressed by a predetermined amount, even though there are no out of gamut colors.
[a href=\"index.php?act=findpost&pid=70239\"][{POST_SNAPBACK}][/a]

Try it.
Title: Editing in AdobeRGB, converting to sRGB
Post by: Hermie on July 10, 2006, 02:31:58 pm
Quote
More precisely, perceptual is compressing the colours within the reference space (PCS), not the input space. The size/shape of the input space is irrelevant for the conversion.
[a href=\"index.php?act=findpost&pid=70221\"][{POST_SNAPBACK}][/a]

Gamut mapping of perceptual rendering intent (lut profiles only!) is fixed and done when profiling software generates the profile. The gamut mapping is incorporated in the lookup tables.
This also means that the profiling software has to make an assumtion on the source colors (size of gamut, shape).

Herman
Title: Editing in AdobeRGB, converting to sRGB
Post by: bjanes on July 10, 2006, 03:05:27 pm
Quote
Gamut mapping of perceptual rendering intent (lut profiles only!) is fixed and done when profiling software generates the profile. The gamut mapping is incorporated in the lookup tables.
This also means that the profiling software has to make an assumtion on the source colors (size of gamut, shape).

Herman
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=70269\")

Yes, if perceptual rendering from ProPhotoRGB into a smaller space such as a printer profile is done, unlike what Steven Best seems to think, there will be compression according to the LUT in the profile. There is a good article by Mike Chaney on this subject. The entire gamut of ProPhotoRGB is not compressed, but the maker of the profile has to make assumptions on what colors the source is likely to contain.

[a href=\"http://www.steves-digicams.com/techcorner/July_2005.html]http://www.steves-digicams.com/techcorner/July_2005.html[/url]
Title: Editing in AdobeRGB, converting to sRGB
Post by: bjanes on July 10, 2006, 03:20:30 pm
duplicate message deleted by author
Title: Editing in AdobeRGB, converting to sRGB
Post by: bjanes on July 10, 2006, 03:56:53 pm
Quote
Try it.
[a href=\"index.php?act=findpost&pid=70246\"][{POST_SNAPBACK}][/a]

To try it, one needs profiles with perceptual rendering intent lookup tables. Photoshop permits perceptual conversions even when the appropriate lookup tables are not present, for example as in matrix based spaces such as ProPhotoRGB and sRGB, where no lookup tables exist. If you perform perceptual and relative colorimetric conversions with these matrix based spaces, you will see no differences, since conversion is always relative colorimetric (clipping) even when one checks perceptual conversion. PSCS2 does not tell you about the problem.

I did try it for an Epson printer profile from DryCreek.com and saw no difference, at least converting to the printer space in both modes and comparing both images brought into photoshop as layers and using the difference blending mode. On investigation, I found that no perceptual tables were present. Someone else will have to do the experiment.
Title: Editing in AdobeRGB, converting to sRGB
Post by: Stephen Best on July 10, 2006, 04:22:54 pm
Quote
I did try it for an Epson printer profile from DryCreek.com and saw no difference, at least converting to the printer space in both modes and comparing both images brought into photoshop as layers and using the difference blending mode. On investigation, I found that no perceptual tables were present. Someone else will have to do the experiment.
[a href=\"index.php?act=findpost&pid=70277\"][{POST_SNAPBACK}][/a]

A simpler technique is to look at the Proof Color readout in Photoshop's info palette.

As Hermie above has explained, the tables are fixed. There is no mechanism for output rendering to know the gamut of the input (working) space. The individual colours within the space get remapped, not the gamut. It's the same for perceptual and colorimetric.
Title: Editing in AdobeRGB, converting to sRGB
Post by: Stephen Best on July 10, 2006, 04:44:35 pm
Quote
There is a good article on the Steve's Digicam site by Mike Chaney on this subject.

http://www.steves-digicams.com/techcorner/July_2005.html (http://www.steves-digicams.com/techcorner/July_2005.html)
[a href=\"index.php?act=findpost&pid=70274\"][{POST_SNAPBACK}][/a]

From the article you linked:

"Some misinformation on the web would lead you to believe that because the CMM cannot account for image gamut, that it simply compresses the entire gamut of the color space used by the image so that it fits inside the printer's gamut. This is, however, also not true. Squashing the entire color space where the image resides into the printer's color space would amount to taking the entire wire frame above and shrinking it in size so that no corners protrude through the printer's solid gamut in the diagram. As you may be able to see by the graphic, that would be an extreme amount of compression that would result in noticeable color desaturation. In addition, it would mean that the same image encoded in two different color spaces of different sizes (say sRGB and Adobe RGB) would result in two different prints with different amounts of desaturation even though the original images should appear the same as they both have all the same colors:  they are just encoded differently."
Title: Editing in AdobeRGB, converting to sRGB
Post by: bjanes on July 10, 2006, 06:18:13 pm
Quote
From the article you linked:

"Some misinformation on the web would lead you to believe that because the CMM cannot account for image gamut, that it simply compresses the entire gamut of the color space used by the image so that it fits inside the printer's gamut. This is, however, also not true. Squashing the entire color space where the image resides into the printer's color space would amount to taking the entire wire frame above and shrinking it in size so that no corners protrude through the printer's solid gamut in the diagram. As you may be able to see by the graphic, that would be an extreme amount of compression that would result in noticeable color desaturation. In addition, it would mean that the same image encoded in two different color spaces of different sizes (say sRGB and Adobe RGB) would result in two different prints with different amounts of desaturation even though the original images should appear the same as they both have all the same colors:  they are just encoded differently."
[a href=\"index.php?act=findpost&pid=70279\"][{POST_SNAPBACK}][/a]

IMHO, you do not understand the concepts addressed in the article. The author does not address the situation where a small space is converted to a larger space (which would make absolutely no sense), and then rendered with perceptual intent back to a smaller space, such as a printer. If the image is in ProPhotoRGB and it is being rendered into a smaller space with perceptual intent, an arbitrary amount of gamut compression will be applied:

"What all this amounts to is the fact that perceptual intent basically uses an arbitrary amount of gamut compression (squashing) in order to reduce the banding effects that might be present in relative colorimetric intent."
Title: Editing in AdobeRGB, converting to sRGB
Post by: PeterLange on July 10, 2006, 06:47:48 pm
Quote
In any case, in your example, convterting from sRGB into ProPhoto, there can be a difference in the prints. If you print the converted ProPhoto with relative colorimetric, there will be no difference, since there could be no out of gamut colors. If you used perceptual rendering, then there would be a difference, since the entire gamut of ProPhoto would be compressed by a predetermined amount, even though there are no out of gamut colors.

/> Create any color in sRGB
/> Duplicate the file and convert the copy to ProPhoto RGB
Note: RGB numbers change, but Lab coordinates stay the same
/> Convert both files to your printer profile* using the Perceptual intent
(same setting for black point compensation, respectively)
/> measure the new RGB numbers, respectively

Finally, both RGB combos should be right the same. The Perceptual Intent has no idea about what the source space was. It just 'collects' the data from Profile Connection Space PCS Lab or XYZ, to apply its rigid non-linear transforms for compression into the target space.

Peter

--
*Epson generic, including all 6 common A2B and B2A tables. For control, a second test can be done, now using RelCol – which again yields identical RGB combos, but different compared to above test. As it was Ethan Hansen who explained this to me some time ago, I’m surprised to hear that his printer profiles wouldn’t contain respective LUTs…
Title: Editing in AdobeRGB, converting to sRGB
Post by: bjanes on July 10, 2006, 07:38:30 pm
Quote
A simpler technique is to look at the Proof Color readout in Photoshop's info palette.
[a href=\"index.php?act=findpost&pid=70278\"][{POST_SNAPBACK}][/a]

The info palette is useful, but with soft proofing, it gives no before and after readouts as it does with curves.

Quote
As Hermie above has explained, the tables are fixed. There is no mechanism for output rendering to know the gamut of the input (working) space. The individual colours within the space get remapped, not the gamut. It's the same for perceptual and colorimetric.
[a href=\"index.php?act=findpost&pid=70278\"][{POST_SNAPBACK}][/a]

The above is not true. Steven starts out with a true statement, and then follows it with nonsense. The gamut of the source space is known to the CMM--how else could it do any mapping? Actually, with perceptual intent, the gamut of the source space is squashed by a fixed amount. In determining the amount of compression needed, the CMS does not look at the individual colors in the source to determine the amount of compression, but rather uses a predetermined amount of compression. All colors are remapped, whether they are in or out of gamut in the destination space, and the appearance of the colors changes. Again a quote from the article on Steve's Digicam site. Note that "all possible colors" refers to the gamut of the source space, not the actual colors in the image.

"Other than reduced color vibrancy, there is another down side to perceptual intent.  The current ICC CMM (color management model) is not a "smart" model meaning that it cannot and does not examine the gamut of the actual image  before trying to compress it to fit in the printer's gamut.  While the gamut available to your original image (the red wire frame) is large, your actual image may only contain a few dull colors like some green foliage and people wearing light pastel clothing.  All colors in your image in this case may be reproducible by the printer.  A "smart CMM" might be able to look at the original image and determine that it doesn't need any squashing to be printed.  Unfortunately, the CMM does not have any knowledge about the image being rendered and must perform a sort of "blind rendering" that assumes that all possible colors must be taken into account whether or not they actually exist in your image"

With relative colorimetric, the colors of the source space are remapped to those of the output space. Colors out of gamut in the output space are clipped and remain at the edge of the output space. Colors that are within gamut of the output space are not changed in appearance, but their numbers change. This is quite different from perceptual.
Title: Editing in AdobeRGB, converting to sRGB
Post by: Stephen Best on July 10, 2006, 07:39:58 pm
Quote
"What all this amounts to is the fact that perceptual intent basically uses an arbitrary amount of gamut compression (squashing) in order to reduce the banding effects that might be present in relative colorimetric intent."
[a href=\"index.php?act=findpost&pid=70286\"][{POST_SNAPBACK}][/a]

Yes, "arbitrary" in that it's not dependent on the input (working) space.

In the context of the original post, it doesn't make any difference what working space is used as far as output is concerned. The working space merely determines the gamut of possible image colours and, inversely, the precision at which they can be edited. As for perceptual rendering, there's been a lot of work done on this and it's likely that one will achieve "better" output with perceptual than editing the image to bring it back into gamut manually. Soft proofing is an easy way of evaluating this.
Title: Editing in AdobeRGB, converting to sRGB
Post by: Stephen Best on July 10, 2006, 07:58:36 pm
Quote
The info palette is useful, but with soft proofing, it gives no before and after readouts as it does with curves.
[a href=\"index.php?act=findpost&pid=70301\"][{POST_SNAPBACK}][/a]

Last try.

Create an RGB image in sRGB (16-bit to minimize rounding). Fill it with your favourite colour. Look at the LAB coordinates. Soft proof it with any printer profile, colorimetric or perceptual, BPC or not ... it doesn't matter. Look at the Proof Color readout. Duplicate the image and convert it to any larger working space, e.g. Adobe RGB or ProPhoto RGB. The RGB values will change (the image is in effect less saturated from its new possible maximum), but both the LAB coordinates and Proof Color values will be the same (or near enough). It's still the same colour and will render the same. Get back to me when you've found a colour, printer profile or rendering that disproves this :-).
Title: Editing in AdobeRGB, converting to sRGB
Post by: bjanes on July 10, 2006, 09:17:58 pm
Quote
Last try.

[a href=\"index.php?act=findpost&pid=70306\"][{POST_SNAPBACK}][/a]

Stephen,

The third time is the charm as they say. I did the experiment you suggested and the results were as you suggested and not what I expected. I stand corrected and have learned something in the process, and hopefully others who read the thread did too.

BTW, I looked at the work on your web site and was impressed.

Bill
Title: Editing in AdobeRGB, converting to sRGB
Post by: Stephen Best on July 10, 2006, 09:45:51 pm
Quote
Stephen,

The third time is the charm as they say. I did the experiment you suggested and the results were as you suggested and not what I expected. I stand corrected and have learned something in the process, and hopefully others who read the thread did too.

BTW, I looked at the work on your web site and was impressed.

Bill
[a href=\"index.php?act=findpost&pid=70313\"][{POST_SNAPBACK}][/a]

Thanks for your comments. I thought it was worthwhile persevering as the concept is fundamental. It wasn't long ago that I needed to be convinced of the same. We're all on the same journey.

Cheers.
Title: Editing in AdobeRGB, converting to sRGB
Post by: Jonathan Wienke on July 11, 2006, 12:53:34 pm
Quote
I tend to agree with this, for many or most images. Examples are do it in C1 or PS (http://www.lashier.com/home.cfm?dir_cat=26101) and River Hybrid (http://www.lashier.com/home.cfm?dir_cat=30551). OTOH there are cases (as in some of my other adjustment examples) where Photoshop is indispensible. Adobe is finally recognizing this by even producing a product such as Lightroom.

I agree that there is a place for doing most of the work on an image in the RAW converter, like preparing web galleries, batch processing yearbook photos, and other jobs where there is a large number of frames involved. In a studio, where one has total control over the lighting, one can work this way much of the time and only get into PS for retouching, compositing, and such things.

My primary objection was to the notion of working in such a way that one is forced to start with a new RAW conversion every time one upgrades printers or switches printing services.
Title: Editing in AdobeRGB, converting to sRGB
Post by: Jack Flesher on July 11, 2006, 02:03:16 pm
Quote
Thanks for your comments. I thought it was worthwhile persevering as the concept is fundamental. It wasn't long ago that I needed to be convinced of the same. We're all on the same journey.

Cheers.
[a href=\"index.php?act=findpost&pid=70316\"][{POST_SNAPBACK}][/a]

Stephen:

I was under the impression this is just a function of the soft-proofing rendering engine in Photoshop and NOT what happens when we actually print.  

The soft-proofing tool obviously uses the paper profile, but since we're looking at it on our monitor it uses perceptual for all intents -- along with the narrow monitor gamut (from the monitor profile in use).  However when we do the actual gamut map for a print, the gamut mapping and rendering intent will make a visible difference.

At least that's how I understood it.
Title: Editing in AdobeRGB, converting to sRGB
Post by: Dennis on July 11, 2006, 06:57:29 pm
Quote
In any case, in your example, convterting from sRGB into ProPhoto, there can be a difference in the prints. If you print the converted ProPhoto with relative colorimetric, there will be no difference, since there could be no out of gamut colors. If you used perceptual rendering, then there would be a difference, since the entire gamut of ProPhoto would be compressed by a predetermined amount, even though there are no out of gamut colors.
AFAIK in general with matrix based profiles there is no perceptual RI, only absolute colorimetric. Only LUT based profiles implement all 4 RI's. Further Thomas Knoll pointed out in the Adobe forums, that PS does always RelCol with matrix based profiles such as ProPhotoRGB and sRGB. If you need a LUT based RGB profile, google for PhotoGamutRGB. You can visualize it at iccview.de.
Title: Editing in AdobeRGB, converting to sRGB
Post by: bjanes on July 11, 2006, 07:23:13 pm
Quote
AFAIK in general with matrix based profiles there is no perceptual RI, only absolute colorimetric. Only LUT based profiles implement all 4 RI's. Further Thomas Knoll pointed out in the Adobe forums, that PS does always RelCol with matrix based profiles such as ProPhotoRGB and sRGB. If you need a LUT based RGB profile, google for PhotoGamutRGB. You can visualize it at iccview.de.
[a href=\"index.php?act=findpost&pid=70398\"][{POST_SNAPBACK}][/a]

Yes, that is true about matrix profiles, as I mentioned in a previous post. The perceptual rendering to which I was refering was in printing, where LUT based profiles are available. Thanks for the reference to PhotoGamutRGB. Would that be useful if one wanted to convert ProPhotoRGB to sRGB for use on the web?
Title: Editing in AdobeRGB, converting to sRGB
Post by: Stephen Best on July 11, 2006, 08:35:29 pm
Quote
I was under the impression this is just a function of the soft-proofing rendering engine in Photoshop and NOT what happens when we actually print.
[a href=\"index.php?act=findpost&pid=70372\"][{POST_SNAPBACK}][/a]

If you're selecting "Let Photoshop Determine Colors" it's doing exactly the same conversion as when you soft-proof, except that soft-proofing then has to convert it back through the printer profile's proofing (AtoB) tables and your monitor profile to display a representation of what the output will look like. Photoshop presumably builds a single table to streamline all this. The Proof Color is what would be sent to the printer driver. If the output space is CMYK, it will show as CMYK. Not convinced? Try converting the image with Convert to Profile to the printer space with the same rendering settings as you used for soft-proofing.