In the following value below does it mean that the ouput device must have 256 colors exactly or can the ouput device have 256 or less or must the ouput device have 256 or more? Can someone explain this to me in simple terms?
(color-index: 256)
From the W3C docs:
The ‘color-index’ media feature describes the number of entries in the color lookup table of the output device. If the device does not use a color lookup table, the value is zero.
From that description, and from the examples after it, it appears that the answer is that it is the exact number of colors in the index (should it exist).
You may specify a minimum with min-color-index.
(color-index: 256) matches any device with 256 colors exactly.
(min-color-index: 256) matches any device with at least 256 colors
it's the bit quantity for the applying object color
From my understanding it is exact and you can you min and max prefixes to determine ranges.
W3C Docs
Related
I have an array of bytes that represents the palette indexes of the pixels of an image, and I'm trying to convert this to an image with ImageSharp, so I can save it later as PNG, but I can't seem to find how, can anyone give me an idea on where to look? The palette is not important, I just need N different colors.
ImageSharp images represent the expanded pixel buffer, not references to color palettes. If you have the original palette use it to create the input buffer of actual pixel data. A byte array as described is not, in real terms a fully decoded image.
Reducing a color set to a maximum amount is a question of quantization. There are methods that allow you to do this as well as encoding options that allow saving images in indexed formats.
I've been looking at this page, as well as this code example and I've noticed that the x_advance, y_advance, x_offset and y_offset fields in hb_glyph_position_t are of the type hb_position_t, which is an alias to int32_t. I haven't found any documentation about which units are used for these fields. The examples above suggest that they're 64ths of something, but that's all I can infer.
Does anyone else know the exact unit implied by hb_position_t?
It is in input font size units (say pixels).
The idea there is you multiply the input font size by 64 then you divide the position by 64 after the shaping so you will be in control of how much sub pixel precision you need.
This is related to CSS color codes:
For hexcode we can represent 16,777,216 colors from #000000 to #FFFFFF
According to W3C Specs, Valid RGB percentages fit in a range from (0.0% to 100.0%) essentially giving you 1,003,003,001 color combinations. (1001^3)
According to the specs:
Values outside the device gamut should be clipped or mapped into the gamut when the gamut is
known: the red, green, and blue values must be changed to fall within the range supported by
the device. Users agents may perform higher quality mapping of colors from one gamut to
another. For a typical CRT monitor, whose device gamut is the same as sRGB, the four rules
below are equivalent:
I'm doubtful if browsers actually can render all these values. (but if they do please tell me and ignore the rest of this post)
Im assuming there's some mapping from rgb(percentage) to hex. (but again Im not really sure how this works)
Ideally I'd like to find out the function rgb(percentage)->HEX
If I had to guess it would probably be one of these 3.
1) Round to the nearest HEX
2) CEIL to the nearest HEX
3) FLOOR to the nearest HEX
Problem is I need to be accurate on the mapping and I have no idea where to search.
There's no way my eyes can differentiate color at that level, but maybe there's some clever way to test each of these 3.
It might also be browser dependent. Can this be tested?
EDIT:
Firefox seems to round from empirical testing.
EDIT:
I'm looking through Firefox's source code right now,
nsColor.h
// A color is a 32 bit unsigned integer with four components: R, G, B
// and A.
typedef PRUint32 nscolor;
It seems Fiefox only has room for 255 values for each R,G and B. Hinting that rounding might be the answer, but maybe somethings being done with the alpha channel.
I think I found a solution for Firefox anyways, thought you might like a follow up:
Looking through the source code I found a file:
nsCSSParser.cpp
For each rgb percentages it does the following:
It takes the percentage component multiplies it by 255.0f
Stores it in a float
Passes it into a function NSToIntRound
The result of NSToIntRound is stored into an 8 bit integer datatype,
before it is combined with the other 2 components and an alpha
channel
Looking for more detail on NSToIntRound:
nsCoord.h
inline PRInt32 NSToIntRound(float aValue)
{
return NS_lroundf(aValue);
}
NSToIntRound is a wrapper function for NS_lroundf
nsMathUtils.h
inline NS_HIDDEN_(PRInt32) NS_lroundf(float x)
{
return x >= 0.0f ? PRInt32(x + 0.5f) : PRInt32(x - 0.5f);
}
This function is actually very clever, took me a while to decipher (I don't really have a good C++ background).
Assuming x is positive
It adds 0.5f to x and then casts to an integer
If the fractional part of x was less than 0.5, adding 0.5 won't change the integer and the fractional part is truncated,
Otherwise the integer value is bumped by 1 and the fractional part is truncated.
So each component's percentage is first multiplied by 255.0f
Then Rounded and cast into a 32bit Integer
And then Cast again into an 8 bit Integer
I agree with most of you that say this appears to be a browser dependent issue, so I will do some further research on other browsers.
Thanks a bunch!
According to W3C Specs, Valid RGB percentages fit in a range from (0.0% to 100.0%) essentially giving you 1,003,003,001 color combinations. (1001^3)
No, more than that, because the precision is not limited to one decimal place. For example, this is valid syntax:
rgb(23.456% 78.90123456% 0%)
The reason for this is that, while 8 bits per component is common (hence hex codes) newer hardware supports 10 or 12 bits per component; and wider gamut colorspaces need more bits to avoid banding.
This bit-depth agnosticism is also why newer CSS color specifications use a 0 to 1 float range.
Having said which, the CSS Object Model still requires color values to be serialized at 8 bits per component. This is going to change, but the higher-precision replacement is still being discussed in the CSS working group. So for now, browsers don't let you get more than 8 bits per component of precision.
If you are converting a float or percentage form to hex (or to 0 - 255 integer) the correct method is rounding. Floor or ceiling will not spec the values evenly at the top or bottom of the range.
what is the color limit for designing a website? is it limited to 256?
will it work on all browsers if i select any color from photoshop color palette?
edit: i am talking about the color attribute in the css
The same as the display of the user viewing the website (which, more often then not, is 32-bit these days).
If you mean how many colors you can specify using rgb() or hex codes, you can specify up to
256 * 256 * 256 = 16,777,216
different colors (each 256 corresponds to a range of 0 (0x0) to 255 (0xFF) for each of red, green and blue).
This does not consider the web-safe color palette of 216 colors that Martin Beeby mentions, or the display capabilities of any monitors for that matter.
Back in the day, Netscape Listed 216 colours that were considered websafe. Nowadays that can be ignored as most computers are capable of reproducing all millions of colours... Worst case senario the browser will dither the colour to somthing the graphics card on the computer can display.
See http://en.wikipedia.org/wiki/Web_colors for more info.
In how many ways we can give color info in X/HTML, css?
I know some
Hex
color name
rgba
is there any other method?
and which method is preferred to use and which not? Please give explanation.
The three ways you mention are the only three.
I don't think a specific method is generally preferred, but as a developer, I like to see hex numbers.
I would avoid color names simply because if you want to know the true value of a color you have to look it up which is an annoyance in my workflow.
Also, hex numbers are the most compact way to describe a color (for most colors), so you might be saying a couple bytes of bandwidth by using hex. This doesn't really matter, but it's one of the only differences I can think of.
There is one more method: the one you're missing is old RGB. RGBa includes opacity (that's the 'a', for alpha)--it's not the same as RGB. RGB is supported by a wide array of browsers, old and new; RGBa is supported by a narrower but significant set of browsers: http://css-tricks.com/rgba-browser-support/ (IE being the main holdout, as usual).
Which method you use really doesn't matter. I prefer hex from habit, but am starting to use RGB more so that I can start getting used to extending it to RGBa.