Pages: 1 [2]   Go Down

Author Topic: Editing in AdobeRGB, converting to sRGB  (Read 18648 times)

bjanes

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 3387
Editing in AdobeRGB, converting to sRGB
« Reply #20 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."
Logged

PeterLange

  • Guest
Editing in AdobeRGB, converting to sRGB
« Reply #21 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…
Logged

bjanes

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 3387
Editing in AdobeRGB, converting to sRGB
« Reply #22 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.
Logged

Stephen Best

  • Guest
Editing in AdobeRGB, converting to sRGB
« Reply #23 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.
Logged

Stephen Best

  • Guest
Editing in AdobeRGB, converting to sRGB
« Reply #24 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 :-).
Logged

bjanes

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 3387
Editing in AdobeRGB, converting to sRGB
« Reply #25 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
Logged

Stephen Best

  • Guest
Editing in AdobeRGB, converting to sRGB
« Reply #26 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.
Logged

Jonathan Wienke

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 5829
    • http://visual-vacations.com/
Editing in AdobeRGB, converting to sRGB
« Reply #27 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 and River Hybrid. 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.
Logged

Jack Flesher

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2592
    • www.getdpi.com
Editing in AdobeRGB, converting to sRGB
« Reply #28 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.
« Last Edit: July 11, 2006, 02:04:00 pm by Jack Flesher »
Logged
Jack
[url=http://forum.getdpi.com/forum/

Dennis

  • Jr. Member
  • **
  • Offline Offline
  • Posts: 82
Editing in AdobeRGB, converting to sRGB
« Reply #29 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.
Logged
Best Regards

Dennis.

bjanes

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 3387
Editing in AdobeRGB, converting to sRGB
« Reply #30 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?
Logged

Stephen Best

  • Guest
Editing in AdobeRGB, converting to sRGB
« Reply #31 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.
« Last Edit: July 12, 2006, 02:48:54 am by Stephen Best »
Logged
Pages: 1 [2]   Go Up