A terse reference with comparisons to JS
# No semicolons, no braces. Blocks defined by colon + indentation.
if x > 0:
print(x)- JS:
{}blocks,;
| ———————————————————————————————————————————————————————————————————————————————————————————————————— | |
| BBEdit / BBEdit-Lite / TextWrangler Regular Expression Guide Modified: 2018/08/10 01:19 | |
| ———————————————————————————————————————————————————————————————————————————————————————————————————— | |
| NOTES: | |
| The PCRE engine (Perl Compatible Regular Expressions) is what BBEdit and TextWrangler use. | |
| Items I'm unsure of are marked '# PCRE?'. The list while fairly comprehensive is not complete. |
Fast integer lightness calculations from RGB — by Andrew Somers
This is part of an experiment in estimating a perceived brightness while remaining in integer math and using bitshifts to maximize performance (avoiding all subtraction, division, and square-root calculations).
The traditional means to determine the perceived lightness or brightness for a given color value is to first normalize R, G, and B from 0-255 to 0.0-1.0, linearize the values via exponent or more exotic methods (we assume colors are in a gamma encoded color space, such as sRGB), and then after linearizing, creating a linear luminance value by applying coefficients to each of the R, G, B values, adding them, and then finally applying an exponent or more exotic math to find a predicted lightness value.
| // An object of Kelly's 22 colors, converted from rjurney's array | |
| // Color names are camelCase, and 'ish' was removed from all | |
| // The two-name colors have an alternate name as well, such as: | |
| // example: orangeYellow lightOrange manilla is "#e1a11a" | |
| // As for "maximum contrast", I do not endorse that claim | |
| // theory - https://eleanormaclure.files.wordpress.com/2011/03/colour-coding.pdf (page 5) | |
| // kelly's colors - https://i.kinja-img.com/gawker-media/image/upload/1015680494325093012.JPG | |
| // hex values - http://hackerspace.kinja.com/iscc-nbs-number-hex-r-g-b-263-f2f3f4-242-243-244-267-22-1665795040 |
The formula for phi can be reduced to a positive exponent, multiplication, and addition:
This is clear and easy to remember, demonstrates interesting relationships, and is less obtuse than the formula as usually written. This can also improve computational efficiency (of admittedly marginal importance). Here is an example for javascript:
- Question: With text overlapping a picture of a person with a black-and-white-striped shirt. No matter what fixed "color value" you choose or what system you express it in (RGBA, APCA, etc.), you're going to have some of your letterforms appear in an area of insufficient contrast. (e.g. if you choose a dark color, your letters won't be readable on top of the black shirt stripe and visa versa for a light color).
Funny you should mention this. One of the experiments that we use in the lab for determining the middle point of perceptual contrast, specifically involves putting text against stripes of black and white.
The spatial frequency, in other words the size of the stripes relative to the font, is substantially important. As is the overall size and weight of the font. If I understand what you are asking for — maximum contrast at any given point, the results may not be what you expect. Here are examples.
This serves as a quick reference and showcase of GitHub Flavored Markdown. For more complete info, see John Gruber's original spec and the Github-flavored Markdown info page.
Calculate the luminance (Y) of the given color, and flip the text either black or white based on a pre-determined middle contrast figure. For a typical sRGB display, flip to white when Y < 0.36 (i.e. 36%)
First I want to acknowledge the massive amount of misinformation on the internet on this particular subject. The fact this field is still a subject of active research and unsettled science adds to the fun. I came to this conclusion as the result of the last few years of research into a new contrast prediction method for readability.
The field of visual perception is dense and abstract, as well as developing, so it is common for misunderstandings to exist. For instance, HSV and HSL are not even close to perceptually accurate. For that you need a perceptually uniform model such as CIELAB or CIELUV or CIECAM02 etc
We have on occasion heard the comment "APCA produces less contrast" — this is not true, though I see how some might come to that conclusion, it does not consider the totality of the new guidelines.
APCA does not produce contrast. APCA does nothing to the colors, it only predicts how a human will perceive them, and their effect on readability. And yes, if you try to compare APCA to the WCAG2 math it might appear that APCA allows lower contrast in some specific cases where one color is white or very bright, but across the entire range, APCA clearly, consistently, and correctly predicts contrast, while WCAG2 more often than not allows lower contrasts to pass that have even been shown to be unreadable, even with normal vision.
Here's an example a user brought to my attention recently:
This Gist is in answer to the question: "How many colors are in CMYK."
CMYK as a color model does not define a gamut, nor does it define a number of colors.