Page 1 of 1

number of neighbors

Posted: 2014-02-03T23:16:30-07:00
by robuntu
this is a theoretical question wich affects my practical problem.
I have to enlarge a given image to a huge size and then cut it
into slices. It is simular to creating photo-wallpapers.
The slices will be 200 inches long (from Top to bottom)
and 20 inches wide, but up to 100 of them.
You can imagine the large size of the toal amount of pixels.

until now I do this in two steps :
1) resize to the huge size
2) cut slices

with the mpc-format which is by far the fastest with this amount of pixels
I need lots of memory (which is ok, I have 132GB of Ram) but also lots of time.
only the resize sometimes takes up to 5 minutes, and this is on a 32core Xeon.

So I wonder if I could to it the other way round.
1) cut slices on the original image
2) enlarge the slices

But here comes my problem and question:

Whith the standard resize method I do some kind of bicubicle interpolation (please correct me if this is wrong!)
When I slice first, the border pixels will be interpolated different to the result I would get with "neighbors".
After this kind of operation you can see the cutting line when you put the slices together again.

What I need to know is, how many neighbors do I need (and cut away after resize) to have the same
result as I would get with the whole image.
I assume it still will be much faster to 1) slice with overlap 2) cut borders 3) resize
to have the same result as I get now with my time and memory consuming method.

Please feel free to make any further suggestions.

Thanks or your help!

Re: number of neighbors

Posted: 2014-02-03T23:35:46-07:00
by fmw42
If you are doing standard bicubic (Keys Cubic Convolution or Catrom interpolation), then for each output pixel it takes a special weighted average of 4 intput pixels. For other interpolation methods it depends upon the number of lobes involved. The default upsampling resize is I believe Mitchell. See

Re: number of neighbors

Posted: 2014-02-04T14:02:24-07:00
by robuntu
Hi fmw42,
nice to see that you are helping on every taskes :D

Yes, the Mitchell is the standard an after testing some options I do agree that Mitchell is the best choice for me, too.
So I just use the standard.
When you say one output pixel uses 4 input pixel, is this one each on top, bottom, left and right or
is it not that easy?
However it sounds to be save to use an overlap of 5 pixels and to cut just these 5 pixels per strip after resize.
That could increase the speed by the times of 8 for me, which would be great!
(Resize uses not more then 4 cores, so I can resize 8 strips in parallel with the same
amount of memory that I used before for the whole image)
So again: thanks for your help!


Re: number of neighbors

Posted: 2014-02-04T14:11:31-07:00
by fmw42

Bilinear use a 2x2 array of points to do the interpolation. It takes fractional pixel coordinates in the output and interpolates linear horizontally twice using the 4 input pixels and then 1 more time vertically.

In cubic convolution it does something similar, but interpolates using a 4x4 array of input pixels. The interpolation is done 4 times horizontally and then 1 time vertically, but is not linear.

I am not sure what Mitchell is doing, but I suspect it is similar in using a 4x4 array of input pixels for each output coordinate. I suspect the weights are different. However, if one specifies more lobes, then it probably involves a larger input array.

Anthony is the best person to ask, since he wrote the code.

Re: number of neighbors

Posted: 2014-02-05T12:21:41-07:00
by Dane Vandeputte
If you're using the default interpolation, then you'll need to pad each slice of the original image with 2 pixels on each side. After a slice has been enlarged, you'll then need to crop off 2*scale pixels on each side. For example, if scale = 16, meaning that each dimension will become 16 times larger, you'll need to crop off 2*16 = 32 pixels on each side. One problem that can arise is if scale is not a whole number. For example, if scale = 16.3, then you'd need to crop off 2*16.3 = 32.6 pixels on each side, which isn't exactly possible, since you can't crop off a partial pixel. In this example, you could probably round 32.6 to 33 and not have a noticeable seam. The larger scale is, the less noticeable a seam will be, but it will always be best if scale is a whole number.