Difference between blockproc() and for loop method of splitting an image with overlap?

So I'm required to split an image into overlapping blocks of 8x8 and 4x4 pixels overlap, and perform dct on each block after that. I know of two methods blockproc() and a for loop method of splitting the image. But I'm wondering, would the output(dct matrix) be different between the methods?

For what i understood, the blockproc() method creates a border around the image in case of overlapping where as the for loop method from https://matlab.fandom.com/wiki/Split_image_into_blocks does not. (Note, the method in the link is for non-overlapping, but some modifications can be made for overlapping, which i did). In the case of blockproc(), the code is:

T2 = dctmtx(8);
dct_2 = @(block_struct) T * block_struct.data * T';
B1 = blockproc(I, [4 4], dct_2, 'BorderSize',[2 2], 'TrimBorder', false, 'PadPartialBlocks',true)

'BorderSize' [2 2] means that blockproc creates a border of 2 pixles top, down, right and left of the image and performs dct then. But in the case of the for loop method above, it doesn't use any borders for padding. Hence the dct when computed by each method will be different. I would like to know which method is more feasible and correct.

Answer 1

[Guillaume]

Hum, a for loop just iterates over whatever you want and execute whichever code you want. You can write a for loop that does exactly the same as blockproc, or something different. The choice is up to you. There's no inherent for loop method. It's whatever you want it to be.

However, note that blockproc doesn't do overlapping blocks. Also note that by default blockproc does not add a border, despite your statement.

One of the functions you can use for processing along a sliding-window is nlfilter. This function does indeed pad the image if necessary (if you don't want that just trim the image). If it's possible, you should be using colfilt instead.

But regardless which function you choose, again, you can implement the exact same thing with for loops and any deviation is your choice.

[Stewart Tan]

@Guillaume I don’t understand. The reason I learnt about it is through a question I asked few days back,and also some googling on “how to divide an image into overlapping blocks”, you’ll see several answers suggesting blockproc and one of the answer was suggesting the use of blockproc, ‘BorderSize’ to define overlapping much like most of the googling done. https://www.mathworks.com/matlabcentral/answers/475327-does-blockproc-divide-the-image-into-overlapping-or-non-overlapping-blocks?s_tid=ab_new_mlc_ans_email_view#answer_386691

I would need some clarification as I’m a beginner. In fact there are many who suggested blockproc() and if that’s not the case then it is really contradicting.

[Guillaume]

Yes, you can pervert blockproc to do some overlapping, but note that the description of the function is "Distinct block processing". However, you are limited in the combination of window size and sliding step. For example, it's not possible to use it to slide a 3x3 window with a sliding step of 2. windowsize - slidingstep must be a multiple of 2.

And as you've pointed out, using blockproc this way, you always get zero-padding on all sides of the image.

The functions I've listed (nlfilter and colfilt) are designed for sliding windows. They will only pad the image (on the right and bottom) if there's not enough pixels for the last sliding blocks.

My point still stand though, the difference between your for loop and whichever function you use, is up to you. You can code the loop to do the same, or not.

[Stewart Tan]

@Guillaume thanks. That cleared up a bit. Also, for the case of for loops, would I even have to consider padding the image? I’ve actually implemented it(not sure right or not)but it doesn’t perform padding(the link in the question) and when I computed the dct for each block, it is different from the output of blockproc. That’s why I began becoming confuse on which is right and wrong. I’ll try out nlfilter and colfilt soon enough and get back to you whenever necessary.

[Guillaume]

would I even have to consider padding the image

That depends solely on your algorithm. Does it require blocks that are always the same size? If so, then you'll either have to pad the smaller blocks (when you reach the edges of the image) or ignore these blocks. If your algorithm doesn't care about the size of the blocks, then padding is not necessary.