Adjustable filtering

Hi - in RV, we’re noticing that when zoomed in really close, to the pixel level, artists are used to behavior that acts like the Nearest Neighbor filter, so they can see the pixel-level details without them being softened by the Linear filter, even if it means seeing some blocky edges.

But when zoomed out, even just playing at normal size, Nearest Neighbor starts to create aliasing artifacts, making Linear filter seem like a better choice.

It’s not extremely difficult for people to hit the ‘n’ hotkey to toggle between those, but I was curious if there’s ever been interest or discussion about having a mode where you could use NN when zoomed in closer than 1:1, and Linear when zoomed out more than 1:1. And would that even make sense to do if you could?

3 Likes

Hi Alan,

That seems perfectly reasonable! In RV 7.3.1 we added a higher quality filtering for when you have very large media viewed at a small output for a somewhat similar purpose, but adding an adaptable mode dependent on zoom level might also be useful.

If you wanted to implement the linear/nn filter, one option would to be to look for graph-state-change events that modify the RVDispTransform2D node’s transform.scale property.
Event: graph-state-change from IPGraph ‘viewGroup_dxform.transform.translate’

It would take a little bit of transforming normalized coordinates back to the source, but totally doable :slight_smile:

4 Likes

Hi Michael -
Thanks for the info about the RVDispTransform2D node – that may be worth trying out, and it looks like the commands.setFiltering() cmd should be able to do the swap programmatically. Thanks!

Alan

4 Likes

Hey Alan,

As a proof of concept, here’s along the lines of what I was thinking. You’d want to plus this up with user preferences (to remember if this mode was enabled or not), error handling, etc, but it should get the point across.

Example_Package_FilterSwap-1.0.rvpkg (1.2 KB)

Cheers,
-Kessler

1 Like

That’s awesome, Michael! Thanks so much for putting that sample together. We’ll play around with it and see if something like that will do what people need. Thanks so much!

Alan

3 Likes

I’ve been playing around with that sample plugin, and it’s a great starting point. I’d like to be able to have a little more control with it, but I’m having a hard time understanding exactly what the 2 numbers represent, that you’re comparing.

In the call self.computePixelRelativeScale(1.0, False), it seems fairly intuitive, but like it implies, seems to be relative to the size of your window. So if I hit ‘f’, that number will be 1.0, no matter how large my window is. I think the idea would be to switch filters whenever the scale is bigger/smaller than 1:1. I assume that’s why you’re using the “viewGroup_dxform.transform.scale” property, but I’m having a hard time understanding how that number works, and how it’s supposed to normalize the other value, possibly.

I also noticed that with computePixelRelativeScale() passing False, whenever I zoom in or out (say using the “2” or Ctrl+3 hotkeys) the displayFeedback bubble always says “1:1”, even though the zooming seems to work. If I pass True instead, that bubble gives the correct scale ratio, but then it always returns 1.0, which doesn’t seem useful.

The main “control” issue is that it seems like the filtering switches somewhere between 1:2 and 1:4 going one direction, but maybe at 3:1 on the other side, possibly depending on how large the window is on screen. I’d just like to understand how to tune that in so it’s happening right at, or very close to 1:1.

Thanks for any extra info on that.
Alan

2 Likes

Hi Alan,

That’s grabbed pretty directly from rvui.mu; which honestly is a great place to pick up some tricks :slight_smile:

Making use of the computePixelRelativeScale directly may have been a bit of a misstep in that it includes displaying the feedback. But the number it returns should make sense still. If you want to go and grab the implementation of computePixelRelativeScale from rvui.mu and either reimplement or make a copy without the display feedback, that would probably be prudent.

The relationship does come down to the window display size. To determine what size we need to scale the viewport, the computePixelRelativeScale will give us the scale factor that is required on the viewport to achieve the input value.

For instance, if our viewport is really small, relative to the viewport, we need to scale the image up a lot to be able to achieve a 1:1 pixel scaling.

If our viewport is really big, say larger than the input source, we need to scale the viewport down so that we can achieve the 1:1 pixel scaling. Because all this is dependent on the viewport relation, that’s why you are seeing changes as you adjust the viewport; this is to be expected and working as intended.

If your viewport was exactly the same resolution as your media and you went into 1:1 mode, you should expect the output value to be 1.0.

Hopefully that gets you the last mile; let me know if I missed the mark or if you have more questions!

-Kessler

2 Likes

I just came back to this yesterday, and while trying to rewrite computePixelRelativeScale in Python, noticed that there’s an additional “silent” arg to that method which controls whether the feedback bubble shows or not. Setting that to True turns off the displayFeedback part, so that looks like it should work great!

As for adding in user preferences wrt whether the mode should be loaded or not, I’ve got examples of doing that for a particular attribute, or whether to display a UI, etc., but can’t find any examples for activating a mode or not based on user prefs. The seemingly tricky part is that activate() is called the same way if I toggle the mode on in the menu, or if it loads on startup, so it’s hard to tell whether to override that behavior with the current prefs or not. Am I missing an obvious way of dealing with that?

I realize Loading/Unloading the mode in the Packages tab of the RV Prefs window saves that state in the RV.conf, but between being a little less of an intuitive way to disable the plugin for the future, and because we have a clobber pref that stomps on the doNotLoadPackages pref, that’s not ideal for us.

Is there a hook at load time that would allow us to check the user prefs only at startup, but not if the user activates the plugin with a hotkey or menu item?

Thanks,
Alan

I know when I was at Autodesk I did some sort of example that did just this, but I don’t remember which event I used.

Check running RV with -debug events and you can see the various startup events. You probably want one of the last ones so it happens as late as possible.

Thanks Michael - I ended up using the session-initialized event, which was a good enough spot to decide if a plugin should be activated or not.

1 Like