FilterMeister - General Info

[NancyJ]

'y_end', ofcourse, why didnt I think of that It just seems strange that examples in the documentation dont work.
Something I noticed running the lab desat code Stroker posted was that it introduced a lot of compression artifacts - I assume thats because of the ForEveryTile rather than ForEveryPixel, I tried altering the code but then it became so slow. I've noticed that with other code examples, it takes quite a while to do and recreates the preview everytime you move a slider or press a button etc.

[NancyJ]

Ok, I think I'm getting to grips with what does what... but how do you set the tile size?

[byRo]

Originally Posted by NancyJ

'y_end', ofcourse, why didnt I think of that It just seems strange that examples in the documentation dont work.

Don't worry. you'll get used to it.

Originally Posted by NancyJ

Something I noticed running the lab desat code Stroker posted was that it introduced a lot of compression artifacts

Seems that you are using an image that has been through JPEG compression somewhere along the line.
JPG compression applies different parameters to Luminosity and Colours - basically using an 8 x 8 pixel base for Luminosity and 16 x 16 for Colours. Also, I believe, JGP will discard a lot more Colour information than Luminosity when you lower the quality. This is done because we perceive the artifacts much less in the colours.
Now, if you are going to make use of the (noisy) colour information to make your new Luminosity then the artifacts will be more visible.

Originally Posted by NancyJ

I've noticed that with other code examples, it takes quite a while to do and recreates the preview everytime you move a slider or press a button etc.

Yes, that's the (default) way it works. your code gets processed again every time you touch something. For a simple filter that's fine. When processing takes longer then it's a good idea to take some control over this.

Originally Posted by NancyJ

but how do you set the tile size?

Dunno, don't think you do. Never had to worry about this, seems that when you start using src(), pget(), pset() etc. the tile is just the whole image. As I understand it, this would only be a worry for a very big image in a very complex filter.

hope this helped,

Rô

[NancyJ]

Just seems to me that if the tile is the whole image then the function is moot.
A lot of the examples I've seen start with ForEveryTile then for(z) for (y) for(x), which is equivalent to ForEveryPixel, surely?

[byRo]

Well, yes, sortta, not quite.
Sweeping through the (preview) image is automatic and happens every time you alter anything.
As FM is doing this this, it will run parts of your code as identified by "handlers".
The name of the handler (good word to remember) tells you when it will be called.

OnFilterStart: Just once at the start
ForEveryTile: Once for each tile
ForEveryPixel: Once for each pixel
OnFilterEnd: Just once at the end
OnCtl(n): Every time you touch a control.

So, if you use ForEveryPixel, then you don't need to (well, "should not", actually) use any looping, 'cuz FM is already doing that for you. (Which is probably what happened to you - for every pixel, you code was looping through the whole tile.)

If the tile is the whole image, then OnFilterStart and ForEveryTile are just about the same thing.

As posted somewhere above, there is no handler for when your filter is first activated - the OnFilterStart runs once every time you touch something. If you want to initialize (as I did) then you need a flag. As in stroker's suggestion, you can use one of the pre-definied global integers (i0...i9) which are initalized as 0. Just test for 0, and set it to 1 after initializing the filter.

OnCtl(n) is used for administration of the dialog. You can test for n to discover which control was actioned.

Originally Posted by NancyJ

A lot of the examples I've seen start with ForEveryTile then for(z) for (y) for(x), which is equivalent to ForEveryPixel, surely?

For the simplest filters, yes, that works. Although I read, somewhere, that ForEveryPixel is not the recommended method.

Hope that explained it.
If you have any more doubts, please ask.

Rô

[Kraellin]

well, true to my nature, i couldnt stand to wait and read through 100 pages of docs. so, i just jumped in and started editing i used the 'adjustsaturation.ffp' file that came with the program and remmed out the ctl(0) and ctl(1) and wrote my own for those based on what i was talking about in the last post. this was just a test. it worked .... sort of.

i dont understand all the rest of that code that came with that ffp, but my little test did take the image from 0 to 255 saturation using the first slider, instead of what was originally there. and it also seemed to move the other range, the 8-15 one, up and down a bit.

this was just a simple test and by no means what i'm fully after here, but ok. been a long while since i played with code.

i shld also mention that even though this desired filter is meant for grays, i do want to primarily have it work on 8 bit grays, not grayscale. fine if it also works on grayscale, but mostly i convert any true grayscale i'm working on into 8 bit grays anyways before actually working on it. so the filter shld primarily be for 8 bit rgb mode.

attached is an image of the pic i worked on and the code i adjusted. the adjusted code is highlighted in red. the rest is what was there in the filter to begin with.

craig

[byRo]

Originally Posted by Kraellin

...so, here's my first question. when you compile an ffp you get the filter in a working form immediately. but, can you save these out as .8bf's and not have to compile them each time when you want to use one?

You don't need to compile to .8bf's unless you intend to share with / sell to other people. Just like any software coding you can go "open source" and post source code for everyone, or compile to .8bf and distribute the executable.

If you are going to use the same filter many times then a .8bf is better, if you're doing a one-off then no need.

The license for creating .8bf's is around US$20.

Rô

[Kraellin]

thanks Ro,

going on what you said, i hit the 'make' button to see what it would do, and you get a blurb about registering at filtermeister.com. so, ok

craig

[byRo]

Originally Posted by Kraellin

....so, some questions on that code. what does 'track' do?

When a slider is specified as "track" your code will be re-executed with every movement of the slider. For simple (i.e. quick) processes that works fine.
If your code ain't so fast, it won't be able to keep up with the slider and the preview will be choppy. In this case better without track, then the code will be executed only at the end of the slider movement.

Originally Posted by Kraellin

also, in another piece of code, not stroker's piece here, i ran into 'rv', 'gv', and 'bv' as variables, i would think. but i couldnt find any definition for them in the docs. and they seem to be reserved variables. i tried changing them and got an error message that it basically didnt know what these were now that i changed them. so, what do they stand for and what do they do?

I don't think they are reserved. Maybe you forget that all variables have to be declared before using. If you wish to change the variable's name, you must update the declaration too.

Originally Posted by Kraellin

...and the docs just refuse to tell me what i want to know when i want to know it

That's why it's fun A Magical Mystery Learning Experience
Or...just ask here! I'm sure Stroker and I will have some good answers.

Rô

[Kraellin]

Ro,

thanks.

so, this line: "int r,g,b,Gray, rv,gv,bv;" is the line that defines-declares-initializes the variables? looks like it. so 'rv', 'gv', and 'bv' are just arbitrary variable names the person used in the code and not pre-set or reserved. ok.

then why are 'R', 'G' and 'B' not declared in some programs? and the same with 'r', 'g', 'b', 'x', and 'y'? are those reserved?

also, in going over stroker's last piece of code posted, the line:

number=floor(workingfloat+0.5);

has a variable that doesnt seem to be declared as well, 'floor'. or is this a function? lol. gotta do more reading.

i'm going to also assume in that code that 'float', up near the top, just under the 'int' line, means: 'make these next items floating point variables'. that right? the docs, or my ability to find things, seems to be woefully lacking here as far as definitions of things and what they do.

i do recognize a few things from having studied C briefly a few years back, but technical writing has always been my bane in learning things like this. the writer knows certain given things and seems to always think i know them also. heh...i dont. and that's fine if you're teaching others that have that background of basics already down pat, but again, i dont. i need 'filtermeister for dummies'

ah well, i'll keep looking.

oh, and i also did find out that 'standard' means simply, 'use the default control, the slider or scrollbar'.

craig

[Kraellin]

ceil(u), floor(v)
These two functions take the term u respectively v and return the whole numbers directly above respectively
below the actual term.For example, in the number 5.3, the ceiling is equal to 6 and the floor is equal
to 5.Both functions return floating point values.

ok, found 'floor'. seems to be a rounding off function, along with 'ceil'. floor rounds down, ceil rounds up, and both give these as floating point values.

so ok, i'm curious here; why did stroker use floating point values at all in that last piece of code? because of the division done in that one formula? and i'm completely lost as to the purpose of this line: avg=r*0.30 + g*0.59 + b*0.11; he seems to be weighting the r g b values differently, but why? why not just use the //avg=(r+g+b)/3; line which he remmed out?

craig

[Stroker]

Real quick and I'm off to bed.

Integers are number without decimals places or fractional parts.

int a=1, b=10, c=257;

Floats and doubles can have decimals places.

float pi=3.14159;

I used floats in the last code because I needed percentages. You know, numbers between 0 and 1. This is to weight the sliders from 0% to 100%. I'll get into this later.

and i'm completely lost as to the purpose of this line: avg=r*0.30 + g*0.59 + b*0.11; he seems to be weighting the r g b values differently, but why? why not just use the //avg=(r+g+b)/3; line which he remmed out?

Personal preference. The way I weighted the RGB values is how Photoshop weights RGB for Luminosity as it uses it in the Luminosity blending mode.

[Kraellin]

stroker,

ah, ok. int does equal integer then. wasnt sure if it was integer or initialize or something else. so, just adding 'int' tells the following items that they are now integer type variables. cool. and the same with 'float', only that makes them floating points. ok.

and yes, forgot about the percentages. i see that now. thanks sorry, it's been quite a while since i played with code.

seems a bit of an odd way to weight the values, but i'm guessing that has to do with how luminosity is stored in the various channels, so ok. it works, so cant argue much with that.

ok, i altered your code to make it 32 bands/ranges. i also upped the percentage values in the ctl(x) lines to (-1000,1000). this allows me to take most values to complete black or complete white rather than just percentages of the original. i mean, they're still percentages, but now they just go further. and yes, i changed the divide by 51 accordingly. with 16 bands i changed it to 16. with 32, i changed it to 8.

also, the 'standard' thing was causing the sliders to write over each other with this many sliders, so i changed back to the longhand way.

i've still got to figure out how to resize the interface window. it currently doesnt want to hold all my sliders in view when you first compile the code. they are there, but the window has to be opened up more to see them completely.

and, i think i saw a piece of code in the docs about a 'reset' button. gonna need that too. setting 32 sliders back to 0, each having a range of -1000 to 1000 is a bit of a task. so, gotta do that too.

this is cool stuff. i just posted a pic in the photo art forum i did with this new filter. it's in the 'red flower' section/post. i mean, why limit your creativity to just using other folk's plugins and programs.... make your own! very cool.

craig

[byRo]

Originally Posted by Kraellin

....so, this line: "int r,g,b,Gray, rv,gv,bv;" is the line that defines-declares-initializes the variables?

Yes to definition, not sure about initialization. Maybe the variables get initialized to 0 (zero) but I wouldn't count on that (ever ).

Originally Posted by Kraellin

then why are 'R', 'G' and 'B' not declared in some programs? and the same with 'r', 'g', 'b', 'x', and 'y'? are those reserved?

Yes, exactly. R, G and B (capital letters - it does make a difference) are reserved variables represententing the R, G, B values when using FM in the Filter-Factory-type mode. In "programming" mode you would use src(x,y,z) to read the channel value and pset(x,y,z) to set it.

Originally Posted by Kraellin

i'm going to also assume in that code that 'float', up near the
top, just under the 'int' line, means: 'make these next items floating point variables'. that right?

You got it.

Originally Posted by Kraellin

..the docs, ......, seems to be woefully lacking here as far as definitions of things and what they do.

Yes, that's half the fun

Originally Posted by Kraellin

... so, just adding 'int' tells the following items that they are now integer type variables. cool. and the same with 'float', only that makes them floating points. ok.

Not quite. Adding (int) and (float) does not change the type of variable. It defines what sort of arithmetic to use. With int all fractional results get thrown away. With float the arithmetic is precise but takes longer.

Originally Posted by Kraellin

...seems a bit of an odd way to weight the values, but i'm guessing that has to do with how luminosity is stored in the various channels, ...

No, actually it's exactly the other way round. These are the relative weights that our eyes attribute to the R, G, B channels. Thus if we set up this mix (30/59/11) of the three channels the result corresponds to the "luminosity" that we (humans) see. Like stroker said about Photoshop luminosity plus... JPG images have the Luminosity stored separate to the colours - guess the R/G/B percentages used!

Philosophical aside
This Luminosity stuff exists only in our heads. In Nature there is just a mixture of different wavelengths, nothing separated into greyscale / Colour information.
Our eyes are, mostly, sensitive to two basic wavelengths corresponding to (what we call) Green and Red. Why? Because, for a very long time, those are the two colours that really mattered as a question of life or death. The Blue information was always more hazy and gets included as a filler.
/Philosophical aside

Resize the dialog. Inlcude this and you'll have a nice big dialog.

OnFilterstart:{
	setCtlPos(CTL_OK,       420,280, -1, -1);
	setCtlPos(CTL_CANCEL,   460,280, -1, -1);
	setCtlPos(CTL_PREVIEW,    5,  5,245,265);
	setCtlPos(CTL_ZOOM,     200,285, 50, 10);
	setCtlPos(CTL_PROGRESS,   5,285,185, 10);
	return false;
}

Rô

[byRo]

Originally Posted by Kraellin

.....his secret for writing good manuals is, he NEVER writes them himself. he's a coder, not a writer and he just knows too much and would assume too much. so, he writes his programs and then finds someone who knows absolutely NOTHING about the program and has them write the manuals. this works a charm. the newbie has to learn what's there and learn it in his/her terms with his/her current knowledge of the program, which is nothing. so, they have to figure it out just like the end user is going to have to do. and as they do so, they simply write down what they find out. if they have questions, they ask him. it's the most brilliant technical writing technique i've ever heard of.

Craig, this is your big chance! Go to the FM site (http://www.filtermeister.com/) , select Documents, then FilterMeister Wiki. When you're through writing the manual (or if you have any doubts ) just call us up. I've already corrected one of the entries there.

Rô