Hdf5 output layer

[kloudkl]

This PR resolves #213 and also closes #220.

@sergeyk, please review and check whether this is what you asked for.

[sergeyk]

Looks great! One thing, could you make sure that the Forward/Backward GPU mode functions are split into separe .cu file, like in the other layers? Will merge as soon as that's done.

[sguada]

@kloudkl one probably want to save multiple blobs in the same HDF5 file.

[kloudkl]

The implementation assumes that a dataset corresponds to a blob as hdf5_load_nd_dataset indicates. Future needs would be satisfied in some future PRs.

[sguada]

Actually, hdf5_load_nd_dataset can load different Blobs from the same file, but it's true it could be a future feature.

[kloudkl]

The ImagesLayer.cpp and WindowsDataLayer.cpp need to be split in another PR.

[sergeyk]

Agree with @kloudkl on both counts. Is a commit to split to .cu coming up?

[shelhamer]

This introduces a new layer and proto field so it needs to be coordinated with @jeffdonahue's #219.

[kloudkl]

The ImagesLayer.cpp and WindowsDataLayer.cpp are coming up.

[sguada]

@kloudkl I think ImagesLayer.cpp and WindowsDataLayer.cpp should go in a different PR. Leave this one only for HDF5Output

[kloudkl]

Yes, they are in #253.

[sergeyk]

@shelhamer let's avoid blocking situations as agreed. let's merge this, then 219, then fix whatever needs fixin'

[shelhamer]

@sergeyk agreed–just flagging for Jeff so it isn't missed.

[kloudkl]

The changes to src/caffe/proto/caffe.proto are inline with #219.

 +  
 +  optional HDF5OutputParameter hdf5_output_param = 1001;
 +}
 +
 +message HDF5OutputParameter {
 +  optional string file_name = 1;

But I am afraid that adding enum LayerType { HDF5_OUTPUT = 100; } to message LayerParameter would cause merge conflicts with #219.

[shelhamer]

@kloudkl don't worry about it. As Sergey said we'll merge this, and having made the needed notes, #219 can be updated and merged next.

[sergeyk]

Thanks @kloudkl