Non-square cropping

[okuta]

Add crop_h and crop_w to TransformationParameter.
This PR is implemented similar to h/w kernel size.
Related issue: #1834

[seanbell]

This is a great addition.

Small suggestion: I think it's a good idea to add in some checks (in the DataTransformer constructor) with helpful messages like:

CHECK(!param_.has_crop_size() !=
      !(param_.has_crop_h() && param_.has_crop_w()))
      << "Crop size is crop_size OR crop_h and crop_w; not both";
CHECK(param_.has_crop_size() ||
      (param_.has_crop_h() && param_.has_crop_w()))
      << "For non-square crops both crop_h and crop_w are required.";

(this was adapted from checks done in the convolution layer https://github.com/BVLC/caffe/blob/master/src/caffe/layers/base_conv_layer.cpp#L16 )

[okuta]

@seanbell Tahnk you for your suggestion.
crop_size, crop_h and crop_w have default value.
https://github.com/okuta/caffe/blob/4d445f420e7e6fe6426ffbc62e6c212f5b9fc6d8/src/caffe/proto/caffe.proto#L333-335
Therefore I wrote a check code that does not use methods such as has_crop_size().

[haoyangz]

This is very helpful for Deep Learning work on non-CV fields . Any chance that it could be merged soon?

[liyongsea]

I am working with 1d time series data and a 1d crop could be very useful. I am wondering if this change would be merged?

[bobbens]

I think the crop_h and crop_w are swapped.

[lukeyeager]

👍

[elezar]

Can this non-square crop be implemented using the ND crop layer as in #3570?

[shelhamer]

Closing as better handled by a Python data layer. Thanks for extending crop, but I think including all these varieties of augmentation adds too much code which is more clearly expressed in Python anyway.