I am working on RGB color formats and I came across the RGB formats as listed here. I was just wondering what will be the 25-bit ARGB1888 format bit-stream look like.
Will it be
AUUUUUUU RRRRRRRR GGGGGGGG BBBBBBBB
or
UUUUUUUA RRRRRRRR GGGGGGGG BBBBBBBB
where A = Alpha bit, U = unused bit, R = Red Color, G = Green Color, B = Blue Color.
Any help is greatly appreciated.
Thank You.
Related
I am trying to make a little script to switch the rgb values of an image. The code I have works to alter the image, but the list of images is out of order when compared to the list of permutations. I have been unable to figure out why the images at indices 3 and 4 are switched in order.
from skimage import io
import numpy as np
import itertools
def create_permutations_auto(image):
im_col = np.split(image, 3, axis = -1)
color_keys = ["red", "green", "blue"]
colors = dict(zip(color_keys, im_col))
cp = list(itertools.permutations(color_keys))
im_list = []
for perm in cp:
color_data = [colors.get(k) for k in perm]
image = np.squeeze(np.stack(color_data, axis = -1))
im_list.append(image)
return cp, im_list
orig = io.imread(filename)
text, image_perms = create_permutations_auto(orig)
for i in range(len(image_perms)):
print text[i]
io.imshow(image_perms[i])
io.imsave(filepath + "{}_{}_{}.png".format(text[i][0], text[i][1], text[i][2]), image_perms[i])
io.show()
I would expect this code to output the original image with the green values replacing the red, the blue values replacing the green and the red values replacing the blue for the fourth image created. However, what I get is blue → red, red → green, and green → blue. The fifth image created seems like it should be the fourth.
Third Image (should be green, blue, red):
Fourth Image(should be blue, red, green):
To see if it was the something to do with the order of the dictionary, I tried to do the permutations manually. Using the following:
def create_permutations(image):
red, green, blue = np.split(image, 3, axis = -1)
perms = []
perms.append(np.squeeze(np.stack((red, blue, green), axis = -1)))
perms.append(np.squeeze(np.stack((green, red, blue), axis = -1)))
perms.append(np.squeeze(np.stack((green, blue, red), axis = -1)))
perms.append(np.squeeze(np.stack((blue, green, red), axis = -1)))
perms.append(np.squeeze(np.stack((blue, red, green), axis = -1)))
return perms
This code also seems to switch the placements of the two same permutations although it is the images at index 2 and 4. For this simple example, I can switch them around but it seems like I am missing something fundamental here. I am using a Python(x,y) distribution with Python 2.7.10 and numpy 1.12.1 on a machine running windows 10.
The effect of spectral permutation is different from that of spatial permutation. When you split the original image into its chromatic bands, referred to as red, green, and blue, and then you rearrange them as blue, red, and green, the order of the colors from left to right in the resulting image is green-blue-red (spectral permutation) rather than blue-red-green (spatial permutation).
The figure below is intended to schematically explain such a counter-intuitive result. For the sake of clarity let us denote the red, green, and blue chromatic channels with indices 0, 1, and 2, respectively. It clearly emerges from the figure that the intensities of the pixels in the leftmost region of the image are transformed through permutattion from [255, 0, 0] to [0, 255, 0], Indeed, in the leftmost region of the permuted image pixels' intesities are 0 for channel 0 (red component), 255 for channel 1 (green component), and 0 for channel 2 (blue component). That's the reason why the color of the leftmost region of the image changes from red to green. Similar arguments apply to the central and rightmost regions.
Bonus
You could simplify your function like this:
def create_permutations_auto(img):
colors = {0: 'red', 1: 'green', 2: 'blue'}
index_perm = list(itertools.permutations(colors.keys()))
cp = [tuple(colors[i] for i in perm) for perm in index_perm]
im_list = [np.dstack([img[:, :, i] for i in perm]) for perm in index_perm]
return cp, im_list
I have a program that generates an grayscale image. The grayshading for every pixel is set with the following code sniped:
//loop over all pixel
*PixelColorPointer = Number * 0x010101;
in this case the Number is an integer number between 0 and 255. Which generates all grayscale colors from black to white.
What I try to do is have an colored image (in order to have false colors), but I don't really understand the calculation with the hex value. I figured out if I assign e.g. Number * 0xFFFFFF I have a gradient/variety from white to yellow.
Can someone explain me how the calculation of this colors is working? Please remember that (as said already) I want/have to pass the Number variable to get variety.
RGB color are stored byte by byte (0 to 255).
When you say 0x010203 it is (in hex) 01 red, 02 green, and 03 blue. It can also be inverted (03 red, 02 green, 01 blue) depending on your Endianness.
Here you have to separate your 3 colors. Then you shoud multiply every color by it's coefficient.
You can store your color in an union, it's the easiest way.
union Color
{
struct
{
unsigned char b;
unsigned char g;
unsigned char r;
unsigned char a; // Useless here
};
unsigned int full;
};
Color c;
c.full = 0x102030;
unsigned char res = 0.229 * c.r + 0.587 * c.g + 0.114 * c.b;
Color grey;
grey.r = grey.g = grey.b = res;
0.229, 0.587 and 0.114 are the Relative luminance.
Remember, you might need to invert the rgba order and move the a place :)
You need to give a little more information. What library of function are you using to do this??
But by just seeing the problems I think the hexadecimal number refers to the color in the Color-hex code, the Number would refer to the brightness 0 being blank and 255 max color intensity (white)
EDIT: Actually I think the whole number resulting from:
Number * 0x010101
Is the hexadecimal color code, in the particular case of 0x010101 the Number works as the intensity. But any other hexadecimal would give you some weird result.
Use an Color-hex code table choose any random color and just input :
*PixelColorPointer = 0XHEXCODE;
if the output is the desired color then I'm right
Assuming I have a photographic film negative scanned as an RGB image, I'm trying to find an algorithm that will convert the color values to an RGB positive.
Due to the orange bias ( http://photo.net/learn/orange-negative-mask ) if I simply say redPositive = 255 - redNegative I get a final image that has a strong cyan tint to it, and is very washed out. That means the answers given here: Convert negative image to positive are NOT correct.
So how would I craft the following routine:
struct RGB
{
unsigned byte red;
unsigned byte green;
unsigned byte blue;
};
void FilmNegativeToPositive(RGB const &negative, RGB &positive)
{
// What goes here?
}
I don’t have data to test, but according to the link you gave, the negative is a mixture of cyan, magenta and yellow dyes that are impure:
The yellow dye layer is the most pure. The magenta dye layer has a noticeable amount of yellow in it. The cyan dye layer has noticeable amounts of both yellow and magenta in it.
Therefore, you want to do something like this (untested pseudocode):
Let I_MY be the ratio of yellow impurity to pure magenta dye
Let I_CY be the ratio of yellow impurity to pure cyan dye
Let I_CM be the ratio of magenta impurity to pure cyan dye
Given R, G, B in [0, 255]
Convert to CMY:
C = 1.0 - R/255.0
M1 = 1.0 - G/255.0
Y1 = 1.0 - B/255.0
Calculate the impurities in the cyan dye and remove them, since we assume no other dye has cyan impurities:
M = M1 - I_CM×C
Y2 = Y1 - I_CY×C
Now the amount of magenta dye is correct, so subtract its yellow impurity:
Y = Y2 - I_MY×M
Convert the corrected CMY values back to RGB:
R' = 255×(1.0-C)
G' = 255×(1.0-M)
B' = 255×(1.0-Y)
If it turns out there’s more complicated contamination than that, you get a linear algebra problem:
[ 1 I_MC I_YC] [C'] [C]
[I_CM 1 I_YM] × [M'] = [M]
[I_CY I_MY 1] [Y'] [Y]
Where you want to solve for C', M', and Y', then convert back to the RGB color space.
I have a given color and want to create variations of it in terms of hue, saturation and lightness.
I found a webpage which creates variations the way I would like it (See http://coloreminder.com/). However, I do not entirely understand how these variations are created for an arbitrary color. From what I can tell from considering created variations at this home page, it seems not to be enough to simply change the HSL values separately to create variations.
Hence, I wanted to ask if anybody knows an approach for creating these variations, or ideally knows where to get a piece of code to adopt this kind of color variations creation in my own program?
I am using C++ and QT.
EDIT: Thank you for your replies! Actually the variations of the given homepage really only varies the HSL values separately in 10% steps. I got confused since I compared the values with HSV values in color picker of my program.
From what I can tell from considering created variations at this home page, it seems not to be enough to simply change the HSL values seperately to create variations.
Really? The interface seems to be clear enough about what modifications it makes. You can select "hue", "saturation" or "luminance" and it shows 9 variations on that channel. The following MATLAB script will plot the different variations in a similar way (although in the HSV color space, not HSL).
% display n variations of HTML-style color code.
function [] = colorwheel ( hex, n )
% parse color code.
rgb = hex2rgb(hex);
% render all variations.
h = figure();
for j = 1 : 3,
% build n variations on current channel.
colors = variantsof(rgb, j, n);
% display variations.
for i = 1 : n,
% generate patch of specified color.
I = zeros(128, 128, 3);
I(:,:,1) = colors(i, 1);
I(:,:,2) = colors(i, 2);
I(:,:,3) = colors(i, 3);
% render patches side-by-side to show progression.
imshow(I, 'parent', ...
subplot(3, n, (j-1)*n+i, 'parent', h));
end
end
end
% parse HTML-style color code.
function [ rgb ] = hex2rgb ( hex )
r = double(hex2dec(hex(1:2))) / 255;
g = double(hex2dec(hex(3:4))) / 255;
b = double(hex2dec(hex(5:6))) / 255;
rgb = [r g b];
end
% generate n variants of color on j-th channel.
function [ colors ] = variantsof ( rgb, j, n )
colors = zeros(n, 3);
for i = 1 : n,
% convert to HSV.
color = rgb2hsv(rgb);
% apply variation to selected channel.
color(j) = color(j) + ((i-1) / n);
if color(j) > 1.0,
color(j) = color(j) - 1.0;
end
% convert to RGB.
colors(i,:) = hsv2rgb(color);
end
% order colors with respect to channel.
if j > 1,
colors = sortrows(colors, j);
end
end
Using the "goldenrod" sample color, as:
colorwheel('daa520', 9);
I get:
The first row is a variation on hue, the second on saturation and the third on value. The outputs don't correspond exactly to the ones on the coloreminder.com, but this is explained by the difference in color space and exact value used in permutations.
Have you read through the documentation for QColor?
The QColor class itself provides plenty of useful functions for manipulating colors in pretty much any way you can think of, and the documentation itself explains some basic color theory as well.
I have a jpeg image with the colors encoded in the YCCK color space. I have already decoded it in C++ using libjpeg. How can I convert it to RGB?
Converting it to CMYK would also be useful for me, since I know how to convert from CMYK to RGB using ICC color profiles.
Have a look here.
First, conversion is done into RGB format as:
R = Y + 1.402*Cr - 179.456
G = Y - 0.34414*Cb - 0.71414*Cr + 135.45984
B = Y + 1.772*Cb - 226.816
After that, conversion to CMYK image is performed as follows:
C = 255 – R
M = 255 – G
Y = 255 – B
The values of K channel are written without modification.