Pass varied sized images as input to a model without resizing

username: N1h1l1sT
cooked: <p>I’ve searched on google and suggested threads here for an answer to this but couldn’t find one.<br>
So, let’s say I have these 4 images as input:</p>
<pre><code class="lang-auto">########################
### Images / Dataset ###
Image1 = torch.rand((3, 255, 255))
Image2 = torch.rand((3, 320, 320))
Image3 = torch.rand((3, 320, 320))
Image4 = torch.rand((3, 120, 120))
</code></pre>
<p>I tried to create a simple dataset and data loader for this:</p>
<pre><code class="lang-auto">def VariedSizedImagesCollate(batch):
    return [item for item in batch]


class Images_X_Dataset(Dataset):
    def __init__(self, ListOfImages):
        self.data = ListOfImages

    def __getitem__(self, index):
        return self.data[index]
    
    def __len__(self):
        return len(self.data)


MyDataset = Images_X_Dataset([Image1, Image2, Image3, Image4])
MyDataLoader = torch.utils.data.DataLoader(dataset = MyDataset, batch_size = 4, shuffle = True, collate_fn = VariedSizedImagesCollate, pin_memory = True)
</code></pre>
<p>We can take one batch and put it in the variable MyX<br>
<code>MyX = next(iter(MyDataLoader))</code></p>
<p>Now we have a simple fully convolutional network (so that the network itself can handle different size pictures without any tricks).</p>
<pre><code class="lang-auto">#############################################
### Model to work with Varied Size Images ###
class Net(nn.Module):
    def __init__(self):
        super(Net, self).__init__()
        
        self.Conv1 = nn.Conv2d(in_channels = 3, out_channels = 32, kernel_size = (7, 7))
        self.Conv2 = nn.Conv2d(in_channels = 32, out_channels = 64, kernel_size = (5, 5))
        self.Decv1 = nn.ConvTranspose2d(in_channels = 64, out_channels = 1, kernel_size = (4, 4))
        self.Sigm1 = nn.Sigmoid()

    def forward(self, X):
        out = self.Conv1(X)
        out = self.Conv2(out)
        out = self.Decv1(out)
        out = self.Sigm1(out)
        return out

model = Net()
</code></pre>
<p>Now if I instantiate the model and pass the 1st image of MyX, I will get an output as I should.</p>
<pre><code class="lang-auto">MyOutImg = model(MyX[0].unsqueeze(0))
print("Original shape of 1st image:", MyX[0].shape, "Output's 1st image shape: ", MyOutImg[0].shape)
</code></pre>
<blockquote>
<p>Original shape of 1st image: torch.Size([3, 120, 120]) Output’s 1st image shape:  torch.Size([1, 113, 113])</p>
</blockquote>
<p>The problem arises when I want to pass the whole batch:</p>
<pre><code class="lang-auto">MyOutImg = model(MyX)
print("Original shape of 1st image:", MyX[0].shape, "Output's 1st image shape: ", MyOutImg[0].shape)
</code></pre>
<blockquote>
<p>TypeError: conv2d(): argument ‘input’ (position 1) must be Tensor, not list</p>
</blockquote>
<p>Which I understand. It couldn’t be a tensor (as far as I understand) because of the fact that pictures have different sizes and tensors require same sizes for all pictures to have N pictures in a tensor (NxCxHxW), so VariedSizedImagesCollate() does return a list.</p>
<p>I tried <code>torch.cat</code> and <code>torch.stack</code> but they both seem to require same size images. So what’s a way where I can pass the whole batch?<br>
I also need to it work on the backpropagation as well, but I guess if it works in the forward it should work on back too.</p>

username: eqy
cooked: <p>You can pad the images to the same size if you truly want to avoid resizing.</p>
<p>There are two fundamental as to why variable sized images cannot be combined in a batch:<br>
(1) When trying to stack or concat the tensors when their spatial dimensions are not the same, what should the output tensor shape be? How can the spatial dimensions be unified as there is a single output tensor?</p>
<p>(2) Even suspending the first issue for a moment and considering the possibility that a tensor could exist with different spatial dimensions for different batch indices, this would wreak havoc in terms of batch-level parallelization. This fundamentally introduces data-dependent control flow, which means algorithms that are written to repeat the same computation (e.g., sliding a filter across multiple input examples) have to be modified to consider the potential different dimensions of each input.</p>

username: N1h1l1sT
cooked: <p>For the 1st point, yeah, I can imagine.<br>
But because I’ve seen papers where they use different sizes of images as input, they explicitly say that they don’t resize, but they don’t mension how they handle the different sizes in the end.</p>
<p>So I imagined, since I can use this network with different sizes 1 by 1, just not in a batch, that perhaps since that’s possible, there would be a way to make a list-like kind of batch instead of a torch tensor.<br>
You know what I mean?<br>
Certainly it’s impossible with tensors, but perhaps there’s another way?</p>
<p>On the 2nd point, for this list-like batch, I don’t think there will be any fundamental change since predicting with different size images on this network already works, so long as you do it 1 picture at a time. Just, instead of iterating on the 1st dimension of N x C x H x W tensor, you iterate over the length of the list with C x H_i x W_i tensors as elements of the list</p>
<p>(Now if a picture is too small for the current architecture, ofc that will throw an error)</p>

username: eqy
cooked: <aside class="quote no-group" data-username="N1h1l1sT" data-post="3" data-topic="123203">
<div class="title">
<div class="quote-controls"></div>
<img loading="lazy" alt="" width="24" height="24" src="https://discuss.pytorch.org/user_avatar/discuss.pytorch.org/n1h1l1st/48/32741_2.png" class="avatar"> N1h1l1sT:</div>
<blockquote>
<p>On the 2nd point, for this list-like batch, I don’t think there will be any fundamental change since predicting with different size images on this network already works, so long as you do it 1 picture at a time. Just, instead of iterating on the 1st dimension of N x C x H x W tensor, you iterate over the length of the list with C x H_i x W_i tensors as elements of the list</p>
</blockquote>
</aside>
<p>The issue is that the underlying implementations on CPU and GPU are usually written to take advantage of batching for data reuse. Of course, you can always write your own function that takes in a list of tensors, one per each image. The performance will likely be much lower than batching (even if it means zero-padding is used).</p>
<p>I am referring to changes in the underlying kernel implementations. These kernels are highly shape dependent (e.g., the best axis for data reuse changes depending on the relative sizes) of which batch size is an important parameter.</p>

username: N1h1l1sT
cooked: <p>I see.</p>
<p>Well, in that case, I guess the best I can do is abandon hope for list of 3D tensors and pad the images to create 1 actual 4D tensor.</p>
<p>Perhaps I could sort by Height and width so that each batch can have a different amount of padding, as little as possible for it to get to the same size as the biggest picture in each current batch.</p>