像素

使用L8图像格式 从TouchGFX 4.12.3开始 TouchGFX 4.12现在支持L8标准图像格式格式。 与ARGB8888等相比，L8格式的图像占用较少的闪存，并且绘制速度更快。 L8格式的图像由一个调色板和一个像素阵列组成：调色板最多列出256种不同的颜色，分别以16位格式RGB565、24位格式RGB888或32位格式ARGB8888指定。 像素阵列由每个像素一个字节组成。 该字节是调色板（颜色列表）的索引，指出像素的颜色。 TouchGFX框架通过依次读取像素，查找调色板中的颜色并将其写入帧缓冲区来绘制L8图像。 这会自动发生，并由STM32 Chrom ART硬件加速器加速。 8位至今 像素表示一张L8图像可以使用256种不同的颜色。 另一个L8图像可以使用256种其他颜色，因为两个图像都有各自的调色板。 具有4 x 4像素的L8图像和具有4种颜色的调色板 像素每个为一个字节（8位）。 因此，像素的大小是宽度x高度字节。 调色板颜色可以是16位，24位或32位颜色。 因此，每个颜色定义将占用2、3或4个字节。 如果帧缓冲区是16位（RGB565格式），则纯色图像应存储在L8_RGB565中。 如果帧缓冲区是24位（RGB888），则L8图像必须以L8_RGB888格式存储。 如果图像是透明的，则必须使用32位格式（ARGB8888）： 格式 帧缓冲格式

ImageData 对象 ImageData 对象中存储着canvas对象真实的像素数据，它包含以下几个只读属性： width 图片宽度，单位是像素 height 图片高度，单位是像素 data Uint8ClampedArray 类型的一维数组，包含着RGBA格式的整型数据，范围在0至255之间（包括255）。 data属性返回一个 Uint8ClampedArray ，它可以被使用作为查看初始像素数据。每个像素用4个1bytes值(按照红，绿，蓝和透明值的顺序; 这就是"RGBA"格式) 来代表。每个颜色值部份用0至255来代表。每个部份被分配到一个在数组内连续的索引，左上角像素的红色部份在数组的索引0位置。像素从左到右被处理，然后往下，遍历整个数组。 Uint8ClampedArray 包含高度 × 宽度 × 4 bytes数据，索引值从0到( 高度 × 宽度 ×4)-1 例如，要读取图片中位于第50行，第200列的像素的蓝色部份，你会写以下代码： blueComponent = imageData.data[((50-1)*imageData.width + (200-1))*4 - 1 + 3]; 根据行、列读取某像素点的R/G/B/A值的公式： imageData.data[((行数-1)*imageData.width + (列数-1))*4 - 1 + 1/2/3

转：https://blog.csdn.net/woniuye/article/details/89218461 图像基本数据结构 要讲图片格式还先得从图像的基本数据结构说起。在计算机中, 图像是由一个个像素点组成，像素点就是颜色点，而颜色最简单的方式就是用RGB或RGBA表示, 如图所示 (图1) (图2) 如果有A通道就表明这个图像可以有透明效果。 R,G,B每个分量一般是用一个字节(8位)来表示，所以图(1)中每个像素大小就是3*8=24位图, 而图(2)中每个像素大小是4*8=32位。 这里有三点需要说明: 一、图像y方向正立或倒立 图像是二维数据，数据在内存中只能一维存储，二维转一维有不同的对应方式。比较常见的只有两种方式: 按像素“行排列”从上往下或者从下往上。 如图所示的图像有9个像素点，如果从上往下排列成一维数据是(123456789)， 如果是从下往上排列则为(789456123)。 只所以会有这种区别是因为，前一种是以计算机图形学的屏幕坐标系为参考(右上为原点,y轴向下 )，而另后一种是以标准的数学坐标系为参考(右下为原点,y轴向上)。这两个坐标系只是y值不一样，互相转换的公式为: y2 = height-1-y1 y1,y2分别为像素在两个坐标系中的y坐标，height为图像的高度。 不过好像只有bmp图片格式以及windows下的GDI，GDI

立体匹配十大概念综述—立体匹配算法介绍 来自：https://blog.csdn.net/wintergeng/article/details/51049596 一、概念 立体匹配算法主要是通过建立一个能量代价函数，通过此能量代价函数最小化来估计像素点视差值。立体匹配算法的实质就是一个最优化求解问题，通过建立合理的能量函数，增加一些约束，采用最优化理论的方法进行方程求解，这也是所有的病态问题求解方法。 二、主要立体匹配算法分类 1）根据采用图像表示的基元不同，立体匹配算法分为： A、区域立体匹配算法（可获取稠密视差图。缺点：受图像的仿射畸变和辐射畸变影响较大；像素点约束窗口的大小与形状选择比较困难，选择过大，在深度不连续处，视差图中会出现过度平滑现象；选择过小，对像素点的约束比较少，图像信息没有得到充分利用，容易产生误匹配。） B、基于特征的立体匹配算法（可获得稀疏的视差图，经差值估计可获得稠密视差图。可提取点、线、面等局部特征，也可提取多边形和图像结构等全局特征。缺点：特征提取易受遮挡、光线、重复纹理等影响较大；差值估计计算量大） C、基于相位立体匹配算法（假定在图像对应点中，其频率范围内，其局部相位是相等的，在频率范围内进行视差估计） 2）依据采用最优化理论方法的不同，立体匹配算法可以分为： A、局部的立体匹配算法 B、全局的立体匹配算法 三、匹配基元（match

译者：蓝燕子 声明：作者翻译论文仅为学习，如有侵权请联系作者删除博文，谢谢！ 摘要 目标检测和实例分割是计算机视觉的两项基本任务。它们密切相关，但他们之间的关系在以往的大多数工作中还没有得到充分的探讨。本文提出了一种新的用于交互目标检测和实例分割的深度结构RDSNet。为了回应这两个任务，我们设计了一个两个流结构以共同学习对象级别（即边界框）和像素级别（即实例掩码）上的特征。在这个结构中，来自两个流的信息是交替融合，即对象层的信息引入实例意识和翻译差异到像素级，像素级的信息-在对象级别细化对象的定位精度作为回报。具体地说，相关模块和裁剪模块被提议产生实例掩码，以及基于掩模的边界求精模块边界框。通过对COCO数据集的大量实验分析和比较，证明了该方法的有效性以及RDSNet的效率。源代码位于 https://github.com/wangsr126/RDSNet 。 1. 引言 目标检测和实例分割是计算机视觉中两个基本的、密切相关的任务论对象层次上的渐进图像理解像素级别。由于应用了deep神经网络，近年来见证了这两项任务的重大进展。然而，他们的关系但在之前的大部分工作中都进行了充分的探索。因此，通过利用交互来提高这两个任务的性能仍然是有意义和具有挑战性的在对象级和像素级信息之间。 目标检测的目标是用矩形边界框并将其分类为特定类别。在这项任务中，最关键的挑战之一在于对象定位

见解： ------> https://blog.csdn.net/zhaokaiqiang1992/article/details/45419023 ;这一篇网文内容详尽 对于鸿洋的百分比适配，由于目前无法覆盖所有分辨率，对于现在也没有全备的测试，问题可能会比较多，所以目前不采用。如果使用，需要进一步注意的是，对于有虚拟按键的手机，需要在该分辨率下，还需要创建一套除去NavigationBar高度后分辨率的适配方案。比如1920 x 1080 的手机，虚拟按键高度为170px。针对该款手机，既要创建values-1920x1080 ，还需要创建values-1750x1080。 针对目前的开发进行适配，做好网文中主要介绍的内容即可。以下内容方便查阅，直接粘贴出来： 屏幕尺寸 屏幕尺寸指屏幕的对角线的长度，单位是英寸，1英寸=2.54厘米 比如常见的屏幕尺寸有2.4、2.8、3.5、3.7、4.2、5.0、5.5、6.0等 屏幕分辨率 屏幕分辨率是指在横纵向上的像素点数，单位是px，1px=1个像素点。一般以纵向像素*横向像素，如1960*1080。 屏幕像素密度 屏幕像素密度是指每英寸上的像素点数，单位是dpi，即“dot per inch”的缩写。屏幕像素密度与屏幕尺寸和屏幕分辨率有关，在单一变化条件下，屏幕尺寸越小、分辨率越高，像素密度越大，反之越小。 dp、dip、dpi

1.像素 老子曾说“天下难事必作于易，天下大事必作于细”，Android开发也是一样，再复杂的App也无非就是数百万个像素点的排列组合。像素虽然看似简单，但是里面大有学问。如果在开发时对像素单位不以为然仅仅一根筋的填数字，最后在模拟器上取得很好效果的界面在真机上也可能东倒西歪，这就是没打好基础的缘故。接下来通过介绍像素的基本概念及单位间的相互转化来进一步理解像素。 Android支持的像素单位有px、in、mm、dp、sp等。其中，px是手机屏幕上可显示的最小的单位，它与物理设备的显示屏有关。dp与物理设备无关，只与屏幕的尺寸有关，一般来说，同样尺寸的屏幕以dp计算的分辨率是一样的。sp的原理跟dp差不多，专门用于设置字体大小，通过sp设置的字体可以在系统设置字体大小（小、普通、大、超大）时有不同的显示效果。 dp和px的联系取决于具体设备上的像素密度，像素密度就是DisplayMetries里的density参数，当density=1.0时代表1dp=1px，当density=1.5时代表2dp=3px。具体的转换函数如下： //根据手机的分辨率从dp单位转换成px单位 public static int dip2px(Context context,float dpValue){ //获取当前手机的像素密度 final float scale=context

这几天刚刚接触了新的项目，做一个android客户端。本周的工作是完成客户端的UI界面和功能实现，但是对于Android开发最头疼的部分，即是对于纷杂的屏幕做适配的工作现在来说是最棘手的！ 图像显示所需的概念: 像素: 一幅图片的显示就是由许多显示着不同颜色的小方格组成的,这样的小方格就被称为像素，是构成图片的最小单位.但是这个像素的具体大小是多少呢?这需要取决于显示这张图片的具体的物理设备显示一个图片像素点的荧光点的大小.图片文件只是记录着它自身有多少个像素点,每个像素点显示什么颜色,至于它自身物理尺寸有多大,它自身也无法得知,例如一张480*800像素的图片在电脑显示器上显示明显要比在手机屏幕上显示大很多,而这张图片本身并没有改变.只是手机的屏比电脑显示器的屏要精细许多,也就是每一个物理像素点要小许多,密度也就大许多. 分辨率: 分为“图像分辨率”与“物理显示分辨率”。它们都是水平像素点数与垂直像素点数的乘积,也就是像素总和数。图像分辨率是指图片文件记录着自身所有的像素数。物理显示分辨率是指物理显示屏水平与垂直能显示的像素数的乘积.有的人说分辨率越高,显示的图片就越清晰,这点是针对物理尺寸相同的情况而言,因为一样的分辨率有可能尺寸可能不一样大,这样光就分辨率来比较清晰度没有可比性. 密度: 就是物理设备上单位尺寸里的像素数,当然是密度越大图片显示就越清晰了.

移动端适配，是我们在开发中经常会遇到的，这里面可能会遇到非常多的问题： 1px问题 UI图完美适配方案 iPhoneX适配方案 横屏适配 高清屏图片模糊问题 ... 上面这些问题可能我们在开发中已经知道如何解决，但是问题产生的原理，以及解决方案的原理可能会模糊不清。在解决这些问题的过程中，我们往往会遇到非常多的概念：像素、分辨率、PPI、DPI、DP、DIP、DPR、视口等等。 本文将从移动端适配的基础概念出发，探究移动端适配各种问题的解决方案和实现原理。 一、英寸 一般用英寸描述屏幕的物理大小，如电脑显示器的17、22，手机显示器的4.8、5.7等使用的单位都是英寸。 英寸和厘米的换算：1英寸 = 2.54 厘米 二、物理像素 2.1 像素 像素即一个小方块，它具有特定的位置和颜色。 图片、电子屏幕（手机、电脑）就是由无数个具有特定颜色和特定位置的小方块拼接而成。 像素可以作为图片或电子屏幕的最小组成单位。 2.2 物理像素 到电商网站购买手机，都会看一看手机的参数，以apple的官网上对手机分辨率的描述为例： iPhone XS Max 和 iPhone SE的分辨率分别为2688 x 1242和1136 x 640。表示手机分别在垂直和水平上所具有的像素点数。 这里描述的就是屏幕实际的物理像素，即一个屏幕具体由多少个像素点组成。 屏幕从工厂出来那天起

题目 对于计算机而言，颜色不过是像素点对应的一个 24 位的数值。现给定一幅分辨率为 M×N 的画，要求你找出万绿丛中的一点红，即有独一无二颜色的那个像素点，并且该点的颜色与其周围 8 个相邻像素的颜色差充分大。 输入格式： 输入第一行给出三个正整数，分别是 M 和 N（≤ 1000），即图像的分辨率；以及 TOL，是所求像素点与相邻点的颜色差阈值，色差超过 TOL 的点才被考虑。随后 N 行，每行给出 M 个像素的颜色值，范围在 [0,224) 内。所有同行数字间用空格或 TAB 分开。 输出格式： 在一行中按照 (x, y): color 的格式输出所求像素点的位置以及颜色值，其中位置 x 和 y 分别是该像素在图像矩阵中的列、行编号（从 1 开始编号）。如果这样的点不唯一，则输出 Not Unique；如果这样的点不存在，则输出 Not Exist。 输入样例 1： 8 6 200 0 0 0 0 0 0 0 0 65280 65280 65280 16711479 65280 65280 65280 65280 16711479 65280 65280 65280 16711680 65280 65280 65280 65280 65280 65280 65280 65280 65280 165280 165280 65280 65280 16777015 65280