Let's say I have just picked a foreground color with the eye dropper.
The script to read RGB values I have...
var Colour = app.foregroundColor; var R = Colour.rgb.red.toFixed(2); var G = Colour.rgb.green.toFixed(2); var B = Colour.rgb.blue.toFixed(2);
Now, how can I get the true luminosity value of this sample? (which I would use to set Blend-If Gray settings, with some adjustments)
Can I just calculate this somehow from the RGB numbers, or does a virtual measurement need to be taken?
As you may know, some claim that the TRUE luminosity is not always what PS is using, but we should. AFAIK, you can get this number, for instance, by measuring after you've added a Solid Color layer (any gray) on top in Color mode. This indeed matches with what I expected.
So are there at least two ways?
(1) Maybe some simple recalculation/parameter that brings the near perfect value?
(2) A method where I temporarily add this mentioned layer on top (with the script) and do a new measurement for the perfect value?
The problem here is that if my cursor has moved, the script would sample in the wrong location... I've also read warnings not to sample from within a script. I could fill a temp layer with the fg color though, and work from there...
Example of what I want ...
Let's say I have an area of Red: 255, G: 0, B: 0
When I measure with the gray layer on top, values are 76, 76, 76
I want a method to get to the 76 (in this case).
Someone just told me one of the formulas for the luminosity is ...
0.3*R + 0.6*G + 0.1*B
So that's one thing I could use 🙂
There is no such thing as "true luminosity". It depends on the color space used, because they have different tone response curves.
Here's the same image in Adobe RGB (gamma 2.2) and ProPhoto (gamma 1.8). This is by your method, a solid color gray layer on top:
In true grayscale, it will depend on your working gray, or assigned grayscale profile.
If you want a "standard" value, the closest thing is the Lab L number.
Thanks. There seems no doubt that there are different formulas and views, but IMO that also makes it logical that some should be better suited for certain work? For now, I wanna follow one of these preferred views (for RGB).
That PS seems to be mixing "color systems" depending on adjustment layer seems to be exactly the problem and why things can go wrong (like using Hue/Sat adj layer set to fully desaturate instead of a "true luminosity" layer)...
Explain with an example with a picture, with screenshots, how you got 76 from RGB (255,0,0).
Cursor is over the Red 255 area.
It's ok to be one number off (rounding?), but I wanna be very close to that.
Aha, and here it is : )
Need to think. Interest Ask
Copy link to clipboard
var c = new SolidColor() c.rgb.red = 255 c.rgb.green = 0 c.rgb.blue = 0 var lm = Math.round(0.299*c.rgb.red + 0.587*c.rgb.green + 0.114*c.rgb.blue); alert(lm)
Thanks!! I will test this over the next days with different colors and get back to you 🙂
First ten tries all hit the mark or miss by the expected "one." 🙂
Did you have to make a special tweak or is this one of the standard formulas after all...?
As noted, the easiest way to convert to the RGB colour space dependent "luminosity" is to fill with a solid, white, black or gray fill set to color blend mode. This strips out all colour and leaves the "luminosity" component of the image which is the value shown in the gray layer blend-if options window or the master/composite RGB curve.
I would have added a temporary fill layer as described above and then placed a colour sampler.
For me, my appraoch for scripting this would likely require placing the colour sampler in the correct position and then getting the values from the sampler with the temporary gray fill color blend layer performing the colour conversion (which would be independent of the base colour space.
The most correct one is channelmixer. There you can form any formula. )
I have the formula for the Channel Mixer and it seems 100% identical to the Solid Color layer. And I hear it should be.
[to Stephen] Psychologically, I would feel better with this method, but I've also taken note of warnings about using samplers in scripts?
Namely by r-bin here ...
r-bin: ColorSampler is a bad tool in scripts. Here is a real ColorSampler 31x31. See what the code shows. alert (activeDocument.colorSamplers  .color.rgb.red)
And this old quote, does it mean you ideally have to sample at 100% size?
Sean Baker: Don't use the color sampler tool (Info Palette) to test error levels at anything less than 100% zoom. Otherwise it uses that same awful resizing algorithm which PS uses to preview images on non-HW-accelerated systems in order to estimate what a value might be, not actually reporting the real value to you. This can give you all sorts of ghosts to chase.
Just as long as it's understood that this is only valid in the actual color space of the document. In a different color space you get different results.
Just want to be clear on this, since the OP used the term "true luminosity", which this is not.
I still maintain that for a "universal" or standard number, valid in all scenarios, you would use Lab L.
If in a color space it can be demonstrated that one method clearly works above another one that leads to errors/damage, then I don't think it's unfair to call this the "true luminosity" for this color space. And that is what I mean, though in another sense you might be right. In a few "high circles" I get my info from, it is however called true luminosity. And if it's not true in some sense, it is the one you normally should use for the things I care about, "AFAIK."