FilterMeister - Color Theory and Conversions

[Stroker]

Let's play Connect the Dots.

Sobel
Canny Edge Detection
Gradient
Flow Up and Down
Diplacement Sharpening

Can you see the bigger picture?

[Stroker]

I'm about to jump out of my skin. How about a quick-n-sleazy tutorial? I call this High Pass Masking, but it might be known by other names.

- Start with some photograph
- Copy it and High Pass to taste
- Add an Adjustment Layer > Gradient Map
-- for the G-Map, use Black <> White <> Black
-- start with the white stopper at 50% and tweak from there

What did we just do? We used High Pass for edge detection. The good thing is that it has radius. The bad thing is that it fails in the delta change department. High Pass + delta change = bad! Well, bad for current purposes.

To fill in the holes, all you have to do is complement with regular ol' find edges.

Oh! Did I just say that?

[byRo]

Originally Posted by Cameraken

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

OK, You guys up to mind reading again?

Yes I have read that - and about 50 others in the last couple of days.
The book he quotes, "Numerical recipes in C", is very interesting. I'm getting comfortable with the basic FFT routine, but the 2-dimensional version (which we need here) still scares me a bit.

Actually, I was quite surprised at how (relatively) simple it is. What complicates matters is when you try to get it running faster and faster.

However, our need for bigger and bigger images is just about satisfied. It pretty hard to justify anything bigger than 3000 pixels on each side.
Processing power and memory capacities continue to rise exponentially.
When theses guys started with these techniques they were using "fast" 100MHz computers, but now 1GHz is pretty slow.
Which means that instead of talking of reducing execution times from 5s to 2s, we have something that may take 500ms and reduce to 200ms. Which, for a one-off process, nobody is even going to notice.

Rô

[Cameraken]

Wooha

Hue, Sat and Lum all working fine. Thanks Stroker.


Ken

[Stroker]

Kudos, Ken.

Now, my way is a bit long-winded. Ralph of Simpel Filter has provided his snippet for HsY > RGB.

--------------snip-------

              //HsY to RGB - Y hier mit v bezeichnet
      //Scale to float
      hf=6*r/255.0; sf=g/255.0; vf=b/255.0;

      // H is given on [0, 6] or UNDEFINED. S and V are given on [0, 1].
      // RGB are each returned on [0, 1].

      if (sf == 0.0) {rf = vf;  gf = vf;  bf = vf;}
      else {
      i = floor(hf);
      switch (i) {
          case 6:
          case 0: hf = hf;    bf = vf - sf*(0.299 + 0.587*hf); gf = bf
+ sf*hf; rf = bf + sf; break;
          case 1: hf = 2.0 - hf;     bf = vf - sf*(0.587 + 0.299*hf);
rf = bf + sf*hf; gf = bf + sf; break;
          case 2: hf = hf - 2.0;     rf = vf - sf*(0.587 + 0.114*hf);
bf = rf + sf*hf; gf = rf + sf; break;
          case 3: hf = 4.0 - hf;     rf = vf - sf*(0.114 + 0.587*hf);
gf = rf + sf*hf; bf = rf + sf; break;
          case 4: hf = hf - 4.0;     gf = vf - sf*(0.114 + 0.299*hf);
rf = gf + sf*hf; bf = gf + sf; break;
          case 5: hf = 6.0 - hf;     gf = vf - sf*(0.299 + 0.114*hf);
bf = gf + sf*hf; rf = gf + sf;
          }
      }

      //Scale to int
      k1=rf*255;
      k2=gf*255;
      k3=bf*255;
------------------

It's a bit more elegant and is a bit more accurate.

For the most part, I'm going to bow out for now. But I will watch for questions and things that tickle my fancy.

[Stroker]

Grrr...!

Basic Lab manipulation using FM's built-in polar functions.

%ffp

supportedmodes: labmode

ctl(0):"Theta",range=(-512,512),val=0,track
ctl(1):"Rho",range=(0,300),val=100,track

ForEveryTile:{
int aa,bb;
int theta,rho;

for(x=x_start;x<x_end;x++){
for(y=y_start;y<y_end;y++){

// grab and normalize to 0
aa=src(x,y,1)-128;
bb=src(x,y,2)-128;

// convert to polar
theta=c2d(aa,bb);
rho=c2m(aa,bb);

// modify polar
theta=theta+ctl(0);
rho=rho*ctl(1)/100;

// back to Cartesian
aa=r2x(theta,rho);
bb=r2y(theta,rho);

// output normalized to 128
pset(x,y,1,aa+128);
pset(x,y,2,bb+128);

}} // y x

return true;
} // for every tile

[Stroker]

Emboss a bit heavy on precision. If you do it integer style, it's much faster.

%ffp

ctl(0):"Angle",range=(-180,180),val=0,track
ctl(1):"Height",range=(0,40),val=5,track
ctl(2):"Amount",range=(0,300),val=100,track

supportedmodes: rgbmode

OnFilterStart:{
setZoom(1);
set_edge_mode (3);
return false;
}

ForEveryTile:{
int x,y,z;
int v1,v2,final;
float angle,gx,gy;
float pi = 3.14159;

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

angle=pi*ctl(0)/180.00;
gx=fcos(angle)*ctl(1)/5.0;
gy=fsin(angle)*ctl(1)/5.0;

v1=iget(x+gx,y+gy,z,0,3);
v2=iget(x-gx,y-gy,z,0,3);

final=(v1+(255-v2))/2;
final=128+(128-final)*ctl(2)/100;
pset(x,y,z,final);

}}} // x y z

return true;
} // for every pixel

[Stroker]

I adore the subject of desaturating. What I don't like is Channel Mixer for desaturating. IMHO, CM is poor for desaturating because it's so one directional.

Here is a variation of Channel Mixer specifically for desaturating.
- not in the code, but I call it Mono Mixer
- Subtract is inverted and works like Multiply
- Substrate is like Constant in CM

Use it wisely.

%ffp

ctl(0):standard,"Substrate",range=(-226,256),val=0,pos=(280,5),track

ctl(1):standard,"R",range=(-200,200),val=33,pos=(260,25),track
ctl(2):combobox(vscroll,extendedui),"Add\nSubtract\nLinear Light",val=0,pos=(390,23),size=(55,80),action=preview

ctl(3):standard,"G",range=(-200,200),val=33,pos=(260,55),track
ctl(4):combobox(vscroll,extendedui),"Add\nSubtract\nLinear Light",val=0,pos=(390,53),size=(55,80),action=preview

ctl(5):standard,"B",range=(-200,200),val=33,pos=(260,85),track
ctl(6):combobox(vscroll,extendedui),"Add\nSubtract\nLinear Light",val=0,pos=(390,83),size=(55,83),action=preview

supportedmodes: rgbmode

ForEveryTile:{
int x,y;
int r,g,b;
float addr,addg,addb;
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);

addr = addg = addb = 0;

switch(ctl(2)){ // R
case 0: // add
addr=(float)r*(float)ctl(1)/100.00;
break;
case 1: // subtract
addr=(255.00-(float)r)*(float)ctl(1)/-100.00;
break;
case 2: // linear light
addr=((float)r-128.00)*(float)ctl(1)/200.00;
break;
} // R switch

switch(ctl(4)){ // G
case 0: // add
addg=(float)g*(float)ctl(3)/100.00;
break;
case 1: // subtract
addg=(255.00-(float)g)*(float)ctl(3)/-100.00;
break;
case 2: // linear light
addg=((float)g-128.00)*(float)ctl(3)/200.00;
break;
} // G switch

switch(ctl(6)){ // B
case 0: // add
addb=(float)b*(float)ctl(5)/100.00;
break;
case 1: // subtract
addb=(255.00-(float)b)*(float)ctl(5)/-100.00;
break;
case 2: // linear light
addb=((float)b-128.00)*(float)ctl(5)/200.00;
break;
} // Bswitch


final=ctl(0) + addr + addg + addb;

pset(x,y,0,final);
pset(x,y,1,final);
pset(x,y,2,final);

}} // x y

return true;
} // for every pixel

[Cameraken]

I like the last one Stroker.

Converting from colour to Black and White can be controversial. I read your “Fighting the Status Quo”
With many pictures it doesn’t seem to matter which method is used but with others it can make a big difference.
I particularly like one method (which I think was yours)

* create a new blank Layer on top of your Background
* Fill the new Layer with 50% Grey
* Change the new Layer Blending to Color (or Saturation)

This code gives a lot more control. It's going to need some practice.
Linear Light = Add/Subtract using 128 as the mid-point

Mono Mixer is definitely going in my toolbox.

Thanks Again.

Ken.

[Stroker]

Ken, you tickle me. Fighting the Status Quo is one of my favorites. I've gotten into some heated arguements over that one. Oh, the irony.

Maybe one of these days I'll wage war again. Show you guys and gals a few uber tricks, and maybe have a chat about contrast while we're at it.

Contrast: to set in opposition in order to show or emphasize differences.

Something to think about - and very relevant when it comes to desaturating.

[Stroker]

Lab mixer for desaturating much like Mono Mixer.

%ffp

supportedmodes: labmode

ctl(0):"a center",range=(-100,100),val=0,track,pos=(280,5)
ctl(1):"a weight",range=(-200,200),val=50,track,pos=(280,15)

ctl(2):"b center",range=(-100,100),val=0,track,pos=(280,40)
ctl(3):"b weight",range=(-200,200),val=50,track,pos=(280,50)

ForEveryTile:{
int ll,aa,bb,x,y,final;

for(x=x_start;x<x_end;x++){
for(y=y_start;y<y_end;y++){

ll=src(x,y,0);
aa=src(x,y,1)-128+ctl(0);
bb=src(x,y,2)-128+ctl(2);

final = ll + aa*ctl(1)/100 + bb*ctl(3)/100;

pset(x,y,0,final);
pset(x,y,1,128);
pset(x,y,2,128);

}} // y x

return true;
} // for every tile

There are several things hidden in the code. Ramble coming soon.

Dichotomy: division into two usually contradictory parts.

[Cameraken]

Oh no! Not contrast. I’ve seen debates about that as well (Where is Flora).
Did you ever write the Shadow/Highlight Filter. (Us Poor PS7 Users).
I tried writing that one myself. I got something working but it does not seem to do exactly the same thing. I remember reading that you had figured out what it was doing.

“Contrast: to set in opposition in order to show or emphasize differences.”
That definition sounds good but a contrast reduction can bring out more detail. Especially in some of the older restoration projects. But I think this depends on global contrast (low frequency) or local contrast (high frequency)

Shadow/Highlight - Now that would be a good project.

http://www.photoshoptechniques.com/f...ad.php?t=14755
http://tech-slop.serveit.org/wiki/in...title=Contrast
http://tech-slop.serveit.org/wiki/in...um_Frequencies

I’ve just downloaded TS_Lum FrequenciesV? I noticed the picture on your webpage was different to my version, Version Numbers would be good. It’s changed a lot. Looks like I need to learn this one all over again.

And talking of contrast.
Ro.
Wow, great stuff, you are flying with this.
http://www.retouchpro.com/forums/software/12957-free-equalization-plugins-byro.html


Ken.

[byRo]

WARNING! If you are experimenting the source codes in the codelibrary beware of the filter named "FilterWithoutDialog.ffp".
I ran that one, just to see what happened, and then spent half an hour trying to get FM to appear again - it just blinked and disappeared every time I tried to call it up.
Not exactly sure what I did to get it back - I think it was when I pressed the Shift (or maybe Ctrl) key while trying to open the program.

Rô

[Stroker]

Heh. My wiki is behind the times on a few things. I ran into a version problem with L* Frequencies and taking care of the LF nodes ground to a halt. I finally got the version problem taken of, so I should update the wiki nodes, eh? Maybe in a few days or so.

When dinking with str0 in FM, be wary when saving files.

One of these days I'll talk about Shadow/Highlight. Rather, show some of the tricks involved. I'll do it on the sly at my wiki for various reasons.

Roland, same thing happened to me with FilterWithoutDialog. All I did was restart Photoshop because that's the only sure fire way I know of to break the vicious cycle.

I'll do my best to field any questions, Ro.

[Cameraken]

Stuck Again.

I have been trying to use stock tools to split Highlights, Midtones and Shadows.
Using Select > Colour Range I am getting gaps.
Even selecting just the Highlights (claw) and Shadows I still get a gap.

I decided to use FM.
I wrote this code to split Highlights, Midtones and Shadows onto the channels however I am back to a similar problem

Using a Black to White gradient as a test picture and the code below I don’t get gaps anymore But the midtones are not an equal third of the picture.

Now I thought this was because I used
lum=r*0.30 + g*0.59 + b*0.11
So I replaced it with
lum=(r+g+b)/3

but my test picture is still the same. The midtones don’t cover 1/3 of the picture like I would expect.

Questions
Have I done something wrong?
If Not. Then why do the midtones not cover 1/3 of the picture?

%ffp

ForEveryPixel:{
int low,mid,high,lum;

//lum= r*0.30 + g*0.59 + b*0.11;
lum=(r+g+b)/3;

low=(lum<85)? lum:0;
mid=(lum>86) & (lum<170)? lum:0;
high=(lum>171)? lum:0;

R=low;
G=mid;
B=high;

}

Ken

[byRo]

Ken,

The good news: You are not going crazy. Your code is correct.
The bad news: Photoshop gradients are not linear

Put an eyedropper at the transition lines, then go back and see what the readings are at these points in the original gradient.
The channel values will fit in fine. However, they are not at 1/3 intervals.

Maybe stroker can explain to us why that happens.

Meanwhile, if you want to generate a perfectly linear gradient, then do it with FM!!

Rô

[Stroker]

When you lay the gradient, make sure Smoothness is set to 0%.

Smoothness 0% = linear interpolation
Smoothness 100% = b-spline interpolation

This tid-bit took me a long time to figure out. Chris Cox of Adobe confirmed, and you can see this for yourself with a little help from Histogram. Since then, whenever I lay a gradient, I *always* double-check Smoothness.

Gonna hide under my rock again for a bit.

edit:

Roland, how good are you with geo/trig?
Basic 3D Math
Yeah, I got something brewing, but ran into a funky anomoly.

[byRo]

Thanks, stroker.

I knew you'd have something interesting to add.
Problem is, I can't see how that works out.

The smoothness setting is in the Gradient Map editor. Setting this to "0" really does explain a whole bunch of quirky things that I'd seen on the past.

The Gradient Map, however, does not generate the gradient, just translates it.
So the question stands, how can I generate a black-to-white linear (as in "x" vs. R,G,B) gradient? (in PS, without resorting to FM?)

.....or, maybe I missed something.

(Trigonometry and 3D math never were my favourites - but I can usually muddle my way through. - What's up?)

Rô

[Stroker]

Gradient tool has Smoothness as well. When you lay down the initial gradient with the tool, make sure it is Smoothness 0 right from the begining.

Yes?

Meh. Don't worry about the geo/trig thing. Gonna put it on the back burner for a few.

[Cameraken]

Thanks.

The Gradient Was the problem. I set the Smoothness to Zero and my code works fine.

(Smoothness is in the same place as when using Gradient Map – Click on the Gradient)

This does explain a lot. I have been setting Smoothness to Zero when putting Sat back without realising the reason why.

Ken

[byRo]

Originally Posted by Cameraken

Smoothness is in the same place as when using Gradient Map – Click on the Gradient

(insert here a couple of smileys smacking themselves on the forehead)

Thanks, Ken.

(insert a couple more here )

Rô

[Stroker]

Lab is a sphere. Lab is Cartesian. This good for a lot of simple tricks that just plain rock.

Basically use Pythagoras to measure distance from the center of the Lab sphere. The ranges are 0 to 255 with the center at 128. But because of the math involved, better to offset for a range of -128 to 127. This means that the maximum distance will be 128. Have to multiply that by 2 to get back to 0 to 255.

This isn't exactly mid-tone as most are used to. This is more of a 3d mid-tone and is quite different from Colour Range. Personally, I adore it. Plus this is the beginning of some cool Lab tricks.

%ffp

SupportedModes: LABMode

ForEveryTile:{
 int x,y,ll,aa,bb;
 float dx,dy,dz;
 float dist;
 int final;

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

// grab values and normalize to 0
ll=src(x,y,0)-128;
aa=src(x,y,1)-128;
bb=src(x,y,2)-128;

// get delta and convert to float
dx=(float)ll;
dy=(float)aa;
dz=(float)bb;

// pythagoras
dist=sqrt(dx*dx + dy*dy + dz*dz);

// convert, invert, and multiply by 2
final=255-(int)dist*2;

// output to greyscale
pset(x,y,0,final);
pset(x,y,1,128);
pset(x,y,2,128);

}} // x,y

return true;
} // for every tile

[Stroker]

Pretty much the same above but with a little extra junk. Just added some controls to define the center of the greyscale. Few other minor changes.

As it is, it is pretty good as a simple colour range do-hickey.

Things you may want to add:
- controls to level the greyscale
- right-click Preview to set controls

%ffp

ctl(0):"L",range=(0,255),val=128,track
ctl(1):"a",range=(-128,127),val=0,track
ctl(2):"b",range=(-128,127),val=0,track
ctl(3):checkbox,"Invert",val=0

SupportedModes: LABMode

ForEveryTile:{
 int x,y,ll,aa,bb;
 float dx,dy,dz;
 float dist;
 int final;

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

// grab values and normalize to 0
ll=src(x,y,0);
aa=src(x,y,1)-128;
bb=src(x,y,2)-128;

// get delta and convert to float
dx=ll-ctl(0);
dy=aa-ctl(1);
dz=bb-ctl(2);

// pythagoras
dist=sqrt(dx*dx + dy*dy + dz*dz);

// convert, invert, and multiply by 2
final=255-(int)dist*2;

// output to greyscale
if(ctl(3)==1){final=255-final;}
pset(x,y,0,final);
pset(x,y,1,128);
pset(x,y,2,128);

}} // x,y

return true;
} // for every tile

Basic Pythagoras was fun. How about some polar next?

[Stroker]

Let's get a little polar in Lab space.

Rather than use Pythagoras and trig functions, going to use FM's built-in polar functions. I believe these polar functions can be found in UserGuide.pdf near the trig functions.

%ffp

ctl(0):checkbox,"L* = 128",val=0

supportedmodes: labmode

ForEveryTile:{
int x,y;
int ll,aa,bb;
int theta,rho,maxrho;

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

// grab values
//ll=src(x,y,0);
aa=src(x,y,1)-128;
bb=src(x,y,2)-128;

// convert to polar
theta=c2d(aa,bb);
//rho=c2m(aa,bb);
rho=127;

// back to Cartesian
aa=r2x(theta,rho);
bb=r2y(theta,rho);

// output with L* option
if(ctl(0)==1){pset(x,y,0,128);}
pset(x,y,1,aa+128);
pset(x,y,2,bb+128);

}}// x, y

return true;
} // for every tile

[Cameraken]

Basic Pythagoras was fun. How about some polar next?

OK Great. I hope you can show some uses for Lab.

The code from post 90 is like a channel mixer with monochrome checked. Which is useful as the channel mixer is grayed out in Lab.

Post 91.
Stroker. Could you explain what this code is doing please? It looks like hue.

The Polar functions are in the user guide on page 28
Polar coordinate functions r2x(d,m), r2y(d,m), c2d(x,y), c2m(x,y)


There is also some sample code to convert RGB to Lab (RGB_to_Lab_and_back.ffp). Does this work as well as using PS?


Ken

[Stroker]

Okay, Lab is Cartesian. Uses x, y, and maybe even z. Imagine a square or a cube.

HSL et al are polar. These are things that are round. Angles and magnitudes. Theta and rho. Cylinders, spheres, and cones.

Even though Lab is a sphere, it is Cartesian. This leads to some interesting things. For example, if you want to rotate hue in Lab like you would in HSL, you have to convert to a polar system, and then convert back to Cartesian. Covnerting back and forth between Cartesian and polar is basic trigonometry.

One of the very basic things to know is Pythagoras' Formula. I'm sure you've seen this.

a^2 + b^2 = c^2

That will give us the distance, magnitude, or rho between origin and an arbitrary point. In colour systems, this is commonly called saturation. No matter the name, it's all effectively the same.

In post 90, we used Pythagoras to get 3d distance from the center, which is 50% grey.

a^2 + b^2 + c^2 = r^2
r = sqr( a*a + b*b + c*c )

To get the distance between two arbitrary 3d points, it would look something like this:

(x2-x1)^2 + (y2-y1)^2 + (z2+z1)^2 = r^2
r = sqr( (x2-x1)*(x2-x1) + (y2-y1)*(y2-y1) + (z2-z1) )

In Lab space, this is an excellant trick for converting colour ranges to greyscale. With a little savvy, I find this method better than Photoshop's own Select > Colour Range.

Now, post 91 is also a trick of trig, but with a focus on polar instead of just Pythagoras.
theta = hue
rho = saturation
Convert a and b to theta and rho, set rho to a given value, convert back to a and b. What you are effectively doing is setting saturation to a fixed number. The code basically says set saturation to 127. It is doing this in Lab space using a polar system.

Few more tricks, then the rabbit hole is going to get deep again.

[Stroker]

Almost forgot about rgb2lab and lab2rgb.

For the majority of applications, they work fine. However, be aware that you might run into some shifts due to gamma. Largely negligable, but might make a difference if you are into the device independance thing in Lab.

[Cameraken]

Thank You for the explanation Stroker.

I’m just about keeping up. But I’m having to do a lot of searching.

Further Math’s ‘A’ Level was a Long Long time ago and now I can’t find my log books.

http://en.wikipedia.org/wiki/Lab_color_space

The more I play with the greyscale converter – The more I like it. Another one for my Toolbox.


Ken

[Stroker]

Polar is good. But let's try something a little bit different.

To do colour balance in Lab, you just add to a and b channels. There is a way of doing this that is similiar to polar but remains in Cartesian.

Gradient
This is simply an amount. That's it. Displace works by using an x gradient and a y gradient. You know, move things up/down using this gradient and move things left/right using that gradient.

Vector
More than one gradient. All gradients at 90 degrees to each other. For example, ( x+3, y-5) is a vector. So is ( x-2, y+10, z+3).

Normal
A normal is a vector with a unit length of 1. If you use Pythagoras to get the distance of a normal, it will be 1. I guess you can think of a normal as an angle using two (or more) numbers. Or something like that.

Rough analogy:
- hue = x grad and y grad as a normal
- sat = amount to travel in the direction of the normal

Now, it is possible to convert a vector to a normal. This is done simply by dividing each axis by the distance.

x=3
y=-4
distance=5
x grad = 3/5 = 0.6
y grad = -4/5 = -0.8

0.6^2 + -0.8^2 = 1^2
0.36 + 0.64 = 1

Any distance you multiply by 0.6 and -0.8 will go in the same direction as the original 3 and -4.

Cool beans.

Here is a simple example using that junk to colour balance in Lab.

%ffp

ctl(0):standard,"x grad",range=(-100,100),val=10,track
ctl(1):standard,"y grad",range=(-100,100),val=10,track
ctl(2):standard,"u",range=(-100,100),val=10,track
ctl(3):checkbox,"Colourize",val=0

supportedmodes: labmode

ForEveryTile:{
int aa,bb,adda,addb;
float distance,nx,ny;

for(x=x_start;x<x_end;x++){
for(y=y_start;y<y_end;y++){

// grab values
// not going to bother with 128
aa=src(x,y,1);
bb=src(x,y,2);

// Pythagoras to get distance
distance=sqrt( (float)ctl(0)*ctl(0) + ctl(1)*ctl(1) );

// normalize the vector
nx=ctl(0)/distance;
ny=ctl(1)/distance;

// amount to add to each axis
adda=ctl(2)*nx;
addb=ctl(2)*ny;;

// output with option
if(ctl(3)==0){l
pset(x,y,1,aa+adda);
pset(x,y,2,bb+addb);
}else{
pset(x,y,1,adda+128);
pset(x,y,2,addb+128);
}

}} // y x

return true;
} // for every tile

Kind of a weird way of going about it, but it has advantages.

[Cameraken]

Stroker

There is an error in the above code

// output with option
if(ctl(3)==0){l

I changed it to

if(ctl(3)==0){

Does that look correct?

Changing that seems to get the colourize working.But I don’t think its doing what it should.

Ken