首页 文章 精选 留言 我的

精选列表

搜索[长程任务],共10000篇文章
优秀的个人博客,低调大师

基于飞桨Res-Unet网络实现肝脏肿瘤分割任务

【飞桨开发者说】韩霖,PPDE飞桨开发者技术专家,吉林大学计算机科学与技术学院,主要研究医学影像方向。 ​ 项目背景 近年来,快速发展的深度学习技术已经渗透进了各行各业,医疗方面也不例外。这篇文章我主要介绍如何使用深度学习计算机视觉方法对CT扫描中的肝脏和肝脏肿瘤进行分割。 根据2018年的统计数据[1],肝脏肿瘤是全球第7常见的肿瘤,但致死病例总数却在所有肿瘤类疾病中排名第二。早发现早治疗能有效提升肝脏肿瘤疾病的治愈率,但人工在大量的肝脏CT影像中寻找体积很小的肿瘤工作量极大,也很容易漏检。这个场景下,使用深度学习算法自动进行快速、准确的肝脏及肝脏肿瘤分割筛查是一个很好的解决方案。 基于飞桨PaddlePaddle框架,我使用Res-Unet网络结构在 LiTS 数据集[2]上训练了一个分割网络,最终在肝脏和肝肿瘤上分别达到了 0.92 和 0.77 的分割准确率。LiTS数据集是目前最大的开源肝脏分割数据集,其中包含130名患者的CT扫描和医生对患者肝脏及肿瘤的分割标注,下图是数据集中的一个示例: 图1 肝脏分割示例 项目在AI Studio上公开,提供包含数据集在内的完整环境,fork后可以直接运行。 https://aistudio.baidu.com/aistudio/projectdetail/250994 此外还有更适合命令行执行的Github开源项目medSeg,经过性能优化,训练及推理速度更快。 https://github.com/davidlinhl/medSeg 下载安装命令 ## CPU版本安装命令 pip install -f https://paddlepaddle.org.cn/pip/oschina/cpu paddlepaddle ## GPU版本安装命令 pip install -f https://paddlepaddle.org.cn/pip/oschina/gpu paddlepaddle-gpu 网络结构介绍 本文中主要针对项目使用的网络结构,数据预处理及增强,Loss,训练和推理步骤进行描述。 首先简单介绍项目中用到的网络结构Res-Unet。在医学影像领域,Unet[3]结构因为其网络参数规模较小,实现简单,边界分割比较准确被广泛应用。其结构如下图所示: 图2 Unet网络结构 其采用编码器-解码器结构,是一个 U 的形状,因此作者取名Unet。网络首先对输入图片进行了左边的4组卷积和下采样操作来获取图像的抽象特征,之后通过右边的对称的4组反卷积和上采样将图像放大回接近输入图像的大小。Unet的一个重要创新是在相同深度的下采样和上采样操作之间加入了跳转连接(图中横向灰色箭头所示),有效地提升了网络的分割精度。具体的实现方法一般是将左侧卷积block的输出拼接到右侧同一深度反卷积block的输入上。 这样反卷积block的输入特征图大小不变,但是厚度变成了原来的两倍。其中一半是绿色箭头代表的下层反卷积block的输入,给网络提供更抽象的高阶图像特征;另一半是灰色箭头代表的左侧卷积block的输出,给网络提供更准确的位置信息,提升边缘分割精度。 我使用的Res-Unet网络在Unet结构的基础上引入了残差连接,如下图所示。具体的做法是添加一条从两次卷积的输入到输出的连接,并做一次卷积操作。这种残差结构改善了网络的梯度流通,避免网络退化,并能加速网络收敛。 图3 残差连接 具体的网络构建代码比较复杂,这里不做详细展示,可以访问AI Studio项目或Github repo查看。 https://github.com/davidlinhl/medSeg/blob/master/medseg/models/unet.py 数据处理及增强 上述的Res-Unet结构是一个2D的分割网络,因此我们首先将LiTS数据集中3D的CT扫描分成2D的切片。CT在拍摄和重建的过程中会引入一些噪声,因此我们只保留-1024到1024范围内的数据。经过这两步处理,可以得到大概1万张CT扫描切片及对应的分割标签,随机选择一组进行可视化结果如下 图4 2D切片 在训练深度神经网络的过程中,我们通常需要在训练集上训练多个epoch以让网络达到一个比较高的训练准确率。但是这样做又容易使网络过拟合训练集,其表现为网络在训练集上准确率很高但是测试时准确率偏低。针对这个问题有多方面的解决方案,数据增强是其中重要的一种。这个项目中我们采用的数据增强策略包括随机水平、垂直翻转、随机旋转、随机尺度缩放、随机位置裁剪和弹性形变。在项目中可以看到具体代码,图5是对图4中数据进行数据增强的结果: 图5数据增强效果 CT图像和分割标签共同进行了左右翻转,逆时针15度旋转,0.8倍尺度缩放和弹性形变。虽然一些简单的数据增强步骤过后图像看起来没有很大区别,但是只要图像有变化对算法来说就是新的数据,结合Droupout、权重正则化等方法能较好地抑制网络过拟合,提升测试准确率。 开始训练前的最后一个步骤是定义损失函数。飞桨PaddlePaddle框架为开发者准备了许多Loss函数,通过几行代码就可以方便地调用。这里我们采用交叉熵和Dice Loss结合作为模型的Loss。Dice评价我们网络分割输出和数据集中的实际分割结果有多大程度的重合,是我们最终的优化目标。但是Dice Loss在训练过程中不是很稳定,不利于网络收敛,因此加入了交叉熵来稳定训练。 defcreate_loss(predict,label,num_classes=2): predict=fluid.layers.transpose(predict,perm=[0,2,3,1]) predict=fluid.layers.reshape(predict,shape=[-1,num_classes]) predict=fluid.layers.softmax(predict) label=fluid.layers.reshape(label,shape=[-1,1]) label=fluid.layers.cast(label,"int64") dice_loss=fluid.layers.dice_loss(predict,label)#计算diceloss ce_loss=fluid.layers.cross_entropy(predict,label)#计算交叉熵 returnfluid.layers.reduce_mean(ce_loss+dice_loss)#最后使用的loss是dice和交叉熵的和 模型训练 万事俱备,下面可以开始训练了。首先使用静态图API进行组网 withfluid.program_guard(train_program,train_init): #定义网络输入 image=fluid.layers.data(name="image",shape=[3,512,512],dtype="float32") label=fluid.layers.data(name="label",shape=[1,512,512],dtype="int32") #定义给网络训练提供数据的loader train_loader=fluid.io.DataLoader.from_generator( feed_list=[image,label], capacity=cfg.TRAIN.BATCH_SIZE*2, ) #创建网络 prediction=create_model(image,2) #定义Loss avg_loss=loss.create_loss(prediction,label,2) #定义正则项 decay=paddle.fluid.regularizer.L2Decay(cfg.TRAIN.REG_COEFF) #选择优化器 ifcfg.TRAIN.OPTIMIZER=="adam": optimizer=fluid.optimizer.AdamOptimizer(learning_rate=0.003,regularization=decay) optimizer.minimize(avg_loss) 之后定义读取数据的reader defdata_reader(part_start=0,part_end=8): data_names=os.listdir(preprocess_path) data_part=data_names[len(data_names)*part_start//10:len(data_names)*part_end//10]#取所有数据中80%做训练数据 random.shuffle(data_part)#打乱输入顺序 defreader(): fordata_nameindata_part: data=np.load(os.path.join(preprocess_path,data_name)) vol=data[0:3,:,:] lab=data[3,:,:] yield(vol,lab) returnreader 将数据增强操作整合进一个函数 defaug_mapper(data): vol=data[0] lab=data[1] vol,lab=aug.flip(vol,lab,cfg.AUG.FLIP.RATIO) vol,lab=aug.rotate(vol,lab,cfg.AUG.ROTATE.RANGE,cfg.AUG.ROTATE.RATIO,0) vol,lab=aug.zoom(vol,lab,cfg.AUG.ZOOM.RANGE,cfg.AUG.ZOOM.RATIO) vol,lab=aug.crop(vol,lab,cfg.AUG.CROP.SIZE,0) returnvol,lab 数据增强操作涉及旋转和弹性形变,计算比较复杂,耗时长,如果只使用单线程进行数据读取和增强会拖慢网络的训练速度。但使用飞桨PaddlePaddle框架,只需两行代码就可以将单线程reader变成多线程,大幅提升训练效率。在AI Studio的测试环境中,8线程reader让训练速度提升了7倍以上。 train_reader=fluid.io.xmap_readers(aug_mapper,data_reader(0,8),8,cfg.TRAIN.BATCH_SIZE*2) train_loader.set_sample_generator(train_reader,batch_size=cfg.TRAIN.BATCH_SIZE,places=places) 最后一步就是进行训练,以下是训练中进行前向和反向梯度传递的核心代码,其余的输出,验证等操作可以视需要添加。 step=0 forpass_idinrange(cfg.TRAIN.EPOCHS): fortrain_dataintrain_loader(): step+=1 avg_loss_value=exe.run(compiled_train_program,feed=train_data,fetch_list=[avg_loss]) print(step,avg_loss_value) LiTS数据集比较大,我们选择的Res-Unet也比较复杂,整个训练过程大概需要20个epoch,6个小时左右的时间完成。 推理预测 训练完成后保存模型,我们就可以对新的数据进行分割了。进行分割前我们同样需要将数据转化为2D切片,并保留相同的强度范围。经过网络前向处理后将数据从2D合并为原来的3D形态 segmentation=np.zeros(scan.shape) withfluid.scope_guard(inference_scope): #读取预训练权重 [inference_program,feed_target_names,fetch_targets]=fluid.io.load_inference_model(infer_param_path,infer_exe) forslice_indintqdm(range(1,scan.shape[2]-1)): #2.5D的输入,每次取出CT中3个相邻的层作为模型输入 scan_slice=scan[:,:,slice_ind-1:slice_ind+2] #添加batch_size维度 scan_slice=scan_slice[np.newaxis,:,:,:] #模型的输入是CWH的,通道在第一个维度,因此需要将数组中的第一和第三个维度互换 scan_slice=scan_slice.swapaxes(1,3) result=infer_exe.run(inference_program,feed={feed_target_names[0]:scan_slice},fetch_list=fetch_targets) result=result[0][0][1].reshape([scan.shape[0],scan.shape[1]]) #保存分割结果 segmentation[:,:,slice_ind]=result.swapaxes(0,1) #预测概率超过0.5的部分认为是前景,否则认为是背景 segmentation[segmentation>=0.5]=1 segmentation[segmentation<0.5]=0 图6分割结果 深度学习算法对一组CT扫描进行分割大概耗时15S,其效率明显高于医生阅片的效率。而且从分割结果中,我们可以计算获得肝脏体积,肿瘤数量,肿瘤体积,肝脏肿瘤负担等数量化的指标,更好地辅助医生进行诊断。 项目内容到这里就介绍完了,如果你对深度学习医疗应用感兴趣,欢迎加入 AI Studio医疗兴趣小组和更多大佬一起学习进步,QQ群号:810823161 下载安装命令 ## CPU版本安装命令 pip install -f https://paddlepaddle.org.cn/pip/oschina/cpu paddlepaddle ## GPU版本安装命令 pip install -f https://paddlepaddle.org.cn/pip/oschina/gpu paddlepaddle-gpu >>访问 PaddlePaddle 官网,了解更多相关内容。

优秀的个人博客,低调大师

SAP ABAP Netweaver容器化, 不可能完成的任务吗?

Jerry之前的文章 一个13年ABAP老兵的建议:了解这些基础知识,对ABAP开发有百利而无一害, 回顾了ABAP Netweaver服务器主要的组件。本文咱们就来聊聊ABAP Netweaver容器化这个话题。 Jerry假定阅读本文的朋友,都听说过虚拟机和容器的概念, 并且对虚拟机和容器的区别有所了解。 容器与虚拟机的出发点很类似:对应用程序及其依赖进行隔离,生成一套能够随处运行的自容纳单元;二者都能够使应用运行在一个虚拟出的抽象层里,摆脱对传统物理硬件的依赖,使得计算资源的利用更加高效,能源效率与成本效益得以提升。 容器在虚拟化程度上比虚拟机技术更进一步,摆脱了前者对Hypervisor层的依赖,直接利用宿主机的内核,抽象层比虚拟机更少,更加轻量化,同虚拟机技术相比能达到更高的物理资源利用率,因此更受当今云服务提供商的青睐。 Docker是一个开源的应用容器引擎,是当今最流行的容器技术之一。 那么SAP ABAP Netweaver,能否利用Docker引擎,让它运行在容器里呢? SAP官方的note 1122387 - Linux: SAP Support in virtualized environments给出了答案:截至2020年1月17日,答案是不支持。SAP官方不支持将ABAP应用服务器运行在容器或者容器编排环境内。比如目前业界流行的Docker和LXC,以及运行在Google Cloud Platform, Microsoft Azure, AWS上的Kubernetes Cluster,都不是SAP官方支持的能够将ABAP Netweaver服务器以容器的方式运行的平台。https://launchpad.support.sap.com/#/notes/1122387 那么在2018年5月的时候,SAP社区有一篇博客: Installing SAP NW ABAP into Dockerhttps://blogs.sap.com/2018/05/30/installing-sap-nw-abap-into-docker/ 这又是怎么一回事呢?我们可以通过阅读博客了解作者是怎么做到的。 首先,我们从SAP官网上能免费下载Netweaver的开发者试用版,ABAP版本号为7.52 SP04: https://developers.sap.com/trials-downloads.html?search=7.52%20SP04 下载到本地,得到一个rar文件,解压之后执行里面的安装文件即可把ABAP Netweaver安装到本地。 因此SAP社区上的一群ABAP爱好者们,想到了一个点子:如果把下载的Netweaver安装文件,解压之后,将其内容构建成一个Docker镜像文件,在这个Docker镜像内完成Netweaver的安装和启动工作。如此一来,岂不是达到了在容器里运行ABAP Netweaver的目的? 我们可以在这位ABAP爱好者的github仓库上找到用来制作Docker镜像的Dockerfile文件,从中了解到该容器镜像的制作过程: https://github.com/tobiashofmann/sap-nw-abap-docker/blob/master/Dockerfile 这个Dockerfile构建的镜像选择了openSUSE Leap作为母镜像,该镜像提供了ABAP Netweaver运行的Linux操作系统。 Dockerfile的第一行用FROM关键字指定了这个基准镜像的名称: 第16行用COPY将事先从SAP官网下载好的存储在宿主机NW752文件夹下的Netweaver开发者版本安装文件,拷贝到容器镜像里,然后第22行用RUN关键字运行安装脚本。 安装完毕后,执行47行的启动脚本run.sh, 这样就能在容器里启动Netweaver服务器了。 这个容器镜像制作好之后,只需要简单地使用docker run命令行,就能启动一个新的容器运行实例了。从SAP官网下载的Netweaver开发者版本,就运行在这个新启动的容器实例里。 我们回顾这种做法,发现Docker技术较之虚拟机的优点并没有体现出来,按照博客作者提供的信息,通过这种方式制作出的镜像文件的大小超过了100GB,如此巨型的镜像文件几乎无法通过Docker Hub分发给其他人,无法用于生产用途。 另一方面,通过这种容器化方式,Jerry之前文章 一个13年ABAP老兵的建议:了解这些基础知识,对ABAP开发有百利而无一害 介绍的Netweaver服务器的诸多组件,被放置到同一个容器内,无法通过简单地增加容器实例的方式,实现Netweaver处理能力的水平扩展。 正是因为意识到将Netweaver所有组件放置于同一容器镜像内这种措施无法发挥容器技术的优势,SAP Linux实验室的工程师们采取了另一种思路,即这篇SAP社区博客里给出的架构图所体现的,将Netweaver组件进行拆分,分别放置于不同的容器编排逻辑单元中。 Proof of Concept: Deploying ABAP in Kuberneteshttps://blogs.sap.com/2020/02/06/proof-of-concept-deploying-abap-in-kubernetes 上面的架构图里并没有看到容器的影子,而Jerry之前文章介绍的ASCS(ABAP SAP Central Services instances)和AS(Application Server,应用服务器),被放置到了名为Pod的逻辑单元里。 Kubernetes是容器编排和管理的平台,不直接操作容器,而是将一个或多个功能上相关的容器封装到称之为Pod的逻辑单元中,我们可以简单的把Pod理解成容器的集合。 一个SAP系统由一个ASCS实例和一个或多个AS实例构成,对于ASCS里包含的组件,比如之前介绍过的消息服务器,Enqueue服务器,Dispatcher等等,每个组件分别构建不同的容器镜像,再将这些镜像封装到一个单独的ASCS Pod里。 而ABAP Netweaver支持多AS实例部署的这种特性,恰巧能让Kubernetes原生支持的Horizontal Pod Autoscaler机制大显身手。将AS单独制作成容器镜像并放入AS Pod里,通过Kubernetes的Deployment Unit管理这些Pod,从理论上说,可以使用Kubernetes命令行进行ABAP应用服务器的水平扩展。 这种思路将ABAP Netweaver的组件分别进行容器化,大大缩小了每个组件对应的容器镜像文件的尺寸,使得应用服务器实例能够根据实际计算能力的需求变化,进行动态伸缩。如果想将这种方法应用到生产场景中,面临的一些挑战有: (1) Kubernetes对待Pod的方式是官网里所谓的Cattle-like treatment,即Kubernetes就是Pod的上帝,可以根据实际需要,随时创建新的Pod或销毁已有的Pod,而运行在Pod内的应用消费者,完全感知不到Pod的这些变化。另一方面,我们知道,运行在ABAP Netweaver上的很多应用都是有状态的事务,比如编辑一个订单之前,用户先点击编辑按钮,此时应用会往Enqueue服务器发起一个申请锁的请求,成功获取锁之后继续编辑操作。如果此时运行该事务的AS实例所在的Pod正好被Kubernetes销毁了,那该用户尚未结束的编辑操作该如何处理?再比如某个Pod内的AS实例正在运行很多后台作业,那么这种Pod可以被Kubernetes销毁么? 这种挑战简单概括起来,就是如何调和Kubernetes Pod的水平伸缩机制和ABAP Netweaver的有状态事务处理(会话一致性)的需求。 (2) 在ABAP Netweaver容器化以前,大部分组件是在同一物理网络下彼此通信。容器化之后,组件与组件之间的通信会多经过一层Kubernetes的网络层,这使得整个系统的复杂度增加。 (3) 我们知道ABAP Netweaver有很多种同第三方系统集成的途径:RFC,Web Service,OData,IDOC等等。将ABAP容器化之后,以前这些技术是否仍然可以在不需要调整Netweaver核心实现的前提下继续工作,需要进行实际的验证。 所谓No pain,no gain,付出总会有收获。如果ABAP成功容器化之后,理论上我们会享受到哪些容器技术带来的便利呢? (1) ABAP的安装和部署过程将会大大简化。假设出现了官方的ABAP容器镜像和Kubernetes Deployment文件,我们可以仅仅用几行简单的命令行,在任何支持容器和Kubernetes的平台上,轻松完成ABAP的安装和部署。 (上图来自博客:https://www.itsfullofstars.de/2017/09/dockerfile-for-sap-netweaver-abap-7-5x-developer-edition/) (2) 假设前文介绍的ABAP会话一致性的挑战已经成功解决,那么ABAP应用服务器实例的弹性伸缩,仅仅通过Kubernetes几条简单的命令行就可轻松实现。在ABAP传统部署场景下,增添新的应用服务器实例需要ABAP Basis人员进行繁琐配置的局面将不复存在。 除了在Kubernetes里通过人工敲命令行的方式调整Kubernetes的计算资源以外,Kubernetes原生就具有根据CPU或者内存的使用率,进行全自动伸缩的调整能力。这种完全无需人工界入的资源调整功能,如果能够运用到ABAP Netweaver上,无疑给我们留下了太多美好的想象空间。 SAP技术在不断向前演化,ABAP也从未停止前进的脚步,让我们活到老,学到老。感谢阅读。 本文来自云栖社区合作伙伴“汪子熙”,了解相关信息可以关注微信公众号"汪子熙"。

优秀的个人博客,低调大师

Ubuntu 20.04 LTS 开发周期的重要任务:移除 Python 2

官方已宣布 Python 2 将于 2020 年 1 月 1 日后停止维护,而计划于明年 4 月发布的 Ubuntu 20.04 将是下一个长期支持版本,所以 Ubuntu 20.04 的一个重要目标就是移除 Python 2。据 Ubuntu 开发团队介绍,目前仍有许多依赖 Python 2 的软件包保留在 Debian 测试版和 Ubuntu 的 "Focal Fossa" 中,偿还这些“债务”迫在眉睫。 Ubuntu/Debian 项目的开发者 Matthias Klose 负责为 Ubuntu 20.04 LTS 移除 Python 2,目前已经做了大量的工作。近日他在邮件列表中同步更新了一些进度,并说道 Debian 中仍然存在大约 3300 个与 Python 2 软件包相关的错误,其中大约 1500 个错误已关闭。另外,大约 350 个软件包仅在 Ubuntu 的 Focal 仓库中可用,在上游 Debian 中不可用。 所以 Matthias 认为当前的目标是将尽可能多的软件包从 Python 2 转换为 Python 3,不过这对于许多不再维护的软件包可能会成为问题。对于大多数不兼容 Python 3 的软件,如果没有人进行必要的移植,它最终将会从存档中删除。最后是一种情况更为特殊的软件,它们于Ubuntu/Debian 而言十分重要,不过仅支持 Python 2。如何处理他们?Matthias 表示目前仍未确定,但目标是在 4 月 Ubuntu 20.04 LTS 发布之前移除 Python 2。 对于决定保留基于 Python 2 的软件包的开发者,Matthias 提醒到,请确保该软件包未引用任何 python, python-dev, python-dbg, python-doc 软件包,并且不使用未加入版本控制的 python 二进制文件。这些软件包应该使用 python2, python2-dev, python2-dbg, python2-doc 来替代,并使用 python2 二进制文件。 不过看起来 Matthias 也为自己买了坑 —— 他似乎上传过适用于 Ubuntu 且仅支持Python2 软件包 ;) 最后附上一个非官方的 Python 2.7 “退休”倒计时网站:https://pythonclock.org/

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长,特征是大鼻子、头戴帽子、身穿背带裤,还留着胡子。与他的双胞胎兄弟路易基一起,长年担任任天堂的招牌角色。

Nacos

Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称,一个易于构建 AI Agent 应用的动态服务发现、配置管理和AI智能体管理平台。Nacos 致力于帮助您发现、配置和管理微服务及AI智能体应用。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据、流量管理。Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。

Rocky Linux

Rocky Linux

Rocky Linux(中文名:洛基)是由Gregory Kurtzer于2020年12月发起的企业级Linux发行版,作为CentOS稳定版停止维护后与RHEL(Red Hat Enterprise Linux)完全兼容的开源替代方案,由社区拥有并管理,支持x86_64、aarch64等架构。其通过重新编译RHEL源代码提供长期稳定性,采用模块化包装和SELinux安全架构,默认包含GNOME桌面环境及XFS文件系统,支持十年生命周期更新。

Sublime Text

Sublime Text

Sublime Text具有漂亮的用户界面和强大的功能,例如代码缩略图,Python的插件,代码段等。还可自定义键绑定,菜单和工具栏。Sublime Text 的主要功能包括:拼写检查,书签,完整的 Python API , Goto 功能,即时项目切换,多选择,多窗口等等。Sublime Text 是一个跨平台的编辑器,同时支持Windows、Linux、Mac OS X等操作系统。

用户登录
用户注册