Pages: 1 [2] 3   Go Down

Author Topic: RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?  (Read 33999 times)

tho_mas

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1799
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #20 on: June 01, 2009, 05:21:24 pm »

Quote from: MarkDS
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.
Quote
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.
Quote
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.
« Last Edit: June 01, 2009, 05:22:18 pm by tho_mas »
Logged

Czornyj

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1948
    • zarzadzaniebarwa.pl
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #21 on: June 01, 2009, 05:55:41 pm »

Quote from: tho_mas
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).

Quote from: MarkDS
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)
Logged
Marcin Kałuża | [URL=http://zarzadzaniebarwa

tho_mas

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1799
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #22 on: June 01, 2009, 07:26:26 pm »

Quote from: Czornyj
Eizo CG's are factory calibrated to gamma 2,2 - so maybe that's the reason they don't like L* gradation.
I agree.

Quote
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).


Logged

Peter_DL

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 544
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #23 on: June 02, 2009, 05:25:27 am »

Quote from: Jon Wiles
- 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
--
Logged

Czornyj

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1948
    • zarzadzaniebarwa.pl
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #24 on: June 02, 2009, 07:17:28 am »

Quote from: tho_mas
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.
« Last Edit: June 02, 2009, 07:18:07 am by Czornyj »
Logged
Marcin Kałuża | [URL=http://zarzadzaniebarwa

tho_mas

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1799
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #25 on: June 02, 2009, 07:30:41 am »

Quote from: Czornyj
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.

Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #26 on: June 02, 2009, 08:41:30 am »

Quote from: Jon Wiles
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
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #27 on: June 02, 2009, 08:44:17 am »

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...

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.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #28 on: June 02, 2009, 08:56:02 am »

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:

Quote
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):
Quote
On 3/11/08 7:16 AM, "Jan-Peter Homann" <homann at colormanagement.de>  
wrote:
Quote
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.

Quote
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?

Quote
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?

Quote
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?

Quote
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".
« Last Edit: June 02, 2009, 08:59:35 am by digitaldog »
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Jon Wiles

  • Newbie
  • *
  • Offline Offline
  • Posts: 4
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #29 on: June 03, 2009, 01:52:18 pm »

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.


Quote from: tho_mas
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
Logged

Peter_DL

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 544
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #30 on: June 03, 2009, 04:36:17 pm »

Quote from: digitaldog
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

Peter

--
Logged

digitaldog

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 20630
  • Andrew Rodney
    • http://www.digitaldog.net/
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #31 on: June 03, 2009, 04:47:45 pm »

Quote from: DPL
Not precisely L*, however, Joseph Holmes is located in California  
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.
Logged
http://www.digitaldog.net/
Author "Color Management for Photographers".

Peter_DL

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 544
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #32 on: June 03, 2009, 04:58:10 pm »

Quote from: digitaldog
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.
« Last Edit: June 03, 2009, 04:59:16 pm by DPL »
Logged

Czornyj

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1948
    • zarzadzaniebarwa.pl
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #33 on: June 03, 2009, 06:18:17 pm »

Quote from: DPL
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.
Logged
Marcin Kałuża | [URL=http://zarzadzaniebarwa

Peter_DL

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 544
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #34 on: June 04, 2009, 06:41:29 am »

Quote from: Czornyj
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 (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

--
Logged

Czornyj

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1948
    • zarzadzaniebarwa.pl
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #35 on: June 04, 2009, 07:26:01 am »

Quote from: DPL
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 (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.
« Last Edit: June 04, 2009, 07:27:06 am by Czornyj »
Logged
Marcin Kałuża | [URL=http://zarzadzaniebarwa

Chas

  • Newbie
  • *
  • Offline Offline
  • Posts: 13
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #36 on: June 04, 2009, 09:45:26 am »

[!--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*.
Logged

madmanchan

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2115
    • Web
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #37 on: June 04, 2009, 11:10:57 am »

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.
Logged
Eric Chan

tho_mas

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 1799
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #38 on: June 04, 2009, 11:25:36 am »

Quote from: madmanchan
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.
Logged

madmanchan

  • Sr. Member
  • ****
  • Offline Offline
  • Posts: 2115
    • Web
RGB work space gamma: 2.2, 1.8, L*, 1.0, or what?
« Reply #39 on: June 04, 2009, 12:57:16 pm »

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.
« Last Edit: June 04, 2009, 12:59:38 pm by madmanchan »
Logged
Eric Chan
Pages: 1 [2] 3   Go Up