Gamma

Actually, allow me to expand this topic a bit. What I'm finding myself funning up against with my first attempt at creating some image-processing filters is what seems to be the lack of granular control. I can only assume I'm looking in the wrong place, so bear with me! Any help is appreciated.

For example, I'd like to start small and create a simple color correction filter that works in 32bpc in CS2. Three sliders: Red Gain, Green Gain, Blue Gain. Maybe a Mater Gain if I feel fancy.

All I want to do is multiply the R, G and B channels of the image by these slider values.

I don't want my sliders to be 0-100. I want them to be 0-5, but allow larger values than five if the user types them in. Default value will be one. A gain of one = no change.

Right away I get stuck. I can pipe my sliders into an Assemble RGB node, but that node expects 0-100 values. I can't seem to use a remapper to turn my 0-1 values into 0-100.

So then I look for a simple "Multiply" node to string between my slider and the Assemble RGB, thinking that I can just multiply my slider values by 100 on thier way into the Assemble RGB. But I can't find a node that will allow me to multiply a value. I thought it might be "Gain," but the gain node really needs a new name because it does a lot of nifty things that are in no way "gain." Gain is multiply -- that's a pretty well-accepted definition.

It does work as expected that I can multply my color with my image input using Blend. But again, I think what would be sweet here would be a multiply node that worked on images as well as values.

Maybe I'm trying to misuse this app but I'm really hoping to build some basic color and image-processing tools to turn PSCS2's float mode into something useful.

Thanks in advance for any help!

-Stu

Quote
uberzev wrote: Sliders and their value fields are inherently equal. Having them scale independently is not something that would be usefull or intuitive to most users.

I respectfully disagree -- not everything is best expressed as 0-100. Photoshop is full of sliders that range all over the place. What creates an intuitve experience is how the slider is ranged, so that the user can easily manipulate the values. The gamma slider in Levels is a perfect example -- it uses values between 0 and 5, but the UI is ranged such that 1.0 is dead center. This plus the histogram is an intuitive way to present the un-intuitive concept of a power function.

But I'd be OK with using 0-100 values as my color-correction inputs if only I could enter values greater than 100. Seems like it would be hugely limiting to max out all sliders -- there are plenty of times where 150% is the perfect amount!

-Stu

OK, so the idea of defining a range for a slider is already in the works. That's great!

Quote
uberzev wrote: But if someone drags the slider all the way to one side it makes no sense for them to have not reached a boundary point where no greater or lesser value can be entered. I don't think you'll find any mainsteam software that offers this functionality.

Shake, Fusion, After Effects, and most 3D applications do indeed work this way. The reason is simple -- for a slider to be useable, you need some precision, so you have a "comfortable range" of, say, zero to five. But that doesn' necesarily mean that values above five are illegal -- just that they are rarely used.

In After Effects, for example, the Blur slider in Gaussian Blur maxes out at something like 150 pixels. But you can freely type in values larger if you like, and they are accepted. You can also right-click on the slider and get a dialog where you can set your own new top end of the slider's motion. Very handy.

-Stu

Quote
uberzev wrote: Hopefully they beef up these user controls in the future to provide more flexibility.

Agreed!

-Stu

Thanks for the welcome!

Yes, I think the ideal way to design a slider woul be o specify both the absolute caps on either end of legal values and also the default min and max for the GUI.

-Stu

Is this maybe going into the right direction?



Channel Multiplier.ffxml

Quote
ProLost wrote: Maybe I'm trying to misuse this app

Please do misuse it as much as you can! This beta has been online for just one month, and we already logged a tremendous number of things people would like to see in Filter Forge. So any misuse is absolutely welcome here!

Quote
ProLost wrote: I'm sure there are reasons for Gamma being expressed as -100 to 100, but I sure do wish there was a node for just regular old gamma or power. Is there such a thing?

Our Gamma is the same regular gamma as you see everywhere. The range of -100 to 100 is a limitation of our current architechture. Here's how to convert our ranges into traditional Gamma values:

http://www.filterforge.com/more/help/...ction.html

Color values are not clipped in the Photoshop, not clipped in our transfer code, but are clipped inside components to prevent problems in non-HDR (mainstream) filter development.

It was a source of a rather heated discussion here some time ago (I was up for partial HDR pipeline, while Vlad decided to output HDR only from Surface root component lighting). I still firmly beleive that partial HDR is possible with clipping the inputs only where range 0..1 is required, but there are some complexities (like some kind of HDR color picker, component input flags which force clipping and a lot of additional testing). Still, partial HDR pipeline will improve the stability of existing components and probably give some interesting opportunities.

The point: clipping is an artificial decision which is not required in most of the components and can be removed with some thinking and working, although I doubt Vlad will consider this as a near-term task.

Quote
onyXMaster wrote: Clipping has its uses...

Agreed, but like you I think it should be an option. In Conduit many nodes have checkboxes for clipping black and white on output, and this works great.

Despite Vlad's statement that FF is not designed for compositors, I think I see something in FF that maybe you guys don't. Irrespective of all the cool 3D surface stuff you've created, you also happen to have built a fantasticly useful build-your-own-filter tool -- sort of a GUI version of the once-proud Filter Factory.

All it would ake for us film industry folk to jump all over FF would be the removal of the clipping and some simple, atomic math nodes. I guess I'll just check back here every once in a while and see if you've seen fit to implement those enhancements.

(At which point I'll begin begging you to make an After Effects version!)

-Stu

Quote
Vladimir Golovin wrote: Just to confirm that I understand this correctly -- Gain is a well-accepted definition for multiplications where the multiplier is greater than one. Am I correct here?

In image processing gain, mult, and slope all mean the same thing. The multiplier can be any value.

-Stu

Will those add/subtract/mult nodes work on values, such as from a slider?

-Stu

Quote
ProLost wrote: Will those add/subtract/mult nodes work on values, such as from a slider?

Oh, if you mean the math for control components, the answer is no -- Filter Forge currently has no infrastructure for this.

Thanks for that byRo, my request is and has been that FF provide the simple atomic math nodes that would allow one to perform those exact equasions.

-Stu

Quote
Vladimir Golovin wrote: a pipeline that can handle overbrights and underbrights

Well I'm glad that you agree this is the most important issue facing FF!

-Stu