Googles appar
Huvudmeny

Post a Comment On: cbloom rants

"04-04-11 - Yet more notes on filters"

15 Comments -

1 – 15 of 15
Blogger won3d said...

"But this is equivalent to convolving the continuous filter f(t) with the original image if the original pixels has dirac delta-functions at each pixel center.

That seems kind of whack. Don't I want to imagine that the original pixels have some size? Maybe the are squares (box impulses), or maybe they are bilinear (triangle hats), etc."

This seems whack-ier to me. The "shape" of the pixel is determined at reconstruction time, i.e. when it gets displayed on the screen. If anything, you want to invert this by pre-convolving with the inverse of the pixel shape.

April 4, 2011 at 12:34 PM

Blogger cbloom said...

Consider for example if I want to do some analysis on an image as it would be seen on a monitor.

Then the "hats" should be the monitor's pixel response functions.

And I should apply whatever filter I want to run on that output continuous light field.

April 4, 2011 at 12:47 PM

Blogger won3d said...

Yeah, I misinterpreted when you would be doing this. But if you're going to do this at the analysis phase, you ought to invert it at the synthesis phase. I was assuming that you're creating a new image, but I see that you could be generating something something based on stats, like a quality score or something in which case the output is not another image.

April 4, 2011 at 12:50 PM

Blogger cbloom said...

Yeah yeah, I think we agree.

There's a few subtle points :

1. Upon display on the monitor, some hat shape is implicitly multiplied per pixel.

2. Resizing using some filter is implicitly using that filter as the hat shape of the pixels.

So in both of those cases you should not do your own (and if you already did it, you should invert it).

But if you just want to compute some numerical score - like what's the gaussian convolution of this region of the image? - I believe you should pre-convolve the image with the pixel hat shape (which is equivalent to applying to the filter).

Nasty.

April 4, 2011 at 12:54 PM

Comment deleted

This comment has been removed by the author.

April 4, 2011 at 12:59 PM

Blogger castano said...

> Note that this doesn't really apply to resizing

Can you elaborate more on that? In NVTT I tried representing the image pixels as boxes or bilinear functions and although I didn't do a very exhaustive testing, I think it worked quite well. In fact, the box-sampling version enabled by default.

April 4, 2011 at 10:19 PM

Blogger ryg said...

"in fact for any rational ratio resize, you could precompute the filters for the repeating fractions"
Yeah but why bother being clever in the non-integer ratio case? Worst case you just compute+store filter taps for every destination row/column. That's between 1000 and 5000 filters you need to precompute and store for current expected image sizes, and your accesses to that table are always perfectly sequential.

And of course if you're walking through the image in raster order, you only need to precompute filter taps for the horizontal dimension and then recompute your vertical filter weights every row.

April 5, 2011 at 10:49 AM

Blogger cbloom said...

"Yeah but why bother being clever in the non-integer ratio case? "

Well, it depends how expensive your filter function is to evaluate.

If your dest image is 3000 pixels wide, and your filter is quite wide, say 15 taps or so, that's 45,000 function evaluations.

Currently in my implementation that's a function-pointer-call for each evaluation, which is super slow, but of course you could rearrange to make that just one function pointer call that evaluates it many times.

But of course if your filter is a kaiser window with a bessel function or some nutty shit like that, it's still ungodly slow.

But yeah, I'm not actually going to implement the rational case, just noting it. I'm not going to remove my function pointer calls either cuz it would make the code so much uglier.

April 5, 2011 at 11:27 AM

Blogger ryg said...

I retract the "extra complexity" bit btw, that was just BS, the whole "extra complexity" of doing the full rational over what I just described is one extra gcd computation :)

April 5, 2011 at 11:32 AM

Blogger cbloom said...

"Can you elaborate more on that? In NVTT I tried representing the image pixels as boxes ..."

I've been thinking about this a bit more and can't quite get my head around it.

What I meant is that when you run a filter for resizing, that's like using that filter as as the reconstruction shape of the pixels, and then point-sampling at the new grid points.

eg. if I resize with a gaussian filter, that's the same as me saying my pixels are gaussian blobs, and then I point sample the continuous field in a few places.

Okay, but what if you wanted to say "my source pixels are hat blobs, and I want to resize to hat blobs at a different spacing" (where hat=box,linear,gaussian,whatever). It's a bit tricky.

April 5, 2011 at 8:40 PM

Blogger Pinky's Brain said...

Shouldn't spline interpolation be on the list? Not a convolution kernel, but it is linear.

Did you see Hughes Hoppes big ass comparison of resamplers?

"Generalized sampling in computer graphics."

He has some videos for slow changes in translation. Mitchell (compromise) and Keys (aka Mitchell sharp aka Catmull-Rom splines) look quite poor. Lots of pumping between blurry and sharp.

April 7, 2011 at 8:15 PM

Blogger cbloom said...

I hadn't seen that Hoppe paper, thanks.

"Shouldn't spline interpolation be on the list?"

Well, cubic filter is a type of cubic spline. Mitchell can be made into Catmull-Rom by choosing the parameter right. In fact the filter that I call "cubic" is B-spline Beta3, which is box convolved with itself 3 times.

You could also ask about things like "natural" splines, which would be a linear synthesis but a very complicated analysis.

April 7, 2011 at 9:07 PM

Blogger cbloom said...

Though to be clear when I say "cubic filter" I'm not usually meaning solving for the control points to be interpolating which means that under nop the original image is not preserved.

April 7, 2011 at 9:19 PM

Blogger Pinky's Brain said...

Yeah, sorry ... meant B-splines, they are natural splines. It's not as cheap as a convolution kernel, but Unser has found some cheap-ish ways of implementing them.

April 7, 2011 at 10:11 PM

Blogger Jeff Larson said...

I stumbled across your post while researching lanczos, I'm trying recreate your constants for the filter -- but I must be missing something in the calculation, could I bother you to post some code or psuedocode for how you arrived at them?

February 6, 2015 at 1:02 PM

You can use some HTML tags, such as <b>, <i>, <a>

This blog does not allow anonymous comments.

Comment moderation has been enabled. All comments must be approved by the blog author.

You will be asked to sign in after submitting your comment.