surface

介绍 华为机器学习（ML Kit）提供手部关键点识别服务，可用于手语识别。手部关键点识别服务能识别手部21个关键点，通过每个手指的方向和手语规则作比较去找手语字母表。 应用场景 手语通常被听力和口语有障碍的人来使用，是收集手势包含日常互动中所使用的动作和手势。 使用ML Kit 可以建立一个智能手语字母表识别器，它可以像一个辅助器一样将手势翻译成单词或者句子，也可以将单词或者句子翻译成手势。 这里尝试的是手势当中的美国手语字母表，是基于关节，手指和手腕的位置进行分类。接下来小编将会尝试从手势中收集单词“HELLO”。 开发步骤 1. 准备 详细的准备步骤可以参考华为开发者联盟： https://developer.huawei.com/consumer/cn/doc/development/HMS-Guides/ml-process-4 这里列举关键的开发步骤。 1.1 启动ML Kit 在华为开发者AppGallery Connect, 选择 Develop > Manage APIs 。确保ML Kit 激活。 1.2 项目级gradle里配置Maven仓地址 buildscript { repositories { ... maven {url 'https://developer.huawei.com/repo/'} } } dependencies { ...

据媒体披露信息指微软正联合一家芯片企业合作开发一款ARM架构的服务器芯片，甚至可能会为surface开发一款ARM架构处理器，作为wintel联盟的关键成员，它如此做似乎已决心与Intel分手。 在PC时代，微软持续升级Windows系统，对硬件资源的需求不断提高；Intel则不断提升处理器的性能，两者合作无间奠定了它们在互联网时代的龙头地位。 然而到了移动互联网时代，Intel却未能有所建树。在手机和平板电脑上占据垄断地位的是ARM，而iOS和Android则在移动操作系统市场占据主导地位，这自然引发了微软的不满，为了在移动互联网市场打开局面，微软开始逐渐拥抱ARM。 微软先是自行开发了ARM架构的surface，不过并未取得成功；后来又与高通合作开发了骁龙本，可惜的是依然未能获得市场的认可，但是这一切动作都显示出它正向ARM阵营倾斜，希望在移动市场取得立足之地。 屡经挫折的微软如今意图联合芯片企业开发用于云服务的ARM架构服务器芯片，这无疑将侵蚀Intel视为核心业务的服务器芯片业务。Intel在服务器芯片市场占有近97%的市场份额，ARM阵营屡屡试探都未能打破局面，不过随着亚马逊、谷歌开发用于云计算或AI的ARM架构芯片，ARM阵营正慢慢从Intel垄断的服务器芯片市场撕开裂缝，如今微软再加入将这道裂缝进一步扩大，无疑给Intel一记重拳。

　　对于做海洋数据处理的同学，会经常遇到nc格式的文件，nc文件的格式全称是NetCDF，具体的详细解释请查询官网【https://www.unidata.ucar.edu/software/netcdf/docs/index.html】，一般从全球大洋数据库里面下载的温盐、风场及云量等数据，基本上是nc文件格式，每一个文件里面包含多个数据集，例如最简单的海面表温数据（ Sea surface temperature data），数据范围是全球，空间分辨率为 0.25 *0.25(~25km)，时间分辨率为3 hour，所以一天的观测数据里面包含着两个子数据集（subDataset），一是海洋表温数据集，另一个是遗失数据说明信息数据集，在第一个子数据集（海洋表温数据集）内，又会包含分层数据，也就是每隔3个小时时间分辨率下的表温数据。 　　基于前期查询李民录老师的《GDAL源码剖析与开发指南》一书才了解到，GDAL库本身是支持上述文件的读取的，故编译GDAL库（2.3.2版本），编译器采用MSVC2017版本，开发平台采用QT 5.11.2版本，由于QT本身不具有MSVC编译器配套的调试器，所以去微软官网下载了相应的调试器（winsdksetup.exe，安装的时候只选择安装Debugging Tools for Windows即可）；经过查找GDAL官网的资料

Python实战社群 Java实战社群 长按识别下方二维码， 按需求添加 扫码关注添加客服 进Python社群▲ 扫码关注添加客服 进Java社群 ▲ 作者 | 派大星星星星 来源 | 掘金，点击阅读原文查看作者更多文章 https://juejin.cn/post/6897134377202499598 现如今随着 Flutter 的应用越来越广泛，纯 Flutter 项目也越来越多，本篇内容主要分享的是 Flutter 移动端（iOS + Android）的屏幕采集的实现。 概述 在视频会议、线上课堂、游戏直播等场景，屏幕共享是一个最常见的功能。屏幕共享就是对屏幕画面的实时共享，端到端主要有几个步骤：录屏采集、视频编码及封装、实时传输、视频解封装及解码、视频渲染。 一般来说，实时屏幕共享时，共享发起端以固定采样频率（一般 8 - 15帧足够）抓取到屏幕中指定源的画面（包括指定屏幕、指定区域、指定程序等），经过视频编码压缩（应选择保持文本/图形边缘信息不失真的方案）后，在实时网络上以相应的帧率分发。 因此，屏幕采集是实现实时屏幕共享的基础，它的应用场景也是非常广泛的。 实现 准备 首先我们看看原生系统提供了哪些能力来进行屏幕录制。 iOS 11.0 提供了 ReplayKit 2 用于采集跨 App 的全局屏幕内容，但仅能通过控制中心启动；iOS 12.0 则在此基础上提供了从

等离子体元分析用于同时测定斯托克斯参数 摘要： 测量光的偏振态是一个固有的难题，因为正交偏振态之间的相位信息在检测过程中往往会丢失。 在本文中，我们提出了在适当设计的相位梯度双折射元表面上，归一化斯托克斯参数与衍射对比的等价性，并引入了全极化双折射元的概念。 元网格由三个交织的元表面组成，通过同时进行(即 (平行)相应衍射强度的测量，可以立即揭示被测偏振态的斯托克斯参数。 基于800 nm波长反射的等离子体元表面，我们设计并实现了相梯度双折射元表面和相应的元配准，而所制备组件的实验表征令人信服地展示了预期的功能。 我们预见在任何感兴趣的频率范围内，在紧凑的偏振设置中使用元agrating. 1. 介绍 测量光的偏振态是一个固有的难题，因为正交偏振态之间的相位信息在检测过程中往往会丢失。因此，确定偏振通常需要一系列测量， 在探测器前连续放置适当排列的偏振器 ，从而最终获得与椭圆偏振参数类似的 斯托克斯参数 ，充分描述偏振状态。 作为一种一次性测量偏振状态的方法，通过将入射光束分成几束，并使用多个偏振镜和探测器，可以使测量过程并行化，（虽然这种方法增加了光学系统的尺寸和复杂性）。 尽管在确定偏振方面存在诸多不便，但在大多数应用中，知道这个参数是至关重要的，因为光与物质的相互作用通常依赖于偏振。作为典型的例子，我们提到了平面波在材料界面的反射和传输，在这些界面中，正交极化的菲涅耳系数不同

一、功耗：CPU的“人体极限” 程序的 CPU 执行时间 = 指令数×CPI×Clock Cycle Time CPI和指令数都不太容易，越是研发CPU的硬件工程师们就从COU主频下手 1、为什么奔腾 4 的主频没能超过 3.8GHz 的障碍呢？ 是因为功耗，我们的CPU，一般都被叫做超大规模集成电路，这些电路，实际上都是一个个晶体管组合而成的，CPU在计算、其实就是让晶体管里面的开关不断地区“打开”和“关闭”，来组合完成各种运算和功能 要想计算得快，一方面，我们要在CPU里，同样的面积里面，多方一些晶体管，也就是增加密度； 另一方面，我们让晶体管“打开”和“关闭”的更快一点，也就是提升主频，而这两者都会增加功耗，带来耗电和散热的问题 2、CPU和工厂的故事 你可以把CPU想象成一个 巨大的工厂 、里面有 很多工人，相当于CPU上面的晶体管 。互相之间协同工作，为了工作的快一点，我们在工厂里多塞一点人，你可能会问，为什么不把工厂造的大一点呢？ 1、为什么不把工厂造的大一点呢？ 这是因为，人和人之间如果离得远了，互相之间走过去需要花的时间就会变长也会导致性能下降， 这就好像如果CPU的面积大，晶体管之间的距离会变大，电信号传输的时间就会变长，运算速度自然就慢了 2、要是太热工厂里的人会中暑、cpu会出错或崩溃 除了堵塞一点人，我们还希望每个人的动作都快一点

解决微软surface pro在某些情况下wifi转输速度过慢的问题 - z 参考文章： （1）解决微软surface pro在某些情况下wifi转输速度过慢的问题 - z （2）https://www.cnblogs.com/EasyLive2006/p/8509348.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/u/4437884/blog/4727507

[译]Vulkan教程(20)重建交换链 Swap chain recreation 重建交换链 Introduction 入门 The application we have now successfully draws a triangle, but there are some circumstances that it isn't handling properly yet. It is possible for the window surface to change such that the swap chain is no longer compatible with it. One of the reasons that could cause this to happen is the size of the window changing. We have to catch these events and recreate the swap chain. 我们现在的程序成功地绘制了一个三角形，但是有的情况它处理的不合适。窗口surface可能改变，使得交换链不再与之兼容。可能的原因之一是，窗口的大小改变了。我们必须捕捉这些事件，并重建交换链。 Recreating the swap chain 重建交换链 Create a new

一、背景 Android对OpenGL这块封装是非常好的，也是非常隐蔽的，一般使用者直接使用GLSurfaceView即可达到需求。最近项目中将很多功能下层到c++层，这样必须对OpenGL 底层逻辑有所了解。Android虽然提供OpenGL 各个版本的So库，但是并没有对底层api做封装，所以如果是自己想用C++写OpenGL，最好的方式学习Android源码。 二、GLSurfaceView如何使用 在分析GLSurfaceView源码之前我们非常有必要介绍一下GLSurfaceView的使用方法： surfaceView = findViewById(R.id.triangle_api_surfaceView) surfaceView.setEGLContextClientVersion(3) surfaceView.setRenderer(object : GLSurfaceView.Renderer { /** * Called when the surface is created or recreated. * * * Called when the rendering thread * starts and whenever the EGL context is lost. The EGL context will typically * be lost when