FilterMeister - Color Theory and Conversions

[Stroker]

(byRo: This thread has been split - so some posts may seem out of context)

I'm sure most of us are familiar with the various colour spaces. The ones that come to mind are RGB, HSL, HSB, Lab, and CMYK. Oy, but Photoshop uses a priority space when you are not looking. This space is very similiar to HSL and HSB with a hint of xyz/Lab tossed in.

I used to call this colour space HS/Lum, but have taken to calling it HsY. I got the name, HsY, from a guy in Germany (I think Germany). I just like his name better.

Whenever you use the blending modes Hue, Saturation, Colour, or Luminosity, you are using this hidden space.

Here is a simple experiment to try:
- open photograph in RGB mode, preferably with lots of blue and yellow
- Adjustment Layer > Hue/Sat
-- bring Sat all the way down to -100

When you do this, you are looking at Lightness of HSL.

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.

Here is the basic code for turning RGB into HsY:

%ffp

ForEveryPixel:{
int hue,sat,lum;

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

R=hue;
G=sat;
B=lum;

}

After running this, use the Channels palette to inspect the channels separately. One thing I want you to note is that the resulting Lum 'channel' will usually have higher fidelity than the Hue and Sat 'channels'.

You see, the two colour channels are usually compressed more than the luminosity channel. This is why there are tutorials out there about smoothifying when you increase saturation (Deke). If you amplify a compressed channel, then you will bring out the compressedness of the channel.

This one little thing can mean an awlful lot.

[Cameraken]

Thank you Stroker.

It’s amazing what you can achieve with a few simple lines of code.

I am still learning. And find C+ syntax quite confusing at times. I learnt VB instead.
I usually look through the FilterMeister code library for a similar type filter and then amend it.

It’s Interesting the way you split HsY onto the channels. That was a good idea as I don’t think FilterMeister will let you create new layers.

Now if I could only put this back together again.

Ken

[Cameraken]

Tips

If you wish to try Stroker’s code you will find that you can’t use the mouse to paste code straight into FilterMeister.

It is possible to paste with the keyboard.
• Ctrl+C - Copy (OR You Can use the mouse)
• Ctrl+V - Paste (place the cursor where you want to paste first)

Or, of course, the code can be saved as a *.ffp file using notepad.

Ken

[Stroker]

What Ken said about copy, cut, and paste.

In my previous example, used rgb2hsl function to get a value of hue in the range of 0 to 255. You know, 1 dimensional greyscale or something. But what about full colour hue?

One way of doing this is by using rgb2hsl and hsl2rgb. Check it out:

%ffp

ForEveryPixel:{
int hue;

hue = rgb2hsl(r,g,b,0);

R=hsl2rgb(hue,255,128,0);
G=hsl2rgb(hue,255,128,1);
B=hsl2rgb(hue,255,128,2);

}

First we get the hue in the range of 0 to 255. Now, in order to get hue in full colour, we have to use sat=255 and lightness=128 in the hsl2rgb function. Why? Because in the HSL double-cone that is where the full range of RGB lies. That is, smack dab in the center with full saturation.

As fun as that is, there is another way that uses the scale function (scl). Find the min, find the max, then scale everything to full 0 to 255 range.

%ffp

ForEveryPixel:{
int min,max;

min = min(r, min(g,b) );
max = max(r, max(g,b) );

R=scl(r,min,max,0,255);
G=scl(g,min,max,0,255);
B=scl(b,min,max,0,255);

}

I prefer the latter. Later I'll tell you why.

[Stroker]

Easy Sat:

sat=max(r, max(g,b) ) - min(r, min(g,b) );

Pieces of easy sat:

min = min(r, min(g,b) );
max = max(r, max(g,b) );

Scale for full colour hue:

R=scl(r,min,max,0,255);
G=scl(g,min,max,0,255);
B=scl(b,min,max,0,255);

Now we are going to take all of those pieces and put them together.

%ffp

ForEveryPixel:{
int min,max,sat;

min = min(r, min(g,b) );
max = max(r, max(g,b) );
sat = max - min;

R=scl(r,min,max,0,sat);
G=scl(g,min,max,0,sat);
B=scl(b,min,max,0,sat);

}

Notice that the scl functions use the different pieces of the saturation code. That is, we are using mix, max, and sat to scale the RGB values.

What did we do? Rather than scale RGB to full colour hue, we scaled RGB to saturation while retaining hue. That is, the final output will have the hue and sat information of the original input image. All we did is rearrange the hue and sat a little bit.

- copy photograph
- run that code
- change blending mode to Hue, Sat, or Colour

See any difference? You shouldn't because we are using HsY.

Let's try it again but with simple subtraction:

%ffp

ForEveryPixel:{
int min;

min = min(r, min(g,b) );

R=r-min;
G=g-min;
B=b-min;

}

Now let's try addition using max:

%ffp

ForEveryPixel:{
int max;

max = max(r, max(g,b) );

R = r + ( 255 - max );
G = g + ( 255 - max );
B = b + ( 255 - max );

}

The output should look way different, but it will still have the same hue and sat information present in the original. Try Hue, Sat, and/or Colour on the output.

What's the point of all of this? I'm not sure. I think it has something to do with different ways of getting the same data and moving it around different ways to get the same things. I guess your plan of attack will depend on what you are trying to achieve. Sound good? Probably not because I am going rather fast.

At the very least, you should have an idea about hue in RGB and sat. Maybe.

edit:
Okay, I'm gonna see if I can re-focus for where I want to go.

[Cameraken]

Stroker. Thank You.

This is great. Not only are you teaching us FilterMeister but you are teaching us about color spaces as well. Wonderful stuff.
And they thought this was just for geeks. They don’t know what they are missing.
Keep it coming.


FilterMeister can do allsorts of other great things. Here is an example of a bit of code for making borders,

%ffp
ctl[0]: "Border thickness"
ctl[2]: "Red coloring"
ctl[3]: "Green coloring"
ctl[4]: "Blue coloring
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

Ken

[Stroker]

I'm just too ADD sometimes. Pretty sad when I've got to put myself on a leash. Okay, re-focus in effect. Gonna be headin' in Ken's direction.

Now if I could only put this back together again.

That is where we are headed. If I start to stray too much, give me the beat-down.

New code to work with:

%ffp

SupportedModes: RGBMode

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

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=(max+min)/2;

pset(x,y,0,hue);
pset(x,y,1,sat);
pset(x,y,2,lum);

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

return true;
} // end for every tile

There are quite a few differences in there. The biggest thing I want you to note is this chunk:

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

Notice that the structure is ForEveryTile (FET) instead of ForEveryPixel (FEP). While this isn't quite as easy as FEP, it is way more efficient. For images, it is usually better to work with chunks at a time, and those chunks are commonly called tiles. Usually you won't see a speed difference until you start working with way huge images, but let's get started using FET right now.

Using also FET means
- have to make a few extra declarations
- you have to cycle through the image one pixel at a time using for loops and src()

In the code, I have updateProgress commented out. I rarely use this, but I keep it in there just in case I feel the need.

Also made use of SupportedModes. While this won't affect testing within FM, it will make a difference when it comes time to make a stand-alone. RGBMode = RGB using 8-bit per channel.

Another difference, probably more major than minor, is this:

lum=(max+min)/2;

Even though the variable is lum, this is actually the formula for Lightness in HSL. Going to be using this for edification reasons. Once we get past a certain hump or two, we'll change this back to Luminosity that Photoshop uses. By going this route, hopefully save ya'll a lot of frustration.

What exactly are we doing right now? We are mixing-n-matching for our own colour space. Basically taking the easy parts from HSL and HsY.

[Cameraken]

Hee Hee

Don’t try this at home folks

%ffp
SupportedModes: ADD ADHD

ctl[0]: "Attention Deficit Disorder"
ctl[1]: "Attention Deficit Hyperactivity Disorder"

/*R,G,B:

Stroker

I can’t get you last post code to work. It does not even want to compile. (But it does change the picture) I Can’t understand this. Should it work on a RGB picture or is it designed to work with HsY in the channels?

How on Earth did you find that you needed a gradient to put saturation back?


Ken

[Stroker]

If it's not compiling, it should give you an error. What is the error?

The last code that I posted is for RGB mode with 8-bits per channel. What it does is take the RGB values and convert them over to our own blend of HSL/HsY. It's pretty much the same as the first code I posted in this thread.

How on Earth did you find that you needed a gradient to put saturation back?

It's just a matter of knowing what you've got, what you want, and the tools available. If you really understand saturation as Photoshop uses it, you should be able to put the saturation back in using Curves, Levels, or Channel Mixer. You can even do it right in the Channels palette if you really want to. I chose Gradient Map because I thought it would make more sense to other people.

[Cameraken]

Stroker.

Thanks. Everything is working fine. Your code is putting HSL into the channels.

It seems like using the code more than once is the problem. The second time it is run on the same picture it seems to run without the need to compile it.

Open Picture
Open FilterMeister
Paste your code
Press Compile
Press OK

At this point everything is OK and HSL are in the channels

Now
Open FilterMeister again
Now the picture changes without pressing compile

I think I’ve seen this happen before.
Anyway the main thing is that it is working with FET.

Ken

[Stroker]

Now the picture changes without pressing compile

This is because the last compile is cached.

Glad it's working. I'll get to work on the next bit. Actually make a graphic or two. Egads.

[Stroker]

In previous examples, we saw that we could take hue and sat and move them around. In one example, 0 was used as the reference or starting point of sorts. In another example, 255 was used as the reference. You have to pick where to start and then go from there.

In our custom space, the reference or starting point is going to be lum (lum is the name of the variable, but Lightness by definition). Then it's just a matter of scaling. Scale what? Scale hue in full colour, of course.

Plan of attack
- get hue, sat, and lum
- get hue in full RGB colour using temporary values
- scale it using saturation to set the range and lum as the starting point

See attachment for a graphic.

While we are at it, lets add some controls to manipulate hue, sat, and lum.

New 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 rt,gt,bt;

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=(max+min)/2;

// tweak
hue+=ctl(0);
sat+=ctl(1);
lum+=ctl(2);

// get full colour hue
rt=hsl2rgb(hue,255,128,0);
gt=hsl2rgb(hue,255,128,1);
bt=hsl2rgb(hue,255,128,2);

// scale full colour hue down
// to sat range using lum as reference
r=scl(rt,0,255,lum-sat/2,lum+sat/2);
g=scl(gt,0,255,lum-sat/2,lum+sat/2);
b=scl(bt,0,255,lum-sat/2,lum+sat/2);

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

Notice that the controls make use of track. This will make the filter go as you scrub the sliders. Fine for simple filters, but may bog down as things get more intensive.

Also notice that the range of the hue slider is -128 to +128. Cookie if you know why. (Bonus cookie if you know why the range should really be -128 to +127.)

As you get to playing with it, you may notice some funky things. One funky thing in particular is when Sat is set to -255. What this does is allow for illegal values of saturation and that's not always good. To fix, you have to clamp it.

Add something like this:

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

Once you have that, you can desaturate to Lightness in HSL. This is *exactly* the same as hitting ctrl + shift + u. Feel free to do the detective work on that.

Feel free to clamp lum while you are at it. (Bonus cookie for why hue doesn't have to be clamped.)

There is still a lot of funkiness in there. The next funkiness is really funky.

[Stroker]

I would like to thank the RTP Powers that Be for attachments. Normally I would use my own server for my own junk. Mucho appreciated.

In the last code that I posted, there is some funkiness. The major, glaring funk we are looking at is hue. What happens to hue when you get crazy with the Lum slider? It gets funkified. Why? Absolute clipping.

One of the interesting things about hue is that the RGB values stay relative to each other regardless of sat and lum. Do you know the RGB <> hue pattern for yellow? How about the RGB <> hue pattern for green? I'm sure most of you know this, but I don't know if any of you have ever looked at it this way.

The problem with the last code is that RGB <> hue is not being kept relative. If one value is out of bounds, it will get clipped, and that will inadvertantly affect hue. Hopefully the attachment illustrates this.

Welcome to my world.

[Cameraken]

Stroker.

I have never seen ‘Track’ before. I can’t even find it in the manual. But I do understand what it is doing

I’ve spent a lot of time trying to win the cookies but I admit defeat. I could not find the answer at Tech Slop or at the Asylum. I did find an interesting article here.
http://en.wikipedia.org/wiki/Talk:HSV_color_space
I hope I did not miss the answers in this thread.

if (sat<0)}{sat=0;}
I took the extra bracket out

Should I be clamping Sat before or after the calculation of scale full colour hue down
I can’t see any difference on the pictures I tried if the code was before or after or not there at all


Stroker, at
http://tech-slop.serveit.org/wiki/in...a_frequencies1
You are breaking down the picture into frequencies. In another thread (another forum) I read where you tore the luminosity into low, medium and high to correct a face.
I know this can be done with Filtermeister as you must have used it in TS_LumFrequency. Would it be straying too far off subject to show us how to do this?

It’s nice to find someone who can spell ‘colour’ correctly.


Ken

[Stroker]

Track can be found in UserGuide.pdf in section 3.3 User control properties.

For the cookies, you won't exactly find them anywhere. As you do your own research and fiddling, keep them in mind and the answers may come. If not, don't fret too much over it.

Clamp sat immediately like so:
sat+=ctl(1);
if(sat<0){sat=0;}
if(sat>255){sat=255;}

Good catch with the extra bracket.

Actually, more about clamping saturation is coming soon.

Ah, the frequency thing. Fun, isn't it? I used Tom's code because it is wicked fast:

sourcecode\codelibrary\recursiveGauss4b-clean.ffp

- read Lum into an array
- use recursive Gauss for high blur
- High Pass the high bur
- another pass for low blur
- calculate the medium frequencies
- tweak, put back together, and output

That's the real quick of it. Once a lot of this other stuff is out of the way, I'll do a stripped-down version for you.

I think I'm the only person in the USA that still spells colour. I have to make an effort to spell it States style.

[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.