According to
this page, sepia tunes should use the following formula.
Code:
outputRed = (inputRed * .393) + (inputGreen *.769) + (inputBlue * .189)
outputGreen = (inputRed * .349) + (inputGreen *.686) + (inputBlue * .168)
outputBlue = (inputRed * .272) + (inputGreen *.534) + (inputBlue * .131)
But instead of sepia, I'm getting...
this.
Why???
That matrix of parameters isn't singular. Looks like rounding error, though.
Code:
>> [.393 .769 .189; .349 .686 .168; .272 .534 .131]^-1
ans =
1.2727e+03 1.5455e+03 -3.8182e+03
-1.9008e+02 6.1983e+02 -5.2066e+02
-1.8678e+03 -5.7355e+03 1.0058e+04
Is there any chance you typoed or transposed one of the numbers?
You probably want to convert to greyscale and then use a simple colormap to convert that to sepiatone (White down through a grayish color, then through brown, then black)
If the effect you're aiming for is less "real is brown" and more "
the past is brown", this should approximate sepia for an NES picture:
- Map 20 and 30-3C to 37
- Map 10 and 21-2C to 27
- Map 00 and 11-1C to 17
- Map xD-xF and 01-0C to 07
Quote:
These specific values are the values for sepia tone that are recommended by Microsoft.
What an odd statement. Is Microsoft was some kind of sepia authority now?
If you want zero blue in your sepia conversion, you should create your own matrix that completely desaturates the image to remove input colour influences on the output. The one you're using only partially desaturates.
I think lidnariq suggested what you really want. Convert to greyscale first, then some sort of filter/map to convert to brownish colours. (You might be able to do with with a single matrix, but you'll probably want to work it out in steps first, at least.)
Fine, so I'm using my own current method for monochromes.
Code:
newValue_R = (brightness * $70) >> 7
newValue_G = (brightness * $42) >> 7
newValue_B = (brightness * $14) >> 7
The sepia hex triplet (
from wikipedia) is $70$42$14.
Result below.
Which looks more like an amber CRT than actual sepiatone, because sepiatone (a silver sulfide gelatin print) isn't a single line in RGB space. It's formed by producing a thicker and thicker layer of Ag₂S, which for a given amount W of material, blocks X% of blue light, Y% of green light, and Z% of red light. So it's almost a straight line in HSL (but not in HSV)
lidnariq wrote:
Which looks more like an amber CRT than actual sepiatone, because sepiatone (a silver sulfide gelatin print) isn't a single line in RGB space. It's formed by producing a thicker and thicker layer of Ag₂S, which for a given amount W of material, blocks X% of blue light, Y% of green light, and Z% of red light. So it's almost a straight line in HSL (but not in HSV)
But that's not "converting to grayscale firstly". How am I supposed to do with RGB values?
From
this alternative page I've found "43.9% red, 25.9% green and 7.8% blue". With a "small kick of x2", I got the following result below.
Try this nonlinear formula and show us how it looks:
Y = .3R+.6G+.1B
Gnew = Y
Bnew = (Y * Y / Ymax + Y) / 2
Rnew = 3 * Ymax - (Gnew + Bnew)
where Ymax is 1.0 or 255 or whatever for your particular color space
Code:
int Y = (p->red * .3) + (p->green * .6) + (p->blue *.1);
int Gnew = Y;
int Bnew = (Y * Y / 255 + Y) / 2;
int Rnew = 3 * 255 - (Gnew + Bnew);
p->red = Rnew; p->green = Gnew; p->blue = Bnew;
if(p->red > 255) p->red = 255;
if(p->green > 255) p->green = 255;
if(p->blue > 255) p->blue = 255;
Reddish.
Is something wrong?
I typed that off the top of my head without testing, as I was on a rare break from crunch time on my present project.
Try newR = Y, newG = Y, and newB as before.
Or try newR = Y, newB as before, and newG = (newR + newB) / 2.
Or try newR = Y/2 + 128, newG = Y/2 + 64, newB = Y/2.
Or how does it look with my mapping everything to column 7?
All of those won't have the desired effect because they are straight lines in RGB.
Convert the input to grayscale, use the grayscale volume as L in HSL (with H≈orange, S≈50%), convert back to RGB.
Another thought: Grayscale, then try using different gammas for the different channels. Perhaps R=2.2, G=1.1, B=.55? Produces this:
Attachment:
rgamma_2.2_ggamma_1.1_bgamma_0.55.png [ 1.13 KiB | Viewed 4024 times ]
Anything with Rgamma = 2Ggamma = 4Bgamma looks not unreasonable, upon briefly playing with it.
My method of grayscale takes the brightness level and uses it to generate the RGB values for sepia.
I don't know... that red * 2.2 seems to generate a couple of $FFs.
Anyway, result below.
Gamma means a power/exponent operation. In this case I think the suggestion was:
R ^ (1 / 2.2)
G ^ (1 / 1.1)
B ^ (1 / 0.55)
rainwarrior wrote:
Gamma means a power/exponent operation. In this case I think the suggestion was:
R ^ (1 / 2.2)
G ^ (1 / 1.1)
B ^ (1 / 0.55)
Sorry for the request, but mind you to write a C code for it? Mine's generating grayscale only.
Code:
float r; // input colours in the range 0-1
#include <math.h>
r = pow(r, 1.0 / 2.2); // R ^ (1 / 2.2)
// output r is still in the range 0-1
Not working, I get shades of blue. Since I use integer values, I'm adding cast to float. Not sure if correct though.
Code:
p->red = (int)pow((float)p->red, 1.0 / 2.2); // R ^ (1 / 2.2)
p->green = (int)pow((float)p->green, 1.0 / 1.1); // G ^ (1 / 1.1)
p->blue = (int)pow((float)p->blue, 1.0 / 0.55); // B ^ (1 / .55)
Is something obviously wrong here??
Yes. You need to convert the ranges, not just cast to float and back to integer. The naive version of this looks like:
Code:
float fr = float(r) / 255.0; // convert 0-255 unsigned char to 0-1 float
unsigned char ir = int(fr * 255.0); // convert 0-1 float to 0-255 unsigned char
Using the RGB triplet doesn't give the expected result - must be monochrome! So, I decided to convert it to grayscale, then to sepia using the brightness level for each new RGB triplet. The result is below.