【论文阅读笔记】Large-scale Video Classification with Convolutional Neural Networks

  • 论文贡献:

1.采用多种方法扩展CNN到视频识别,并用Sports-1M数据集进行验证和测试。

2.提出了将输入处理为低分辨率流和高分辨率流的方法,在不影响精确度的前提下显著减少了CNN的训练时间。

3.验证模型能够扩展到UCF101数据集上,且显著提升了精确率。

  • 时间信息融合模型:

a)单帧模型(Single-frame):用于得到静态图像对视频分类的贡献。CNN结构:C(96,11,3)-N-P-C(256,5,1)-N-P-C(384,3,1)-C(384,3,1)-C(256,3,1)-P-FC(4096)-FC(4096)。C(d,f,s)中d代表卷积核个数,f代表卷积核大小f X f,s代表步长。N代表normalization layers,P代表池化层,参数均为2 X 2。分类器为softmax。

b)后期融合模型(Late Fusion):模型中包含两个单帧模型,参数共享。两个模型的输入使间隔为15的两帧,通过卷积层后对两个模型的输出使用两个全连接层进行融合。单帧模型无法检测到运动信息,但是通过第一个卷积层能够得到全局运动特征。

c)早期融合模型(Early Fusion):通过整个时间窗即时得到像素级的组合信息。修改单帧模型的第一层卷积核为11X11X3XT,T表示时间范围参数,本文中使用T=10或者1/3秒左右。像素数据的早期连接融合使网络能够精确地检测到局部物体的运动方向和速度。

d)慢融合(Slow Fusion):该模型是上述两个的模型的中和。模型高层能够逐步得到更多时间和空间信息。第一层卷积核的T=4,clip为10帧,步长为2。第二和第三卷积层T=2,步长为2。

                                  

  • 加速CNN:

Fovea and context streams:将178X178的图像整体缩小为89X89,以及截取中间89X89的原图像,分别输入到CNN。如下图所示,可以提速并且不影响模型准确率。

                                       

  • 结果:

 

 

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Contents Preface xi Acknowledgments xvii 1 Introduction 1 1.1 What is Software Architecture 1 1.1.1 What software architecture is not 4 1.1.2 Attributes of software architecture 5 1.1.3 Definitions of other key architecture-related terms 7 1.1.4 Other types of architectures 8 1.2 Why Architect? 10 1.3 Architectural Viewpoint Summary 12 1.4 Other Software Architecture Approaches 16 1.4.1 The 4+1 Views 16 1.4.2 RM-ODP viewpoints 17 1.4.3 Bass architectural structures 1.4.4 Hofmeister software architecture views 1.5 Recommended Reading 2 RolesoftheSoftwareArchitect 21 2.1 Relationship to other key roles in development organization 25 Role: project management 25 Role: development team managers 25 Role: system architect/chief engineer 26 Role: chief software engineer 26 Role: hardware architect 27 Role: network architect 27 19 19 19 Role: technical leads of each release 28 Role: data architect 28 Role: systems engineering leads 28 Role: software systems engineering lead 29 2.2 Skills and Background for the Architect 29 2.3 Injecting Architecture Experience 31 2.4 Structuring the Architecture Team 32 2.5 Traps and Pitfalls Associated with the Role of Software Architect 33 2.5.1 Clear definition of leadership 34 2.5.2 Reporting structure for the software architect 34 2.5.3 Geographical location of software architect and technical leads 35 2.5.4 Architecture team size and composition 36 2.5.5 Software architect lifecycle participation 36 2.6 Recommended Reading 37 3 SoftwareArchitectureandtheDevelopment Process 39 3.1 Overview of Iterative Development 39 3.1.1 Overall process phases 40 3.1.2 Lifecycle stages 41 3.1.3 Architecture and agile processes 43 3.1.4 Start early, refine constantly 47 3.2 Requirements Management 48 3.2.1 Use cases and requirements engineering 48 3.2.2 Additional requirements that impact architecture 49 3.2.3 Requirements tracing 49 3.3 Management of the Technology Roadmap 50 3.3.1 External software products 50 3.3.2 Software technology management traps and pitfalls 53 3.3.3 Organizational technology roadmap 54 3.4 Effective Technical Meetings 55 3.4.1 Informal technical meetings 55 3.4.2 Peer reviews and inspections 56 3.4.3 Design reviews 57 3.4.4 Design communication meetings 57 3.4.5 Management meetings 57 3.4.6 Vendor presentations 58 3.4.7 Distributed technical meetings 58 3.5 Traps and Pitfalls of the Software Architecture Process Activities 59 The out-of-touch architect 59 Analysis paralysis 60 Design for reuse 60 Use cases 60 Schedule 60 3.6 Computer-Aided Software Engineering (CASE) Tools 61 3.7 Recommended Reading 62 vi Contents 4 ExampleSystemOverview 63 4.1 System Overview 64 4.2 Overview of System Interfaces 64 4.3 Constraints 67 4.4 Major Operational Requirements and Software Requirements 67 5 UMLQuickTour 69 5.1 UML Diagram Summary 69 5.2 General Diagramming Conventions 72 5.2.1 General UML features: stereotypes, tagged values, multi-instance 73 5.2.2 View labels 74 5.3 The Diagrams 75 5.3.1 Component instance diagrams 75 5.3.2 Class and subsystem diagrams 76 5.3.3 Interaction (sequence and collaboration) diagrams 77 5.3.4 Deployment diagrams 79 5.3.5 Statechart diagrams 80 5.3.6 Activity diagrams 81 5.4 Managing Complexity 81 5.4.1 Use Case focused modeling 82 5.4.2 Element focused modeling 82 5.4.3 Level of detail 83 5.4.4 Controlling the number of models 83 5.4.5 Use Supplemental Textural Information 85 5.5 Recommended Reading 85 6 SystemContext andDomainAnalysis 87 6.1 Conceptual Diagrams 87 6.2 Context Viewpoint 89 6.3 Domain Analysis Techniques 94 6.3.1 A formal analysis technique 95 6.3.2 Other techniques for finding domain entities 98 6.3.3 Analysis shortcuts 100 6.4 Analysis Viewpoints 101 6.4.1 Analysis Interaction Viewpoint 101 6.4.2 Analysis Focused Viewpoint 103 6.4.3 Analysis Overall Viewpoint 105 6.4.4 Candidate subsystem identification 107 6.5 Recommended Reading 108 7 Component DesignandModeling 111 7.1 Overview 111 7.1.1 Component-based development 111 7.1.2 Terminology 112 7.1.3 Communication and interfaces 115 7.1.4 Finding components 115 7.1.5 Qualities of component design 116 Contents vii 7.2 Component Viewpoint 116 7.2.1 Component communication 117 7.2.2 Component interfaces 118 7.2.3 Message-based component modeling 121 7.2.4 Combining interfaces and messaging 124 7.2.5 Comparison of interfaces and messaging 127 7.2.6 Mechanism and performance annotations 128 7.3 Component Interaction Viewpoint 131 7.3.1 Component to Component Interactions 131 7.4 Component State Modeling 133 7.5 Modeling Highly Configurable Component Architectures 137 7.6 Recommended Reading 137 8 SubsystemDesign 139 8.1 Terminology 139 8.2 Modeling Subsystems, Interfaces, and Layers 141 8.2.1 Subsystem Interface Dependency Viewpoint 141 8.2.2 Enhancing the Subsystem Dependency Views with layers 8.2.3 Top-level Dependencies 144 8.2.4 The Layered Subsystem Viewpoint 146 8.3 Mapping Subsystems and Layers to Implementation 151 8.3.1 Subsystems, layers, and build trees 151 8.3.2 Subsystems and components 8.4 Recommended Reading 154 9 TransactionandDataDesign 155 9.1 Logical Data Architecture 155 9.1.1 Logical data model stability 157 9.1.2 Effects of the stable logical data model 158 9.2 Logical Data Viewpoint 159 9.2.1 Logical Data View example 160 9.2.2 Logical Data View for messaging 9.3 Data Model Design – Other Considerations 9.3.1 Data models and layers 164 9.3.2 Data models and reflection 165 9.3.3 Mapping objects to relational database 166 9.4 Transaction Design 169 9.4.1 Transaction concepts 170 9.4.2 Modeling transaction dynamics 171 9.4.3 Transactions and interface design 173 9.5 Recommended Reading 174 10ProcessandDeployment Design 177 10.1 Physical Data Viewpoint 178 10.1.1 Modeling other storage attributes 179 10.1.2 Detailed physical storage modeling 181 10.2 Process Viewpoint 183 viii Contents 16 153 3 16 143 3 TEAMFLY Team-Fly ? 10.2.1 Processes and components 186 10.2.2 Process and component management 186 10.2.3 Process State Viewpoint 189 10.3 Deployment Viewpoint 193 10.3.1 Scalable node design 194 10.3.2 Backup/archive design 199 10.4 Recommended Reading 199 11ArchitectureTechniques 201 11.1 Architecture Development Techniques 201 11.1.1 Commonality and variability analysis 202 11.1.2 Design for change 203 11.1.3 Generative programming techniques 204 11.1.4 Building a skeleton system 205 11.1.5 Prototyping 206 11.1.6 Interface development – Design by Contract 206 11.1.7 Architectural description languages 208 11.1.8 Architecture evaluation 208 11.2 Software Partitioning Strategies – Separation of Concerns 208 11.2.1 Functional decomposition 209 11.2.2 Isolate donfiguration data 210 11.2.3 Isolate hardware-specific components 210 11.2.4 Isolate time-critical components 211 11.2.5 Separate domain implementation model from human interface 211 11.2.6 Separate domain implementation model from implementation technology 211 11.2.7 Separate main function from monitoring 212 11.2.8 Separate fault recovery processing 212 11.2.9 Adaptation of external interfaces 213 11.3 Software Changeability and Dependency Management 213 11.3.1 The stable dependencies principle (SDP) 214 11.3.2 Acyclic dependencies principle 215 11.3.3 Interface Separation Principle 216 11.4 Using Architectural Patterns 216 11.5 Integration Strategies 218 11.5.1 Data-only integration 219 11.5.2 Executable integration 220 11.6 Establishing Architecture to Support Development 221 11.6.1 Configuration and change management 221 11.6.2 Build management 222 11.6.3 Continuous integration 222 11.6.4 Anticipate multi-language development 223 11.6.5 Anticipate tactical development (scripting) 224 11.7 Recommended Reading 225 12ApplyingtheViewpoints 227 12.1 Bottom-Up Architecture Development 227 12.2 Top-Down Architecture Development 229 Contents ix 12.3 Message Protocol and Interface Development 231 12.4 Reengineering Existing Systems 233 12.5 Documenting the Architecture 233 12.6 Conclusions 235 12.6.1 Becoming an architect 235 12.6.2 State of the Practice 237 12.6.3 Looking forward 238 12.6.4 Final thoughts 240 12.7 Recommended Reading 241 Appendix:SummaryofArchitectural Viewpoints 243 Bibliography 251 Index 257

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值