Showing results for 
Search instead for 
Did you mean: 

FilterBoxBorderGetBufferSize is not monotonically increasing with image size


I am having some trouble with the buffer sizes returned by FilterBoxBorderGetBufferSize.

According to the documentation, roiSize is the "Maximum size of the destination image ROI". As I understand it the buffer size returned should be valid for any destination image ROI smaller or equal to roiSize. This is important for me since I am allocating a buffer once (for a fixed filter size) and reusing it many times on images that are smaller than some known bound. After some testing however, I found out that the returned buffer size is sometimes larger for smaller images. Here is an example:

	int bufferSizeA = -1;
	int bufferSizeB = -1;
	const auto filterSize = IppiSize{ 7, 7 };
	const auto imageSizeA = IppiSize{ 13, 13 };
	const auto imageSizeB = IppiSize{ 14, 14 };
	ippiFilterBoxBorderGetBufferSize(imageSizeA, filterSize, ipp8u, 1, &bufferSizeA));
	ippiFilterBoxBorderGetBufferSize(imageSizeB, filterSize, ipp8u, 1, &bufferSizeB));

When I run it with the initial release of IPP2018 I get bufferSizeA = 3205 and bufferSizeB = 3184. Is this a bug or is my understanding of roiSize wrong?

I wrote a small program to try out various filter and image sizes. It seems there is always a drop when the width and/or height of the image is exactly twice the corresponding dimension of the filter. If that is true I suppose I could detect it and circumvent it by getting the buffer sizes for nearby image sizes and taking the maximum.

Any advice would be greatly appreciated.

0 Kudos
2 Replies

Hi, Nielsen.

By performance reason there are some branches in code for various combinations of ROI size and mask size. These branches require different buffer size. Mainly it is because we build temporal images in memory enclosing it with provided border. For small input images we use one approach, for big - other. In some cases the size of small image can be more than for bigger one. We know about this situation and it is not a bug. The correct solution is to call getbufsize for all planned sizes to be processed and select the maximum. For example we use the same approach in our IPP threading layer when processing images by tiles.   

Thanks for your feedback.


Hi Andrey.

Thanks for your explanation. You should probably change the documentation so it doesn't say "Maximum" anymore.

Best regards