Closed khirotaka closed 3 years ago
Hi @khirotaka,
Glad it was helpful and thanks for the issue! Regarding dilation, you are correct. I actually was trying to come up with a more modularized way to handle this. If you do have a suggestion, I'm more than happy to discuss a PR :pray:
Regarding the receptive field, it's actually a design choice I made earlier:
This might be misleading but the idea was to be able to trace back the relative spatial dependency to a node in the output layer. However, I understand this can be confusing and perhaps it would be best to add an option to specify whether it is relative to the output of the model or the input (and to set the default in the order you suggested).
Regarding the reduction process, I actually implemented it to work using the receptive field increasing order of my initial PR over there: https://github.com/frgfm/torch-scan/blob/master/torchscan/utils.py#L175-L177
So we are to move forward with PRs, I would suggest splitting them up:
I'll look into this, but let me know if you want to help / submit a PR :+1:
Hey @khirotaka,
Actually, I didn't manage to really fix the receptive field computation as the values are really bound to be computed reversely (cf. https://distill.pub/2019/computing-receptive-fields/) for the whole model. If you have a draft that managed to get a 212 value on torchvision.models.vgg16
, I'd be happy to take a look at it.
I tried a few things but it was far from ideal (had to reverse some changes from #31 in #33)
Hey! I'm going to share my idea for a patch. I hope this helps a little bit...
https://github.com/khirotaka/torch-scan/commit/e0932c227de38484413128181252bb0f48d5aa74
Hi @khirotaka,
Thanks for the suggestion! I actually managed to handle this by reversing the recurrence equations in #34 :ok_hand: For the dilation part, I only integrated into the module kernel size to avoid changing the interface. It's working like a charm!
Thanks again :pray:
Thank you as well! I'm looking forward to the latest release!
This library is truly amazing !
In my search for a library to calculate the receptive field size, I was really excited to find this library. (I especially appreciate the support for
Conv1d
.)But I have two questions.
P.S.
I've written a patch for both of them, but there is a problem that the receptive field size is not properly displayed when the
max_depth
is reduced...