Welcome, Guest
Username Password: Remember me

TOPIC: 2D DVE effect with optional interferrence filters.

Re: 2D DVE effect with optional interferrence filters. 3 weeks, 4 days ago #214008

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12175
  • 3 weeks, 4 days ago
I obtained the 0.521 figure by dividing your original RADIUS_1a by your original RADIUS_2b. I subsequently renumbered RADIUS_2b - to RADIUS_5b and discarded RADIUS_5a, which was never used. I also scaled them by the 0.5 factor that you had applied as part of passRadius each time they were passed to ps_blur(). Because s_Input was always passed to ps_blur() I explicitly declared it inside that shader, meaning that passRadius is now the only parameter that has to be passed to ps_blur().

The change in numbering of the radius definitions makes sense to me, because for eight passes we do two successive passes of four, diminishing in size. It means that for the first four we start at a value of 0.5, and for the second four we start at .2605. For both passes the successive scaling is still 1.71.

Inside ps_blur() I inverted the reduction scale factor, and decremented the scale factor by one. That meant that radius declaration became much simpler. (I'm still experimenting with and without Y aspect ratio correction, but I have been preoccupied with another user's masking problem so it's been on the back burner this weekend).

I configured the 45 degree rotation so that it was always calculated at float2 resolution. That's a relic from when I had that happening in a loop, because it's more efficient to do a single float2 maths operation than two floats. In this context the difference is so slight it really doesn't matter and could be put back the way that it was without changing performance significantly if at all.

Re: 2D DVE effect with optional interferrence filters. 3 weeks, 4 days ago #214021

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4032
  • 3 weeks, 4 days ago
jwrl wrote:
.. The change in numbering of the radius definitions makes sense to me, because for eight passes we do two successive passes of four, diminishing in size. It means that for the first four we start at a value of 0.5, and for the second four we start at .2605. For both passes the successive scaling is still 1.71. ..

I had done something similar in a previous test effect. However, for the quick development of other blur effects, where I changed the number of passes, I wanted to intuitively recognize the relative radius from the radius number. So I now chose the factor 1.12, which gives a smaller difference of radius names with the same number. In the technique of using only one row for one pass, whereby the radius names and other parameters of several passes are structured similar to a table, I keep a better overview of how the passes interact, even if there are many passes. This makes the lines very long, but that's ok with my large monitor.
However, some web pages have limitations in displaying long lines of code, which unfortunately makes scrolling necessary.


jwrl wrote:
.. I also scaled them by the 0.5 factor that you had applied as part of passRadius each time they were passed to ps_blur()..

Yes, since I couldn't find any GPU load differences in my tests, I simply had it calculated to have maximum flexibility for later developments based on standard code. But I don't know if my calculations outside the shader are compatible with Linux & Mac. I also wondered if calculations in the technology are only done once per frame, or for each pixel?

jwrl wrote:
..and discarded RADIUS_5a

I usually use many more optional unused standard radius definitions to quickly add additional passes when needed.

jwrl wrote:
.. I configured the 45 degree rotation so that it was always calculated at float2 resolution ..
An elegant solution.

I also had the idea to handle blurring at the edges between alpha 1 and alpha 0 differently than anti-aliasing within a texture. Maybe an RGB blurring that only affects the Transparent texels, so that blurring text minimally enlarges them while alpha is blurred normally?
But that was just an idea without knowing if it would be beneficial, and I don't have a suitable blur code yet.
Mainly automatically translated
--------------------------------------------
Software: Lightworks 2020.1 & 14.5; || Windows 10, 64 Bit
Hardware: Intel i5-4440 (3,1 GHz); || shared RAM: 8 GB; || Intel HD Graphics 4600 (can use max. 2 GB of shared RAM)
Last Edit: 3 weeks, 4 days ago by schrauber.

Re: 2D DVE effect with optional interferrence filters. 3 weeks, 3 days ago #214037

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12175
  • 3 weeks, 3 days ago
schrauber wrote:
I don't know if my calculations outside the shader are compatible with Linux & Mac.

They should be. I can't see any reason why not, anyway.

schrauber wrote:
I also wondered if calculations in the technology are only done once per frame, or for each pixel?

They are definitely done on a per pixel basis. The pixel address is passed to the shader, so they would have to be individually calculated.

schrauber wrote:
I also had the idea to handle blurring at the edges between alpha 1 and alpha 0 differently than anti-aliasing within a texture. Maybe an RGB blurring that only affects the Transparent texels, so that blurring text minimally enlarges them while alpha is blurred normally?

I don't think that you would gain anything by doing that. Remember that any detail within the blended image will also suffer from the jitter problem, so it would still need to be blurred. Just blurring the edges wouldn't help fix that. If you wanted to experiment with it, a way that you can separate out just the edges is the following:

   retval.a = sqrt (1.0 - abs ((retval.a - 0.5) * 2.0));

Breaking it down, the alpha channel is modified to swing between plus and minus 1. That is then used as an absolute value and subtracted from 1, making full transparency and full opacity both 0. The square root of that value is then taken to give a curve to the alpha value, thus broadening and smoothing the range over which the edge alpha operates.

An alternative approach using the sine function would be this.

   retval.a = sine (retval.a * 3.141592);

By the way, I haven't actually used either technique for anything. They're theoretical techniques that I just came up with. There are doubtless more complex methods possible but either of those should work though. I don't know which would be more efficient in practice - possibly the sine method, because I believe that in Cg trig functions are done with lookup tables.
Last Edit: 3 weeks, 3 days ago by jwrl.

Re: 2D DVE effect with optional interferrence filters. 3 weeks, 3 days ago #214042

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12175
  • 3 weeks, 3 days ago
You will get a differing, curved blur effect starting at 0.5 and ending at .08 if you use the formula below to derive it.

X = 1.0 / ((Y * Y - 1.0) * 0.166667 + 2.0)  // really just X = 1 / (a * Y² + b)


That will produce these values.
#define RADIUS_1a    0.5
#define RADIUS_2a    0.3
#define RADIUS_3a    0.167
#define RADIUS_4a    0.1

// and

#define RADIUS_1b    0.4
#define RADIUS_2b    0.222
#define RADIUS_3b    0.128
#define RADIUS_4b    0.08

Changing the formula slightly to make it end at .0521 will do this.

// X = 1.0 / ((Y * Y - 1) * 0.2729 + 2.0)

#define RADIUS_1a    0.5
#define RADIUS_2a    0.239
#define RADIUS_3a    0.117
#define RADIUS_4a    0.0662

// and

#define RADIUS_1b    0.355
#define RADIUS_2b    0.164
#define RADIUS_3b    0.0866
#define RADIUS_4b    0.0512

I haven't yet had the opportunity to plug either of those into my code, but they look like they could be interesting.
Last Edit: 3 weeks, 2 days ago by jwrl.

Re: 2D DVE effect with optional interferrence filters. 3 weeks, 3 days ago #214043

  • jwrl
  • Moderator
    Pro User
  • OFFLINE
  • Moderator
  • Posts: 12175
  • 3 weeks, 3 days ago
OK, I've played with the first of the two sets of values above. On blur setting 1 (the default) your numbers are definitely better. There was no visible difference between your and my settings 2 and 3. So it looks like it's better left as it is.

I've also had a chance to check out the aspect ratio correction, using title effect text instead of my test graphic. In some tests it's actually looking as if it might be necessary to divide scale.x by the aspect ratio, although that's by no means definite at this stage. The details that I'm looking for might be more visible at 4K, but I don't have a 4K monitor available at the moment.

Re: 2D DVE effect with optional interferrence filters. 3 weeks, 3 days ago #214064

  • schrauber
  • OFFLINE
  • Platinum Boarder
  • Posts: 4032
  • 3 weeks, 3 days ago
Thanks.
A few days ago I tested with your effect minimization on images with line patterns, and the artifact reduction within the texture worked well.

I've been on the road with my smartphone for a few days now, so I can't test anything.

I think we should differentiate between:
- blurring at transparency edges.
- Blurring of minimization artifacts within the texture.
- Spatial distribution of blur strength.
- Artefacts caused by the bluring itself.

Changes in the ratio of the blur radii can increase blur artifacts, but with 8 passes this will probably not be visible with this effect.
With the default setting of only two passes this is of course more critical.
Mainly automatically translated
--------------------------------------------
Software: Lightworks 2020.1 & 14.5; || Windows 10, 64 Bit
Hardware: Intel i5-4440 (3,1 GHz); || shared RAM: 8 GB; || Intel HD Graphics 4600 (can use max. 2 GB of shared RAM)
Last Edit: 3 weeks, 3 days ago by schrauber.
Time to create page: 0.30 seconds
Scroll To Top