Is there a spec for RGB values of the emoji skin tone modifiers? - unicode

Wikipedia and Unicode.org both illustrate the emoji skin tone modifiers.
Where are the RGB values specified? (Surely this can't be the font designer's arbitrary choice... there must be a reference somewhere that shows it.)

Read Emoji Modifier Sequence at https://emojipedia.org/:
Emoji characters can be modified to use one of five different skin
tone modifiers. Each tone is based on the Fitzpatrick Scale.
The Fitzpatrick Skin Type Classification system was developed in 1975 by Harvard Medical School dermatologist Thomas Fitzpatrick, MD, PhD. This system classifies complexions and their tolerance of sunlight…
Read the Fitzpatrick skin phototype document as well…
Edit
Fitzpatrick Scale / Von Luschan’s Chromatic Scale
The Von Luschan’s Scale was developed as a tool to assess racial
classifications according to skin color. It consists of 36 colored
tiles which are compared to a person’s skin color.
This image is a reproduction of the Von Luschan scale which was
originally created by Felix von Luschan and printed in Voelker,
Rassen, Sprachen (1927). The original chart was scanned and the skin
colors were copied using the paint program’s dropper tool.
Our team at Open Oximetry calculated the RBG values which are
superimposed on the image of the scale. Notably, 13 and 14 were found
to have the same RGB values.
Note 1: get your own values:
Take any image of von Luschan scale (or Fitzpatrick one), open it in an image editor (e.g. as simple as Windows' native mspaint.exe), use the Colour Picker tool to get the RGB values:
or get them programmatically: How to read the RGB value of a given pixel in Python?…
Note 2: Caution! There are different ways of converting the 36 categories of the von Luschan scale to the six categories of the Fitzpatrick scale (example in PowerShell):
$Fitzpatrick = #'
Type;Effect of Light Exposure;Description;Von Luschan’s Description;Von Luschan’s Color
I;Always burns, never tans;Pale, fair, freckles;Very light;1-5
II;Usually burns, sometimes tans;Fair;Light;6-10
III;May burn, usually tans;Light brown;Intermediate;11-15
IV;Rarely burns, always tans;Olive brown;Mediterranean;16-21
V;Moderate constitutional pigmentation;Brown;Dark or brown;22-28
VI;Marked constitutional pigmentation;Black;Very dark or black;29-36
'# | ConvertFrom-Csv -Delimiter ';'
$Fitzpatrick | Select-Object -Property (
"Type","Von Luschan’s Color","Von Luschan’s Description") |
Out-Default
<#
(based on TABLE V.—Skin Classification by Pigmentation (page 21) in
Imaging skin: Past, present and future perspectives
by Marty O. Visscher)
<##>
$FitzpatrickWiki = #'
Type;von Luschan scale;Also called
I;0–6;Very light or white, "Celtic" type[5]
II;7–13;Light or light-skinned European[5]
III;14–20;Light intermediate, or dark-skinned European[5]
IV;21–27;Dark intermediate or "olive skin"[5]
V;28–34;Dark or "brown" type
VI;35–36;Very dark or "black" type
'# | ConvertFrom-Csv -Delimiter ";"
$FitzpatrickWiki | Out-Default
<#
(based on this Wikipedia table:
the 36 categories of the von Luschan scale in relation to the six categories of the Fitzpatrick scale in
Von Luschan's chromatic scale)
<##>
Result: \SO\75489304.ps1
Type Von Luschan’s Color Von Luschan’s Description
---- ------------------- -------------------------
I 1-5 Very light
II 6-10 Light
III 11-15 Intermediate
IV 16-21 Mediterranean
V 22-28 Dark or brown
VI 29-36 Very dark or black
Type von Luschan scale Also called
---- ----------------- -----------
I 0–6 Very light or white, "Celtic" type[5]
II 7–13 Light or light-skinned European[5]
III 14–20 Light intermediate, or dark-skinned European[5]
IV 21–27 Dark intermediate or "olive skin"[5]
V 28–34 Dark or "brown" type
VI 35–36 Very dark or "black" type

Related

Changes Brightness in color replacement

I am working on replacing certain color in image by User's selected color. I am using OpenCV for color replacement.
Here in short I have described from where I took help and what I got.
How to change a particular color in an image?
I have followed the step or taken basic idea from answer of above link. In correct answer of that link that guy told you only need to change hue for colour replacement.
after that I run into the issue similar like
color replacement in image for iphone application (i.e. It's good code for color replacement for those who are completely beginners)
from that issue I got the idea that I also need to change "Saturation" also.
Now I am running into issues like
"When my source image is too light(i.e. with high brightness) and I am replacing colour with some dark colour then colours looks light in replaced image instead of dark due to that it seems like Replaced colour does not match with colour using that we done replacement"
This happens because I am not considering the brightness in replacement. Here I am stuck what is the formula or idea to change brightness?
Suppose I am replacing the brightness of image with brightness of destination colour then It would look like flat replacemnt and image will lose it's actual shadow or edges.
Edit:
When I am considering the brightness of source(i.e. the pixel to be processed) in replacment then I am facing one issue. let me explain as per scenario of my application.
for example I am changing the colour of car(like whiteAngl explain) after that I am erasing few portion of the newly coloured car. Again I am doing recolour on erased portion but now what happended is colour done after erase and colour before erase doesn't match because both time I am getting different lightness because both time my pixel of to be processed is changed and due to that lightness of colour changed in output. How to overcome this issue
Any help will be appreciated
Without seeing the code you have tried, it's not easy to guess what you have done wrong. To show you with a concrete example how this is done let's change the ugly blue color of this car:
This short python script shows how we can change the color using the HSV color space:
import cv2
orig = cv2.imread("original.jpg")
hsv = cv2.cvtColor(orig, cv2.COLOR_BGR2HSV)
hsv[:,:,0] += 100
bgr = cv2.cvtColor(hsv, cv2.COLOR_HSV2BGR)
cv2.imwrite('changed.jpg', bgr)
and you get:
On wikipedia you see the hue is between 0 to 360 degrees but for the values in OpenCV see the documentation. You see I added 100 to hue of every pixel in the image. I guess you want to change the color of a portion of your image, but probably you get the idea from the above script.
Here is how to get the requested dark red car. First we get the red one:
The dark red one that I tried to keep the metallic feeling in it:
As I said, the equation you use to shift the light of the color depends on the material you want to have for the object. Here I came up with a quick and dirty equation to keep the metallic material of the car. This script produces the above dark red car image from the first light blue car image:
import cv2
orig = cv2.imread("original.jpg")
hls = cv2.cvtColor(orig, cv2.COLOR_BGR2HLS)
hls[:,:,0] += 80 # change color from blue to red, hue
for i in range(1,50): # 50 times reduce lightness
# select indices where lightness is greater than 0 (black) and less than very bright
# 220-i*2 is there to reduce lightness of bright pixel fewer number of times (than 50 times),
# so in the first iteration we don't reduce lightness of pixels which have lightness >= 200, in the second iteration we don't touch pixels with lightness >= 198 and so on
ind = (hls[:,:,1] > 0) & (hls[:,:,1] < (220-i*2))
# from the lightness of the selected pixels we subtract 1, using trick true=1 false=0
# so the selected pixels get darker
hls[:,:,1] -= ind
bgr = cv2.cvtColor(hls, cv2.COLOR_HLS2BGR)
cv2.imwrite('changed.jpg', bgr)
You are right : changing only the hue will not change the brightness at all (or very weakly due to some perceptual effects), and what you want is to change the brightness as well. And as you mentioned, setting the brightness to the target brightness will loose all pixel values (you will only see changes in saturation). So what's next ?
What you can do is to change the pixel's hue plus try to match the average lightness. To do that, just compute the average brightness B of all your pixels to be processed, and then multiply all your brightness values by Bt/B where Bt is the brightness of your target color.
Doing that will both match the hue (due to the first step) and the brightness due to the second step, while preserving the edges (because you only modified the average brightness).
This is a special case of histogram matching, where here, your target histogram has a single value (the target color) so only the mean can be matched in a reasonable way.
And if you're looking for a "credible source" as stated in your bounty request, I am a postdoc at Harvard and will be presenting a paper on color histogram matching at Siggraph this year ;) .

Trying to understand how 1-bit BMP image is drawn

As can be seen in this example, each channel (R, G, B) in a BMP file takes an input. A 24-bit BMP image has 8 bit for-R , 8-bit for G, and 8 bit for B. I saved an image in MS-paint as monochrome(black and white). Its property says the image's depth is 1-bit. The question is who gets this 1 bit: R , G or B? Is it not mandatory that all the three channels must get certain value? I am not able to understand how MS-Paint has drawn this BMP image using 1 bit.
Thanks in advance for your replies.
There's multiple ways to store a bitmap. In this case, the important distinction is RGB versus indexed.
In an RGB bitmap, every pixel is associated with three separate values, one for red, another for green, and another for blue. Depending on the "bitness" (bit depth) and the specific pixel format, the different colour channels can have different amount of bits allocated for them - the simplest case is the typical true-color with 8 bits for each of the channels, and another 8 bits (optional) for the alpha channel. However, some pixel formats allocate a bit differently - the idea is that the human eye has different sensitivity to each of those channels, and you can save up on space and improve visual quality by allocating the bits in a smarter way. For example, one of the more popular pixel formats is BGR-565 - that is, 16 bits total, 5 bits for blue, 6 bits for green and 5 bits for red.
In an indexed bitmap, the value stored with each of the pixels is an index (hence "indexed bitmap") into a palette (a colour table). The palette is usually a simple table of colours, using RGB "pixel" formats to assign each index with some specific colour. For example, index 0 might mean black, 1 might mean turqouise etc.
In this case, the bit-depth doesn't exactly map into colour quality - you're not trying to map the whole colour space, you're focusing on some subset of the possible colours instead. For example, if you have 256 shades of grey (say, from black to white), a true-colour bitmap would need at least three bytes per pixel (and each of those three bytes would have the same value), while you could use an indexed bitmap with a pallete of all the grey colours, requiring only one byte per pixel (plus the cost of the pallete - 256 * 3 bytes). There's a lot of benefits to using indexed bitmaps, and a lot of tricks to improve the visual quality further without using more bits-per-pixel, but that would be way beyond the scope of this question.
This also means that you only need as many possible values as you want to show. If you only need 16 different colours, you only need four bits per pixel. If you only need a monochromatic bitmap (that is, either a pixel is "on", or it's "off"), you only need one bit per pixel - and that's exactly your case. If you have the amount of distinct colours you need, you can easily get the required bit depth by taking a base-2 logarithm (e.g. log 256 = 8).
So let's say you have an image that only uses two colours - black and white. You'll build a pallete with two colours, black and white. And for each of the pixels in the bitmap, you either save 0 if it's black, or 1 if it's white.
Now, when you want to draw a bitmap like this, you simply read the palette (0 -> RGB(0, 0, 0), 1 -> RGB(1, 1, 1) in this case), and then you read one pixel after another. If the bit is zero, paint a black pixel. If it's one, paint a white pixel. Done :)
No, it depends on the type of data you chose to save as. Because you chose to save as monochrome, the RGB mapping is not used here, and the used mapping would go as a one byte per pixel, ranging from white to black.
Each type has its own mapping ways, saving as 24-bit will give you RGB mapping, saving as 256 will map a byte for each pixel, each value represents a color( you can find the table on the internet), as for monochrome, you'll have the same as a 256 bitmap, but the color table will only have white and black colors.
Sorry for the mistake, the way I explained for monochrome is actually used by Gray Scale, the monochrome uses one bit to indicate if the pixel is black or white, depending on the value of each bit, no mapping table is used.

Color in the Unicode standard?

Unicode 6.0 added several characters with descriptions that suggest those characters are supposed to be rendered in a specific color:
RED APPLE U+1F34E
GREEN APPLE U+1F34F
BLUE HEART U+1F499
GREEN HEART U+1F49A
YELLOW HEART U+1F49B
PURPLE HEART U+1F49C
GREEN BOOK U+1F4D7
BLUE BOOK U+1F4D8
ORANGE BOOK U+1F4D9
LARGE RED CIRCLE U+1F534
LARGE BLUE CIRCLE U+1F535
LARGE ORANGE DIAMOND U+1F536
LARGE BLUE DIAMOND U+1F537
SMALL ORANGE DIAMOND U+1F538
SMALL BLUE DIAMOND U+1F539
UP-POINTING RED TRIANGLE U+1F53A
DOWN-POINTING RED TRIANGLE U+1F53B
UP-POINTING SMALL RED TRIANGLE U+1F53C
DOWN-POINTING SMALL RED TRIANGLE U+1F53D
I had thought font symbols were always grayscale.
Did the unicode authors forsee that these might be rendered in different colors?
Within the official unicode.org PDFs (http://www.unicode.org/charts/PDF/U1F300.pdf), these are portrayed only as having different types of crosshatching.
Is there any current mechanism that would allow for specific characters to be rendered in a specific color, based only on its codepoint, and not any other rich-text formatting? (eg. a color property within TrueType or OpenType font files)
From the Unicode FAQ: Emoji and Dingbats, bolding mine:
Q: What about characters whose name specifies a color?
A: Some of the characters from the core emoji sets have names that include a color term, for example, BLUE HEART or ORANGE BOOK. These color terms in the names do not imply any requirement about how a character must be presented; they are intended only to help identify the corresponding character in the core emoji sets. Even names of symbols such as BLACK MEDIUM SQUARE or WHITE MEDIUM SQUARE are not meant to indicate that the corresponding character must be presented in black or white, respectively; rather, the use of black and white is generally just to contrast filled versus outline shapes, or a darker color fill versus a lighter color fill. [PE]
There was quite a bit of debate on the mailing lists at the time on whether these should be named with colors, or generic names that didn't reference color, and whether that was setting a bad precendent. The Emoji Symbols: Background Data includes "old names" such as APPLE-1 instead of RED APPLE and BOOK-3 instead of ORANGE BOOK.
The final names use this principle:
Symbols with an inherent color shall bear this color in their
name unless the entity denoted by the name has identifies the color
anyway (e.g., a BANANA is uniquely yellow and therefore does
not need to be called YELLOW BANANA, while a RED APPLE must be
named so as there are also green apples).
Unicode 6.1 have a feature to change glyph for the same unicode code point, by specifying Variation Selector(U+FE0x).
For example, left-pointing triangle(#"\U000025C0", ◀) can be colored by adding "\U0000FE0F" ◀️* and non-colored by adding "\U0000FE0E" as suffix. (#"\U000025C0\U0000FE0E", ◀︎**).
*looks default on Mac OS X 10.8**This is default on Linux.
From https://learn.microsoft.com/en-us/typography/opentype/spec/otff#tables-related-to-color-fonts:
Tables Related to Color Fonts
COLR: Color table
CPAL: Color palette table
CBDT: Color bitmap data
CBLC: Color bitmap location data
sbix: Standard bitmap graphics
SVG : The SVG (Scalable Vector Graphics) table
In short,
CBDT/CBLC contain colored bitmaps (in PNG). They were proposed by Google.
sbix contains colored bitmaps (in JPG, PNG, or TIFF). It was proposed by Apple.
COLR defines one or more accompanying color glyphs (in vector format) for each glyph, and when they are overlapped they create the final colored glyph. CPAL defines several color themes (dark-on-white, white-on-dark, ...) since COLR is merely paletted images. COLR/CPAL were proposed by Microsoft.
SVG was proposed by Mozilla and Adobe. It may be used with CPAL.
FreeType (part of Android, iOS, and macOS) supports CBDT/CBLC and sbix since 2.5 and 2.5.1 (released in 2013), and COLR/CPAL since 2.10.0 (released in 2018). DirectWrite (part of Windows) supports COLR/CPSL since 8.1 (released in 2013) and all four above since 10 1607 (released in 2016).
Noto Color Emoji (default on Android) uses CBDT/CBLC. Segoe UI Emoji (default on Windows) uses COLR/CPAL. Apple Color Emoji (default on iOS and macOS) uses sbix.
See also https://en.wikipedia.org/wiki/OpenType#Color
I don't know that there's any standard mechanism for colored fonts, but obviously there are colored fonts. For example, the emoji font in iOS and OS X. Emoji characters in any text view on OS X will result in colored symbols, and they won't be affected by choosing a text color. These emoji even show up in Terminal.app.
(From this page.)

JPEG Encoding question

24 bits are available per pixel.
Assuming
1. eyes are sensitive to brightness than color.
2. eyes are sensitive to red & green than blue.
What kind of encoding can I choose?
I thought about it,but didn't get an idea. Y'CbCr with 4:2:0 encoding works for the brightness part, but what about the color?
That's already accounted for. YUV420 meens that the color components are subsampled. I'm not sure if it was horizontally or vertically though. That means that your image will contain half the color information compared to luminence. Also, the quantization tables are different for the color components so that will also increase the compression rate.

Convert print, CMYK images to tiled, RGB images for iPhone?

I was given some high-res images, which were originally made for a printed magazine, to show in an iPhone app, like the Xcode PhotoScroller app (like iPhone's native Photo viewer app). I'm down-sizing them to 1024 x 1536 px and I'm going to be slicing them up for use with UIScrollView and CATiledLayer.
When I'm resizing them, should I also convert them from CMYK to RGB?
I think so because RGB is for digital, right? But they also looked fine on the iPhone as CMYK. Why do they say to use RGB for digital?
What's the best way to resize them to 1/2 & 1/4 and slice all 3 sizes up?
1024/4 = 256, so I'm thinking of making every tile (except for the edge ones) 256 x 256 px. I tried Tile Cutter, which worked, but I have 20 images, so I'll have to do it 20 times. Plus, it doesn't let you put levels deep, so I'll also have to resize each image twice in PhotoShop. So, that's 60 images that I'll have to run through The Cutter. It shouldn't take too long, but odds are, I'll be doing this again, so I'd like to have a better solution. Ideally, it'd be cool to do this with the iPhone, but for now, I think I'll use Paul Alexander's Tile Ruby script unless you suggest a better option. I also might try Zoomify.
RGB has a wider range of colors then CMYK.
CMYK is the range of colors printed on a white paper. it stands for Cyan Magenta Yellow and blacK. (think of the 4 colors in your printer cardiges. CMY for colors and K for black.)
when miking CMY you have a very very dark grey. It goes on a scale of 0-100% from each color.
RGB are monitors colors. It's the way LCDs and CRTs process colors. With Red Green and Blue. It goes on a scale of 0-255. 255 of both 3 colors makes white.
Now since monitors are backed with backlight, it can make bright color printers can't do. like shiny green or shiny pink.
A CMYK picture will look fine on screen. A RGB will lose color on print (like those shiny greens will become matte).
For the iPhone, work on RGB. reasons:
- It process directly RGB values
- You'll get precise color
- RGB takes less memory then CMYK