FilterMeister - Color Theory and Conversions

[Stroker]

Okay, clamping and limiting saturation to get rid of funkiness. Right.

Already clamped sat to the 0 to 255 range. While this is good, it's not entirely good. If you can believe it, you can still get some shifts in hue. Egads! Still have your full colour hue code handy? Go ahead and use it to do some comparing.

In similar colour spaces, saturation is limited by the lightness component. You will find this in HSB, HSL, and Lab. You will even find it in our mix-n-match colour space.

We have to limit sat based on lum - not just 0 to 255. Emphasis!

In order to see this, we have to turn to the colour space itself. We have to look our custom space in a 2d/3d manner. Our custom space is a double-cone.

See attachment.

What we need is another variable that hold what the maximum amount of saturation can be. I'm going to use Smax. This variable, Smax, will be calculated directly from lum.

Since we are dealing with a cone and an isosceles triangle, we can use a simple formula.

Get the absolute difference between lum and 128, multiply it by 2 for full 0 to 255 range, and invert.

Smax=255-abs(lum-128)*2;

Can you see it? I hope so because being able to see these kinds of things is what it's all about.

By the attached graphic, it may look like Smax = sat. No! Remember that sat may be lower than Smax.

Going to use Smax to limit sat, and Smax is derived from lum. This means clamp lum to 0 to 255, and then clamp sat using Smax.

New chunk of code:

// tweak
hue+=ctl(0);
sat+=ctl(1);
lum+=ctl(2);
 if(lum>255){lum=255;}
 if(lum<0){lum=0;}

// limit sat
Smax=255-abs(lum-128)*2;
 if(sat>Smax){sat=Smax;}
 if(sat<0){sat=0;}

Don't forget to add int Smax in the declares.

Using that last chunk, we are done putting our custom mix-n-match colour space back together. It's all good and proper.

Now, while our space and code is very similiar to Hue/Sat in Photoshop, there is still at least one major difference. That major difference is in Hue/Sat > Lightness slider and our own Lum slider.
- cookie if you can illustrate the difference
- bonus cookie if you can explain the difference

Hang on... it's not all good and proper. There is one last little thing in our code. We still have to deal with sat=0. Gadzooks!

[Stroker]

Okay, if sat=0 in the original, then there is no hue - it literally doesn't exist. However, our code will allow us to add saturation. This will result in our code defaulting to hue=0, which is red.

Desaturate some photograph
Run our code and use Sat +255

Not good, eh?

Change this:

sat+=ctl(1);

into this:

if(sat!=0){sat+=ctl(1);}

If there is no saturation in the original, then our code won't add any.
Tada.

Or maybe you can take advantage of this and come up with your own little way to colourize.

[Cameraken]

Thanks Stroker.

I got all the tweaks in and its working OK.

You are loosing me a little. I thought colour was Hue+Sat If that’s the case then why does Sat(max) depend on Lum.
Surely if Sat has been extracted correctly then its dependency should be lost.
It makes me question whether sat=max-min is correct.
This obviously took you a long time to work out so I am sure you are correct. I just don’t quite understand it yet.
I guess The fact that sat+=ctl(1) does not work proves you are correct, (image goes Red)
(sat!=0){sat+=ctl(1);} works fine.

Can you point me to any further reading on this. There seems to be nothing on the web. A Google search found this
http://nebulus.org/tutorials/2d/phot...lor/index.html
Pretty pictures. But not a full explanation.
I think you have already explained this. It has just not sunk in yet.

Difference between PS Hue/Sat > Lightness slider and your Lum slider. Ours is increasing each pixel by a fixed amount hence keeping the contrast. PS looses contrast as the lightness in increased.


Ken

[Stroker]

Saturation is limited by Lum in certain cases. Lum is the starting point and everything else follows.

Consider
Lum = 100% or 255
This is pure white and has no saturation
It's just pure white and that's that
If saturation isn't already 0, then it has to be reduced to 0

RGB is a cube and HSL is a double-cone. The double-cone doesn't fit nice and snug into a cube, so something has got to give. Rather, something has got to be limited or clamped.

This is the case for similiar colour spaces. But in order to see exactly how Lum limits Sat for a given space, you have to get 2d/3d. For example, Lab is a sphere. Lab is also Cartesian. This means you have to use Pythagoras to limit Sat based on L. You know, circles and right triangles and stuff.

Once you are comfortable with the idea of L limiting S, or pretty sure you understand it, we'll move on.

I don't think you will anything on the 'net talking about these kinds of things. I've looked and never found anything explicit. I've had to take a lot of bits-n-pieces and do my own detective work. As far as I know, I'm the only guy willing to talk about these nitty-gritty things.

Difference between PS Hue/Sat > Lightness slider and your Lum slider. Ours is increasing each pixel by a fixed amount hence keeping the contrast. PS looses contrast as the lightness in increased.

Oh, pretty close. Not as close as I would like, but close enough for a cookie.

[Cameraken]

Thanks Stroker.

There are a lot of advantages to the new code.
The border now zooms with the picture and the border changes with the sliders as the slider is moved.
I must start reading that manual.

Here is the new code.

%ffp

SupportedModes: RGBMode

OnFilterstart:{
	//Info("isTileable %d",isTileable);
	isTileable=true;
//	setZoom(1);
	return false;
}

ctl(0):standard,"Border thickness",range=(0,100),val=0,track
ctl(2):standard,"Red coloring",range=(0,255),val=0,track
ctl(3):standard,"Green coloring",range=(0,255),val=0,track
ctl(4):standard,"Blue coloring",range=(0,255),val=0,track

R: ( x < ctl(0) || x > X-ctl(0)-1 || y < ctl(0) || y > Y-ctl(0)-1) ? ctl(2) : r
G: ( x < ctl(0) || x > X-ctl(0)-1 || y < ctl(0) || y > Y-ctl(0)-1) ? ctl(3) : g
B: ( x < ctl(0) || x > X-ctl(0)-1 || y < ctl(0) || y > Y-ctl(0)-1) ? ctl(4) : b
A:a

Also I found this. I don’t know if its any use, Or if it can be converted.
http://www.mathworks.com/matlabcentr...MS_Equalizer.m


Ken

[Cameraken]

Back to HsY

Stroker.
I have been re-reading this thread. (Several Times)

From post 3

Now change the blending mode of the H/S Ad-Layer to Hue, Colour, or Sat. Different, eh? This is because you are now using HsY and seeing Y or Luminosity.

Yes it IS Different in RGB and CMYK but NOT in Lab. I guess this should not be happening at all in Any colour space and sorta proves what you are saying is correct.

From post 6
There is a big difference in the two pieces of code
The first makes the blacks go red
The second the blacks stay black (well blacker)

Changing HsY to HSL (or any other space like CMYK) means that there will be some loss and that is the reason for the funkiness clamping
I guess you can’t fit a square peg in a round hole OR You can’t fit a cube into a double cone.


Ken

[Stroker]

Okay, the Lab thing. When you are in Lab mode, everything is done using Lab - no HsY to muck about with. It's pretty nice because Lab filters are a bit more straight forward. That is, you don't have to really worry about converting spaces for basic operations that would normally require a different space.

Colour blending mode in Lab is done using a and b channels - not hue and sat as we are used to them. Oh, I feel a can of worms coming. Can you feel it? Can you?

The HsY thing was using Lightness, but we want to use Lum as Photoshop defines and uses it. I originally went with Lightness out of convenience and to acclimate ya'll to certain ideas. The main idea being that the L* component will limit the Sat component.

Using Lightness, finding Smax was fairly easy. Using Lum to find Smax is going to be a bit trickier. Time to get funky. See attachment.

Upper-Left
This is the HSL double-cone kind of unwrapped to a cylinder. Across the top is pure white and the bottom is pure black. Right in the middle at 128 is where Smax=255.

Upper-Right
This is a greyscale representation of Smax. See how Smax=255 when Lightness=128? And then Smax fades to 0 as you get closer to the top or bottom? Yeah, finding Smax was easy.

Lower-Left
This is HsY unwrapped to a cylinder in the same manner. What was once a horizontal line is now all wiggly. Well, sort of wiggly.

Lower-Right
This is greyscale Smax for HsY. Definitely funky. Did we step in something funky? Oh, yeah.

If we can find were Smax=255 in HsY, then the rest should be easy to fade to Smax=0 at the top and bottom.

Is there a pattern to this? Is there a simple formula? There is, and it has been sitting right in front of our faces this whole time. Big cookie to anybody that figures it out before I give up the funk.

- = Warning = -
You may want to brush up on your triangles and ratios.

[Cameraken]

HSL
Lightness = (Max-Min)/2
Sat = Max-Min
SatMax = 255-abs(lightness-128)x2


HSY (HS/Lum)
Lum = Rx0.30 + Gx0.59 + Bx0.11
Sat = Max-Min
SatMax = I guess the formula is going to be very similar to above as it will still be based on Lum.

Then if Sat>SatMax then Sat=SatMax

I sure did a lot of reading. These things are just not out there. I really appreciate you taking the time Stroker. The last link here is to a PDF which is interesting.

http://www.13thmonkey.org/~boris/pho...tion-test.html

http://en.wikipedia.org/wiki/HSV_col...rom_RGB_to_HSV

http://support.microsoft.com/kb/q29240/

http://www.prip.tuwien.ac.at/~hanbury/hsy2rgb.m

http://www.prip.tuwien.ac.at/~hanbury/colour_histogram/

http://www.prip.tuwien.ac.at/~hanbury/Online_docs.html

www.prip.tuwien.ac.at/~hanbury/SCIA_Hanbury.pdf


Ken

[Stroker]

You are welcome, Ken and others. And thank you for listening. It's not that often I come out and play like this. Well, not much lately. So, I am enjoying myself rather muchly.

There are several reasons why what I'm talking about is rather exclusive. One of the main things is that HsY is an Adobe thing and they don't document things like this. Another reason is that Smax is something that I invented for working with HsY. If I remember, I'll tell you the really real reason behind Smax. Seems like the rabbit hole just keeps on getting deeper, eh?

Ken, it's good to see you getting out there and doing research on your own. And it's good to see Roland steam-rollin' some of this stuff.

Roland, try this:

setZoom(-888);

It comes in handy from time to time.

Sooner than I wanted, but I'm gonna move on a bit further.

Smax based on Lum. I said that there was a magic formula and that it has been staring us right in the face. Going to use a variable of double type called Lxyz.

double Lxyz;

// get full colour hue
r=hsl2rgb(hue,255,128,0);
g=hsl2rgb(hue,255,128,1);
b=hsl2rgb(hue,255,128,2);

Lxyz =r*0.30 + g*0.59 + b*0.11;

Oh! Look at the formula for Lxyz. Look familiar? I should hope so.

Not completely apparent in that code chunk, but Lxyz comes immediately after getting full colour hue. This is so we can find the point where Smax=255 for *any* given hue. This will give us that funky wiggle.

Lxyz is also a double. I'm not exactly sure why it has to be a double, but it does. I think it has to do with precision in the next few steps.

Now that we have Lxyz as the point where Smax=255, it's just a simple matter of triangles and ratios to find Smax for any given value of Lum. Coming soon.

Kind of funny, isn't it? We have to have Hue in order to limit Sat based on Lum. Some things just aren't as independant as we thought.

[Stroker]

Oh, triangles. Lovely triangles and ratios. You like percentages, don't you?

Some where around here I posted a graphic with a triangle. One corner was red, one corner was black, and the last corner was white. We are going to take another look at that triangle, but in a different light.

You do remember Geometry one-oh-one, right? Check out the attachment and be amazed at how much you remember.

[Stroker]

Using that, we can easily come up with what's in the attachment.

Since the ratios are percentages, have to multiply by 255. The rest should be cake.

[Stroker]

New code chunk:

// get full colour hue
r=hsl2rgb(hue,255,128,0);
g=hsl2rgb(hue,255,128,1);
b=hsl2rgb(hue,255,128,2);

Lxyz =r*0.30 + g*0.59 + b*0.11;

if(lum>=Lxyz){
Smax=255* ((255-lum)/(255-Lxyz));
} // Lum > Lxyz

if(lum<=Lxyz){
Smax=(lum/Lxyz)*255;
} // Lum < Lxyz

if(sat>Smax){sat=Smax;}
if(sat<0){sat=0;}

Previously scaling down to Sat was easy because L* was right in the middle of min and max. Well, Lum isn't always going to be in the middle of min and max. So, how do we scale down to Sat? How do we compensate for a wiggly reference?


Hmmm....

[Stroker]

Something just for fun. The tweaks I added are very sloppy. Forgive me?

%ffp

supportedmodes: RGBMode

ctl(0):standard,"T1 Mult",range=(0,300),val=100,track
ctl(1):standard,"T2 Add",range=(0,100),val=0,track

OnFilterStart:{
//setPreviewCursor (32515);
setZoom(1);
return false;
}

ForEveryTile:{
int x,y,z;
int c1,c2,c3,c4,c5,c6,c7,c8,c9;
int gx,gy;
float distance;
float final;
int finint;

for (z=0;z<Z;z++){
for (y=y_start; y<y_end; y++){
//if(updateProgress(y,y_end)) abort();
for (x=x_start; x<x_end; x++){

//  1  2  3
//  4  5  6
//  7  8  9

c1=src(x-1,y-1,z);
c2=src(x,y-1,z);
c3=src(x+1,y-1,z);
c4=src(x-1,y,z);
// c5
c6=src(x+1,y,z);
c7=src(x-1,y+1,z);
c8=src(x,y+1,z);
c9=src(x+1,y+1,z);

gx= -c1 -c4*2 -c7 +c3 +c6*2 +c9;
gy= -c1 -c2*2 -c3 +c7 +c8*2 +c9;

distance=sqrt((float)gx*gx + gy*gy);

final=distance*(float)ctl(0)/100.00;
finint=255-(int)final+ctl(1);

pset(x,y,z,finint);

}}}// x, y,z

return true;
} // for every tile

[Cameraken]

Thanks Stroker.
I’ve been a bit busy with more OPR Pictures. And a faulty Central Heating Boiler.

The code from Post 49 is great for the artists here. I’ve added an example below.

I have not got the code from post 45 and Post 48 working yet. I’m getting some strange results. I think I need to take something out.
I will try again tomorrow.

Fancy this next Rô
http://www.codeproject.com/cpp/howtofft.asp

Ken

[Stroker]

Those code chunks won't exactly work because we are not quite done putting it all back together.

The next problem is dealing with Lum and Sat. Since Lum isn't always in the middle of min and max, we need a different approach. I've tried several different approaches and only one seems to work decently.

Take care of Smax and sat. Get hue in full colour. Scale RGB down to sat using range 0 to sat. Use another variable to get the luminosity of the scaled down RGB. Take the difference between this temporary luminosity and the desired luminosity. Add that difference to all RGB values. Since we are adding the same value to RGB, hue and sat will be preserved. Plus, in the end, we will have the desired luminosity.

Notice that the temporary lum variable, temL, is also double.

Final RGB <> HsY code:

%ffp

SupportedModes: RGBMode

ctl(0):standard,"Hue",range=(-128,128),val=0,track
ctl(1):standard,"Sat",range=(-255,255),val=0,track
ctl(2):standard,"Lum",range=(-255,255),val=0,track

ForEveryTile:{
 int x,y,r,g,b;
 int min,max;
 int hue,sat,lum;
 int Smax;
 double Lxyz;
 double tempL;

int final;

for (y=y_start; y<y_end; y++){
//if(updateProgress(y,y_end)) abort();
for (x=x_start; x<x_end; x++){

r=src(x,y,0);
g=src(x,y,1);
b=src(x,y,2);

hue=rgb2hsl(r,g,b,0);
min=min(r,min(g,b));
max=max(r,max(g,b));
sat=max-min;
lum=r*0.30 + g*0.59 + b*0.11;

// tweak
hue+=ctl(0);
if(sat!=0){sat+=ctl(1);}
lum+=ctl(2);
 if(lum>255){lum=255;}
 if(lum<0){lum=0;}

// get full colour hue
r=hsl2rgb(hue,255,128,0);
g=hsl2rgb(hue,255,128,1);
b=hsl2rgb(hue,255,128,2);

Lxyz =r*0.30 + g*0.59 + b*0.11;

if(lum>=Lxyz){
Smax=255* ((255-lum)/(255-Lxyz));
} // Lum > Lxyz

if(lum<=Lxyz){
Smax=(lum/Lxyz)*255;
} // Lum < Lxyz

if(sat>Smax){sat=Smax;}
if(sat<0){sat=0;}

// scale to sat
r=scl(r,0,255,0,sat);
g=scl(g,0,255,0,sat);
b=scl(b,0,255,0,sat);

// calc small lum and get difference
tempL= r*0.30 + g*0.59 + b*0.11;
tempL=lum-tempL;

// add the difference
r+=tempL;
g+=tempL;
b+=tempL;

// output
pset(x,y,0,r);
pset(x,y,1,g);
pset(x,y,2,b);

} // end x preview
} // end y preview

return true;
} // end for every tile

There. You can now RGB <> HsY with a fair amount of accuracy. Isn't it beautiful?

Why would you want to do this? I don't know about you, but I like being able to extend a filter beyond the filter itself. That is, making it blending mode friendly for further tweaks. If I want a filter that works with Colour blending mode (Hue + Sat), I can now do that. If I want a filter that manipulates Lum for contrast, I can now do that.

Another good thing is making greyscale masks based on HsY. Practice your ChOps and take it to the code. If we get far enough, I'll tell ya'll about my Trigs in Space.