Deconvolution layer?

[jyegerlehner]

Our excellent Brewers have submitted for publication a paper with interesting ideas.

From a quick reading, I presume there must be a deconvolution layer developed. Would anyone join me in encouraging them to commit the code early? Paper says will be released upon publication. I don't know much about how these things work in the academic world, so maybe there is some kind of disadvantage in not waiting until publication. If we do have to wait until publication, does anyone know when that is likely to be? I'm not sure which conference or journal it was submitted to.

[ducha-aiki]

I think, it is good topic to again draw attention to the problem, opened by @bhack at
#1482 (comment)
"I saw a very very low activity by core developers (BVLC members) also after cvpr 2014 deadline.
What happens? @shelhamer Can you give some general feedback to the community (if we can consider to have ones)? We was quite responsive on every PR that we have opened and we are investing working hours on this but at this rate it very hard to reserve activity in the planning. I really hope the the "final solution" will not be that you are changing the infrastructure so that everyone can maintain its own layer with python prototypes."

Although @Yangqing, @jeffdonahue, @longjon, @shelhamer, @sergeyk, @sguada made a very great job by creating caffe itself, the policy for community contributions is the most necessary PR caffe needed now. There is a good chance for caffe for become academic and indistrial standard, but it decreases with loosing of active community members.

[bhack]

I only don't want to replicate the IMHO failure experience of https://github.com/Itseez/opencv_contrib (that still doesn't have a real policy).
Modularization is not always the gold solution to reviewers bottleneck. Without any strong maintairnership of modules, plugins or whatever you want to call it there will be any shared vision and functionally duplication and frammentation. The "plugin/module mess" of (layers, loss, etc) will need to be handled identifying maintainers of accepted and distributed modules. I like scalable solution like the work done in Debian community for maintainers policy of packages in the distribution. The problem of code growing is that maintainers efforts increase as the code increase and is not only a problem of PR throughput. People switch of to other task, to other life context and abandon PR when probably we needed more momentum (carpe diem) instead of missing in action. Kudos to all the core developers to have created and opened Decaf and then Caffe but I'm really guessing, in the github "social coding era", if the old good open source community practices are still so diffusely owned at a cultural level and if BVLC core member want a growing community around this tool or not because it is incompatible with research workflow.

[bhack]

See also https://groups.google.com/forum/m/#!topic/caffe-users/qB6XC4Oi7-s

[shelhamer]

Thanks all for your clear and earnest interest in coming to a workflow and policy that lets us make the most progress as a community.

I'll not reiterate the BVLC Caffe crew's commitment to open source and open science since our code, reference models, tutorials, and so on say it better. At the moment we are turning our latest research hacking into Caffe worthy code to share as we've done with the framework as a whole.

I saw a very very low activity by core developers (BVLC members) also after cvpr 2014 deadline. What happens?

@bhack I admit that we have finite time. Our schedules are not constant, and we are subject to many deadlines. However, we are making improvements and readying PRs all the while. While research can make us disappear from time to time, it drives a lot of features and improvements. This winter we'll have a chance to catch up on reviews and merging. We are exploring how to keep development steady by including more BVLC students with different deadlines.

the policy for community contributions is the most necessary PR caffe needed now

@ducha-aiki I agree, and the BVLC Caffe crew and I are designing a new workflow to better direct efforts. In part we plan to

• move to a single branch development model to reduce overhead and confusion about where to PR
• post more milestones and make shorter releases to make current directions clear
• introduce a "contrib" track of some kind for contributions that are useful to some part of the community, but don't reach consensus for merge into core Caffe. We're open to advice on how to make this actually work.

I'll follow-up with links once I flesh out these ideas as full issues soon, where we can have focused discussions.

On the whole our issue isn't so much a lack of progress but a lack of signaling. Bartosz made a few suggestions for better communication in the caffe-users thread and we have a few ideas to try like tagging, broadcasting BVLC discussions through issues, and more milestones.

Although there are improvements to be made, I am proud of our first year as an open source project and community!

[shelhamer]

@jyegerlehner

I think our proper titles are brewers ☕

there must be a deconvolution layer developed. Would anyone join me in encouraging them to commit the code early?

When and how to release code with a publication is a whole bundle of questions in itself, but in this case we expect to PR the deconvolution layer soon (with all the same capabilities as convolution like stride, groups, etc. since at heart these operations are the same). Stay tuned.

The FCN models will likewise be released, but we're still reconciling all the needed pieces with BVLC/Caffe.

Thanks for your interest in our work.

[jyegerlehner]

@shelhamer

I think our proper titles are brewers ☕

Excellent. "Maintainer" doesn't do justice to the magnitude of the task of developing and sharing this excellent library with us all. I stand corrected.

Upon re-reading the title of the post, I feared some might think I was being sarcastic. That was not my intent at all. So I changed it.

we expect to PR the deconvolution layer soon (with all the same capabilities as convolution like
stride, groups, etc. since at heart these operations are the same). Stay tuned.

Yay. Will do. Thx.

[bhack]

@shelhamer Please open a new ticket to discuss this with your trough and to collect feedbacks. IMHO is not that the your schedules are not constant. The problem is that your schedules are not communicated to the community nevertheless at a macro level. I want to repeat that out of time availability is a common problem for almost all opensource project not backed by commercial companies. I'll try to comment in some open tickets, citing you, to let make an evidence of different behavior that could be improved community side.

[longjon]

@jyegerlehner I expect to open a deconv PR today; sorry it has taken so long! (Note that there is no deep magic here: it's just a reversal of conv layer. The work is in finding a satisfying way to factor out the common code between deconv and the regular conv layer.)

[longjon]

#1615. It's not fully tested, but it should work, let me know if it doesn't.

[beniz]

@shelhamer thanks for clarifying the on-going reflection on workflow and policy. You guys are doing a really amazing job in a pretty vivid area of research that feels like coding on quicksand!

My 2cents, though I know it is not the right ticket for it: milestones per area of dev (input/output, neural net structure, etc...) and weekly online very short group meetings (on Freenode IRC #caffe seems to be reserved though unused).

I (with others?) would definitely be willing to help maintain a foot on IRC for instant problem resolution and more (could help weed out the ticket list).

[jyegerlehner]

@longjon Thank you! I hope that wasn't a heroic effort just for me. But I'm very glad to have it! I will shelve what I was doing and give it a whirl.

[bhack]

Deconvolution PR was opened. We continue the general discussion here #1623