new, with questions

hello all,
very glad to have found filter forge.

i am struggling with a few things so far and have not found sufficient info with the search or wiki.

1. is there, will there be a median filter, or some quick alternative?
2. how can i process particular color ranges? i need something functionally akin to the 'select color range' in photoshop.

thanks!!

how can i process particular color ranges? [QUOTE] ahh man now Im obbsessed Im close to this one but the range component Im using is flakey sometimes it gives odd results so Ill probably have to start over from scratch

vladimir,

thank you for that.

however, there seems to be a very slight anomoly on this setup. and mind you, i said seems, cause maybe i'm doing something wrong here. i set up just a simple test of all this with the RGB extract and assemble and the impulse and tone curve. when i set the inpulse to a normal curve type so as to not alter the original image, the position control on the red and the green have to be set to 51 instead of 50 in order to not introduce a slight noise variance into the image. by my thinking, it shld work if all position controls are set to 50. but, it doesnt. the blue seems to be right; it works fine at 50, but the red and green seem to be slightly off.

is this a bug or am i just doing something wrong here?

i'm attaching the filter:

Select Color Range 1d.ffxml

Here. A real HLS-based color range extractor, controlled by a reference color (needs more controls though):

HLS Range a1t.ffxml

thank you thank you!

i had experimented with extracting components and tone curves but i was missing a few steps. this opens up a lot more room for experimentation. maybe FF can have self contained modules for color / luma range masking etc down the line!

thanks for the versions, vlad. i'm analyzing this whole area again and those definitely help.

i also find that i'd LOVE a cmyk extract and assemble component now also! it's a bit of a flaw in the current state of digital color that we dont all work in rgbcmyk instead of just rgb or cmyk. i would think that having 7 channels/bitmaps (8, when you count the alpha) would make things much easier when manipulating color.

if you want to extract just cyan, for instance, i can easily set up something to get the blues AND the greens of an image, but separating this into blue OR green, so that you only get the blues OR the greens and not both, is a different matter. i could really use a 'subtraction' component here, such that when i get a blue hue of say, 0, 240, 255, i could just subtract it to 0, 0, 255. and, an addition component would be nice also, just being the inverse of the subtraction one. my 'rose' picture is a good example. lots of great reds in there, but try to EXACTLY extract JUST those reds and not the reds in the yellow of the background. it gets tricky. even mike's 'color isolate', which did a VERY good job, couldnt quite get it exact.

when you extract rgb blue, you get all sorts of blues: blue, blue-reds and blue-greens. but, if i dont want any blue-greens and only blues and blue-reds, this becomes a bit of a problem. and that's not even counting the shades.

there is a bit of a misnomer in color theory. the current think is that blue plus green equals cyan and that's not quite true. cyan is its own frequency in the light spectrum. it's not a mix of anything. it's a frequency. yes, you can average blue and green to get cyan, but it's enough of a distinction in these that it makes a difference once you get to 'digital light'. 'digital light' shld be just a simple alteration of frequency, but it's not currently. it's a mix. you mix 0, 255, 0 and 0, 0, 255 to get cyan. and that's the problem. now that you have 0, 255, 255 and want to change that to 0, 180, 255 it gets tricky, at least in the current methods of digital display.

in a cathode ray tube, you have three electron guns, red, green and blue. each is sweeping the rasters of the tube x number of times per second and the phosphors of the screen retain that sweep for a short time. so, when the next pass of the gun hits a given phosphor on the screen, you get a mix of the old sweep with the new sweep. so, one sweep is green and the next is blue and you see cyan.

the better way to do it would have been one gun sweeping those same phosphors but where the gun's voltage was varied in order to produce the color changes. but, that's kind of moot at this point.

so, digital combines the basics of rgb into the various colors and does this well. but, it makes separation difficult. had digital grown up with 8 channels instead of 3, things would be easier, including talking to printers.

so, all this rambling about televisions and so on, actually has a point. filter forge could do this separation in its native mode. or, at least have components that would aid in this. i know that 'math' components have been requested and i seem to recall you said that you'd put it on the list. if those math components will do what it is i'm talking about, then forget this post. if not, then i'd love to see this all added in there as well.

i'm probably already talking about something you're very aware of, so forgive me for that. i just wanted to state it relative to what i've run into lately.

yup, optical computers. that would be the way to go.