I am parsing colour codes that I get from a Flex(Flash ActionScript) application, then creating HTML div elements with that same colour.
My Problem: The colours are all only 8 digits long. So they cant be RGB colour values can they? What color value format are they in? If I can figure the format they are in I can convert them to RGB. Maybe the last/first digit signifies its 0. alpha value?
PS: Should I convert the colours to RGB or something else?
This is an example of the colour code values I getting from the flash application:
16777215
4803910
84545883
16777215
RGB colours are represented by hexadecimal digits (base 16).
Base 16 means that each place in the number can represent numbers 0-15 in this order:
0 1 2 3 4 5 6 7 8 9 A B C D E F
Using 0x in AS3 represents a hex number. As an example, run this:
trace(0xF); // 15
The output as you can see is represented in decimal (base 10). What you're seeing above in your question is the decimal representation of your colours.
If you want to see the hex version, use toString() and parse 16 as the radix parameter. You'll notice that the default is 10 (for base 10 / decimal numbers that we all know and love).
var num:int = 15;
trace(num.toString(16)); // f
Hope this makes sense.
Related
Is there a way in SSRS code to convert a color name to hex or 3 ints of the a RGB value? ie convert "Silver" to 0xC0C0C0 or (192,192,192).
Thanks Alan,
I was able to find it from the first link. SSRS report listing all available colors
System.Drawing.Color.FromName(my_color)
I can't figure out the difference between the "Color Resolution" field and the "Size of Global Color Table" field in the gif89a spec https://www.w3.org/Graphics/GIF/spec-gif89a.txt (page 9-10):
Color Resolution - Number of bits per primary color [...], minus 1. This value represents the size of the entire palette [...]
Size of Global Color Table - [...] To determine that actual size of the color table, raise 2 to [the value of the field + 1].
...
[The Global Color Table] is a sequence of bytes representing red-green-blue color triplets [...] and contains a number of bytes equal to 3 x 2^(Size of Global Color Table+1).
Let's say we want to create an image with 3 colors, red, green and blue. In this case we need at least ceil(log2(3)) = 2 bits per color (00 = red, 01 = green, 10 = blue). Then, according to the spec, the Color Resolution (CR) field must be set to ceil(log2(3)) - 1 = 2 - 1 = 1:
packed fields = X001XXXX
---
CR field
More generally, if N is the number of colors, then CR = ceil(log2(N)) - 1.
Regarding the size of the Global Color Table (GCT), 1 color requires 3 RGB bytes, therefore the number of entries = the number of bytes / 3 = 2^(Size of GCT + 1). Since we want to store 3 colors, I would go for the power of 2 that comes immediately after 3, which is 2 raised to ceil(log2(3)) = 2^2 = 4. Then, 2^(Size of GCT + 1) = 2^ceil(log2(3)), Size of GCT + 1 = ceil(log2(3)) and Size of GCT = ceil(log2(3)) - 1 = 2 - 1 = 1:
packed fields = XXXXX001
---
Size of GCT field
Again, if N is the number of colors, then Size of GCT = ceil(log2(N)) - 1.
As you can see, CR = Size of GCT = ceil(log2(N)) - 1. It seems like the CR field and the Size of GCT field always hold the same value. I suppose I'm wrong because if I was right one of these two fields would be useless, but I didn't find any clarification in the spec so far.
I'm not alone being confused: http://giflib.sourceforge.net/whatsinagif/bits_and_bytes.html. This article applies the definition of the Size of GCT field to the CR field, and the Size of GCT field is simply not defined at all:
[...] the color resolution [...] allow you to compute [the] size [of the GCT]. If the value of this filed is N, the number of entries in the global color table will be 2 ^ (N+1) [...]. Thus, the 001 in the sample image represents 2 bits/pixel; 111 would represent 8 bits/pixel.
Anybody knows a situation where these two fields differ?
From the spec:
iv) Color Resolution - Number of bits per primary color available
to the original image, minus 1. This value represents the size of
the entire palette from which the colors in the graphic were
selected, not the number of colors actually used in the graphic.
For example, if the value in this field is 3, then the palette of
the original image had 4 bits per primary color available to create
the image. This value should be set to indicate the richness of
the original palette, even if not every color from the whole
palette is available on the source machine.
So to be clear, color resolution is supposed to be the number of bits per color (less 1) in the original image the GIF was made from.
A bag contains 16 balls of following colors: 8 red, 4 blue, 2 green, 1 black and 1 white. Anisha picks a ball randomly from the bag and messages Babu its color using a string of zeros and ones. She replaces the ball in the bag and repeats this experiment many times. What is the minimum expected length of the message she has to convey to Babu per experiment?
(a)3/2
(b)log 5
(c)15/8
(d)31/16
(e)2
According to me, since the ball is taken out with replacement. At any time, there are 16 balls of 5 different colors in the bag. To encode 5 colors, ceiling of log5 (base 2) i.e. 3 bits should be needed but the answer given is (15/8). Can someone point out my mistake and provide some hint for the correct solution?
using static huffman compression you can encode the more common colours in fewer bits than the rare colours, that being the case on can expect that common colours will usually be chosen.
eg:
red 1
blue 01
green 001
white 0001
black 0000
on average from 16 draws there will be
8 reds = 8 bits
4 blues = 8 bits
2 greens = 6 bits
1 white = 4 bits
1 black = 4 bits
for a total of 30/16 bits on average
Your answer is right as the maximum value needed for encoding. But consider the following coding scheme 1 - red (1/2 prob), 01 - blue (1/4 prob), 00 - green (1/8 prob), 001 - black (1/16 prob), 000 - white (1/16 prob) multiply message length by probability and you should have 1 + 5/8 ( not 15/8 ... though)
I want to draw a chart in linux like this:
1################# 64.85
2################### 72.84
3####################### 91.19
4####################### 91.61
5########################### 108.66
6############################ 110.69
7###################################### 149.85
8####################################### 156.60
9########################################### 169.81
I want to do that in python, of course you noticed that I don't want code like:
for i in data:
print "#"*i
because data may contain big numbers, so it is not nice to print "#" milion times.
So what is the mathematical equation that I must use to do this, I think this is a kind of mathematical problem
Thanks a lot
You have to work with percentages I think sum up all you values and then you do bar value / total of bar values
So if I have the following values 1 2 3 6 the total will be 12 so then
i will do 1 / 12 the percentage will be 8 so you print '#' 8 times and so on.
then the max # you can print is hundred.
I don't know if this is what you want, but hope this will help.
I have an (R, G, B) triplet, where each color is between 0.0 and 1.0 . Given a factor F (0.0 means the original color and 1.0 means white), I want to calculate a new triplet that is the “watermarked” version of the color.
I use the following expression (pseudo-code):
for each c in R, G, B:
new_c ← c + F × (1 - c)
This produces something that looks okayish, but I understand this introduces deviations to the hue of the color (checking the HSV equivalent before and after the transformation), and I don't know if this is to be expected.
Is there a “standard” (with or without quotes) algorithm to calculate the “watermarked” version of the color? If yes, which is it? If not, what other algorithms to the same effect can you tell me?
Actually this looks like it should give the correct hue, minus small variations for arithmetic rounding errors.
This is certainly a reasonable, simple was to achieve a watermark effect. I don't know of any other "standard" ones, there are a few ways you could do it.
Alternatives are:
Blend with white but do it non-linearly on F, e.g. new_c = c + sqrt(F)*(1-c), or you could use other non-linear functions - it might help the watermark look more or less "flat".
You could do it more efficiently by doing the following (where F takes the range 0..INF):
new_c = 1 - (1-c)/pow(2, F)
for real pixel values (0..255) this would convert into:
new_c = 255 - (255-c)>>F
Not only is that reasonably fast in integer arithmetic, but you may be able to do it in a 32b integer in parallel.
Why not just?
new_c = F*c
I think you should go first over watermarking pixels and figure out if it should be darker or lighter.
For lighter the formula might be
new_c=1-F*(c-1)