The colors in this table is all not transparent. I guess the value for the A is set to FF.
What is the code for transparency?
For example this color FFF0F8FF (AliceBlue), to a transparent code such as ??F0F8FF ?
Here is the table of % to hex values:
Example: For 85% white, you would use #D9FFFFFF.
Here 85% = "D9" & White = "FFFFFF"
100% — FF
95% — F2
90% — E6
85% — D9
80% — CC
75% — BF
70% — B3
65% — A6
60% — 99
55% — 8C
50% — 80
45% — 73
40% — 66
35% — 59
30% — 4D
25% — 40
20% — 33
15% — 26
10% — 1A
5% — 0D
0% — 00
How is it calculated?
FF is number written in hex mode. That number represent 255 in decimal. For example, if you want 42% to calculate you need to find 42% of numbeer 255 and convert that number to hex. 255 * 0.42 ~= 107 107 to hex is "6B
– maleta
Transparency is controlled by the alpha channel (AA in #AARRGGBB). Maximal value (255 dec, FF hex) means fully opaque. Minimum value (0 dec, 00 hex) means fully transparent. Values in between are semi-transparent, i.e. the color is mixed with the background color.
To get a fully transparent color set the alpha to zero. RR, GG and BB are irrelevant in this case because no color will be visible. This means #00FFFFFF ("transparent White") is the same color as #00F0F8FF ("transparent AliceBlue").
To keep it simple one chooses black (#00000000) or white (#00FFFFFF) if the color does not matter.
In the table you linked to you'll find Transparent defined as #00FFFFFF.
Adding to the other answers and doing nothing more of what #Maleta explained in a comment on https://stackoverflow.com/a/28481374/1626594, doing alpha*255 then round then to hex. Here's a quick converter http://jsfiddle.net/8ajxdLap/4/
function rgb2hex(rgb) {
var rgbm = rgb.match(/^rgba?[\s+]?\([\s+]?(\d+)[\s+]?,[\s+]?(\d+)[\s+]?,[\s+]?(\d+)[\s+]?,[\s+]?((?:[0-9]*[.])?[0-9]+)[\s+]?\)/i);
if (rgbm && rgbm.length === 5) {
return "#" +
('0' + Math.round(parseFloat(rgbm[4], 10) * 255).toString(16).toUpperCase()).slice(-2) +
("0" + parseInt(rgbm[1], 10).toString(16).toUpperCase()).slice(-2) +
("0" + parseInt(rgbm[2], 10).toString(16).toUpperCase()).slice(-2) +
("0" + parseInt(rgbm[3], 10).toString(16).toUpperCase()).slice(-2);
} else {
var rgbm = rgb.match(/^rgba?[\s+]?\([\s+]?(\d+)[\s+]?,[\s+]?(\d+)[\s+]?,[\s+]?(\d+)[\s+]?/i);
if (rgbm && rgbm.length === 4) {
return "#" +
("0" + parseInt(rgbm[1], 10).toString(16).toUpperCase()).slice(-2) +
("0" + parseInt(rgbm[2], 10).toString(16).toUpperCase()).slice(-2) +
("0" + parseInt(rgbm[3], 10).toString(16).toUpperCase()).slice(-2);
} else {
return "cant parse that";
}
}
}
$('button').click(function() {
var hex = rgb2hex($('#in_tb').val());
$('#in_tb_result').html(hex);
});
body {
padding: 20px;
}
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
Convert RGB/RGBA to hex #RRGGBB/#AARRGGBB:<br>
<br>
<input id="in_tb" type="text" value="rgba(200, 90, 34, 0.75)"> <button>Convert</button><br>
<br> Result: <span id="in_tb_result"></span>
BE AWARE 👇🏼
In HTML/CSS (browser code) the format is #RRGGBBAA with the alpha channel as last two hexadecimal digits.
Just use this:
android:background="#00FFFFFF"
it will do your work.
If you have your hex value, and your just wondering what the value for the alpha would be, this snippet may help:
const alphaToHex = (alpha => {
if (alpha > 1 || alpha < 0 || isNaN(alpha)) {
throw new Error('The argument must be a number between 0 and 1');
}
return Math.ceil(255 * alpha).toString(16).toUpperCase();
})
console.log(alphaToHex(0.45));
Just came across this and the short code for transparency is simply #00000000.
The standard hex color code has six characters eg #000000 - black, and the hex color code with more than six characters(likely 8 characters eg #82bc00 - green) exceeds the standard amount making the other two last characters define the transparency level.
so if you need to attain absolute transparency you can add 00 to any hex color but for uniformity you can just use #00000000
.green{
background: #82bc00 /*actual green*/
}
.subgreen{
background: #82bc0070 /*green with little transparency*/
}
.greenparency{
background: #82bc0040 /*green with much transparency*/
}
.transparency{
background: #82bc0000 /*full transparency over green*/
}
<div class="green"> green background color </div>
<div class="subgreen"> green background color </div>
<div class="greenparency"> green background color </div>
<div class="transparency"> green background color </div>
Related
If I have four colours (A, B, C & D) on four points on a line and I want to fill with a gradient that blends nicely between the four colours how would I calculate the colour of the point E?
and A is starting point and D is ending point, before starting point and after ending point fill starting colour and end colour. inside line need to blend colour according to the distance and angle.
The closer E is to any of the other points, the strong that colour should affect the result.
I need like this one.
Any idea how to do that? Speed and simplicity is preferred to accuracy.
Well, in simple terms, take point ß that is halfway between A and B. Assuming the use of RGB colors, if A is red rgb(255, 0, 0) and B is yellow rgb(255, 255, 0), then ß's color will be halfway between these: rgb(255, 128, 0), that is, orange.
As you can see this can be calculated by using a weighted average per color channel - weighted by how close your point is to A and B.
Here's a code example you can run right here:
const slider = document.getElementById("range")
const between = document.getElementById("between")
slider.addEventListener("input", ev => {
const distFromA = ev.target.value
const G = distFromA / 3.92
// Not calculating R and B values, as these don't change in this specific example
const R = 255
const B = 0
between.style.background = `rgb(${R}, ${G}, ${B})`
})
#A { background: red; color: white; }
#B { background: yellow; }
#between { background: gainsboro; }
#between, #A, #B { display: inline-block; width: 50px; height: 50px; }
<aside id=A>A</aside>
<aside id=between>ß</aside>
<aside id=B>B</aside>
<nav><input type=range min=0 max=1000 id=range /></nav>
Do this for each pixel and you get a gradient 👍
I need to convert 24-bit colors to 4-bit RGBI (1 bit for Red, Green, Blue + Intensity).
Converting to 3-bit RGB is rather simple: set color bit if greater than 127, clear otherwise. However, there's only one intensity bit for all three channels, so what's the correct way to set it (if any)?
First I thought about dividing 8-bit channel to three parts like below:
if 0 <= color <= 85, then clear rgbi-color bit
if 86 <= color <= 170, then set rgbi-color bit
if 171 <= color <= 255, then set rgbi-color bit and intensity
But then I thought that probably the correct way would be to set intensity bit only if two of three channels are greater than 127. But in that case pure R, G, or B will not have intensity ever set (for example, in case of rbg(0,0,200)
Any advice is highly appreciated
A simple way to find the closest 4-bit RGBI approximation of a color is to consider the two possibilities for the intensity bit separately. That is to say, first find the closest RGB0 and RGB1 approximations for the color (which is easy to do, just by dividing each color axis at the appropriate point), and the determine which of these approximations is better.
Here's a simple C-ish pseudocode description of this algorithm:
// find the closest RGBx approximation of a 24-bit RGB color, for x = 0 or 1
function rgbx_approx(red, green, blue, x) {
threshold = (x + 1) * 255 / 3;
r = (red > threshold ? 1 : 0);
g = (green > threshold ? 1 : 0);
b = (blue > threshold ? 1 : 0);
return (r, g, b);
}
// convert a 4-bit RGBI color back to 24-bit RGB
function rgbi_to_rgb24(r, g, b, i) {
red = (2*r + i) * 255 / 3;
green = (2*g + i) * 255 / 3;
blue = (2*b + i) * 255 / 3;
return (red, green, blue);
}
// return the (squared) Euclidean distance between two RGB colors
function color_distance(red_a, green_a, blue_a, red_b, green_b, blue_b) {
d_red = red_a - red_b;
d_green = green_a - green_b;
d_blue = blue_a - blue_b;
return (d_red * d_red) + (d_green * d_green) + (d_blue * d_blue);
}
// find the closest 4-bit RGBI approximation (by Euclidean distance) to a 24-bit RGB color
function rgbi_approx(red, green, blue) {
// find best RGB0 and RGB1 approximations:
(r0, g0, b0) = rgbx_approx(red, green, blue, 0);
(r1, g1, b1) = rgbx_approx(red, green, blue, 1);
// convert them back to 24-bit RGB:
(red0, green0, blue0) = rgbi_to_rgb24(r0, g0, b0, 0);
(red1, green1, blue1) = rgbi_to_rgb24(r1, g1, b1, 1);
// return the color closer to the original:
d0 = color_distance(red, green, blue, red0, green0, blue0);
d1 = color_distance(red, green, blue, red1, green1, blue1);
if (d0 <= d1) return (r0, g0, b0, 0);
else return (r1, g1, b1, 1);
}
Alternatively, you could simply use any generic fixed-palette color quantization algorithm. This may yield better results if your actual color palette is not a pure evenly spaced RGBI palette like the code above assumes, but rather something like e.g. the CGA tweaked RGBI palette.
I am trying to generate gutters which span 1/5 of 4 a column span. The global setup is:
$page-width: 1080px;
$susy: (
columns: 12,
math: fluid,
gutter-position: inside,
gutters: 1/4.5, // will be overriden; I think ...
global-box-sizing: border-box,
use-custom: (rem: true),
container: $page-width
);
Followed by this selector:
.mosaic {
// Setting gutters of 4 * 1/5 single column width,
// to be distributed 2/5 left, 2/5 right
#include gallery(4 of 12 4/5);
}
The generated CSS for .mosaic is:
.mosaic {
width: 33.33333%;
float: left;
padding-left: 1.85185%; // Expected/wanted: 3.333...%
padding-right: 1.85185%; // dito
}
I did expect the padding at each side to be 4/5 / 12 (columns) / 2 (sides) = 1/30 = 3.333...% which would result in a gutter of 1/5 (1/10 on each side) of the column span's total width.
How do I achieve the expected result?
How are the padding values (1.85...%) calculated?
Why do they not match what I expect?
This is how Susy does the math:
Each column is 1 column-unit wide, plus 4/5 column-units of gutter. Total: 1.8
There are 12 columns. Total: 21.6
Each gutter is calculated as .8/21.6 (target/context). Total: .037037037
That gutter is divided in half & converted to a percentage. Final: 1.8518518%
The difference is that gutters are considered part of the total context. They add to the width of each column, rather than being subtracted from it.
If you are given red, green, and blue values that range from 0-255, what would be the fastest computation to get just the hue value? This formula will be used on every pixel of a 640x480 image at 30fps (9.2 million times a second) so every little bit of speed optimization helps.
I've seen other formulas but I'm not happy with how many steps they involve. I'm looking for an actual formula, not a built in library function.
Convert the RGB values to the range 0-1, this can be done by dividing the value by 255 for 8-bit color depth (r,g,b - are given values):
R = r / 255 = 0.09
G = g / 255 = 0.38
B = b / 255 = 0.46
Find the minimum and maximum values of R, G and B.
Depending on what RGB color channel is the max value. The three different formulas are:
If Red is max, then Hue = (G-B)/(max-min)
If Green is max, then Hue = 2.0 + (B-R)/(max-min)
If Blue is max, then Hue = 4.0 + (R-G)/(max-min)
The Hue value you get needs to be multiplied by 60 to convert it to degrees on the color circle. If Hue becomes negative you need to add 360 to, because a circle has 360 degrees.
Here is the full article.
In addition to Umriyaev's answer:
If only the hue is needed, it is not required to divide the 0-255 ranged colours with 255.
The result of e.x. (green - blue) / (max - min) will be the same for any range (as long as the colours are in the same range of course).
Here is the java example to get the Hue:
public int getHue(int red, int green, int blue) {
float min = Math.min(Math.min(red, green), blue);
float max = Math.max(Math.max(red, green), blue);
if (min == max) {
return 0;
}
float hue = 0f;
if (max == red) {
hue = (green - blue) / (max - min);
} else if (max == green) {
hue = 2f + (blue - red) / (max - min);
} else {
hue = 4f + (red - green) / (max - min);
}
hue = hue * 60;
if (hue < 0) hue = hue + 360;
return Math.round(hue);
}
Edit: added check if min and max are the same, since the rest of the calculation is not needed in this case, and to avoid division by 0 (see comments)
Edit: fixed java error
Probably not the fastest but this is a JavaScript function that you can try directly in the browser by clicking the "Run code snippet" button below
function rgbToHue(r, g, b) {
// convert rgb values to the range of 0-1
var h;
r /= 255, g /= 255, b /= 255;
// find min and max values out of r,g,b components
var max = Math.max(r, g, b), min = Math.min(r, g, b);
// all greyscale colors have hue of 0deg
if(max-min == 0){
return 0;
}
if(max == r){
// if red is the predominent color
h = (g-b)/(max-min);
}
else if(max == g){
// if green is the predominent color
h = 2 +(b-r)/(max-min);
}
else if(max == b){
// if blue is the predominent color
h = 4 + (r-g)/(max-min);
}
h = h*60; // find the sector of 60 degrees to which the color belongs
// https://www.pathofexile.com/forum/view-thread/1246208/page/45 - hsl color wheel
// make sure h is a positive angle on the color wheel between 0 and 360
h %= 360;
if(h < 0){
h += 360;
}
return Math.round(h);
}
let gethue = document.getElementById('gethue');
let r = document.getElementById('r');
let g = document.getElementById('g');
let b = document.getElementById('b');
r.value = Math.floor(Math.random() * 256);
g.value = Math.floor(Math.random() * 256);
b.value = Math.floor(Math.random() * 256);
gethue.addEventListener('click', function(event) {
let R = parseInt(r.value)
let G = parseInt(g.value)
let B = parseInt(b.value)
let hue = rgbToHue(R, G, B)
console.log(`Hue(${R}, ${G}, ${B}) = ${hue}`);
});
<table>
<tr><td>R = </td><td><input id="r"></td></tr>
<tr><td>G = </td><td><input id="g"></td></tr>
<tr><td>B = </td><td><input id="b"></td></tr>
<tr><td colspan="2"><input id="gethue" type="button" value="Get Hue"></td></tr>
</table>
The web page Math behind colorspace conversions, RGB-HSL covers this however it contains what I believe is an error. It states for hue calculation to divide by max-min however if you divide by this fractional amount the value increases and easily exceeds the full expected range of -1 to 5. I found multiplying by max-min to work as expected.
Instead of this:
If Red is max, then Hue = (G-B)/(max-min)
If Green is max, then Hue = 2.0 + (B-R)/(max-min)
If Blue is max, then Hue = 4.0 + (R-G)/(max-min)
I suggest this:
If Red is max, then Hue = (G-B)*(max-min)
If Green is max, then Hue = 2.0 + (B-R)*(max-min)
If Blue is max, then Hue = 4.0 + (R-G)*(max-min)
You must specify which language and platform you're using because C#, Java and C are very different languages and the performance also varies among them and among the platforms. The question is currently too broad!!!
640×480 is not very large compared to current common resolutions, but "fastest" is subjective and you need to do careful benchmarking to choose which is best for your usecase. An algorithm that looks longer with many more steps isn't necessarily slower than a shorter one because instruction cycles are not fixed and there are many other factors that affect performance such as cache coherency and branch (mis)predictions.
For the algorithm Umriyaev mentioned above, you can replace the division by 255 with a multiplication by 1.0/255, that'll improve performance with a tiny acceptable error.
But the best way will involve vectorization and parallelization in some way because modern CPUs have multiple cores and also SIMD units to accelerate math and multimedia operations like this. For example x86 has SSE/AVX/AVX-512... which can do things on 8/16/32 channels at once. Combining with multithreading, hardware acceleration, GPU compute.... it'll be far better than any answers in this question.
In C# and Java there weren't many vectorization options in the past so with older .NET and JVM versions you need to run unsafe code in C#. In Java you can run native code through JNI. But nowadays all of them also had vectorized math support. Java had a new Vector API in JEP-338. In Mono you can use the vector type in the Mono.Simd namespace. In RyuJIT there's Microsoft.Bcl.Simd. In .NET 1.6+ there's System.Numerics which includes Vector and other
... SIMD-enabled vector types, which include Vector2, Vector3, Vector4, Matrix3x2, Matrix4x4, Plane, and Quaternion.
How to use the Intel AVX in Java?
Parallelism on a Single Core - SIMD with C#
SIMD in Depth - Performance and Cost in C# and C++
Will .NET ever do intelligent SIMD?
Using System.Numerics.Vector for Graphics Programming
System.Numerics.Vectors 'Vector<T>': is it basically just System.UInt128?
Performance Gains with Data Parallelism: Using SIMD Instructions from C#
You could use one of the mathematical techniques suggested here, but instead of doing it on every pixel, do it on a random sample of ~10% of the pixels. This is still very likely to have high accuracy and will be 10x as fast.
By reading HSL/HSV color theory, I get the impression that hue component is a cyclical attribute that repeats every 360 degrees and can be changed independently of saturation and lightness/value. Correct me if I am wrong, but these statements logically follow the previous definition:
Rotating hue by 360 degrees yields the same color
Rotating hue by 180 degrees twice yields the original color
Rotating hue by 180 degrees followed by -180 degrees yields the original color
However, only the option 1 is correct. Rotating hue 4 times by +90 degrees yields a color that isn't even remotely similar to the original.
Furthermore, using -webkit-filter and SVG's
<filter><feColorMatrix in="SourceGraphic" type="hueRotate" values="..." /></filter>
don't produce the same result for the same rotation. On the other hand, colors produced by SVG filters are consistent across browsers.
Is there any "hidden" property of hue rotation that makes the operation not associative?
Examples of both webkit filters and SVGs can be found here: http://jsfiddle.net/maros_urbanec/ARsjb/5/
In both CSS and SVG filters, there is no conversion into HSV or HSL - the hueRotation shorthands are using a linear matrix approximation in RGB space to perform the hue rotation. This doesn't conserve saturation or brightness very well for small rotations and highly saturated colors - as you're seeing.
A true hue rotation, would first convert the input RGB color to HSL, adjust the H and then convert back to RGB. Filters don't do this. And this conversion can't be accurately approximated with a linear matrix, so while the hue is accurately changed(mostly), the saturation and brightness goes all over the place. These effects are non-linear, so adding smaller ops together results in different colors vs. doing one big operation.
(The difference between huerotation in SVG and CSS filters could be due to using different color spaces (sRGB vs. linearRGB) - these should be the same.)
Update: I got interested enough to go and do a manual comparison. As you can see, filters do a terrible job of hue rotating pure colors in the 0 to 180 degree range. This image compares a manual hue rotation done by plugging in hsl colors manually (outer ring) vs. a filter hue rotation on the base color (inner ring)
But, they do a better job at less pure colors like hsl(0,50%,75%) as you can see.
codepen link in case you want to play: http://codepen.io/mullany/pen/fwHrd
Michael's answer is awesome, and I wish I had seen it before; but since I need to not only understand they're damn wierd but also in which way (I want to work around their logic so I need the maths), I've coded a hue-rotate implementation in Javascript (which was mostly taken from reading Firefox's source code), which emulates the hue-rotate that Webkit/Blink/Gecko use.
Again, the whole point here is just to understand what results it produces.
function calculate() {
// Get the RGB and angle to work with.
var color = document.getElementById('color').value;
if (! /^[0-9A-F]{6}$/i.test(color)) return alert('Bad color!');
var angle = document.getElementById('angle').value;
if (! /^-?[0-9]+$/i.test(angle)) return alert('Bad angle!');
var r = parseInt(color.substr(0, 2), 16);
var g = parseInt(color.substr(2, 2), 16);
var b = parseInt(color.substr(4, 2), 16);
var angle = (parseInt(angle) % 360 + 360) % 360;
// Hold your breath because what follows isn't flowers.
var matrix = [ // Just remember this is the identity matrix for
1, 0, 0, // Reds
0, 1, 0, // Greens
0, 0, 1 // Blues
];
// Luminance coefficients.
var lumR = 0.2126;
var lumG = 0.7152;
var lumB = 0.0722;
// Hue rotate coefficients.
var hueRotateR = 0.143;
var hueRotateG = 0.140;
var hueRotateB = 0.283;
var cos = Math.cos(angle * Math.PI / 180);
var sin = Math.sin(angle * Math.PI / 180);
matrix[0] = lumR + (1 - lumR) * cos - lumR * sin;
matrix[1] = lumG - lumG * cos - lumG * sin;
matrix[2] = lumB - lumB * cos + (1 - lumB) * sin;
matrix[3] = lumR - lumR * cos + hueRotateR * sin;
matrix[4] = lumG + (1 - lumG) * cos + hueRotateG * sin;
matrix[5] = lumB - lumB * cos - hueRotateB * sin;
matrix[6] = lumR - lumR * cos - (1 - lumR) * sin;
matrix[7] = lumG - lumG * cos + lumG * sin;
matrix[8] = lumB + (1 - lumB) * cos + lumB * sin;
function clamp(num) {
return Math.round(Math.max(0, Math.min(255, num)));
}
var R = clamp(matrix[0] * r + matrix[1] * g + matrix[2] * b);
var G = clamp(matrix[3] * r + matrix[4] * g + matrix[5] * b);
var B = clamp(matrix[6] * r + matrix[7] * g + matrix[8] * b);
// Output the result
var result = 'The original color, rgb(' + [r,g,b] + '), '
+ 'when rotated by ' + angle + ' degrees '
+ 'by the devil\'s logic, gives you '
+ 'rgb(' + [R,G,B] + '). If I got it right.';
document.getElementById('result').innerText = result;
}
// Listen for Enter key press.
['color', 'angle'].forEach(function(i) {
document.getElementById(i).onkeypress = function(event) {
var e = event || window.event, c = e.which || e.keyCode;
if (c == '13') return calculate();
}
});
body {
font: 14px sans-serif;
padding: 6px 8px;
}
input {
width: 64px;
}
<p>
This algorithm emulates the wierd, nonsensical and completely
idiotic <code>hue-rotate</code> CSS filter. I wanted to know
how it worked, because it is out of touch with any definition
of "hue" I've ever seen; the results it produces are stupid
and I believe it was coded under extreme influence of meth,
alcohol and caffeine, by a scientologist listening to Death Metal.
</p>
<span>#</span>
<input type="text" id="color" placeholder="RRGGBB">
<input type="text" id="angle" placeholder="degrees">
<button onclick="calculate()">Calculate</button>
<p id="result"></p>
The snippet was taken from this answer.
tl;dr Error from converting colors from floats (inside the filter) to bytes (everywhere else).
So it's a bit more complicated than that, the spec provides a good formula for hue rotation matrices, for instance the one for 180 degrees is (excluding alpha and shifts):
-0.5747 1.4304 0.1444
0.4252 0.4304 0.1444
0.4252 1.4304 -0.8556
Note, if you multiply that by itself you get (to four decimal places):
0.9999 0.0001 0.0000
0.0000 1.0 0.0
0.0000 0.0000 1.0
which is very close to the identity matrix, or a null transformation.
That would be perfect, except that the browser is converting back to RGB between each filter. Look what happens when we hue-rotate bright red:
-0.5747 1.4304 0.1444 1 -0.5747
0.4252 0.4304 0.1444 * 0 = 0.4252
0.4252 1.4304 -0.8556 0 0.4252
We get a color that's impossible to represent in RGB with values from 0 to 255. So it gets bound and rounded to 0 0.4235 0.4235 during the RGB conversion, and when it's rotated again we end up with a dark desaturated red, 0.6667 0.2431 0.2431 instead of the bright pure red we started with.