Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: Jon Wiles on May 22, 2009, 12:04:50 pm
-
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
-
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.
-
(...)
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 (http://www.colormanagement.org/download_files/Working-Spaces.zip) (German)
(...) 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.colormanagement.org/en/workingspaces.html)
http://www.cdiny.com/color_profiles.html (http://www.cdiny.com/color_profiles.html)
-
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...
-
...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 ;-)
-
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
-
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
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).
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).
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.8).
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.
-
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.
-
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
-
...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 (http://www.eci.org/doku.php?id=en:colourstandards:workingcolorspaces). 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.
-
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 (http://www.poynton.com/PDFs/GammaFAQ.pdf), 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.
-
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 (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.
-
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.
-
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.
-
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.
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.
-
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?
-
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?
-
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 (http://luminous-landscape.com/forum/index.php?showtopic=24701&st=0) of interest. It quotes from an interesting European paper on Museum Imaging using an L-star TRC (http://www.cdiny.com/ArticlesWhitePapers/ISO%20Standards%20for%20Museum%20Imaging_cdi_v1.0.pdf). 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.
-
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).
-
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.
-
I use ColorEyes Display with L* and I have no banding problem whatsoever. My display is a LaCie 321.
lucky one :-)
I've got an Eizo CG241W. The banding when calibrating with BasICColor Display is only visible in technical gradations and it's minor. Anyway I prefer Gamma 1.8 as it is totally clean on my display.
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.
This is self-evident.
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.
Of course. That's what I do as well. I just don't use ProPhoto. I use the camera profiles of my camera. The gamuts of these profiles are of a size that all captured colours are stored but at the same time not bigger. They are ... accurate. With Camera Raw I would use ProPhoto as well.
-
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.
I have Nec 2190UXi (same display as LaCie 321) calibratet with SVII and there's also no problem with L*, as a matter of fact I get best results with L* calibration.
Eizo CG's are factory calibrated to gamma 2,2 - so maybe that's the reason they don't like L* gradation.
As for greyscale - when the display is L* calibrated, it's actually not a bad idea to work with L* greyscale profile. On the other hand - TRC of offset CMYK is not that similar to L* TRC, so if someone is prepareing greyscale images for offset press, it's better to use CMYK profile (just select yout CMYK space as your greyscale profile in Photoshop)
-
Eizo CG's are factory calibrated to gamma 2,2 - so maybe that's the reason they don't like L* gradation.
I agree.
As for greyscale - when the display is L* calibrated, it's actually not a bad idea to work with L* greyscale profile. On the other hand - TRC of offset CMYK is not that similar to L* TRC, so if someone is prepareing greyscale images for offset press, it's better to use CMYK profile (just select yout CMYK space as your greyscale profile in Photoshop)
In this particular case it is actually the same. The above mentioned greyscale profile is based on the ISOcoatedV2 profile. So if you set ISOcoatedV2 as your CMYK colour space the respective greyscale profile is exactly made to be set as greyscale profile in Photoshop (see documentation at colormagement.org).
-
- 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?
Yes, in the first order, "gamma" is invisible in a color-managed environment. The luminance levels on screen go linear with the RGB numbers of a grayscale in any linear gamma working/matrix space.
But then there are second order aspects such as to avoid banding issues, or, to have a reasonable appearance in non-color-managed apps.
FWIW, I have always made good experience using the sRGB TRC as the target for calibration
(Windows OS, different notebook and TFT screens).
With a new monitor, my first exercise is to study the uncalibrated R/G/B response curves,
to compare it against different target "gamma" and to look for a closest match from the beginning.
So there’s probably no general rule, however, often enough:
a regular 2.2 gamma appears to be too flat (-> steep) in the shadows, whereas the sRGB or L* TRC are closer to the native state. In the lights, the L* curve tends to drops off due to its higher local gamma.
In a nutshell, the idea is to get a best possible alignment of the calibrated R/G/B curves with the target "gamma", while only imposing minimum calibration work onto the video card.
Peter
--
-
In this particular case it is actually the same. The above mentioned greyscale profile is based on the ISOcoatedV2 profile.
Just as long as you print on sheetfed offset press, coated paper, and use periodic screening. There are different CMYK profiles for different papers, screenings, and offset presses.
-
Just as long as you print on sheetfed offset press, coated paper, and use periodic screening. There are different CMYK profiles for different papers, screenings, and offset presses.
sure. It's just about the default in the colour preferences. If you decide to set ISOcoatedV2 (BCC) (for glossy or matte coated papers type 1+2) as default in your colour preferences you may also set the respective grey profile as greyscale profile in the colour prefs. If something else is needed you set it manually or just safe a different set in the colour prefs.
-
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?
Correct. To be exact, its Quasi-Device Independent (no RGB color spaces are purely device independent).
Select a working space based on the capture, archive and output needs, not the TRC.
http://www.adobe.com/digitalimag/pdfs/phscs2ip_colspace.pdf (http://www.adobe.com/digitalimag/pdfs/phscs2ip_colspace.pdf)
-
...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...
In LR, you can export to any RGB space you have a profile for. As for true editing space, its all linear encoded ProPhoto primaries in both products.
-
L* is the "rage" for some (many in Europe). But many in the US are asking for some concrete examples of the benefits in some kind of white paper or with empirical data that shows an advantage. This was discussed in length on the ColorSync list last year. One of the most useful posts was from Lars Borg the chief color scientist at Adobe:
L* is great if you're making copies. However, in most other
scenarios, L* out is vastly different from L* in. And when L* out is
different from L* in, an L* encoding is very inappropriate as
illustrated below.
Let me provide an example for video. Let's say you have a Macbeth
chart. On set, the six gray patches would measure around L* 96, 81,
66, 51, 36, 21.
Assuming the camera is Rec.709 compliant, using a 16-235 digital
encoding, and the camera is set for the exposure of the Macbeth
chart, the video RGB values would be 224,183,145,109,76,46.
On a reference HD TV monitor they should reproduce at L* 95.5, 78.7,
62.2, 45.8, 29.6, 13.6.
If say 2% flare is present on the monitor (for example at home), the
projected values would be different again, here: 96.3, 79.9, 63.8,
48.4, 34.1, 22.5.
As you can see, L* out is clearly not the same as L* in.
Except for copiers, a system gamma greater than 1 is a required
feature for image reproduction systems aiming to please human eyes.
For example, film still photography has a much higher system gamma
than video.
Now, if you want an L* encoding for the video, which set of values
would you use:
96, 81, 66, 51, 36, 21 or
95.5, 78.7, 62.2, 45.8, 29.6, 13.6?
Either is wrong, when used in the wrong context.
If I need to restore the scene colorimetry for visual effects work, I
need 96, 81, 66, 51, 36, 21.
If I need to re-encode the HD TV monitor image for another device,
say a DVD, I need 95.5, 78.7, 62.2, 45.8, 29.6, 13.6.
In this context, using an L* encoding would be utterly confusing due
to the lack of common values for the same patches. (Like using US
Dollars in Canada.)
Video solves this by not encoding in L*. (Admittedly, video encoding
is still somewhat confusing. Ask Charles Poynton.)
When cameras, video encoders, DVDs, computer displays, TV monitors,
DLPs, printers, etc., are not used for making exact copies, but
rather for the more common purpose of pleasing rendering, the L*
encoding is inappropriate as it will be a main source of confusion.
Are you planning to encode CMYK in L*, too?
Lars
Color Geek Chris Murphy had this to say about the proposal to make L* an ISO Spec (and the request for proof of concept):
On 3/11/08 7:16 AM, "Jan-Peter Homann" <homann at colormanagement.de>
wrote:
The idea behind L* based RGBworkingspaces is a perceptual uniform
encoding of ligthness.
I believe Wyszecki & Stiles state that L*a*b* is an approximately
uniform color space. I don't know that they'd suggest it is
perceptually uniform. So out of the gate there is at least some
recognition that it might not be ideal or exact. The question then is,
if it's not, is that a problem? Or can it be ignored? And that depends
on the context of its usage.
As the profile connection space between ICC profiles is mostly Lab
(for LUT-profiles...), profile conversion from an L* based
workingspace to the PCS and from there to an L* calibrated output
device will avoid unnecessary tonal conversions, especially for 8-
Bit data.
Yes but even eciRGBv2, with L* based tone reproduction curve (TRC),
uses an XYZ PCS. I think it's been demonstrated for practical purposes
that as these conversions all occur through a minimum of 16bpc
precision that the tone reproduction curve of the PCS is not relevant.
In practice this bears out by the fact we have non-trivial processing
and editing occurring in real world situations where the TRC is
linear, not based on L*.
Depending on the CMM the data may be converted through XYZ and or LAB,
or it may go directly from source space to destination space, not
actually be converted into the PCS color space at all.
In practice, input devices, output devices, and display devices do not
have a tone response curve described by an L* function. Could they be
compelled to have a natural TRC defined by L*, by inherent design? I'm
not an engineer. They behave the way they behave, and that isn't
described by L*. If we compel them to do otherwise, there is loss of
levels to coerce them away from their natural behavior in favor of a
different TRC. It's easy to quantify these loss mathematically. It's
perhaps not as easy to quantify it in visual terms, as human vision
can be quite tolerant with loss of tonality. Up to a point.
We have now several vendors of high-end monitors and high end
monitor calibration / profiling solutions offering L* based monitor-
calibration, which are used in eciRGBv2 workflows especially in
Germany in the area of post production for photography and prepress.
Such displays have sufficient precision in internal LUTs to compel
their TRC to be defined with a complex function such as L* rather than
a simple gamma function. I don't see a problem with this, although I
have yet to read of a compelling case for it. The benefit of doing so
is unproven.
Unless the press condition is also defined by L* there will be loss of
levels from source to destination. It's another matter if this is a
problem visually. But the advocates of L* based workflows have yet to
present any information that demonstrates the advantages or
disadvantages of such a workflow.
Further, the ECI web site contradicts itself. On the one hand it says:
"The focus of the eciRGB_v2 profile still is on the print and
publishing industry"
but then says
"In general, ECI now recommends to always use the eciRGB_v2 profile
for new projects or when creating new data. This is especially true
when converting from RAW data or from 16 bit image data."
1. The print and publishing industries are clearly 8bpc predominant
workflows. They are not 16bpc workflows.
2. Why, in the fact of it being focused on print and publishing
industries, is eciRGBv2 especially applicable to high-bit imagery? Why
does encoding matter at all with high-bit data?
They created also L* based version of the ProPhotoRGB called
ProStarRGB.
Well on the face of it I find it ridiculous for several reasons:
1. It ignores the origin of ProPhoto RGB being ROMM. This is an output
centric color space. It is not an input centric color space. For that
we should be looking to RIMM or ERIMM or scRGB or what OpenEXR uses or
other.
2. Kodak had some explicit reasons for deciding upon the tone
reproduction curve for ROMM, and it had to do with reversibility.
Since it is an intermediate color space, we have images that are
converted into that space and out of that space. The ROMM non-
linearity, strictly speaking is not defined by a gamma 1.8 function.
But at the time, due to a limitation in Photoshop where a LUT based
editing space could not be defined, they went with a two part
solution. First the ICC profile established the TRC with a gamma 1.8
function, and second the CMM used a limiting function to deal with
loss at the dark end when the curve is inverted.
The L* function, in particular in an 8bpc context, is a more complex
curve and is more aggressive than a gamma 1.8 or gamma 2.2 function,
depending where you are on the curve. Now I don't know that this is a
problem, but have any of the advocates bothered to investigate it? And
what did they find? I haven't read any data indicating even a modicum
of serious scrutiny to its proposal.
3. ProPhoto RGB, while it has an 8bpc implementation, it is considered
best practices to have a 16bpc workflow when using ProPhoto RGB. In
that context, again, why do we care about encoding? Why is the
definition of the TRC important, within obviously reasonable limits?
Does it really matter when we're talking about 16bpc?
So if the advantage to L* is in an 8bpc context, how is it relevant in
a 16bpc context, if at all? Who is advocating an 8bpc "ProStarRGB"
workflow? Anyone? If not, what is the point of changing the TRC?
What's the advantage? What is made simpler? What is made faster? What
are the alternatives to having yet another flavor of the day editing
space?
A strong opinion against L* based workingspaces and outputput
calibration comes from the well known color expert Chris Murphy. He
states, that the "native Gamma" or native tone reproduction curve of
printing processes is better represented by a Gamma of 1,8 and not
of L*. But till today, he has not pointed to scientific research, to
verify this statement.
It is considered conventional wisdom. That conventional wisdom may be
mistaken, but it is present nevertheless. Even in the document you
have cited in your post states this conventional wisdom:
"Apple®, on the other hand adopted a display gamma function of 1.8 in
an attempt to drive the display closer to the gamma of printed
material. This decision is probably why Apple® Macintosh™ computers
became so prevalent in print production."
It is not my burden to point to scientific research when it comes to
conventional wisdom. The advocates of L* based workflows have that
burden. And so far it has fallen completely flat. And that is why I
say it is uncompelling.
It is false to suggest that I'm against someone doing the necessary
work to demonstrate it's possible usefulness. I just having seen a
compelling explanation.
Have any of the questions I've asked on several lists, including this
very posting, been asked by the proponents of L* based workflows? What
were the answers to those questions? Where is the data? What were the
test parameters? What was the metric for success? Under what
conditions is there improvement in quality? Under what conditions was
there a reduction in quality? What were the conditions? What
equipment? What alternatives were explored? What were the results?
My personal view on this topic: The L* based concept for an RGB
workingspace makes the most sense, if we have also L* based monitor-
AND printer calibration.
Why does that make more sense than matching TRC's at the front end and
back end of the workflow, which has been done since the early 1990's?
Why and how is this new idea better?
So I think the initiative for ProStarRGB makes a lot sense and
should be integrated into ISO 22028 We still need more research
about the native tone reproduction curves of printing processes like
e.g. ISO 12647-2 / FOGRA-data, G7, standard inkjet drivers, or
standard settings of digital printing systems.
Well I would suggest more research first before advocating something
that changes people's workflows, let alone than also as an ISO
standard. Otherwise you're putting the cart before the horse. Let's
demonstrate the benefits first.
I think in digital imaging we have other things to be more concerned
about. In particular in the photography and museum markets, the issues
are well beyond L*. L*a*b* is by definition based on relative
luminance and this is not exactly helpful when it comes to describing
scene-referred data, let alone HDR imagery.
It is interesting to note that Microsoft's WCS implementation makes no
use of L*a*b* whatsoever. Its device profiles are XYZ based, and then
on top of that they have implemented CIECAM02. So their mapping all
depends on JCh. Not L*a*b*. Now, regardless of other issues regarding
Microsoft and WCS, I think everyone understands that the color
scientists and engineers who worked on WCS, are quite competent
individuals. I find the lack of dependency on L*a*b* relevant to
point out because there are aspects of WCS that I would like to see
adopted as we move forward.
Best regards,
Chris Murphy
The entire series of posts are on the ColorSync Archives for those that want to go further into the "debate".
-
Thanks to all who have contributed. It makes for some very interesting reading. The link from the digitaldog to the colspacepdf addresses my original questions and is an excellent read for anyone interested.
I think there is a misunderstanding regarding the "inversed" curve you talk about.
tho_mas, it would seem that I do indeed have a fundamental misunderstanding.
I referred to it as an ‘inverse curve’ as there seems to be a strange relationship between the RGB workspace gamma (TRC) and the Grey workspace gamma; reading from the numbers in the Photoshop info pallet, changing the gamma of one space affects editing in the other and visa versa, eg:
Case 1 Workspace Color Settings: RGB Gamma 2.2 , Grey Space Gamma 2.2
Applying 50% K brush results in 50% tint in a new RGB file and a 50% tint in a new Grayscale file.
Case 2 Workspace Color Settings: RGB Gamma 1.0, Grey Space Gamma 2.2
Applying 50% K brush results in 27% tint in a new RGB file AND a 27% tint in a new Grayscale file despite the gamma setting of the Greyscale workspace being the same as in Case 1!
Case 3 Workspace Color settings: RGB Gamma 2.2, Greys Space Gamma 1.0 (or Dot Gain 0%)
Applying 50% K brush results in 78% tint in a new Grayscale file AND a 78% tint in a new RGB file despite the gamma setting of the RGB workspace being the same as in Case 1!
I’m sure there is a very good reason why RGb and Grey work spaces are linked in this way (although it seems counter intuitive) but I do not know what it is and can’t figure it out. If it has already been answered in this thread then I missed it.
Can anyone provide the reason?
Thanks
Jon
-
L* is the "rage" for some (many in Europe). But many in the US are asking for some concrete examples of the benefits in some kind of white paper or with empirical data that shows an advantage.
Not precisely L*, however, Joseph Holmes is located in California
http://www.josephholmes.com/propages/AboutRGBSpaces.html (http://www.josephholmes.com/propages/AboutRGBSpaces.html)
Peter
--
-
Not precisely L*, however, Joseph Holmes is located in California
http://www.josephholmes.com/propages/AboutRGBSpaces.html (http://www.josephholmes.com/propages/AboutRGBSpaces.html)
Peter
--
Yes he is, so what? I think I was clear in my quote above using "some" in Europe and "many" in the US don't imply every human in either location. Doesn't change the facts a lick.
-
Yes he is, so what? I think I was clear in my quote above using "some" in Europe and "many" in the US don't imply every human in either location. Doesn't change the facts a lick.
Thanks for the quick response, but the recommendation was to read Joe's site.
-
Thanks for the quick response, but the recommendation was to read Joe's site.
It still doesn't show any empirical advantage. The problem with L* is that it looks good on paper, but no one cares to elaborate some real life proofs of it's superiority.
-
It still doesn't show any empirical advantage. The problem with L* is that it looks good on paper, but no one cares to elaborate some real life proofs of it's superiority.
Black Point setting in a regular 2.2 gamma space - or less pronounced in a 1.8 gamma space- is prone to posterize the shadows as well as to violate Color integrity. Not so with working spaces featuring an L* or sRGB TRC. This part of the story at least can be nicely shown, illustrated and calculated. Seems we are repeating earlier discussions (http://luminous-landscape.com/forum/index.php?showtopic=24701&st=20) (going back to 2005 in the RG forums).
Perhaps less relevant now, while we do such fundamental moves in the Raw converter i.e. LR/ACR which bears an internal linear gamma working space, and we’ve all seen the documentation on its merits. Keep in mind that I don’t have to sell anything to you, neither a book nor a L* philosophy
Peter
--
-
Black Point setting in a regular 2.2 gamma space - or less pronounced in a 1.8 gamma space- is prone to posterize the shadows as well as to violate Color integrity. Not so with working spaces featuring an L* or sRGB TRC. This part of the story at least can be nicely shown, illustrated and calculated. Seems we are repeating earlier discussions (http://luminous-landscape.com/forum/index.php?showtopic=24701&st=20) (going back to 2005 in the RG forums).
Perhaps less relevant now, while we do such fundamental moves in the Raw converter i.e. LR/ACR which bears an internal linear gamma working space, and we’ve all seen the documentation on its merits. Keep in mind that I don’t have to sell anything to you, neither a book nor a L* philosophy
Peter
--
I'm not a colors scientist, so correct me if I'm wrong - L* is good as long as we stay in synthetic RGB editing space, but what if we convert our image to output device color space? Offset presses and printers are not L* linearized. My personal question is - would there be any benefit of using L* editing space in an offset CMYK workflow? It's easy to imagine, that a L* space rendered image on a L* calibrated display is quantized in the most efficient way, but I don't edit my images to watch them on a screen. There's nothing wrong about selling books or philosophies IMO, but I'd be glad to understand the philosophy or book content that I bought.
-
[!--quoteo(post=0:date=:name=Czornyj)--][div class=\'quotetop\']QUOTE (Czornyj)[div class=\'quotemain\'][!--quotec--]My personal question is - would there be any benefit of using L* editing space in an offset CMYK workflow?[/quote]
PMJI, but aren't there are other factors besides the (admittedly important) color accuracy aspects of working space choice?
It seems to me that for L* working spaces there would be an advantage in better usability of the editing tools in Photoshop. E.G., placing and moving points the Curves tool would have a uniform effect from the light end to the dark end of the scale. As it is, with for example a gamma 2.2 workspace, the curves are greatly more sensitive in the highlights than in the shadows, because there are so few RGB levels allocated to the highlights by gamma 2.2 encoding. Likewise, the perceptual midtone gray is NOT edited by a point placed in the center of the curves display.
Granted, most of us have learned to unconsciously adapt to this and can edit curves successfully, but nonetheless I would think that any editing tool dealing with tonal values would be improved if its editing interface actually reflected the way we perceive tones to be distributed from light to dark... i.e L*.
-
In practice what matters is being able to control the tonality of a certain area in the image, rather than picking out an arbitrary point like "percetual middle gray."
Consider looking at an area of an image, from a photographer's point of view. It's almost never helpful to ask the question, "is this area close to L* = 50 and therefore does that tell me where I should place points on my tone curve?" Instead, it's much more helpful to ask, "ok, here's how the tonality of that area looks now, and I want to lighten/darken it, so what's the tool that is going to allow me to do that most easily?" In Camera Raw, for instance, you can use cmd/ctrl-click directly on that area of the image to add control points to the Point Curve. Or in both CR/LR you can use the Target Adjustment Tool (TAT) directly on that area of the image to adjust the Parametric Curve (or Hue, Saturation, Lightness). Or if you want just a local adjustment to that area, without affecting other areas of the image of similar tone, you can use the local adjustment brush, again painting directly on the specific area of the image of interest.
To my mind, that is much more effective way of dealing with the practical photographic problems at hand.
-
To my mind, that is much more effective way of dealing with the practical photographic problems at hand.
That's right. But as to the practice let's take the practice of viewing into account. Why not set the display and the working space to a perceptual uniform luminosity? I'm not a printer nor a measurement device - viewing images as everything else in the world is not a bad idea. Too, it's not a bad idea that all tonal values all over the tonal range differentiate in the same way.
And if you use the levels or maybe presets like a classical linear "S" curve "Chas'" comment is quite right.
-
For the question of working space, it's very ambiguous exactly what is meant by L*, because it depends very much on the application.
You are presumably thinking in the context of Photoshop, where there is an explicit working space set up by the user in Color Settings, and the space stays that way till you dictate otherwise (e.g., convert to another working space, go to Lab edit mode, etc.). In that context, where PS is most commonly used to edit output-referred images, an L* encoding is fine -- certainly preferable to a linear encoding.
Camera Raw and LR are not like this. It has been said that CR/LR internally use a working space with the ProPhoto RGB primaries and a linear gamma. Yes, but that is only part of the story. CR/LR will also make temporary excursions to other color spaces (or at least make calculations / decisions based on results in other color spaces), depending on the image processing step involved. The interface that you see in CR/LR really translates to many internal processing steps, executed in various color spaces and encodings appropriate to the step involved. There are image processing steps for which an L* encoding works fine (neither better nor worse than a 2.2 or 1.8 gamma encoding, just different), and other steps for which an L* encoding is completely inappropriate.
-
You are presumably thinking in the context of Photoshop...
yes. I don't care about a linear or L* or whatever encoding of the RAW data. The digital capture at the first stage is non linear in any case. Either you translate it to Gamma 1.0, 1.8, 2.2 or TRC L* should be equal as long as this is calculated in 16bit. I see it just from the "user" side: I use a certain RAW converter and what it is doing under the roof I am not interessted in (well, a little bit). I am interessted in the further options such as to convert (process) to any profile I want or need. That's all. And as to the editing and viewing conditions I find L* rather useful (though I am using it rarely).