In this lecture we're going to fill in the missing detail from the last lecture.
How do we calculate the dimensionality of the initial feature vector into the dense layers of a CNN.
For this we need to know about a topic called conversational arithmetic.
Basically these are the concepts that allow us to calculate what the output size of a convolution will
be given some input size some filter size and various options such as padding and strides as a reminder.
The reason why we need this is because pi talk requires you to specify both the input size and output
size of each layer.
Even though we implicitly already know this information.
What's weird is that these calculations are well-defined.
So there isn't really a great reason to require us to do them ourselves.
Libraries such as cars make things super easy by automatically inferring the input size of each layer.
So you only need to specify the output size.
The reason I mentioned carries a lot is because KRS is usually a student's first introduction to deep
learning.
And even if you don't know carries you could easily pick it up in a few minutes provided you have some
base level of programming skill so another great thing about carries is that it allows you to pass in
a string to specify the type of padding that is used for convolution as a reminder.
We generally have three modes of convolution invalid mode the output sizes and minus K plus 1 in the
same mode of output size is just n the input size and in full mode which no longer exists by the way
the output sizes end plus K minus 1.
And remember that these are just the basic form of convolution with no strides.
So you might think well that's great.
If I just use same mode for all my convolutions then calculating the output size is super easy but way
passing in the mode of convolution as a string exists only in cars not pi torch
the reason I mentioned this is because it's a natural question to ask why not use the same mode so that
it's easy to compute the size of the image after each convolution.
If we do that then let's say we have an input image of size 32 that goes through three convolutions
with a straight of two after the first convolution the image shrinks down to 16 after the second convolution
as shrinks down 8 and after the third convolution it shrinks down to 4 easy.
Well let's ask ourselves how would we do the equivalent of same mode in PI torch.
Let's see we have to specify this padding argument which tells PI talk how many spaces to pad the input
image on each side but way in order to specify this argument correctly so that you achieve the equivalent
of same mode.
You need to do convolution all arithmetic to calculate the correct amount of padding.
In other words you still need to do convolution of arithmetic whether you have same mode or not.
So there's no benefit to using say mode because either way you still have to do convolution or arithmetic.
In fact this might be a little harder because you have to do convolution arithmetic in reverse.
The only good reason to use say mode would be if you really believe it benefits your model's predictions.
OK so now you're convinced that there is no way out of doing convolution or arithmetic and this course
is not my goal to go in-depth about this topic.
If you want to gain a better intuition about convolution or arithmetic I've left a link to deep learning
dot net in the file extra reading DST.
Which leads you to a tutorial about convolution or arithmetic and how the calculations change when you
have padding strides and so forth.
It's pretty non trivial however an easy way to get around this is to simply use the formula that pi
twitch provides in their documentation.
With this formula you can plug in all your values and calculate the output dimensions.
You don't need to understand convoluted mental arithmetic to use this formula.
You just need to know how to multiply add and divide.
Let's do a simple example to make sure you know how to use this formula since the formulas for both
the height and with dimensions are the same.
We only need to do one firstly the concept of dilation is outside the scope of this course and we will
use the default value of one next.
Let's assume we have padding equals one colonel size equals three and straight equals two.
Let's set each in a two 32 which is common for deep learning image datasets.
If we plug these values into our formula we get thirty two plus two times one minus one at times three
minus one minus one all divided by two then we plus one and then take the floor.
So that gives us thirty one over two plus one which is fifteen point five plus one which is sixteen
point five.
Then we take the floor of sixteen point five and we get sixteen so each out equals sixteen.
Now it's easy to make mistakes with these and I wouldn't be surprised if I did.
So if you want to double check my work please do alternatively you could just implement this in code
you may have noticed something a little curious on the previous slide which is that in the PI talks
documentation the input size and the output size are specified as and by color by height by width.
This is contrary to what we've been working with so far which is data sets of size and by height by
with my color.
Why is there this discrepancy.
Well it has to do with the conventions of the library.
Remember that when you're a programmer building a library you have full control over how it works.
So you get to decide what the conventions are how you want to structure the data and so forth.
It turns out that some developers decided to put the color channel first while other developers decided
to put the color channel last.
In our case libraries such as the ANO and Pi torch decided to put the color channel first.
Libraries like open v tensor flow map plot lib and pillow use the convention that the colour Channel
comes last.
Although open C does other weird things like using the BGR colour ordering instead of RG B so it seems
that putting the colour channel last has now become more common.
But pi torch was built with the colour channel first.
We can't just switch it around one day and expect everyone to update their code.
Therefore pi torch still uses the convention that the colour channel comes first.
This detail is hidden from you.
If you use utilities such as those from the torch vision library since we haven't worked with colour
images yet in this course we haven't had the opportunity to uncover these hidden details but now we
do.
As you recall if you inspect the data attribute of a dataset loaded in from torch vision it gives you
the UN a transformed version of the data.
These will be end by height by with by colour but when you yield batches of data from the data loader
this data is transformed in whatever way is needed before it goes into the neural network.
And so when you inspect these batches of data yielded by the data loader you will see that they appear
as end by colour by height by width so in fact pi towards still uses the convention that the colour
channel comes first.
But it comes with interfaces that work with the more commonly used convention that the colour channel
comes last.