Ad
Ad
Ad
Pages: [1] 2 3 »   Bottom of Page
Print
Author Topic: RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?  (Read 13863 times)
Jon Wiles
Newbie
*
Offline Offline

Posts: 4


« on: May 22, 2009, 11:04:50 AM »
ReplyReply

This is my first post to this forum. Any help and advice would be gratefully received over a problem to which I am in need of some input to decide on the best solution.

Am I correct in assuming that the Adobe98 gamma of 2.2 (or I am told more correctly a Tonal Responce Curve or TRC for short) and AppleRGB gamma of 1.8 has nothing to do with Windows monitor gamma of 2.2 and the Mac’s gamma of 1.8, after all the whole point of a work space is that it is device independent?

Am I also right to assume that in a colour managed work flow the monitors gamma is taken care of by its respective profile. So the question is why then in a 'closed' colour managed work flow do most RGB work spaces tend to either have a TRC of 1.8 or 2.2?

In our own work flow we edit allot of greyscale files for prepress in Photoshop. The dot gain is set to 0% for the editing. Once we know which press we are going use for the print run the file is then converted to this presses profile (which has the appropriate dot gain) before output to film.  Because the RGB work space TRC is also applied to the greyscale space a 50% tint does not give a 50% K reading as one might expect in a greyscale space with 0% dot gain. To achieve this the TRC would have to be set to 1.0. Is this to be recommended, after all for the purposes of editing there is no expansion or compression of the ¼ and ¾ tones?

 The only reason I can see for a Tonal Response Curve is if an accurate 50% halftone dot does not perceptually result in a 50% tone. If this is the case then why not use a L*TRC  which is perceptually correct as some RGB work spaces do? However since the LAB colour model was formulated under precise viewing conditions I would suggest that exactly how that halftone dot is perceived by the eye depends of many differing factors all the way from the observer to the white point of the substrate that has actually been printed, in which case a different Tonal Response Curve may well be need for each output profile.  If this is the case then where is the device independence of the RGB workspace?

So which TRC should I be using?

Thanks

Jon
Logged
Jonathan Wienke
Sr. Member
****
Offline Offline

Posts: 5759



WWW
« Reply #1 on: May 22, 2009, 11:56:04 AM »
ReplyReply

2.2 is closest to the average native TRC of monitors (including all of Apple's monitors since 1990 or so), 1.8 is closer to the average native TRC of printers. With 8-bit image files, matching the TRC of the image space to the TRC of the output device space reduces banding and posterization artifacts. With 16-bit image files, this isn't really an issue. I use ProPhoto as my editing space, not so much because it has a gamma 1.8 TRC, but because it has the widest gamut of the industry-standard RGB spaces. I also do all editing in 16-bit mode.
Logged

tho_mas
Sr. Member
****
Offline Offline

Posts: 1692


« Reply #2 on: May 22, 2009, 03:19:31 PM »
ReplyReply

Quote from: Jon Wiles
(...)
Maybe I did get the question wrong...
Monitors (CRT monitors) have a Gamma of (~) 2.2. Though obslolet for TFT monitors they are still set to Gamma 2.2 as their "parents".
Printers produce tonal curves similar to Gamma 1.8. In this sense Gamma 2.2 and Gamma 1.8 are device dependent.
The TRC L* in ECI-RGB V2 and ProStarRGB is visual equidistant - while Gamma 2.2 differentiates better in dark tonal values and Gamma 1.8. differentiates better in in bright tonal values the TRC L* differentiates equal all over the grey axis.
[attachment=13908:l1.jpg]
[attachment=13909:l2.jpg]
origin: http://www.colormanagement.org/download_fi...king-Spaces.zip (German)
Quote
(...) in which case a different Tonal Response Curve may well be need for each output profile. If this is the case then where is the device independence of the RGB workspace?
As there is no device with a TRC L* the working spaces with TRC L* are device independent - they store the data in a TRC that is the same as in Lab, which is the PCS in colour conversion. Instead of creating files with regard to a certain output and its dispersion of luminance you create files with a dispersion of luminance that is close to the human perception [and that is represented in Lab with an equidistant TRC form L=0 (black) to L=100 (white)]
In a colour managed envirenment the TRCs of the profiles are calculated against each other: you simply convert from your device independent working space with TRC L* to a certain output profile. The trick with TRC L* here is that it reduces quantization errors in colour space conversions (which is especially helpful in 8bit workflows).

I'd say you should use a working space with TRC L*. To profit from the L* workflow your display should be calibrated to L* as well (but this is only a good idea if you have a display that provides hardware calibration).

http://www.colormanagement.org/en/workingspaces.html
http://www.cdiny.com/color_profiles.html
« Last Edit: May 22, 2009, 03:23:29 PM by tho_mas » Logged
Czornyj
Sr. Member
****
Offline Offline

Posts: 1304



WWW
« Reply #3 on: May 22, 2009, 04:03:08 PM »
ReplyReply

Quote from: tho_mas
I'd say you should use a working space with TRC L*. To profit from the L* workflow your display should be calibrated to L* as well (but this is only a good idea if you have a display that provides hardware calibration).

...and if you have a RAW converter, that is rendering the images to L* based editing spaces - for some mysterious reason Adobe is limiting the choice of editing spaces in ACR and LR...
« Last Edit: May 22, 2009, 04:17:33 PM by Czornyj » Logged

Marcin Kałuża
tho_mas
Sr. Member
****
Offline Offline

Posts: 1692


« Reply #4 on: May 22, 2009, 04:28:20 PM »
ReplyReply

Quote from: Czornyj
...and if you have a RAW converter, that is rendering the images to L* based editing spaces - for some mysterious reason Adobe is limiting the choice of editing spaces in ACR and LR...
well, yes... and if you have a smart RAW-converter with suitable colour management options ;-)
Logged
Jon Wiles
Newbie
*
Offline Offline

Posts: 4


« Reply #5 on: May 28, 2009, 01:29:26 PM »
ReplyReply

Thanks for the replies; they are greatly appreciated along with the links. My apologies for the delay in following this up – had a few problems logging back into the forum!

To be honest I am still a bit confused here. So to easy my muddled state can we take it in short easy steps:

Question 1 - starting with the display: If a display is manufactured with a gamma of lets say 2.2 then the display profile needs to apply a gamma correction curve of 2.2 – net result the display will have a linear response. Is this correct?

Question 2: The AppleRGB TRC of 1.8 and Adobe 98 TRC of 2.2 do not affect the display profile. Is this correct?

Question 3 - working in Photoshop: The TRC of an RGB workspace is applied to greyscale files.- If I open a greyscale file with a dot gain profile of x% and output this to print on a press also with a dot gain of x% then (in theory) my print should match what is shown on the display whether the TRC is L* 1.0 or 2.2 So why do I even need a TRC??  Why not just set it to 1.0

Question 4: With a RGB workspace TRC of 1.0 if I select a 50% K tint from the photoshop color picker (HSB 0,0,50) in a greyscale file with a dot gain of 10% then I can understand why the eye dropper tool will actually read nearer a 40%K tint whilst  look on screen like a 50% tint – it is compensating for the dot gain of the press and when printed will look correct. So far it makes perfect sense. What is confusing me is the effect that any TRC greater than 1.0 has. It will increase the 40% tint. It is as though the TRC and dot gain curve are working against each. Why is this increase against the dot gain needed; aren’t two curves working against each other counter intuitive?

Thanks.

Jon
Logged
tho_mas
Sr. Member
****
Offline Offline

Posts: 1692


« Reply #6 on: May 30, 2009, 06:58:23 PM »
ReplyReply

Quote from: Jon Wiles
If a display is manufactured with a gamma of lets say 2.2 then the display profile needs to apply a gamma correction curve of 2.2 – net result the display will have a linear response. Is this correct?
yes

Quote
The AppleRGB TRC of 1.8 and Adobe 98 TRC of 2.2 do not affect the display profile. Is this correct?
yes. your display is set to a certain TRC and the TRC of the document profiles are translated to the monitor TRC (in effect the document profile is converted relative colormetric to the monitor profile).

Quote
If I open a greyscale file with a dot gain profile of x% and output this to print on a press also with a dot gain of x% then (in theory) my print should match what is shown on the display whether the TRC is L* 1.0 or 2.2
in theory: yes. in practice the contrast of the different media is the problem here. this is why you should set the softproof with simulation of "black ink" selected ("black ink" is actually the BPC for the monitor preview. The simulation of paper white is a very different and very tricky thing).

Quote
So why do I even need a TRC??  Why not just set it to 1.0
monitors (with backlight) are very different from print media. Look at the greyscales posted above: with gamma 1.0 you couldn't differentiate in dark tonal values. (And printers differentiate better in dark tonal vlaues, too, as they mostly produce a TRC similar to Gamma 1.Cool.

Quote
What is confusing me is the effect that any TRC greater than 1.0 has. It will increase the 40% tint. It is as though the TRC and dot gain curve are working against each. Why is this increase against the dot gain needed; aren’t two curves working against each other counter intuitive?
can't comment on this as I am not qualified for CMYK printing.
« Last Edit: May 30, 2009, 07:34:30 PM by tho_mas » Logged
Czornyj
Sr. Member
****
Offline Offline

Posts: 1304



WWW
« Reply #7 on: May 31, 2009, 06:53:52 AM »
ReplyReply

Quote from: Jon Wiles
Question 4: With a RGB workspace TRC of 1.0 if I select a 50% K tint from the photoshop color picker (HSB 0,0,50) in a greyscale file with a dot gain of 10% then I can understand why the eye dropper tool will actually read nearer a 40%K tint whilst  look on screen like a 50% tint – it is compensating for the dot gain of the press and when printed will look correct. So far it makes perfect sense. What is confusing me is the effect that any TRC greater than 1.0 has. It will increase the 40% tint. It is as though the TRC and dot gain curve are working against each. Why is this increase against the dot gain needed; aren’t two curves working against each other counter intuitive?

Thanks.

Jon

TRC of your panel doesn't (almost) matter at all. CMS reads the TRC of the image, TRC of the display and TRC of the CMYK output device, and it converts it while displaying or printing, so no matter how you'll calibrate your screen you'll see the image in the same way, and you'll get same results from the CMYK otuput device/offset press.
It's only optimal to calibrate the display to a TRC that is same or similar to the TRC of your editing space and TRC of your output device - the displayed image is only 8 bit per component, so when it simulates the TRC of CMYK or RGB it may introduce some banding. If the TRC of CMYK or RGB editing space is closer to TRC of the display, then the banding is less visible, and if the TRC's are the same, there's no visible banding at all.
Logged

Marcin Kałuża
Jon Wiles
Newbie
*
Offline Offline

Posts: 4


« Reply #8 on: June 01, 2009, 06:30:31 AM »
ReplyReply

Thanks Tho mas and Czornvi. I’m now a lot clearer about this.

So to summarise……  the RGB TRC has no effect on the monitors gamma and it dose not change the appearance or numbers of a greyscale image when it is opened, only when it is edited will the K values not behave as expected (ie in a linerised manner), if the dot gain profile does not match the working space RGB TRC - but then hey, what you see is what you get.

Following on from this Photoshop comes with three gray space profiles, sGray, Gamma 1.8 and Gamma 2.2 It would seem that these are actually the inverse curves, net result use sGrey with sRGB = linerised gray, Gamma1.8 with any RGB workspace with a TRC of 1.8 = linerized gray, and the same for the 2.2 gamma.

Tho mas I am definitely leaning towards your way of thinking with your suggestion of using an RGB space with L* TRC, eg eciRGBv2, if for no other reason than as you say there will be less errors in the numbers when converting profiles as the PCS uses L*a*b*. This of course now leads to another question.

Does anyone know where I can get a gray space profile with an L* curve (or more correctly if my assumptions are correct an inverse L* curve)? If not does anyone know the correct numbers to enter in the custom gray space gamma setup in Photoshop?

Also whilst on this whole gamma / TRC subject can anyone explain what effect the check box next to ‘Blend RGB Colors Using Gamma:’ (the default is set to 1.00) in the Photoshop colour settings has, and how does it work?

Thanks All for your posts.

Jon
Logged
bjanes
Sr. Member
****
Offline Offline

Posts: 2714



« Reply #9 on: June 01, 2009, 08:58:49 AM »
ReplyReply

Quote from: Czornyj
...and if you have a RAW converter, that is rendering the images to L* based editing spaces - for some mysterious reason Adobe is limiting the choice of editing spaces in ACR and LR...
If you want to use a L* space with images rendered by ACR, you should render the image into 16 bit ProPhotoRGB and then convert to an L* space, such as eciRGB_v2. Since the latter is not a wide gamut space, some saturation clipping can occur. A wide gamut L* space would avoid this clipping. If you stay in 16 bits, I don't think that the L* space would have any significant advantage, but it would provide better shadow gradation with an 8 bit file.
Logged
bjanes
Sr. Member
****
Offline Offline

Posts: 2714



« Reply #10 on: June 01, 2009, 09:16:34 AM »
ReplyReply

Quote from: Jon Wiles
Question 1 - starting with the display: If a display is manufactured with a gamma of lets say 2.2 then the display profile needs to apply a gamma correction curve of 2.2 – net result the display will have a linear response. Is this correct?

That is approximately correct. sRGB and most other gamma based color spaces do not use a straight gamma curve, but rather use a linear segment and sometimes an offset for the shadows (see the Pointon Gamma FAQ, Section 6). With a straight gamma curve, zero luminance would result in a curve whose slope is infinite. When converting from the raw file to a gamma 2.2 encoded space, an exponent of 1/2.2 is applied, and an exponent of 2.2 is used when going from the gamma encoded file to the output. The idealized monitor inverts the transform, resulting in a linear response, as you mention.
Logged
tho_mas
Sr. Member
****
Offline Offline

Posts: 1692


« Reply #11 on: June 01, 2009, 09:46:50 AM »
ReplyReply

Quote from: Jon Wiles
Does anyone know where I can get a gray space profile with an L* curve (or more correctly if my assumptions are correct an inverse L* curve)? If not does anyone know the correct numbers to enter in the custom gray space gamma setup in Photoshop?
I think there is a misunderstanding regarding the "inversed" curve you talk about. In the process you create a file in L*. Period. As your monitor is calibrated to L* as well there are no further corrections applied (and if so this would just affect the viewing on the display!). Period.
From your working space (preferably ECI-RGB V2 rather than ProStarRGB) you convert to a certain printer profile and the dot gain is translated (depending on the real process you may have to edit the dot gain manually but in theory you just convert from ECI-RGB V2 to e.g. ISOcoatedV2).
here you'll find different profiles: http://colormanagement.org/de/isoprofile.html
there is the profile "ISOcoated_v2_grey1c_bas.ICC". this one is to convert to greyscale based on the fogra39 characterization data (don't know if you can use it in the US with success as the entire L* workflow and ISO profiles are adressed to the European print standards. ECI-RGB V2 and ISOcoatedV2 as well as the grey profile refer to each other). Just set this profile as greyscale for grey in the colour preferences.
Logged
tho_mas
Sr. Member
****
Offline Offline

Posts: 1692


« Reply #12 on: June 01, 2009, 09:53:20 AM »
ReplyReply

Quote from: bjanes
Since the latter is not a wide gamut space, some saturation clipping can occur. A wide gamut L* space would avoid this clipping.
I've posted the ProStar profile above. But I'd recommend to use ProStar (ProPhoto) for RGB workflows only. ECI RGB V2 execeeds the gamut of any CMYK printer ... this is what ECI-RGB is all about.
« Last Edit: June 01, 2009, 09:54:22 AM by tho_mas » Logged
bjanes
Sr. Member
****
Offline Offline

Posts: 2714



« Reply #13 on: June 01, 2009, 10:33:04 AM »
ReplyReply

Quote from: tho_mas
I've posted the ProStar profile above. But I'd recommend to use ProStar (ProPhoto) for RGB workflows only. ECI RGB V2 execeeds the gamut of any CMYK printer ... this is what ECI-RGB is all about.

If one is using a 16 bit workflow, do you see any advantages of ProStar over ProPhotoRGB, and if so, what are they? Even though ECI_RGB_V2 exceeds the gamut of any CMYK printer, there could be problems if the gamut of the image exceeds the gamut of ECI_RGB_V2. In this case there could be clipping of the out of gamut colors unless the rendering is adjusted according to some type of perceptual rendering that remaps the out of gamut colors into the gamut of the ECI_RGB_V2 space. IMHO, it would be preferable to capture the entire gamut into a wider space and then use perceptual rendering or manual editing to take care of out of gamut colors.
Logged
tho_mas
Sr. Member
****
Offline Offline

Posts: 1692


« Reply #14 on: June 01, 2009, 10:55:33 AM »
ReplyReply

Quote from: bjanes
Even though ECI_RGB_V2 exceeds the gamut of any CMYK printer, there could be problems if the gamut of the image exceeds the gamut of ECI_RGB_V2.
before converting from ProPhoto to ECI-RGB one should edit the out of gamut colours.
Quote
IMHO, it would be preferable to capture the entire gamut into a wider space and then use perceptual rendering or manual editing to take care of out of gamut colors.
basically: yes. Safe all the colours the camera can capture in a suitable colour space (in ACR/Lightroom this is ProPhoto). For further conversion edit the out of gamut colours.
For the conversion ProPhoto to ECI perceptual RI is not an option as ECI is a matrix profile and as the common CMMs have no strategy to do perceptual conversions it's only possilble with table based profiles containing a table for the perceptual RI.
Given an Adobe workflow I would edit the RAW in ProPhoto, process to 16bit TIF and store this as "master". In a copy then edit the out of gamut colours (if there are any) and convert to ECI. The trick with ECI here is that when you convert from ECI with perceptual RI to one of the above linked CMYK profiles that this should work mostly without further editing.

Logged
bjanes
Sr. Member
****
Offline Offline

Posts: 2714



« Reply #15 on: June 01, 2009, 11:51:44 AM »
ReplyReply

Quote from: tho_mas
before converting from ProPhoto to ECI-RGB one should edit the out of gamut colours.
 basically: yes. Safe all the colours the camera can capture in a suitable colour space (in ACR/Lightroom this is ProPhoto). For further conversion edit the out of gamut colours.
For the conversion ProPhoto to ECI perceptual RI is not an option as ECI is a matrix profile and as the common CMMs have no strategy to do perceptual conversions it's only possilble with table based profiles containing a table for the perceptual RI.
Given an Adobe workflow I would edit the RAW in ProPhoto, process to 16bit TIF and store this as "master". In a copy then edit the out of gamut colours (if there are any) and convert to ECI. The trick with ECI here is that when you convert from ECI with perceptual RI to one of the above linked CMYK profiles that this should work mostly without further editing.

Yes, one could not use perceptual rendering in converting matrix profiles, but one could use perceptual rendering when printing from ProPhotoRGB using a printer profile which does have perceptual rendering tables. However, considering the limitations of current dumb perceptual rendering profiles, many users would prefer to use manual editing. My unanswered question is what advantage is there for an intermediate conversion to ECI-RGB?
Logged
tho_mas
Sr. Member
****
Offline Offline

Posts: 1692


« Reply #16 on: June 01, 2009, 12:18:53 PM »
ReplyReply

Quote from: bjanes
My unanswered question is what advantage is there for an intermediate conversion to ECI-RGB?
is ProPhoto looking appropriate to fit ISOcoatedV2??? (gamuts of ProPhoto, ECI, ISOcoatedV2)
[attachment=14211:gamut.jpg]
Again: ECI-RGB V2 and the ISO CMYK profiles are well-matched. With ECI you will mostly have perfect results when converting perceptual to the ISO printer profiles (without further editing).
Conterquestion: what is the advantage of a colour space containing much more colours than you will ever need (and in addition imaginary colours) when the target is CMYK printing? There is nothing wrong with ProPhoto as editing and archive colour space when you start with a raw file. But when it comes to CMYK printing I think it's useful to change to something more handy.... otherwise you start editing from scratch when you want to convert form ProPhoto to such small CMYK profiles. Except if the colours actually used in ProPhoto are all little saturated. But in this case the question is: why use ProPhoto when you don't need the high saturated colours?
« Last Edit: June 01, 2009, 12:19:38 PM by tho_mas » Logged
bjanes
Sr. Member
****
Offline Offline

Posts: 2714



« Reply #17 on: June 01, 2009, 12:44:02 PM »
ReplyReply

Quote from: tho_mas
is ProPhoto looking appropriate to fit ISOcoatedV2??? (gamuts of ProPhoto, ECI, ISOcoatedV2)
[attachment=14211:gamut.jpg]
Again: ECI-RGB V2 and the ISO CMYK profiles are well-matched. With ECI you will mostly have perfect results when converting perceptual to the ISO printer profiles (without further editing).
Conterquestion: what is the advantage of a colour space containing much more colours than you will ever need (and in addition imaginary colours) when the target is CMYK printing? There is nothing wrong with ProPhoto as editing and archive colour space when you start with a raw file. But when it comes to CMYK printing I think it's useful to change to something more handy.... otherwise you start editing from scratch when you want to convert form ProPhoto to such small CMYK profiles. Except if the colours actually used in ProPhoto are all little saturated. But in this case the question is: why use ProPhoto when you don't need the high saturated colours?

When working with a limited gamut, there would be no advantage in using a wide gamut space. However, when working with a bit depth of 16, there is little disadvantage of using a wider space if you use sensible editing. However, careless editing of a wide gamut space could produce imaginary colors and lead to problems. When using ACR with the supported color spaces, it is easy to determine if clipping is occurring, in which case one can use a wider space. However, if you convert from a wide to narrower space using colorimetric rendering, clipping without warning may occur. One could use soft proofing or gamut mapping software to detect clipping, but then you would have to re-render the image into a larger space.  If you do not know the gamut of the image in advance, a wide space is a good general purpose solution.

Readers may find this old thread of interest. It quotes from an interesting European paper on Museum Imaging using an L-star TRC. L* is primarily a European initiative, and does not appear to have caught on in the USA. In the above thread, the American Guru, Andrew Rodney, doubted the utility of the L* TRC, perhaps a case of Not Invented Here thinking. Personally, I don't do any CMYK printing, and would use the ProStar space if it were available directly from ACR, which is my default raw converter.
Logged
tho_mas
Sr. Member
****
Offline Offline

Posts: 1692


« Reply #18 on: June 01, 2009, 01:01:29 PM »
ReplyReply

Quote from: bjanes
If you do not know the gamut of the image in advance, a wide space is a good general purpose solution.
absolutely - no objection! But basically I do not see any advantage in having no choice (in camera raw you actually have no choice). I prefer to have the choice as e.g. in Capture One. In C1 I can convert to all RGB or CMYK colour spaces right from the RAW file. But that was not the topic here...
Yes, L* with its visual equidistant dispersion of luminance actually is a good thing for photographers. Problem here is that you need a calibration software that supports L* accurate (e.g. Eizos Color Navigator does not). When calibrating with BasICColor Display ("Color Eyes" in the US) I have some banding in dark tonal values though my display has a 12bit LUT. So I stick with Gamma 1.8 (with Color Navigator).
Logged
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6767


WWW
« Reply #19 on: June 01, 2009, 04:01:09 PM »
ReplyReply

Quote from: tho_mas
absolutely - no objection! But basically I do not see any advantage in having no choice (in camera raw you actually have no choice). I prefer to have the choice as e.g. in Capture One. In C1 I can convert to all RGB or CMYK colour spaces right from the RAW file. But that was not the topic here...
Yes, L* with its visual equidistant dispersion of luminance actually is a good thing for photographers. Problem here is that you need a calibration software that supports L* accurate (e.g. Eizos Color Navigator does not). When calibrating with BasICColor Display ("Color Eyes" in the US) I have some banding in dark tonal values though my display has a 12bit LUT. So I stick with Gamma 1.8 (with Color Navigator).

I use ColorEyes Display with L* and I have no banding problem whatsoever. My display is a LaCie 321.

As long as the colour gamut of a raw file exceeds the colour gamut of a CMYK printer, some kind of gamut compression needs to occur somewhere along the processing pipeline. Anyone who thinks they may ever multi-purpose a file should retain their master copy in ProPhoto and make copies for conversion to narrower colour spaces for other purposes, including pre-press. In that respect Bill Janes' earlier suggestions are sensible.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Pages: [1] 2 3 »   Top of Page
Print
Jump to:  

Ad
Ad
Ad