weixin_42754237的博客

最近做了一个很有意思的工作，可以总结为使用自然语言描述的目标的目标检测。预期使用场景是视频理解，语义检索这一类的场景。传统的目标检测技术，大概可以归纳为，采集数据、标注目标类别和位置，训练，测试使用。这里的主要问题是很多带标注的数据成本很贵，而且很多应用中的目标类别其实挺少见的。学术上的说法是分布成长尾形态(LongTail)，顺带专门有一帮学者搞零样本、少样本的检测。两年前，大家的做法是弄一个query(输入图像)，再指定一个suport(要检索目标的图像，模板图像)，让后通过同样的网络生成两个不

学习一些图像生成领域东西,加油!!素描线稿生成看过两个demo,一个是清华搞得APDrawingGAN,专门用于人脸图片的线稿生成,用的是GAN,还用了人脸区域分割(感觉这里要复杂好多,没有CNN重头怼到尾的感觉).目前只支持人脸,实际使用需要配合人体分割一起使用.github:https://github.com/yiranran/APDrawingGAN2效果:另外一个项目是公众号的推文,一个老外用fastai搞得ArtLine,用的是UNet结构,可以生成整体漫画线稿图,感觉这个会

Device类实例化采用工厂模式进行，由于Device类有很多子类，所以DeviceFactory也派生出对应设备的工厂类( ThreadPoolDeviceFactory，GPUCompatibleCPUDeviceFactory，dengBaseGPUDeviceFactory，XlaCpuDeviceFactory，XlaGpuDeviceFactory等 )。//设备工厂抽象类，定义了几个静态变量和，虚函数接口class DeviceFactory { public: virtua

DeviceMgr类是设备管理器的抽象，以向量的方式存储设备指针，提供查找设备、输出设备参数怒相关方法，主要用于会话、汇合点和进程之间通信等场合。//设备管理类class DeviceMgr { public: //输入一个包含设备对象指针的列表，初始化DeviceMgr explicit DeviceMgr(std::vector<std::unique_ptr<Device>> devices); //输入单个设备指针，初始化DeviceMgr ex

DeviceContext是非CPU设备执行计算操作的核心类，重点提供了stream虚函数、以及张量拷贝相关函数。并且根据不同设备进一步派生出不同的设备上下文类（GPUDeviceContext、SYCLDeviceContext、XlaDeviceContext）。与CPU设备不同 GPU设备(SYCL/XLA/RPC也一样)，设备在执行具体计算任务时并不是给Eigen底层计算的，而是由设备底层接口计算的(例如cuda)，当计算较多时，不同节点的与底层设备的交互并不是直接调用相关接口，而是通过传入执行

Env类是tensorflow访问系统函数的接口，主要包含了大部分系统操作函数的封装。整体上Env类提供了统一的接口（大量虚函数），但不能直接实例化，需要调用在不同系统上的子类实例化。class Env 定义在tensorflow/core/platform/env.h中，部分函数定义在同目录下的env.cc中，另外一部分在tensorflow/core/platform中不同平台（posix、windows、hadoop等有不同）目录下的env.cc中。即tensorflow在编译时，会指定编译哪个平

RemoteDevice类为Device子类，专门针对远程设备提供接口。远程设备与本地的通信主要通过RPC服务进行的。对于本地进程来说，RemoteDevice类提供了与Device类一致的接口，但在底层运算上，通过RPC通道传输操作指令与数据。RemoteDevice类定义在tensorflow/core/distributed_runtime/remote_device.cc中，注意不是在头文件里，其头文件中定义了两个创建RemoteDevice实例的函数:typedef std::funct

代码研读 Tensor类Tensor类定义在tensorflow/core/framework/tensor.h中Tensor定义了以下几个构造函数

LocalDevice类根据底层执行具体计算设备的不同，可以进一步派生子类：SYCLDevice(异构)、BaseGPUDevice(Cuda显卡)、ThreadPoolDevice(CPU设备)、XlaDevice(支持xla的设备？)。其中ThreadPoolDevice是针对CPU设备的类，主要重写了allocator与张量拷贝创建相关操作，其下还有GPUCompatibleCPUDevice的子类，主要用于GPU兼容CPU的设备（配有GPU的PC？），BaseGPUDevice针..

Device类定义在tensorflow/core/common_runtime/device.h中，主要定义了设备设备属性、设备名称、设备管理器等成员变量，以及相关的成员函数。Device类继承DeviceBase类，DeviceBase类定义在tensorflow/core/framework/device_base.h中，DeviceBase是一个抽象类，主要定义系统环境对象、CPU线程池、GPU设备信息等底层信息。Device类在实际应用中还派生多种具体细化的子类，例如LocalDevice,Rem

Tensor类中包含了两个核心成员变量 TensorShape shape_;TensorBuffer* buf_;其中TensorBuffer类型变量定义在tensor.h文件中,继承RefCounted类.RefCounted类是一个引用计数器类.class RefCounted { public: // Initial reference count is one. RefCounted();//引用计数器类,引用计数初始化为1 // Increments refere

在Tensor类中核心为 TensorShape shape_与TensorBuffer* buf_两个变量.其中TensorShape类继承与TensorShapeBase<TensorShape> 这个是一个模板类,而TensorShapeBase类继承与TensorShapeRep类.TensorShapeRep是TensorShape的爷爷,TensorShapeBase是TensorShape的爸爸.....其中爷爷类TensorShapeRep(tensor_shape.h)

       目前darknet框架下的模型训练都是在C环境下训练的，难免较为晦涩，如果能将模型转换到Tensorflow环境下完成模型的训练，在将训练好的权重转为Darknet可以识别的权重部署到实际应用中。这样就可以将算法的训练和实际部署分开！1、将Darknet框架下的.cfg与.weights 转为Tensorflow框架下的.cpkt模型先clone这个项目，用于darknet模...

yolo3-tiny是yolo3的简化版本，主要区别为、主干网络采用一个7层conv+max网络提取特征（和darknet19类似），嫁接网络采用的是13*13、26*26的分辨率探测网络，结构如下。yolo3-tiny的优点主要是，网络简单，计算量较小，可以在移动端或设备端运行。缺点为精度也比较低（候选框和分类精度都比较低） 探测精度低一个很重要的原因是tiny的主干网络比较浅（7层...

 背景说明：Darknet是一个完全开源的深度学习框架，完全由C语言实现！原作者在实现时是在Linux环境完成开发调试的，因此很多嵌入式终端可以很方便的移植Darknet的深度模型。大部分深度学习框架都可以分为模型的训练与应用两部分。训练一般需要使用GPU加速，需要大型工作站跑模型。应用部分则只需要模型加载预测就好了，这一部分可以单独在小本本上开发就好了（很多Darknet开发是针对嵌入式设备...

cfg文件是darknet中描述网络结构的文件，和caffe的prototxt类似。在darknet框架下cfg中一般先以[net]或[network]开头，描述网络的整体参数，然后接着各层参数的描述，查看string_to_layer_type()函数，一共包括以下层结构：[shortcut],[crop],[cost],[detection],[region],[yolo],[iseg],...

之前研究了Yolo3网络结构，论文中没有写具体架构，跟着作者的代码把网络结构给扒出来了，如下图所示，主干网络是论文中提到的Darknet53网络，然后在主干网上嫁接出三个分辨率的探测网络。Darknet53网络原来是作为分类网络训练的，在Yolo3的架构中主要用于提取特征，后面3个分辨率的嫁接网络则在Darknet53提取的特征上进一步探测每个cell中包含目标的可能性、置信度、类别等信息，三个分...