Allow Pooling over the size of Bottom

[sguada]

Instead of defining a kernel_size we could Pool over the size of the bottom, which would allow pooling for different bottom height x width without changing the prototxt.

[shelhamer]

Wait, what? Are you saying there should be a pooling mode that parameterizes the dimension of the top so that pooling regions can be relative sizes in the input i.e. spatial pyramid pooling?

Or do you mean there should be a pooling mode that pools the entire bottom, no matter the size, as in global average pooling?

@kloudkl proposed #560 and @ronghanghu submitted #641. Can you just revive one of those contributions?

[sguada]

I was thinking on something simpler for now the top will always be num x
channels 1 x 1, if one specify kernel_size = -1 then it means it would
define the kernel_size_h equal to the bottom_height and kernel_size_w equal
to the bottom_width. And if one specify kernel_size_h = -1 or kernel_size_w
= -1 then it actual size it is inferred from the bottom_height or
bottom_width

Sergio

2014-10-02 15:40 GMT-07:00 Evan Shelhamer notifications@github.com:

Wait, what? Are you saying there should be a pooling mode that
parameterizes the dimension of the top so that pooling regions can be
relative sizes in the input i.e. spatial pyramid pooling?

@kloudkl https://github.com/kloudkl proposed #560
#560 and @ronghanghu
https://github.com/ronghanghu submitted #641
#641. Can you just revive one of
those contributions?

—
Reply to this email directly or view it on GitHub
#1210 (comment).

[shelhamer]

Oh ok, it's a special flag for global pooling. Thanks for the clarification.

[shelhamer]

It might be better to introduce a new field in the proto like global instead of a magic value of kernel_size, but whatever works.

[sguada]

What about introducing a future feature like bins, which for now it only
allows to be 1. It gets the same semantics as global, and would allow in a
later PR to do pooling by specifying the number of desired bins (bins_h,
bins_w).

Sergio

2014-10-02 16:12 GMT-07:00 Evan Shelhamer notifications@github.com:

It might be better to introduce a new field in the proto like global
instead of a magic value of kernel_size, but whatever works.

—
Reply to this email directly or view it on GitHub
#1210 (comment).

[shelhamer]

That's just a special case of SPP, which can be seen in the two PRs I
referenced. I think it's worth having an SPP layer that takes a pooling
mode as a parameter and just creates the necessary layers within itself by
composition.

On Thu, Oct 2, 2014 at 4:21 PM, Sergio Guadarrama notifications@github.com
wrote:

What about introducing a future feature like bins, which for now it only
allows to be 1. It gets the same semantics as global, and would allow in a
later PR to do pooling by specifying the number of desired bins (bins_h,
bins_w).

Sergio

2014-10-02 16:12 GMT-07:00 Evan Shelhamer notifications@github.com:

It might be better to introduce a new field in the proto like global
instead of a magic value of kernel_size, but whatever works.

—
Reply to this email directly or view it on GitHub
#1210 (comment).

—
Reply to this email directly or view it on GitHub
#1210 (comment).

[sguada]

I know it is a special case of SPP, but since those PR are not happening
soon, I think having a Global pooling for now would be good. Having a
pooling with bins could be part of the building blocks of the future SPP
layer.
If I don't add any parameter and reuse kernel_size it is only changing few
lines of code in the pooling.cpp

Sergio

2014-10-02 16:30 GMT-07:00 Evan Shelhamer notifications@github.com:

That's just a special case of SPP, which can be seen in the two PRs I
referenced. I think it's worth having an SPP layer that takes a pooling
mode as a parameter and just creates the necessary layers within itself by
composition.

On Thu, Oct 2, 2014 at 4:21 PM, Sergio Guadarrama <
notifications@github.com>
wrote:

What about introducing a future feature like bins, which for now it only
allows to be 1. It gets the same semantics as global, and would allow in
a
later PR to do pooling by specifying the number of desired bins (bins_h,
bins_w).

Sergio

2014-10-02 16:12 GMT-07:00 Evan Shelhamer notifications@github.com:

It might be better to introduce a new field in the proto like global
instead of a magic value of kernel_size, but whatever works.

—
Reply to this email directly or view it on GitHub
#1210 (comment).

—
Reply to this email directly or view it on GitHub
#1210 (comment).

—
Reply to this email directly or view it on GitHub
#1210 (comment).

[shelhamer]

Global pooling is a useful special case for now, so let's start with that
and defer the rest. Adding bin logic to the pooling layer itself is a
confusion of responsibility to me and one might as well just finish the SPP
layer if that's what's desired.

On Thu, Oct 2, 2014 at 4:35 PM, Sergio Guadarrama notifications@github.com
wrote:

I know it is a special case of SPP, but since those PR are not happening
soon, I think having a Global pooling for now would be good. Having a
pooling with bins could be part of the building blocks of the future SPP
layer.
If I don't add any parameter and reuse kernel_size it is only changing few
lines of code in the pooling.cpp

Sergio

2014-10-02 16:30 GMT-07:00 Evan Shelhamer notifications@github.com:

That's just a special case of SPP, which can be seen in the two PRs I
referenced. I think it's worth having an SPP layer that takes a pooling
mode as a parameter and just creates the necessary layers within itself
by
composition.

On Thu, Oct 2, 2014 at 4:21 PM, Sergio Guadarrama <
notifications@github.com>
wrote:

What about introducing a future feature like bins, which for now it
only
allows to be 1. It gets the same semantics as global, and would allow
in
a
later PR to do pooling by specifying the number of desired bins
(bins_h,
bins_w).

Sergio

2014-10-02 16:12 GMT-07:00 Evan Shelhamer notifications@github.com:

It might be better to introduce a new field in the proto like global
instead of a magic value of kernel_size, but whatever works.

—
Reply to this email directly or view it on GitHub
#1210 (comment).

—
Reply to this email directly or view it on GitHub
#1210 (comment).

—
Reply to this email directly or view it on GitHub
#1210 (comment).

—
Reply to this email directly or view it on GitHub
#1210 (comment).

[shelhamer]

Done in #1214