Any one know? I dont think this will be a straight forward answer...

thanks

min

This has been discussed a few times in recent threads. Do a search.

thanks for your helpfulness...

IIRC - this 18% gray refers to a white of 90% reflectance.

So the normalized reflectance for this perceived mid gray is 18/90= 0.2

In a linear gamma space this makes an RGB of 0.2 x 255 = 51

In a 2.2 gamma space such as Adobe RGB it is (51/255)^(1/2.2) x 255 = 123

Peter

--

The other question would be, why would it a useful number?

Read this thread, paying close attention to the end of post #4. You'll learn what the value is for various color spaces, and also why worrying about isn't very useful.

The middle gray can be important for calibration and proofing purposes as explained in some detail in this post ISO Standards for Museum Imaging

Bill

Your link doesn't contain any URL information. Care to try again?

Thanks,
Mike.

Clicking the link crashed Safari...

Sorry. I fixed the link.

Bill

Now it just crashes Adobe Reader...

The link works now with Firefox. A few minutes ago, the link's server appeared to be responding very slowly, so try again.

Bill

Ah but the issue is, its based on the encoding color space, the values can change.

Also, there's been some debate about using a scale like this, instead of say how Lightroom presents the values using a scale of 0-100%. 50% gray is 50% gray, using a scale of zero to 255 is based on the encoding color space which can range from 1.0 to 2.2 (or further if for some reason, someone's using some exotic color space). Yes, a 50% gray in a 1.8 gamma space is different than 50% gray in a 2.2 gamma space but the nice thing is, its always presented to the user as 50%.

A bit of math is simply part of the game.

Peter

--

The link just worked for me in Safari. I have only skimmed it so far, but find the contents to be quite informative. I notice that near the end they discuss the differences in reading color values from Photoshop and Lightroom and how they vary. It seems that we have come a very long way from digital color's dark ages, but in terms of absolutes and color standards, we still have a ways to go.
-Ron H.

Yes, that is one of the main points in the article. The author suggests using L* to remove these ambiguities.



Your math is incorrect. Mid-gray (L* = 50) can be converted to gamma 1.8 or 2.2 values by use of Bruce Lindbloom's companding calculator. The normalized pixel values are 0.3907 for a gamma 1.8 space and 0.4635 for a gamma 2.2 space. The corresponding values in 8 bit are 99.62 and 118.2 respectively. Lightroom reports values in normalized notation for gamma 2.2.

If you create a mid-gray in Photoshop by filling an sRGB image with midgray (L* = 50), the sRGB pixel value in Photoshop is 119, close to the calculated value of 118.2. If you import this image into Lightroom, the pixel value is reported as 46.7 or 119 in 8 bit notation, not 50% as you claim.

If you read the paper, you will see documented inconsistencies between Photoshop and Lightroom.

Bill

You're missing the point and geeking up the experience. The math is necessary to convert but there's no need to do so with this simpler scale for end users. I don't need to know the values in 0-255 any more than I do 0-640000 odd values. I only need to know where highlight, shadow clip (0-100) and where middle gray falls (50%).

For years we've had photographers ask "what RGB values equal middle gray" and we have to jump through the math hoops due to the encoding space. Photoshop could do this for us! Its being done in Lightroom. 0-255 is fine for some old farts, its been around since day one of Photoshop. But that doesn't mean newer users need to worry about it (they don't) and in fact, we really NEED this scale in Photoshop for all the newer LR users who never see (nor need to see) 0-255.

Well if you need information about the shadow clipping in terms of percent gray, your Lightroom readout will not be accurate. For L* = 5, the LR readout will be about 9%, not 5%. The Lightroom readout is not percent gray, but a normalized pixel value for gamma 2.2. Often the two are close (as for mid-gray) but they are not in the shadows.

Bill

Well considering that the data is in a linear encoding, that the numbers are using a 2.2 encoding, there's a disconnect here and L* is pretty immaterial. The numbers and histogram are based on a color space that is neither being used under the hood or what you'd end up with in Photoshop. But that's a different issue, one that sometimes troubles me just a tad.

Looks like people are still willing to discuss this issue...good thing my Luminous search didnt uncover any threads!

Thank you all so much for your insight and taking the time to share it! I figured the answer would be complex, I just didnt know how complex. You guys are amazing...I wish my brain was big enough to contribute something!

thanks again!!

Min

ps - no problem for me with the link with firefox on leopard

Interesting:
so there’s now a ProStarRGB space = ProPhotoRGB + L* trc.
A while ago we created L*-beta-RGB = Bruce Lindbloom’s beta-RGB + L* trc

Anyway, a straight 2.2 gamma never was a good choice for several reasons:
see ProphotoRGB with 1.8 gamma
see sRGB with a "shadows bump" i.e. gamma < 2.2 for a start
see Adobe’s color engine which supresses a straight 2.2 gamma in the deep shadows by means of a slope limiting feature

However, as we know, gamma never was invented to comply to human perception, but to compensate for the non-linear response i.e. grid voltage / luminance on screen of CRTs:
>> In early days of the television industry it was decided that the non-linearity of the cathode ray tube (CRT) called gamma, would be taken into account in the video-camera by applying an inverse transfer function to the video-signal in order to compensate the CRT gamma. This way expensive non-linear signal processing was not needed in the TV receivers so the cost of the receivers was kept at minimum. At those days non-linear analog signal processing hardware was very expensive and difficult to realize. << by Timo Autiokari

Bill, - just to use the opportunity to compile some related links.



Agreed - also regarding "troubles me just a tad".

As I understand, it finally means to take care with the "Blacks" slider in LR and ACR as well, in order not to collect too many pixel in the left corner close to black clipping.

Peter

--

Yes, the Lightroom pixel reporting doesn't make good sense to me either. I much prefer the system the Mr. Knoll uses in ACR where you can select the space into which the file will be rendered (usually ProPhophotoRGB for me). As long as one understands what is being reported, allowances can be made. L* may not be of importance to you, but it is to many. RGB color spaces based on L* rather than gamma are coming into increasing usage, especially in Europe. The ISO has just approved eciRGBv2.

Bill

I'm going to have to ping Bruce and see if he did this purely as an interesting exercise or he feels that its useful, because just about every color geek I respect in the US thinks this L* stuff is a bunch of baloney. There was a rash of long but interesting discussions last month on all this, some good posts by both Karl Lang and Chris Murphy which basically points out, this is a solution in search of a problem. Its a big deal in Europe, but the bottom line is, no one there from the list had anything useful to prove that this is of use.

Lars Borg (the color scientist at Adobe, a guy who knows a few things about color) wrote this:

[quote=bjanes,Apr 15 2008, 03:40 PM]
Yes, the Lightroom pixel reporting doesn't make good sense to me either. I much prefer the system the Mr. Knoll uses in ACR where you can select the space into which the file will be rendered (usually ProPhophotoRGB for me).
[/quote]

The problem is workflow. In ACR, you pick the encoding color space and boom, you end up with the rendered image in Photoshop based on what you asked for. In LR, you may never leave it since you can print, then export that data at any point. So do you make a UI of preferences that say "use this encoding color space for all the work"? Or do you use some non existent color space for the numbers and histogram because you fear showing the actual linear encoded data would confuse the users the product is aimed for? Personally, I think it might be useful to see ProPhoto RGB linear values but the histogram would be wacked out.

I also really like how I can SEE in the ACR histogram the effect of the encoding color space option I make in terms of gamut clipping. Of course, we could just force all LR users to work with only ProPhoto RGB (something that was suggested internally by one alpha tester).

I agree its not as seamless as it could be. At first I was put off by the scale but now I'm totally hip to percentages but I'd like them to be based on something I'm actually doing. Melissa RGB is a name for an imagery color space that no one is using, although anyone who wishes could build one in Photoshop. Buy why?

[quote] L* may not be of importance to you, but it is to many. RGB color spaces based on L* rather than gamma are coming into increasing usage, especially in Europe. The ISO has just approved eciRGBv2.


I didn't make a personal judgement that it was useful to me or not, only that a pretty smart group of people on this side of the pond think its a lot to do about nothing, and as discussed on the ColorSync list, they challenged proponents to provide some empirical evidence of its use, something that was ignored. Case in point, this post from Chris Murphy:

[QUOTE]I have no problem with research and testing these ideas. My complaint
is the grandiose language used in unproven statements, and the
premature establishment and recommendation by the ECI and others for
real world workflows that are not, and should not be, test beds for
research. I find it inappropriate.

It is in exactly the wrong order of the way things are to be done in a
scientific manner. Research, hypothesis, test, refinement, theory
development including beta test. Then publish a recommendation for end
users, while working on making the recommendation an ISO standard.

I'm quite frankly mystified how eciRGBv2 became an ISO standard and
what the point is, absent any semblance of compelling information on
why yet another flavor of the year RGB color space is necessary, and
that the goals it wishes to achieve are relevant and also not possible
any other way.

My complaint is primarily about the process followed thus far,
although increasingly it is based on what is being presented (i.e.
what is not being presented) to back up grandiose claims. Case in
point from the ECI web site:

"'conversion losses' between data and the human eye are thus a matter
of the past"

"substantial advantages in the shadows"

"risk of posterization effects – is significantly reduced"

"Errors caused by colour space conversions – are minimized as much as
currently technically feasible"

These are not proven. There is slim to no context given. No test
parameters have been published so people can reproduce the test and
the findings. And there appears to be no metric. These grand
statements, are based on what empirical data?

The obvious conclusion most end users will read into this is that the
opposite must be true with respect to eciRGBv1 and that is:

There are conversion losses that are visible
There are substantial disadvantages in the shadows.
There are significant risks for posterization.
There are errors in color space conversions.

Now these are obviously not true with respect to eciRGBv1 workflows.

It is confusing whether L* based intermediate space advocates are
talking about 8bpc workflows, 16bpc workflows, or both. The arguments
would naturally be different, but advocates seem to flip flop on this
and just say it's great for both, missing the relevance of bitdepth in
the entire discussion.
[/QUOTE]

Actually Karl Lang created this space back in 2005 (with permission of Bruce L.) after I bothered him long enough. It happens that this is just a local call for me. Perhaps you remember the initial discussion in the robgalbraith forum.



No problem. It’s after midnight here, so you may allow me just to quote from an earlier discussion (with Gernot Hoffmann):

>> Further, for introduction: Tonal settings in Photoshop can be calculated on a pure RGB basis, completely ignoring the underlying gamma. I won’t say that Photoshop operates this way, but it’s possible to do this on a descriptive basis.
For example, moving the Levels’-blackpoint slider to the right, subtracts a respective value from all RGB data in the deep shadows. The more general equation should be:
RGBout = a x (RGBin - BP)
a = 255 / (255 - BP)
wherein BP refers to a Levels’-blackpoint setting from 0 to a value BP

Now let’s take a brief, 3-step grayscale in Adobe RGB with dark grays of RGB 9, 16 and 21. In a copy file (!) and converted to sRGB (!), this makes 4, 7 and 13. Understandable, due to the lower local gamma of sRGB. Nonetheless, both grayscales should look right the same on screen.

The next step is mentioned ‘image editing practice’ to move the Levels’-blackpoint slider towards a value where the first patch reaches zero. In case of Adobe RGB, the value for BP setting is 9. In case of sRGB, the value for BP setting is just 4 (see above numbers).

Now what is the result. The grayscale in Adobe RGB turns to RGB 0, 7 and 12. Whereas with the copy file ‘in’ sRGB the new grayscale is 0, 4 and 9. Big difference!

Zero to 12 in Adobe RGB corresponds to below / equal L* 1. A critical range and the grayscale tends to disappear on screen. Zero to 9 in sRGB goes up to L* 3. The steps should stay clearly visible on screen or print.

Just give it a try.<<

Another aspect is that a numerically lower BP setting is less damaging for Color integrity a la David Dunthorn.


Andrew, - we really don’t have to argue here. At the end of the day, I find the implementation with LR/ACR (acting on linear data while showing a gamma encoded histogram) better than to combine the two contradictive requirements in one working space. Just in Photoshop, I would not use a straight 2.2 gamma space, even though I notice that many liked Adobe RGB.

Please note, I’m not at all talking about this “L* monitor calibration & profiling” thing here.

Peter

--

Well credit to you for bothering him, apparently more recently, he's not at all hip to the L* idea:




Who's arguing? I so far am just posting older posts in another public forum on the subject. I have no opinion, but I think what Chris said about proof of concept would be useful.

Sorry - confused the name, it was the other Karl: Karl Koch with basICColor

Peter

--

We could turn the question around, to ask why Adobe uses this linear ProPhoto space as an intermediate in LR/ACR.

Of course, I can’t answer for your engineers, but there’s an inherent issue with Black-point setting, which is most pronounced in a regular 2.2 gamma space such as Adobe RGB, and less pronounced in any 1.x gamma space starting with 1.0 ProPhoto but also including sRGB, L*-type RGB working spaces and most of Joseph Holmes' spaces – which altogether bear such low local gamma in the shadows (not to be confused with the midtone gamma as indicated e.g. by Photoshop’s Custom Profile function).

Say we have a dark gray of linear RGB 2 which shall be brought to zero. In a linear space it just requires to set the Black-point slider 2 levels to the right. Done.

Now in a regular 2.2 gamma space, same dark gray is indicated by an RGB of 28. Means to get it zero (and zero is always the same independent from gamma) we will have to move the Levels’ Black-point slider 28 units to the right.

Q: So what ?
A: Problem with this much stronger move is a considerable stronger effect on all other RGB data. It’s an unnatural operation so to speak. In detail this can result in:
a.) posterization of shadow details (see my post above),
b.) an undesired increase of color saturation, starting from the shadows with decreasing significance towards the highlights,
unless of course you would find this particularly pleasing.

Hope this contributes for clarification.

Peter

--

Intermediate?

>> White Balance (Color Temperature and Tint), in addition to any adjustments with Camera Raw’s Calibrate tab, actually tweak the conversion from native camera space to an intermediate, large-gamut processing space

(This intermediate space uses ProPhoto RGB primaries and white point, but with linear gamma rather than native ProPhoto RGB gamma of 1.8.)

… It’s simply impossible to replicate these corrections in Photoshop, so it’s vital that you take advantage of Camera Raw to set the white balance and, if necessary, to tweak the calibration for a specific camera.

… The remaining operations are carried out in the intermediate linear-gamma version of ProPhoto RGB.<<
[comment: in the whole context it becomes clear that this excludes the Exposure slider and the Lens tab controls as well].

Cited from: Camera Raw with Adobe Photoshop CS, PeachPit Press, 2005 by Bruce Fraser, p. 29/30.

Peter

--

OK I understand the term now. But I don't know that having access to the data prior to this would be useful (I'll have to think about that one). It might be difficult for users decipher the color numbers and certainly the histogram of the native space (whatever that might be). And if we're using different camera models, would this imply that they would be different? That might be an issue for users. With this ProPhoto space, all users work with the same color space.

Camera Raw uses a linear intermediate space for raw processing because many of the image processing algorithms operate better on the linear data, esp. in the early stages.

It was reported that >> a little noise reduction, and any chromatic aberration corrections, are also done in the native camera space. (Chromatic aberration corrections could cause unwanted color shifts if they were done later on in a non-native space.)<< The native camera space is supposed to be linear by nature as the sensor should respond linearly on the "dosage" of light received.

Then comes the conversion to ProPhoto linear. As explained by Thomas Knoll: the sliders for Exposure, Temperature, Tint as well as the 3x2 hue/sat controls of the Calibrate tab tweak the 9 degrees of freedom with the 3 by 3 camera matrix, which is then used to process the data.

Regarding all further "creative rendering tools" which are subsequently applied in the frame of this intermediate linear-gamma version of ProPhoto RGB, well, there’s probably more than one way to skin a cat. The idea of a strict metadata editor may reason why this platform is kept closed.

Peter

--

Yes, but there are additional image processing algorithms besides the ones you mention that operate better in a linear space. (Others don't matter so much and work fine in either a linear space or tone-mapped space with different but equally plausible results.)



I don't understand this comment at all. Clarify, please?

Blending of images e.g. for HDR purposes, application of Plug-ins and some more Photoshop tools which I like to use at times are currently not supported within Camera Raw, just afterwards (or let’s call it downstream) in Photoshop.

So we are again at the question why some of us do such fancy things i.e. to skip many of the creative tools in ACR in order to start from scratch with a "scene-referred image" in Photoshop. Actually I came to this with ACR version 2.x where many of the nice rendering controls which we are now appreciating were simply not given at this point of time.
Nonetheless, I still find this route to be a viable option e.g. for some operations such as blending of images or noise reduction which often benefit from "virgin" data -- which have not been squeezed so far through the notorious tone curve and other tools which are supposed to belong to the category of "creative processing" at the stage of ProPhoto linear with ACR (as opposed to those controls which are really essential for matrix conversion and what is called color reconstruction, or which are even applied before in the native camera space).

One could think about ways for a more seamless assembly and integration of both environments, i.e. Photoshop + ACR tools, on the platform of this linear ProPhoto space which seems to be inherently present with ACR anyway. However, technical realization might jeopardize the idea of storing all changes in the metadata. IMHO.

Peter

--

As usual, Peter is thinking outside of the box. The linear ProPhoto space of ACR is essentially the RIMM Color Space as stated by Thomas Knoll in a post on the Adobe forums:

"Camera Raw uses both RIMM and ROMM in its processing path (ignoring the gamma encoding). After the white balance and initial camera profile application, the data is basically in RIMM space. The tone curve and other user controls transform the image into ROMM space, which is then converted to the final selected RGB working space.

The big difference is RIMM is *input* (or scene) referred, and ROMM is *output* referred. Otherwise, they are really the same color space. Most of the controls that raw converters have are control knobs for the process of converting scene referred data to output referred data."

This RIMM space has sufficient dynamic range for current raw camera input, but if several files are merged into a high dynamic range image, then one must use a true HDR encoding. Various HDR encodings are discussed by Greg Ward.

The Microsoft linear scRGB is similar to the linear ProPhotoRGB, but it uses sRGB primaries. Greg notes:

"The scRGB standard is broken into two parts, one using 48 bits/pixel in an RGB encoding and the other employing 36 bits/pixel either as RGB or YCC. In the 48 bits/pixel substandard, scRGB specifies a linear ramp for each primary. Presumably, a linear ramp is employed to simplify graphics hardware and image-processing operations. However, a linear encoding spends most of its precision at the high end, where the eye can detect little difference in adjacent code values. Meanwhile, the low end is impoverished in such a way that the effective dynamic range of this format is only about 3.5 orders of magnitude, not really adequate from human perception standpoint, and too limited for light probes and HDR environment mapping."

In view of the above, if we want a scene referred format for out data, it would be best to use a true HDR format with log or floating point encoding. In such an encoding, half of the data would no longer be in the brightest f/stop of the capture and one rationale for exposure to the right would be removed, but one should still use ETTR for better dynamic range and signal to noise.

I am bringing up these points for discussion.

Bill

Fascinating thread which I've only just stumbled on.

As someone who shoots for galleries and museums for a living, the topic is right up my street. Thanks for the link to the document entitled "Adopting ISO Standards for Museum Imaging." Would appreciate some more links to info on eciRGBv2.

As to grey cards..........

The basICColor grey card, as I posted on another link, is the best I know of.

http://www.color-solutions.de/english/Orde...isTargets_E.htm

It has a Lab* of 60, 0, 0 or 143 in Adobe 1998. So, if you set your white a black points with a photo of an oil on canvas, for example, you can then adjust luminance until the card is 143. Never fails.

It is also spectrally neutral, so use it under any combination of lighting. Brilliant for shooting interiors under multiple light sources. Even if you don't like what the click of the white balance tool produces, it always acts as a starting point.
D.