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