ISBI ACDC challenge 赛后反思

前段时间不忙，就参加了ACDC challenge，后来划划水了，毕竟工作狗，在后来deadline延期的那段时间活多，没办法。最后很尴尬的只有18名。清明的时候又搞了一下paper,毕竟没有写paper，就不算有效提交，哎，沉没成本有点高啊。这个事情算是尘埃落定了吧，虽然成绩渣渣，但是还有蛮多需要改的地方和值得总结的地方，先来一弹总结吧。比赛链接：https://acdc-lunghp.grand-challenge.org/Challenge/

不足之处：
1.在数据处理之后，没有去double check一下，开始使用的数据，很多边缘信息都没有被选取为正样本，处于边缘的区域很多因为自己的限制条件过滤掉了。后来发现问题的时候已经来不及了。
2.在选择 open sourse 的时候，不要挑最简单的，fork下来踩坑无数，本身就是个toy,这点和自己本身工程能力有关，也和一时的畏难情绪有关。这里接连导致了后续非常多的问题，耗了非常多的时间。
3.取法乎上仅得其中。开始的时候调研不够充分，没有看到之前的比赛的论文，而仅仅是看了百度的文章和提供的banchmark,里面对数据处理上的描述也没有很认真的看，主要是看了代码，代码里面并没有对数据处理这一块有描述，直接提供了json文件，是做了挖掘后的，所以就很尴尬。应该在百度的上面改的。
4.对程序的熟悉度不够，由于是git clone了别人的代码，但是又改的面目全非的，中间掺杂了一些别人的东西，然后前面看了又忘了，导致后来问题的排查就很累。一个bug找了两天。就是发现测试效果奇差无比，很随机，这时候就很混乱了，第一次是发现 train模式和eval模式差距很大，然后发现，在pytroch下面，确实有这个问题，自己的那个bn的大小太小了，所以得出来的统计量不稳定，后来用了256的batchsize就没有这个问题了。在8 batchsize下，在测试的时候还是用train的模式。但是发现还是不对，在测试上和训练的差距太大了，不可能泛化能力那么差。最后，逐步开始看代码，发现了。竟然是读图方式的问题。开始的时候，都是用slide.read_region来处理图片，用的是PIL的库，然后保存。结果训练的时候，好死不死突然来了了CV2.imread， 然后又转成PIL array，然后用PIL做预处理。自己测试的时候直接从原图slide。read_region来读，所以是rgb的，通道反了，把通道改了回来之后，就好了。在这里坑了两天，真的气傻了。
5.时间进度安排不合理。
主要是改了一次deadline，后面的时候就很松散，没有去利用时间。拖拖拉拉的，然后就被各种赶超了。导致后面的时间根本来不及，毕竟只有一张卡的穷人，在最后一周换了模型换了数据，时间就total不够了。所以只训练了5个epoch，然后nms写的还有问题，直接没用上，前面就该把代码测试好，不是最后一天用的时候调，完全调不上。
6.代码写的太乱。参数没有定义在一起，这里改吧改吧，那里改改，然后就不同意了，在数据处理的时候，就处理错了，浪费了很多天的时间。而且还懒，就不想把预处理的代码改成多线程的，等数据处理完，一天没了，然后一看，妈呀，处理的还是错的，就很尴尬。最后发现时间来不及了，周五deadline，周一数据还没出来，花了十分钟就把多线程搞了，真的是呵呵了。