You forgot gamma correction? One online tool gives sRGB 0.461 = linear 0.18 (normalized values), thereby for 8-bit 118 equals to 18% of gray :)
/edit/
I likely misunderstood your claim. 118 for 8bit and sRGB is correct, but images, from what you pick your colors, are most likely not correctly made.
What your screen color picker dispalys for next one - should be 117 or 118 (sRGB 118 ≈ Adobe RGB 117):
Yes, it displays RGB 117,116, 117.
It is not a claim, Arvo. It is taken from this Japanese Standard:
That's absolutely fine. But the zones specifically relate to the performance of B&W negative film when exposed to light, and specifically the densities produced when you subject that film to varying exposures. To make it relevant to cameras those varying exposures are set at one stop differences, a step wedge where the densities of the film are measured and related to print densities. I'm sorry it's not the pure mathematical exercise of dividing a log scale into 10 steps.
I don't. But you are specifically asking about the principals involved and they are about exposing B&W film and measurinfg the densities on the film post development. I'm sorry, I can't help what the Zones relate to only try to explain.
So the answer must be pure maths??
Well, between the lines, again I'm sorry that it is not the answer you wish, but I have studied the Zone System and used it extensively. Which brings me to:
Being thumbnails on a search results page there may be anything from "slight glitches" to a "complete lack of" colour management. Helps to consider rather than glance. Just like the 18% grey being the mathematical middle of the grey scale, I thought it was derived as the average tone from the average scene, and different manufacturers used different average values and "middle" tones. Do't forget that B&W is an abstract based on the response of blue sensitive photographic film to light. It is not an exact mapping of subject luminance to an exact mathematical scale.
Sorry again, but to me there seems a lot of BS on photo forums about the Zone System by people looking for a framework based on maths. That's not what it is.
116 for G? Is your display somehow calibrated (has some profile set)? In this file R=G=B=117 in AdobeRGB; converting to sRGB (by browser) should result in 117 or 118 (117.7) for all channels. If your screen has custom profile attached and screen color-picker reads actual pixel values - then yes, channels can be different.
After being beaten to death by @Andrew546, I almost do not dare to respond ... [edit] and, sure enough ... [/edit]
My screen uses the display profile it came with and has not been calibrated.
Your file goes through FireFox and my monitor display driver and my monitor is 98% sRGB - so slight variations in my screen color-picker do not bother me.
P.S. I made a new image in the GIMP and set it to 117,117,177. With the GIMP still open, I applied the screen picker and it said 116,116,116 for what that is worth
P.P.S. I downloaded your Abobe RGB file and opened it in the GIMP: GIMP's picker says 118, 118, 118 (GIMP review set to 8-bit perceptual). However RawTherapee says 117 mostly but 119 around the outside quite a lot (RawTherapee set to native 32-bit floating point and ProPhoto working space). XnView said 117,117,117 all over.
I'm losing faith in color-pickers ... 😡
Sure, getting 117 in one software, 118 in another and 116 in third makes life hard :(
It is less than one percent difference however - and considering jpeg compression and sRGB/AdobeRGB conversion and presence of some kind of screen color profile this is actually quite good result :)
Agreed!
I assume you mean the 'eye drop' tool where hovering on a pixel it tells you the rendered rgb values for that pixel.
The key point here is rendered rgb values and not the pixel's rgb values in the image file.
The rendered values on any particular screen depend on if and how a screen is calibrated and then profiled, whether colour management (with its various configurations) is used by the app displaying the image - web browser, editing app etc.
You are kinda pushing the limits of my patience here, I understand exactly what you mean. I have tried explaining the zone system and how it's derived, and what it relates to, but hey, the truth can be whatever you wish it to be.
P.P.P.P.P.S. If a web page is not colour managed then there is no guarantee that any file loaded through it will display correctly. It's about continuity in colour management from one program to another when creating the web page and that of the search engine and web browser you use, and also the savvy of the person creating the pages, editing the images... There is no guarantee that it exists and so no guarantee that the value (118-) is preserved.
It has nothing to do with the calibration of your screen or the colour picker. Which doesn't actually sample the colour on your screen (??) it takes the data from the file attached. The display is just a GUI. The values of it's pixels do not relate directly to RGB values and it's calibration is simply to fine tune the generic LUT in the driver so the colours it displays are closer to the reference colour for the sRGB values in the file.
18% grey is a calibrated standard, it is 118- in sRGB but an actual grey card target is more than just a value. It didn't start life as the mathematical middle value on an RGB greyscale and isn't.
You all carry on, I'll leave you alone.
Wrong for my system. My screen color picker often shows values different than those in an image data file.
Not so quick, please.
In its simplest form usual display profile consists of two parts.
One is gamma correction graph, which is loaded into graphic card/driver LUT and is not directly detectable by screen color-picker (does not change its readings).
Another part is screen color model - mostly color primaries (RGB coordinates in some profile connection space), this the basis of software color correction - and this already changes underlying pixel values, sent to the driver and graphic card and affects color-picker readout.
It is rare for real screens its primaries to match precisely to sRGB or Adobe RGB or some other common color space ones, thereby (if any custom profile is in use) pixel values usually do not match image values. For monitors with hardware calibration this can be achieved - at least for smaller color spaces (like sRGB on Adobe RGB capable monitor); for common consumer monitors almost never.
Of course displaying non-native color space images (like AdobeRGB ones on even hardware-calibrated sRGB screen or vice versa) yields profile conversion in viewer program, which may change pixel values in different ways, depend on color management system properties and configuration.
So when you're working in PS on the specific colours for logos? Are you telling me that the eyedropper tool is giving me the Pantone references of the closest match my screen can display rather than the colour I need to send to the printer? It may know which colours are out of gamut for the output device but it sure makes a whole lot of nonsense to colour management if your eyedropper tool samples the rendering intent of your screen.
Also consider the premise of this thread, the idea of converting, or mapping the "zones" to specific and fixed values on the greyscale. If you remove the reference to actual negative densities what do you have?
You have a direct map of Zones, or stops on the camera, related directly to values of grey on a fixed greyscale.
So what relevance does it have in photography, as in what does it represent, or what actual camera are you mapping the precise grey achieved by selecting those specific zones?
If there were an emoji for shrugging shoulders in disbelief... 😀
Of course not.
From Ted postings I understood that he is using some system-wide screen color-picker, not application specific eyedropper tool, used inside the same application. The latest of course knows, what it reads from underlying image - it does not need to know anything about screen properties.
If I was mistaken, then I apologise.
You mean this one: 🤷 ?
¯\_(ツ)_/¯
No need to apologise, if I'm ever offended then it is often because I add my own dynamic to the meaning of the words. We all make assumption, and the to and fro highlights mine as well.
Damn, with one fell swoop you prove I don't know everything. 😡
... and here it is ...
Between the image data and the screen data there exists the matrix-type color profile 'n199sx.icm' ...
As I said to Arvo earlier:
,,, now you know everything ... 😀
I'm never working in PS - my computer is Adobe-free
No. For the record, not everybody uses PS and none of my apps provide "Pantone references".
Reading this 24 days later, I'm not sure how it would "know" which colors are out of gamut for the output device and what it would do about that, if anything?
I have several "eye-dropper tools", only one of which shows screen values, so your statement: "it sure makes a whole lot of nonsense to colour management" falls upon deaf ears, sorry ...
So I did find a Kodak publication on sensitometry where they specifically used a 21-step wedge i.e. half-stop intervals
I think the key words here are still "sensitometry" and "step wedge".
As for the previous edited post, not really sure if you're not just trying to prod here so I'll leave that alone. Look it up, it's all readily available info.
