Handling Non-Uniform Downsampling Correctly

[Christian Lett]

Please forgive what is probably a very stupid question, but even those of us who have made ludicrously complex plugins still need to go back to basics every once in a while!

My plugin draws thousands of circular particles. It also applies blurs. At one point in its history the plugin drew elliptical particles and non-uniform blurs in order to deal with non-square PARs and odd downsample ratios (who uses these ratios, seriously?). However it was pointed out that I should really work internally with square pixels, and then, if necessary, stretch the render back to the output dimensions, which is a logical suggestion.

Question is, how do you deal with non-uniform downsampling?

Say I have a layer that is 960x540. This is given to me as in_data->width = 960, in_data->height=540, regardless of the downsampling. Normally I'd just divide each of these by the requisite denominator in the in_data->downsample struct, so if I'm using a 2x downsample I'd end up with a working PF_EffectWorld with width = 480, height = 270 (which is also the dimensions of the output world). This is fine, as I'm still left with square pixels.

However once I get to a 2:1 or 1:2 downsample ratio, this seems to fall apart. 960 / 2 = 480, 540 / 1 = 540, so I have a working PF_EffectWorld of 480x540. This isn't square pixels - it's narrow pixels so any circles would end up as fat ellipses when displayed stretched in the comp viewer. Likewise 960x240 (1:2) is flat pixels that would result in a skinny ellipse.

Is it a dumb question? Should I even bother (Trapcode Particular doesn't draw correctly for these odd downsample ratios)? I'm a bit snow blind with the countless things going on in the code so the answer is probably staring me in the face!

Thanks

[françois leroy · Accepted solution]

Hi Christian,

honestly, I wouldn't bother... I don't see any 'custom' pixel size anymore, and I'm pretty happy with it 😉

But if you really want to, you could use the smallest downsample factor.

Divide by min(downSample.X, downSample.Y), work with 'square' calculation, and stretch it to fit the output.

This way, you can use your plugin with almost no change in code, and you keep the highest resolution needed.

Cheers,

François

[Christian Lett]

Hey Francois,

Thanks for the reply. Yeah, that's what I ended up doing. It basically offers no improvement in performance, as opposed to a uniform downsample, so pretty pointless really. But it handles it, just in case!

Cheers, Christian

[françois leroy]

Well, you still downsample, so you get better performance than just a full res image.

If you have a 4:3 downsample, you still compute at same speed than 3:3...

Cheers,

François

[Christian Lett]

True. I meant 2:1 or 4:1 (although why anyone would use these is beyond me!) 🙂

[françois leroy]

If they do, they don't deserve all the hard work you've done for them 😉