Switching to absolute pixel coordinates

Hi,

My first question is as the title suggests: I want to switch to using absolute X/Y coordinates across the board in Fusion as I can't handle the 0 to 1 scale.

My second question is that I'd like to know what reasoning led to the design choice of using relative 0 to 1 coordinates?

//

You can't, because it isn't useful.

Fusion is resolution independent. It uses varying subsamples of the full raster to make proxies for speed and memory savings. Those would break if the effects applied were based on pixels. There's lots of other reasons, but that's the most obvious one.

Individual controls can be made into a pseudo pixel coordinate, but it always gets translated back to normalized coordinates before being handled by the image processing code.

EDIT: this is also a RTFM type of question. It's literally in the Getting Started chapter under the heading "Introduction to Fusion".

A great plus is it also for templates, presets and macros.
They work with any project you have.
No need to adjust settings for HD, UHD, 4k, 8k,...

You can't, because it isn't useful.

On the contrary. I consider absolute pixels to be very useful.

It uses varying subsamples of the full raster to make proxies for speed and memory savings. Those would break if the effects applied were based on pixels.

Is that so? I doubt that. In fact, as a programmer, I doubt that quite strongly. Because that type of setup would be no problems to deal with "under the hood" as it does with the 'Use Frame Format Settings' enabled.

Individual controls can be made into a pseudo pixel coordinate, but it always gets translated back to normalized coordinates before being handled by the image processing code.

You mean it's being translated _to_ normalized coordinates before being handled? The normalization of the coordinates can't happen unless it uses the actual image resolution to normalize with. An operation which use absolute pixels technically don't care about the size of an image (unless specified through expression), it just directly apply the operation at relevant pixels. In the case with normalization though, the operation does not know where to go until it knows the size of the input, hence the operation needs to fetch the resolution first, multiply the dimensions with the normalized values and then go to the absolute coordinates given to apply the operation.

this is also a RTFM type of question. It's literally in the Getting Started chapter under the heading "Introduction to Fusion".

Thanks "Chad", but that it says that it uses/offers this "feature" does not mean it would not also offer the absolute pixel coordinate option.

But then I know Fusion is not my cup of tea. Too bad.

//

You can choose Reference size in Merge and Transform, then coordinates will be in pixels.

Wow. Two posts in on the forum, and you're already acting like a spoiled ***.
Chad gave you a well informed answer, based on 15+ years of using Fusion, interacting directly with its developers, developing his own plug-ins for Fusion and you don't even have the courtesy to spell his name without quotation marks. That's incredibly rude. It greatly diminishes my desire to help you out with any future questions you might have.

You can't, because it isn't useful.

On the contrary. I consider absolute pixels to be very useful.

I consider circles to be very useful. Doesn't mean I think Fusion should use polar coordinates. Nor would I use my first two posts to complain about it.

It uses varying subsamples of the full raster to make proxies for speed and memory savings. Those would break if the effects applied were based on pixels.

Is that so? I doubt that. In fact, as a programmer, I doubt that quite strongly. Because that type of setup would be no problems to deal with "under the hood" as it does with the 'Use Frame Format Settings' enabled.

I'm glad you're so smart.

If you checked my sig you'd understand why I made the statement I did.

Individual controls can be made into a pseudo pixel coordinate, but it always gets translated back to normalized coordinates before being handled by the image processing code.

You mean it's being translated _to_ normalized coordinates before being handled? The normalization of the coordinates can't happen unless it uses the actual image resolution to normalize with. An operation which use absolute pixels technically don't care about the size of an image (unless specified through expression), it just directly apply the operation at relevant pixels. In the case with normalization though, the operation does not know where to go until it knows the size of the input, hence the operation needs to fetch the resolution first, multiply the dimensions with the normalized values and then go to the absolute coordinates given to apply the operation.

Correct, which is why it uses normalized coordinates, so it doesn't need to know the resolution of the input. When you set up your modified control, you would create a request for the input image resolution, which can sometimes be determined without actually rendering the image. There's a special request type for that.

The operations applied to the pixels don't matter, since you only need to do that when requesting the image. Your first post asked a question about the input controls. What Fusion presents to the user in the interface and what the image processing uses aren't the same at all. If you want to create image processing tools, then sure, you can, and almost certainly will, work on the pixel coordinates.

this is also a RTFM type of question. It's literally in the Getting Started chapter under the heading "Introduction to Fusion".

Thanks "Chad", but that it says that it uses/offers this "feature" does not mean it would not also offer the absolute pixel coordinate option.

If you kept reading it would answer that, yes. In fact, Chapter 14 deals with exactly this.

Wow. Two posts in on the forum, and you're already acting like a spoiled ***.
Chad gave you a well informed answer, based on 15+ years of using Fusion, interacting directly with its developers, developing his own plug-ins for Fusion and you don't even have the courtesy to spell his name without quotation marks. That's incredibly rude. It greatly diminishes my desire to help you out with any future questions you might have.

Did you even read Chad's arrogant answer to me? He gave me attitude so I returned it. If he have so much time invested in Fusion and its development it explains his bias and also why he seemed to take my question so personally that he had to answer the way he did.

I suppose I'll have to manage w/o your insights and answers Sander.

I'm glad you're so smart.

If you checked my sig...

The irony. First of all, I said I was a programmer, not smart. Also you telling me to check your sig makes me understand why you answered as you did. I bet your attitude and personality do wonders for the success of Fusion/the Fusion community.

Claiming that a normalized system won't need it's reference to be meaningful in its practical application (or even normalized to begin with) is completely absurd. However this discussion is clearly infected and I doubt we'll get anywhere.

Good luck with Fusion.

I think the most confusing aspect of relative vs abs coordinates is (in addition to the scale of values one must operate with) the logic behind range of different settings for effects. For example Blur size. What is the unit of Blur size? It is not in relative size of image, otherwise blur with size 1 would be super heavy. So I guess it is in pixels (manual says nothing about the unit). But in this case, how does a 10-pixel blur scale when input size is changed and how does it preserve the look as advertised?

I think the most confusing aspect of relative vs abs coordinates is (in addition to the scale of values one must operate with) the logic behind range of different settings for effects. For example Blur size. What is the unit of Blur size? It is not in relative size of image, otherwise blur with size 1 would be super heavy. So I guess it is in pixels (manual says nothing about the unit). But in this case, how does a 10-pixel blur scale when input size is changed and how does it preserve the look as advertised?

That one is a good question but there is an answer :
Too understand the logic behind the math you must know fusion has a long history. The days where video resolution was 720x576pixel (or in ntsc 720x480). A blur size of 1 equals a 1pixel blur in this resolution.

If you have now a bigger source image then the blur size of 1 equals a bigger pixel blur. But optical the stay the same

That one is a good question but there is an answer :
Too understand the logic behind the math you must know fusion has a long history. The days where video resolution was 720x576pixel (or in ntsc 720x480). A blur size of 1 equals a 1pixel blur in this resolution.

If you have now a bigger source image then the blur size of 1 equals a bigger pixel blur. But optical the stay the same

Interesting. The bad thing is that this logic or history of Fusion is not covered in manual and thus makes no sense at all. If one tried, for example, match the blur in Fu to blur in some other app, the only reasonble explanation one would reach is that Fu blur is scaled by some magic coeficcient which makes it literally a black box.

Stay tuned. I'm working on something to help with this.

Someone made a macro a couple years ago that does Erode/Dilate (I think) by pixel value instead of a relative radius.

Searching…
Here it is:
https://www.steakunderwater.com/wesuckl ... 094&p=8281

I am almost done building an absolute blur macro, which is cool, but you do lose the advantage of resolution independence, when switching between different sized source footage.

I am almost done building an absolute blur macro, which is cool, but you do lose the advantage of resolution independence, when switching between different sized source footage.

Build in an optional reference size?

Yeah. That would be version 2.0. For now I am doing a quick one for people who *think* they need absolute pixel values in their blurs.

And here it is: a macro for blurring in absolute pixels: AbsoluteBlur_SdR

Internally this macro takes the input and uses the resolution of the incoming image in a calculation to make sure you always blur in absolute pixels.

The macro can be found at

https://www.steakunderwater.com/wesuckl ... f=6&t=2453

since you can't upload a *.setting file to this forum to share macros and other settings.
I hope it's useful for some of you.

To be honest I have a hard time grasping the necessity of changing source footage size which relative coords is advertised to solve. I very rarely have to do that, I could almost say never. But I use pixel based values all the time, transforms, filters, you name it. I find that by default seeing just the position in pixel values alone aubstantially outweights my pain for almost nonexistent resolution changes. So I'm curious, how often do you actually need this and why?

As someone who makes many macros, I have a great appreciation for the normalized coordinate system. 20% of the screen width is always 20% of the screen width, regardless of the input size, so the effect that a macro creates will always look the same no matter what's being run through it.

If you get used to a particular value for something like glow size to generate a look you like, it works for every comp, whether the deliverable is in HD, UHD, or some off-the-wall format. When everything is measured in pixels, you have to constantly be aware of your image size in order to keep everything looking the way you expect.

You can do something like tracking a full-resolution image for better accuracy, then apply that data to a half-size image for better speed.

Try doing some spatial pattern generation in a Custom Tool. r = x is a simple linear gradient in normalized coordinates, but you need r = x / width to do it if you're referencing pixels. Easy to overcome in that simple example, but suppose you're generating something more complex? Divide the terms of your smoothstep by width? Turns into a nightmare in a hurry!

This is a nice example Bryan and makes sense. But most users most of their time don't write macros. I'd argue 95-99% of total time spent in comp software goes into basic tools and fiddling with their controls. And there the cognitive overload of values in range 0.000xxx units versus lets say 5 pixels has great effect. It is probably very dependent on what one prefers either subconciously or due to experience in software and what is easier to grasp for certain person. There probably is research done in this area, UI and UX are hot topics.

Well… that was four examples! It's really just a matter of what you're accustomed to. I've been using Fusion long enough that when I go into AE I'm just plain annoyed at having to convert screen widths into pixels. It's a waste of my brain power to have to remain aware of the image dimensions.

I agree that tiny values can be obnoxious, particularly when the slider has a lot of "throw" to it. The Erode/Dilate control comes to mind. Actually, it's bad in two ways: not only do you usually need very small values, but the process itself is logarithmic—the bigger the dilate, the less visual effect it has. It would be nice to have a log slider to go along with it. Nuke has such sliders for some parameters, and I really like them. That's no solution to the small values, but at least it would be more controllable.

Anyway, are there any other tools you'd like to see with absolute pixel values? Blur and Erode/Dilate are taken care of. Transform and Merge have a Reference Size parameter that can be used to convert them to pixels. It might be nice to put together a Reactor Atom with a collection of such tools for those who prefer to think in pixels.

But most users most of their time don't write macros.

The people making the macros don't care. It's the people USING them that care, and that's the category most users fall into.

I'd argue 95-99% of total time spent in comp software goes into basic tools and fiddling with their controls. And there the cognitive overload of values in range 0.000xxx units versus lets say 5 pixels has great effect. It is probably very dependent on what one prefers either subconciously or due to experience in software and what is easier to grasp for certain person. There probably is research done in this area, UI and UX are hot topics.

What's more likely, a client or art director saying "Put the center of the logo 248.3 pixels from the right side" or "Put the center of the logo 1/7 of the way from the right"?

What's more likely, setting the blur size by typing in integers into a text box while not looking at the image or adjusting a slider while looking at the image and not looking at a text box?

Generally speaking, users don't care about the number at all most of the time. There are controls in Fusion that don't have exposed numerical values at all, they're entirely visual. Users prefer that.

The people making the macros don't care. It's the people USING them that care, and that's the category most users fall into.

It is up to macro maker to present the controls in most meaningful way.

What's more likely, a client or art director saying "Put the center of the logo 248.3 pixels from the right side" or "Put the center of the logo 1/7 of the way from the right"?

What's more likely, setting the blur size by typing in integers into a text box while not looking at the image or adjusting a slider while looking at the image and not looking at a text box?

Generally speaking, users don't care about the number at all most of the time. There are controls in Fusion that don't have exposed numerical values at all, they're entirely visual. Users prefer that.

Clients usually say put that logo a little more to the left, they don't express themselfes in any meaningful number. And they don't stand behind my back mumbling fractional numbers

I'm adjusting blur by first banging in the ballpark by clicking on slider and then scrolling the number of whatever magnitude I want to adjust by mouse wheel or arror keys while looking at the image. The solution of having only option to either adjust a slider with no scale whatsoever or manually typing in number is one of the biggest pitas in Fusion for me. I don't know what users prefer, I know what I personally prefer.

The people making the macros don't care. It's the people USING them that care, and that's the category most users fall into.

It is up to macro maker to present the controls in most meaningful way.

Maybe you're not following what Bryan was saying, but the issue isn't making the macro, it's using it. Relative coordinates ensures that the macro works on anything it is applied to. Whether that's proxies or completely different projects at completely different facilities.

Clients usually say put that logo a little more to the left, they don't express themselfes in any meaningful number. And they don't stand behind my back mumbling fractional numbers

Really? I got that all the time. "Put it a third of the way down" or "split the difference" or "make it about half that".

I'm adjusting blur by first banging in the ballpark by clicking on slider and then scrolling the number of whatever magnitude I want to adjust by mouse wheel or arror keys while looking at the image. The solution of having only option to either adjust a slider with no scale whatsoever or manually typing in number is one of the biggest pitas in Fusion for me.

We might have found the issue.

Do you use modifiers to scale the sliders?

I don't know what users prefer, I know what I personally prefer.

The point is that at no time is having the values scaled to a variable image size useful. If users were so set in their understanding of the relationship between the desired effect and the number of pixels in their image, they'd struggle to change between 720p and 8K projects. Maybe if users always saw an absolutely scaled image, that would work, but the images the user looks at is always scaled. You don't swap out a 30" monitor for a 60" one when moving between a 4K ane 8K project.

Maybe you're not following what Bryan was saying, but the issue isn't making the macro, it's using it. Relative coordinates ensures that the macro works on anything it is applied to. Whether that's proxies or completely different projects at completely different facilities.

I understand what Bryain is saying, I code (although miserably) myself. What I'm saying is that converting between relative and absolute coordinates behind the scenes is easy (and fiddling with pixels in the end needs abs coords anyway) and just as easy is to present the controls to user either in relative units or absolute, depending on what makes most sense. Transform scale value for example makes no sense in pixels, cropping on the other hand is most logical in pixel values (you are cropping to some exact format afterall). Proxies are not generated manually in macro, the engine of software does this behind the scenes either by supersampling or dropping scanlines and it has nothing to do with whether you are doing something in relative or abs coords in your macro or whether your slider shows relative or abs coords.

Really? I got that all the time. "Put it a third of the way down" or "split the difference" or "make it about half that".

We are probably dealing with different kind of work which is fine. My point is that for what I do, I find pixel values most of the time either more useful or not an issue. But as I said before, it is also a matter of personal preference and how someones brain is wired.

We might have found the issue.

Do you use modifiers to scale the sliders?

No, ordinary sliders. What makes my head hurt is that sliders dont have scale indicated on them, so I can't click on a place on slider to get to ballpark quickly. And even if they had scale markers, I can't click and place anyway because slider increments in fixed steps instead of setting the value where I clicked. Sounds like a teeny-weeny thing but isn't.

The point is that at no time is having the values scaled to a variable image size useful. If users were so set in their understanding of the relationship between the desired effect and the number of pixels in their image, they'd struggle to change between 720p and 8K projects. Maybe if users always saw an absolutely scaled image, that would work, but the images the user looks at is always scaled. You don't swap out a 30" monitor for a 60" one when moving between a 4K ane 8K project.

I agree to disagree. It is a matter of preference, but arguing that one is not useful at all, never, is a bit too much Why would I struggle to set the effect in pixels any more than setting it in relative values? I use my eyes for that, I don't just put a 20% glow on everything every time with my eyes closed, but I can grasp numbers in range lets say 1-200 much more easily than range 0.00007672-0.025125. I usually fit the image to viewer to see full image, why would I need to see an absolutely scaled image? Working in pixel values does not mean I have to work 1:1 all the time.

Maybe you're not following what Bryan was saying, but the issue isn't making the macro, it's using it.

I actually think both of you managed to miss my point with regard to macro building. Yes, if everything were in absolute pixels, the macro could still be built to be resolution independent, but it would likely involve a heck of a lot of expressions to convert things in and out of normalized values in order to get it all to work the same way regardless of input dimensions. It would mean that most tools were designed for a single resolution, and those more sophisticated ones that were properly designed would be much less efficient.

As it is, I've made a few macros that don't respond appropriately to input size due to the presence of Background tools inside setting the format. They only work if the Frame Format preferences match the incoming image. I never noticed until we started moving from HD to 4k. Several of the existing Glitch tools have this problem—I'm updating as I have time, but my stupid boss keeps wanting me to do work that makes money.

As it is, I've made a few macros that don't respond appropriately to input size due to the presence of Background tools inside setting the format.

Eric Westphal's suggestion from a while back really was an eye opener for me in that respect.
He uses a B/C tool with gain set to 0 for R/G/B/A effectively creating an empty background that automatically adjusts to the incoming image.

oh, that's a good tip, never thought of that - thx Sander!

oh, that's a good tip, never thought of that - thx Sander!

You're welcome and thank Eric

Or use the SetColor fuse to set an arbitrary color in one go.

That's Fusion for you: so many ways to roto a cat.

I actually think both of you managed to miss my point with regard to macro building. Y

I admit that it may be the case

I can clearly see the benefits of relative coords in writing plugins, I developed an OpenGL fragment shader renderer for Nuke (still an ongoing project) and seeing how these shaders effortlessly scale to whatever format is pretty neat. On the other hand, I have also banged my head on pixel based filters and stuff where relative coords would be a real pain, so it all comes down to use case I guess.

To be fair, Fusion isn't perfect either. Several tools work on fixed pixel kernels, so they don't scale at all, and they aren't specially labeled as such, so you can accidentally mess up when changing resolutions.

Crop and the disparity toolset are also not resolution independent, so more chances to trip up.

The people making the macros don't care. It's the people USING them that care, and that's the category most users fall into.

It is up to macro maker to present the controls in most meaningful way.

What's more likely, a client or art director saying "Put the center of the logo 248.3 pixels from the right side" or "Put the center of the logo 1/7 of the way from the right"?

What's more likely, setting the blur size by typing in integers into a text box while not looking at the image or adjusting a slider while looking at the image and not looking at a text box?

Generally speaking, users don't care about the number at all most of the time. There are controls in Fusion that don't have exposed numerical values at all, they're entirely visual. Users prefer that.

Clients usually say put that logo a little more to the left, they don't express themselfes in any meaningful number. And they don't stand behind my back mumbling fractional numbers

I'm adjusting blur by first banging in the ballpark by clicking on slider and then scrolling the number of whatever magnitude I want to adjust by mouse wheel or arror keys while looking at the image. The solution of having only option to either adjust a slider with no scale whatsoever or manually typing in number is one of the biggest pitas in Fusion for me. I don't know what users prefer, I know what I personally prefer.

Hey Hendrik,

Off the back of you discussion I created some functionality to allow users to set a default field in each tool that can automatically be incremented/decremented via hotkeys when the tool is active. Ive been using it for a few days now and it has pretty useful for the way I work, less time tracking down often used controls within tools and more time on the monitor getting things done. Unfortunately it will require some knowledge of scripting and the hotkeys file to get it setup.

If anyone is interested:

https://www.steakunderwater.com/wesuckl ... f=6&t=2470

I was looking for "how to move the image up of just a single pixel".... this come out...

I was looking for "how to move the image up of just a single pixel".... this come out...

You can move things with a single pixel if you use the reference size option in your merge or transform.
This will change the value fields to whatever you feed it. So if you set it to your image size moving in pixel increments is possible.

I was looking for "how to move the image up of just a single pixel".... this come out...

You can move things with a single pixel if you use the reference size option in your merge or transform.
This will change the value fields to whatever you feed it. So if you set it to your image size moving in pixel increments is possible.

Yes, i learned something last night!

Yes, i learned something last night!

If you want to learn more: https://www.steakunderwater.com/wesuckl ... =16&t=3050

Yes, i learned something last night!

If you want to learn more: https://www.steakunderwater.com/wesuckl ... =16&t=3050

Well, Thanks!

I’m a donkey with fusion, I’m mostly a colorist...