Jump to content


Photo

Improved Interface For The Blur Tool

Settings Defaults Macros Blur Gringo

  • Please log in to reply
11 replies to this topic

#1 Gringo

Gringo

    Associate Administrator

  • Adv Members
  • PipPipPipPipPip
  • 1,455 posts

Posted 12 August 2011 - 05:23 PM

The issues of the basic Blur tool are:
  • It produces unwanted negative color values in 32 bit color mode if you blur objects on a black background.
  • The size values don't relay to anything unless you work with an image 720 pixels wide.
This new version uses the Multi-box blur filter by default which is 1.5 times faster than the Gaussian and doesn't go negative.

Setting the blur size you don't have to choose between uniform blur and separate X and Y controls any more.
It has the general Blur Size parameter along with X and Y Blur Multipliers which are all constantly exposed, so after setting the aspect of blurring you are still able to easily adjust the global blurring amount.

The amount of blur is now set relatively to the image width just like in other Fusion tools such as Polygon mask or DirectionalBlur. Besides, you can choose between this resolution-independent approach and setting blur size in pixels.

Posted Image

Download the improved Blur tool

To install this version, put the Blur_Blur.setting file into your Fusion:/Defaults folder

#2 SecondMan

SecondMan

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,797 posts

Posted 12 August 2011 - 05:30 PM

Nice one Gregory. Nice and simple!

Thanks,
Pieter.

#3 Gringo

Gringo

    Associate Administrator

  • Adv Members
  • PipPipPipPipPip
  • 1,455 posts

Posted 12 August 2011 - 05:44 PM

You're welcome!

By the way, it would be really nice if all the other tools had such a possibility to set parameter values in pixels.
Including the Transform tool (instead of the Reference Size which is not really intuitive and needs to be set manually).

#4 SecondMan

SecondMan

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 1,797 posts

Posted 12 August 2011 - 05:52 PM

Yeah! Go for it man! :)

#5 Gringo

Gringo

    Associate Administrator

  • Adv Members
  • PipPipPipPipPip
  • 1,455 posts

Posted 12 August 2011 - 05:57 PM

:))))) It's actually a much easier task for the developers

#6 Tilt

Tilt

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 2,137 posts

Posted 12 August 2011 - 05:58 PM

You're welcome!

By the way, it would be really nice if all the other tools had such a possibility to set parameter values in pixels.
Including the Transform tool (instead of the Reference Size which is not really intuitive and needs to be set manually).


Well, setting the center in normalized units is useful in a lot of situations (resolution independence and so on). But if you add a pixel-based offset, it should really be centered around 0/0 instead of 0.5/0.5 (which, converted to pixels, is just some value nobody can ever recognize as being the image center).

Good job on the blur setting. Haven't tried it yet, but does it handle proxy/autoproxy properly?

cheers
Stefan

#7 Gringo

Gringo

    Associate Administrator

  • Adv Members
  • PipPipPipPipPip
  • 1,455 posts

Posted 12 August 2011 - 06:07 PM

Speaking about the possibility to switch to absolute values in all the tools, I would propose to convert the values on the fly.
For example, you have the Center coordinates 0.5; 0.5 by default. Once you switch to absolute mode, the coordinates should be turn to 1024; 778 for a 2K image or to 360; 288 for PAL D1.

If you use the proxy mode, the blur size remains the same, so the blur relates to the initial image resolution, not to the reduced one.

#8 RFC3514

RFC3514

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 78 posts

Posted 13 August 2011 - 01:15 AM

Would be nice to automate the conversion on every tool. Maybe this could be done with a global change to the interface. In other words, wherever a screen coordinate or size is shown as:

[ 0.5 ]

Replace it with two boxes:

[ 0.5 ] / [ 960 ]

Where the first is the absolute value and the other is the pixel coordinate for the current resolution. Both should be editable, but the tool would only store one of them (ex., if you edit the pixel coordinate, the system divides by the current resolution and stores only the absolute value). Change the comp size and all the pixel values get updated to the new resolution.

In some tools where it might make sense to store pixel values independently of screen resolution, add a checkbox or button to select which is the "master" value and store that one instead.

Alternatively (to avoid having to reformat the interface due to the extra box), there could be a single box:

[ 0.5 ]

And right clicking on it would display, in the context menu, these options:

Absolute coordinate (master)
Pixel coordinate (derived)
Pixel coordinate (master)

One of which would be checked (active). The first would store and show the absolute value. The second would store the absolute value but show the pixel value (and would automatically update when the comp resolution was changed. The third would both display and store the pixel value (and would resist resolution changes). A preference could be added to determine the default "coordinate mode" of new tools (giving those three options plus "auto" to use a default defined by the tool itself).

Tools designed to work only with absolute coordinates would have the last option disabled until they get updated to also support direct input of pixel values. The first two options could be forced on any tool, since they both store the same value.

With the single-box version, hovering the cursor over the value would display both (i.e., if the input box was set to "absolute value", hovering the mouse cursor would display a tool-tip showing "Pixel: 960".

#9 Tilt

Tilt

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 2,137 posts

Posted 13 August 2011 - 01:53 AM

The on-the-fly conversion is exactly what the "reference size" inputs do :-)

#10 Gringo

Gringo

    Associate Administrator

  • Adv Members
  • PipPipPipPipPip
  • 1,455 posts

Posted 13 August 2011 - 07:13 AM

Alternatively (to avoid having to reformat the interface due to the extra box), there could be a single box:

[ 0.5 ]

And right clicking on it would display, in the context menu, these options:

Absolute coordinate (master)
Pixel coordinate (derived)
Pixel coordinate (master)

One of which would be checked (active). The first would store and show the absolute value. The second would store the absolute value but show the pixel value (and would automatically update when the comp resolution was changed. The third would both display and store the pixel value (and would resist resolution changes). A preference could be added to determine the default "coordinate mode" of new tools (giving those three options plus "auto" to use a default defined by the tool itself).

Interesting idea! In this case you could choose which parameters should be set in pixels and in normalized units. For example, Center of a polygon mask can be normalized whilst the Soft Edge and Border Width could be defined in pixels.

Adobe Illustrator uses a similar approach: you can either set a global option which units to use or you can type a postfix after the number in the parameter box (px, mm, cm) and Illustrator converts it immediately for you.

But don't forget that regardless the global resolution setting in the comp, different branches in the flow can have different resolutions.
That's why it would be good if the tools converted the units according to the input resolution. Here the difference between the master pixel values and derived ones would matter.

I thought about the master mode, so once you switch, the values are being converted, but then stored as pixels. I think, if you decide to define the center offset or the line width in pixels, you really want them maintain the same effect in pixels even though the input resolution changes.

This can be an issue with instanced tools applied to branches with different resolutions, but it's solvable as a special case.

#11 Gringo

Gringo

    Associate Administrator

  • Adv Members
  • PipPipPipPipPip
  • 1,455 posts

Posted 13 August 2011 - 07:24 AM

The on-the-fly conversion is exactly what the "reference size" inputs do :-)

True. But again, I bet the majority of the users don't associate the Reference Size with a possibility to shift the Center and Pivot in pixels. Besides, you have to set it manually and adjust if the input resolution changes.

And this works only for the Transform anyway.

#12 RFC3514

RFC3514

    Flying Pig

  • Adv Members
  • PipPipPipPipPip
  • 78 posts

Posted 13 August 2011 - 01:18 PM

Adobe Illustrator uses a similar approach: you can either set a global option which units to use or you can type a postfix after the number in the parameter box (px, mm, cm) and Illustrator converts it immediately for you.


Yes, a few other programs do that as well, but they generally convert after you input the value and then show you the converted result. Which isn't necessarily what you want (and doesn't explain what should happen if you rescale the source - rescale the parameters or keep the value you wrote?). I suppose Fusion could use the "HTML / CSS rule" (which I think is keep the values with units - px, cm, etc. - and rescale percentage values). But I suspect doing that in Fusion would force a lot of code to be updated. .

But don't forget that regardless the global resolution setting in the comp, different branches in the flow can have different resolutions.


True. I'd be inclined to say that pixel values (both "master" and "derived") should be based on the resolution of the branch they're in, although I suppose some people might prefer to see the "pixel size it will have in the final render".

This can be an issue with instanced tools applied to branches with different resolutions, but it's solvable as a special case.


If they have different resolutions they won't be sharing any cached data, so it's really just a decision about what to display, it shouldn't cause any major issues architecture-wise.

P.S. - And you're right, "normalized" is a much better term (more accurate, too). I tend to use it in mathematical contexts, but for some reason I keep saying "absolute value" when talking about software. Probably because one of my college teachers kept referring to normalized FP values that way. :huh:





Also tagged with one or more of these keywords: Settings, Defaults, Macros, Blur, Gringo

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users