I'm have a color calibrated camera and projector pair. I'm trying to come up with an algorithm based on color additivity, and I'm wondering whether color additiveness holds under the RGB space. For example, will the colors in RGB with values of (30, 30, 30) and (60, 60, 60) produce colors close to (90, 90, 90). I'm observing that this isn't the case and it produces a color like (72, 72, 72). I'm wondering whether this is due to some system error, or do I have to go into a different color space like YUV or Lab? Or whether I'm misunderstanding color additiveness and the color additive property does not apply for the addition of separate color components?
EDIT: I'm talking in decimal values.
Usually RGB integer values in domain [0-255] are 8bit values with the working RGB colourspace OECF (transfer function) applied thus non linear values. If you want to perform arithmetical operations on those values you ideally need to apply the inverse OECF to the values prior the operations.
This PDF describes the sRGB colourspace OECF for example: http://www.color.org/srgb.pdf
Related
I'm writing some image processing code to do some creative color gamut limiting that I want to use for color grading applicationgs. I'm building to operate in the Davinci Wide Gamut color space, typically using the DaVinci Intermediate logarithmic encoding, since that is my typical working space in a color managed workflow. To do this, I want to convert the input to xyY, limit the value of xy to fit within my desired gamut and then convert back to DaVinci Wide Gamut/Intermediate.
These are the steps I'm following:
Convert DaVinci Intermediate RGB to linear RGB
Multiply by DWG to XYZ conversion matrix.
Convert XYZ to xyY.
Modify x and y to fall within gamut.
Convert xyY to XYZ.
Multiply by XYZ to DWG conversion matrix.
Convert linear RGB to DaVinci Intermediate.
This works fine for most cases, I have also verified that roundtripping without modification of x and y works as intended. The problem occurs for for extremely saturated blues. Take the following RGB values in Davinci Wide Gamut/Intermediate as an example: [0, 0, 1.0]
Let's follow along:
Convert to linear: [0, 0, 100]
Convert to XYZ: [10.11,-14.78, 132.59]
Convert to xyY: [0.08,-0.12,-14.78]
Modifying x and y to fit in my gamut: [0.18, 0.07, -14.78]
Convert back to XYZ: [-35.64,-14.78,-149.08]
Convert back to DWG linear: [-27.99,-27.99,-117.44]
Convert back to DaVinci Intermediate: [-292.34, -292.34, -1226.52]
As you can see, the result is nonsensical, but only for these extreme blue values. To me, it seems pretty clear that this is caused by the blue primary in DaVinci Wide Gamut which has a negative y coordinate ([0.0790, -0.1155]). This causes negative luminance (Y = -14.78) and when messing with the xy values without dealing with the luminance at the same time, things go haywire.
How do I deal with negative values in xyY and XYZ when doing gamut limiting in this way?
So I know basically nothing about colors apart from the very basics.
I have a color I'm trying to mimic.
I copied it, stuck it in paint, and used the color feature to get the RGB HSL numbers. Great!
RGB: 0; 49; 70
HSL: 132; 240; 33
The issue: When I try to manually input them into Excel, it "autocorrects" the RGB values after I enter in the HSL, and it "autocorrects" the HSL when I re-enter the RGB.
Why is this happening? Is this just an aspect to colors I know nothing about? Some limitation on Excel?
For reference, when I put in just the RGB, I'm much closer (but not quite there) on the color I'm looking for
HSL and RGB are two ways of "translating colors" into numbers.
HSL means Hue, Saturation, Lightness.
Hue is a degree on the color wheel from 0 to 360. 0 is red, 120 is green, 240 is blue.
Saturation is a percentage value; 0% means a shade of gray and 100% is the full color.
Lightness is also a percentage; 0% is black, 100% is white.
RGB means Red, Green, Blue, each of which is given a value between 0 and 255 in Excel.
Check this tool - https://www.w3schools.com/colors/colors_hsl.asp
If you put 0, 49, 70 for HSL you would see that it gets translated to 216, 141, 141 into RGB.
Excel is following the same logic, thus once you adjust the RGB the HSL gets automatically adjusted to represent the same color.
Excel colors are confusing because they don't follow the standard
Although the first reason you may have been confused was if you didn't know that RGB and HSL are two different ways of describing colors (and that every RGB color code has an equivalent HSL color code—see examples below), a second reason many people can get confused when selecting colors in Excel particularly is:
“Frustratingly, Excel does not handle HSL in the standard way. Instead, Excel measures all the numbers where 0 is the lowest and 255 is the biggest. But, it’s a quirk we can handle.” - https://exceloffthegrid.com/convert-color-codes/
“This approach assumes that each of your HSL values can be express in the range of 0 to 255. If, however, your HSL values are either an angle (for hue) or a percentage (for saturation and luminance), then you'll need to convert them manually before entering them in step 6. You can convert an angle value by multiplying the angle by 255 and then dividing by 360. Percentages can be converted by multiplying them by 2.55.” - https://excelribbon.tips.net/T013535_Converting_HSL_to_RGB.html
“To change the lightness (adding white) or darkness (adding black), drag your selection up and down the luminance scale on the right. Notice that the Lum value increases as the color gets lighter. Full luminance is 255 (white), and setting Lum to 0 results in black regardless of the hue and saturation settings.” - https://support.microsoft.com/en-us/office/choosing-colors-in-the-colors-dialog-box-c3d59ddf-65a7-4e62-aad7-f7b8d7684a2d
Examples of converting RGB color codes to HSL
rgb(0, 49, 70) = hsl(198, 100%, 14%)
These independent sites agree with Google that that RGB code converts to that HSL code:
https://colorpicker.me/#003146
https://hslpicker.com/#003146
So if someone told you that rgb(0, 49, 70) was equivalent to hsl(132, 240, 33), they were mistaken (even when using Excel's non-standard way of calculating HSL).
Just a short explanation how I came to this question. I have a ruby module which is basically a hash that gives me HTML "colours", like "slateblue", and gives me back an Array that holds the R,G,B values, like [106, 90, 205] for slateblue.
I googled how to make these R,G,B values into a lighter colour (for mouse cursor on hover effect), and several people told other people when they had a similar problem to just increase the R,G,B values. My current solution, which is a hack, is to add to the R,G,B values, like +20 (capped at 255), and then convert this into a hexstring #FF0000 something.
This seems to work okish but here is the thing now - I have absolutely no understanding about why this works.
Is it so that the 0 always denotes the lowest value of R/G/B and 255 the highest? If so, why is it capped at 255 and not at, don't know, 1024 or some other arbitrary number?
Using 8-bits per color channel - one each for red, green, and blue - yields a large number of colors (2^24 or 16777216), and is sufficient to be used in most applications. Note that there are other color formats with higher precision though.
0 is used for black, while 255 (the maximum stored in 8-bits) denotes "full-on" color.
Adding a specific number to each channel moves the entire color toward (255, 255, 255), or White. If you would like to be more exact in your lightening of the color, you might try converting your RGB color to HSL, doing your addition to the light component only, then converting back to RGB.
You can start research of HSL here: http://en.wikipedia.org/wiki/HSL_and_HSV
I'm writing shadow removal for my pony detector. After I've converted a PNG image from sRGB to CIE XYZ I remove the luminance as per instructions:
When I try to convert the image back to sRGB for display, I get RGB values that fall outside the sRGB gamut (I get values greater than 255). Is this normal, or should I keep looking for bugs? Note: conversion to XYZ and back without modification produces no glitches.
Illustration (top left: original, bottom left: byte value wraparaund for red and blue hues):
For completeness: top right: color ratios, bottom right: convert to HSV and equalize value.
The final transformation does not remove the luminance, it creates two new values, x, y that together define the chromacity while Y contains the luminance. This is the key paragraph in your instructions link (just before the formulas you link):
The CIE XYZ color space was
deliberately designed so that the Y
parameter was a measure of the
brightness or luminance of a color.
The chromaticity of a color was then
specified by the two derived
parameters x and y, two of the three
normalized values which are functions
of all three tristimulus values X, Y,
and Z:
What this means is that if you have an image of a surface that has a single colour, but a part of the surface is in the shadow, then in the xyY space the x and y values should be the same (or very similar) for all pixels on the surface whether they are in the shadow or not.
The xyz values you get from the final transformation cannot be translated directly back to RGB as if they were XYZ values (note capitalization). So to answer your actual question: If you are using the xyz values as if they are XYZ values then there are no bugs in your code. Translation to RGB from that should not work using the formulas you linked.
Now if you want to actually remove the shadows from the entire image what you do is:
scale your RGB values to be floating point valies in the [0-1] range by dividing each value by 255 (assuming 24-bit RGB). The conversion to floating point helps accuracy a lot!
Convert the image to xyY
Replace all Y values with one value, say 0.5, but experiment.
Reverse the transformation, from xyY to XYZ:
then to RGB:
Then rescale your RGB values on the [0..255] interval.
This should give you a very boring but shadowless version of your original image. Of course if your goal is detecting single colour regions you could also just do this on the xy values in the xyY image and use the regions you detect there on the original.
how to get RGB values in percentage in photoshop.
and is cmyk percentage values are similar to RGB?
RGB and CMYK are different color modes.
RGB colors are screen colors. It is expressed in absolute values, usually in integer values from 0 to 255, representing the brightness on the screen. The exact range of values depends on the color depth of the image. The higher the value, the more light of that color is added, so the highest color is white.
CMYK colors are printing colors. They are used to represent the amount of ink used for a pixel. This is no absolute value, because it is merely a ratio between the color components. The higher the value, the darker it gets. 100% of each is (near) black, although real black is usually constructed by using 100% of K (key) and about 30% of each of the other components.
integer values from 0 to 255 are for 8 bit color, in the day of 16 or 32 bit color it would make sense to be able to view rgb as percentage values.
this is being added to Adobe lightroom currently does percentaes unless you're in the develop module, in soft proof mode