Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Within-channel LRN layer #273

Merged
merged 18 commits into from
Apr 8, 2014
Merged

Within-channel LRN layer #273

merged 18 commits into from
Apr 8, 2014

Conversation

jeffdonahue
Copy link
Contributor

(Not sure how I accidentally submitted this without any description.)

This PR implements within-channel local contrast response normalization across a square neighborhood of each input channel, a la cuda-convnet's rnorm layer [1]. This layer is used in many of the cuda-convnet CIFAR example architectures, including our current cifar_full example that was based on the layers-18pct example in cuda-convnet, so I've updated that example to use this new layer type here. It doesn't make much of a difference -- running the full training gets to (exactly) 82% accuracy, as opposed to 81.65% the old normalization across channels was getting. It is also unfortunately slightly slower, taking 6 minutes and 57 seconds for 5000 iterations (compare to 6 minutes 43 seconds for the cross channel normalization), but I think this might make sense as we're summing over N^2 input pixels for each output, instead of N. I think it's nice to be able to reproduce these network architectures exactly though, even if it doesn't make much of a difference which type you use in practice.

Because I'm not smart enough to write something along the lines of the code for the current cross-channel LRN layer [2], I basically implemented this under the hood as a sequence of 5 other layer types, including 2 new ones: the EltwiseProductLayer, which computes outputs z = x .* y (excuse the MATLAB notation) on >=2 input blobs and PowerLayer (open to suggestions on a better name..), a neuron which computes z = (alpha + beta * x) ^ gamma for fixed values of those parameters. This implementation has a small memory penalty as it uses a few internal blobs for storing the intermediate results of each layer's computation. If somebody wanted to rewrite this later without using any "helper layers" to make it more memory efficient, they could do that.

[1] https://code.google.com/p/cuda-convnet/wiki/LayerParams#Local_response_normalization_layer_(same_map)

[2] https://github.com/BVLC/caffe/blob/master/src/caffe/layers/lrn_layer.cpp

@jeffdonahue jeffdonahue changed the title Lrn map layer Within-channel LRN layer Mar 29, 2014
@shelhamer
Copy link
Member

Agreed that exact replication's in the spirit of having reference architectures and examples. I don't quite understand why you introduced the layers instead of doing blob operations, but perhaps the helper layers could be otherwise useful, and like you said they do no harm.

The direct, efficient way can be Caffe dev practice for the future.

(Note I haven't fully reviewed this–someone else should take a look and merge.)

@jeffdonahue
Copy link
Contributor Author

My main motivation was to avoid rewriting code to sum over regions (for which the implementation, to me at least, looks pretty hairy). This is handled by an (average) PoolingLayer instead.

@kloudkl
Copy link
Contributor

kloudkl commented Mar 29, 2014

The acronym for local contrast normalization is perhaps LCN.

vector<Blob<Dtype>*> power_top_vec_;
shared_ptr<EltwiseProductLayer<Dtype> > product_layer_;
Blob<Dtype> product_data_input_;
vector<Blob<Dtype>*> product_bottom_vec_;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that both PowerLayer and EltwiseProductLayer are suitable to be refactored in #244.

@shelhamer
Copy link
Member

This is distinct from LCN. This is a within-channel scoped response
normalization. LCN normalizes with variance instead if I remember right.

Le samedi 29 mars 2014, kloudkl notifications@github.com a écrit :

The acronym for local contrast normalization is perhaps LCN.


Reply to this email directly or view it on GitHubhttps://github.com//pull/273#issuecomment-39007771
.

@jeffdonahue
Copy link
Contributor Author

yup my bad, it is indeed not contrast normalization (e.g. https://code.google.com/p/cuda-convnet/wiki/LayerParams#Local_contrast_normalization_layer)

@jeffdonahue
Copy link
Contributor Author

Let me know if someone wants to merge this*. If/when that's going to happen, I'll first change the added IDs in the LayerType enum (and the PowerParameter ID) to the actual next available values (currently using placeholder values of 1000+ to ease rebasing).

*if not, feel free to close the PR -- not going to be offended if people don't care about having a within-channel LRN in Caffe.

@shelhamer
Copy link
Member

I'm all for including this to polish the replication, but I don't see myself reviewing this soon.

How about you set the field IDs, take a last glance at the diff with dev, and merge it yourself?

jeffdonahue added a commit that referenced this pull request Apr 8, 2014
@jeffdonahue jeffdonahue merged commit 58998df into BVLC:dev Apr 8, 2014
@jeffdonahue
Copy link
Contributor Author

Thanks for giving the go-ahead Evan - done.

@jeffdonahue jeffdonahue deleted the lrn-map-layer branch April 8, 2014 18:54
@shelhamer shelhamer mentioned this pull request May 20, 2014
mitmul pushed a commit to mitmul/caffe that referenced this pull request Sep 30, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants