图像像素

原文：http://www.cnblogs.com/chris-oil/p/5367106.html 初涉移动端设计和开发的同学们，基本都会在尺寸问题上纠结好一阵子才能摸到头绪。我也花了很长时间才弄明白，感觉有必要写一篇足够通俗易懂的教程来帮助大家。从原理说起，理清关于尺寸的所有细节。由于是写给初学者的，所以不要嫌我啰嗦。 现象 首先说现象，大家都知道移动端设备屏幕尺寸非常多，碎片化严重。尤其是Android，你会听到很多种分辨率：480x800, 480x854, 540x960, 720x1280, 1080x1920，而且还有传说中的2K屏。近年来iPhone的碎片化也加剧了：640x960, 640x1136, 750x1334, 1242x2208。 不要被这些尺寸吓倒。实际上大部分的app和移动端网页，在各种尺寸的屏幕上都能正常显示。说明尺寸的问题一定有解决方法，而且有规律可循。 像素密度 要知道，屏幕是由很多像素点组成的。之前提到那么多种分辨率，都是手机屏幕的实际像素尺寸。比如480x800的屏幕，就是由800行、480列的像素点组成的。每个点发出不同颜色的光，构成我们所看到的画面。而手机屏幕的物理尺寸，和像素尺寸是不成比例的。最典型的例子，iPhone 3gs的屏幕像素是320x480，iPhone 4s的屏幕像素是640x960。刚好两倍，然而两款手机都是3

场景： 人物：前端实习生「阿树」与 切图工程师「玉凤」 事件：设计师出设计稿，前端实现页面 玉凤：树，设计稿发给你啦，差那么点像素，就叼死你┏( ￣へ￣)=☞ 阿树：~(>_<)~毛问题噶啦~ 阿树：哇靠，为啥你给的设计稿是640px宽 ，iPhone 5不是320px宽吗？？？ 玉凤：A pixel is not a pixel is not a pixel, you know ? 阿树：(#‵′)，I know Google。。。 为什么会出现以上的情况，难道他们当中一位出错了，摆了这样的乌龙？ 事实上，他们都是对的，只是谈的不是同一个「像素」。 此像素非彼像素 设备像素(device pixel) : 设备像素设是物理概念，指的是设备中使用的物理像素。 比如iPhone 5的分辨率640 x 1136px。 CSS像素(css pixel) : CSS像素是Web编程的概念，指的是CSS样式代码中使用的逻辑像素。 在CSS规范中，长度单位可以分为两类，绝对(absolute)单位以及相对(relative)单位。px是一个相对单位，相对的是设备像素(device pixel)。 比如iPhone 5使用的是Retina视网膜屏幕，使用2px x 2px的 device pixel 代表 1px x 1px 的 css pixel，所以设备像素数为640 x 1136px

用python处理图像时，可能会涉及两幅图像像素值之间的加减运算，这里需要注意的是图像像素值是ubyte类型，ubyte类型数据范围为0~255，若做运算出现负值或超出255，则会抛出异常，下面看一下异常示例： from PIL import Image import numpy as np image1 = np.array(Image.open( "1.jpg" )) image2 = np.array(Image.open( "2.jpg" )) # 异常语句 temp = image1[ 1 , 1 ] - image2[ 1 , 1 ] # 此处如果为负值则溢出 # 正确写法 temp = int (image1[ 1 , 1 ]) - int (image2[ 1 , 1 ]) # 强制为整型再计算就不会溢出了 以上代码即为异常RuntimeWarning: overflow encountered in ubyte_scalars的出现原因以及解决方法，希望能帮助遇到此问题的朋友。 来源： CSDN 作者： Acecai01 链接： https://blog.csdn.net/Acecai01/article/details/80248139

图像分割—基于图的图像分割（Graph-Based Image Segmentation） Reference: Efficient Graph-Based Image Segmentation,IJCV 2004,MIT Code Graph-Based Segmentation 是经典的图像分割算法，作者Felzenszwalb也是提出DPM算法的大牛。该算法是基于图的 贪心聚类 算法，实现简单，速度比较快，精度也还行。不过，目前直接用它做分割的应该比较少，毕竟是99年的跨世纪元老，但是很多算法用它作垫脚石，比如Object Propose的开山之作《Segmentation as Selective Search for Object Recognition》就用它来产生过分割（oversegmentation）。还有的语义分割(senmatic segmentation )算法用它来产生超像素（superpixels）具体忘记了…… 图的基本概念 因为该算法是将照片用加权图抽象化表示，所以补充图的一些基本概念。 图 是由 顶点 集 （vertices）和 边 集 （edges）组成，表示为 ，顶点 ，在本文中即为单个的像素点，连接一对顶点的边 具有 权重 ，本文中的意义为顶点之间的 不 相似度，所用的是 无向图 。 树： 特殊的图，图中任意两个顶点，都有路径相连接，但是没有

前言 　　最近看了语义分割的文章DeepLab，写写自己的感受，欢迎指正。 介绍 　　图像语义分割，简单而言就是给定一张图片，对图片上的每一个像素点分类。 　　图像语义分割，从FCN把深度学习引入这个任务到现在，一个通用的框架已经大概确定了。即前端使用FCN全卷积网络输出粗糙的label map，后端使用CRF条件随机场/MRF马尔科夫随机场等优化前端的输出，最后得到一个精细的分割图。 前端 为什么需要FCN？ 　　分类网络通常会在最后连接几层全连接层，它会将原来二维的矩阵（图片）压扁成一维的，从而丢失了空间信息，最后训练输出一个标量，这就是我们的分类标签。 　　而图像语义分割的输出需要是个分割图，且不论尺寸大小，但是至少是二维的。所以，流行的做法是丢弃全连接层，换上全卷积层，而这就是全卷积网络了。具体定义请参看论文：《Fully Convolutional Networks for Semantic Segmentation》 FCN结构 　　在FＣＮ论文中，作者的FCN主要使用了三种技术： 卷积化（Convolutional） 上采样（Upsample） 跳层连接（Skip Layer） 　　 卷积化 即是将普通的分类网络，比如VGG16，ResNet50/101等网络丢弃全连接层，换上对应的卷积层即可。 　　 上采样 即是反卷积（Deconvolution）

玩前端也有几个月了，发现大家普遍混淆了响应式和自适应的概念。先给大家体验一下响应式和自适应的区别，请放大缩小一下屏幕尝试 自适应的体验http://m.ctrip.com/html5/ 响应式的体验 http://segmentfault.com/ 整理了几篇自适应和响应式的文章，摘抄并修改了一下，请大家欣赏： 起初，网页设计者都会设计固定宽度的页面，最开始的电脑显示器分辨率种类不多，因为当时电脑本来就少，即使有变化也是 800 ||850|| 870|| 880。比如 开源中国 的网页就是固定宽度为998来定制的。至于为什么是 998 ，请 @红薯 后来随着显示器越来越多，以及笔记本的普及，这种方式的页面出现了问题。于是出现了一种新的布局方式宽度自适应布局。我们平时谈论的自适应布局，大多指的就是宽度自适应布局。 在这种布局下，出现了两派： 百分比宽度布局 流式布局 题主说的是第一派，宽度使用百分比，文字使用 em，现在也很多开始使用rem了，也就是所谓的高清方案。第二派的布局以 iGoogle 为代表（已经停止）。 一 开始没有响应式布局这个词语，但是慢慢出现了一个词——渐进增强，新词的出现总是伴随的旧词一起出现。就好比 3G 出现之前，没人管自己的手机叫 2G，所以，3G 和 2G 两个词是一起出现的（技术上当然2G技术先出现）。同理，渐进增强出现后，另一个词「优雅降级

#include <opencv2/opencv.hpp> #include <iostream> #include <math.h> using namespace cv; using namespace std; int main() { Mat src; //原图 src = imread(".//pic//test.jpg",IMREAD_UNCHANGED); if (src.empty()) { cout << "can not load image" << endl; return -1; } namedWindow("input", CV_WINDOW_AUTOSIZE); imshow("input", src); //单通道图像反色处理 Mat gray_src; cvtColor(src, gray_src, CV_BGR2GRAY); namedWindow("input", CV_WINDOW_AUTOSIZE); imshow("output", gray_src); int height = gray_src.rows; int width = gray_src.cols; /*for (int row = 0; row < height; row++) { for (int col = 0; col < width; col++) { int

您可能知道， wordpress 为通过媒体库上传的所有图片创建了大量副本。这些附加图像会根据您的设置和其他因素生成各种尺寸的图像。一般来说，这可能完全没问题，但是如果您在站点上使用大量图片，但您的站点没有使用所有尺寸的图像，那多余的文件会占用您的磁盘空间。因此，为帮助您节省资源，消除浪费并保持运行状态尽可能轻巧，本文详细说明了禁用所有 WordPress 默认（或自定义）自动生成的图像。 了解如何禁用任何/所有 WordPress 自动生成的图像以为您的网站实现理想的配置。 为了更好地了解正在发生的事情及其重要性，我们将以我们的一个真实的网站作为例子。这个网站是我喜欢发布奇怪/启发/发现图像的地方。到目前为止，已经通过 WP 媒体库将 800 多个图像上传到该站点。因此，如果我没有采取措施阻止 WordPress 自动生成每个图像的多个副本，那么 800 个数字将更像数千个图像。 因此，以我们这个网站为例，让我们做一些快速数学运算。我们有一个 WordPress 网站，其中包含 800 张原始图片，每张图片平均大小约为 2MB。因此，总共 800 张原始图像的总体积约为 1,600 MB 或 1.6 GB。现在，让我们让 WordPress 完成其工作，并为每个图像创建各种尺寸的额外副本。从 WordPress 5.3 版开始，WordPress

3.glPixelStore 像glPixelStorei(GL_PACK_ALIGNMENT, 1)这样的调用，通常会用于像素传输(PACK/UNPACK)的场合。尤其是导入纹理(glTexImage2D)的时候： C++代码 glPixelStorei(GL_UNPACK_ALIGNMENT, 1); glTexImage2D(,,,, &pixelData); glPixelStorei(GL_UNPACK_ALIGNMENT, 4); 很明显地，它是在改变某个状态量，然后再Restore回来。——为什么是状态？你难道8知道OpenGL就是以状态机不？——什么状态？其实名字已经很直白了，glPixelStore这组函数要改变的是像素的存储格式。 涉及到像素在CPU和GPU上的传输，那就有个 存储格式 的概念。在本地内存中端像素集合是什么格式？传输到GPU时又是什么格式？格式会是一样么？在glTexImage2D这个函数中，包含两个关于颜色格式的参数，一个是纹理（GPU端，也可以说server端）的，一个是像素数据（程序内存上，也就是client端）的，两者是不一定一样的，哪怕一样也无法代表GPU会像内存那样去存储。或者想象一下，从一张硬盘上的图片提取到内存的像素数据，上传给GPU成为一张纹理，这个“纹理”还会是原来的那种RGBARGBA的一个序列完事么？显然不是的

第一题 打开压缩包得到的是一张PNG格式的图片 首先拖放到010Editor中： CTRL+F 搜索IHDR发现只有一个，没有其他问题 然后放到KALI中分析一波： 图片能够在kali中打开，说明不是宽高的隐写，因为如果修改了宽高在linux中是无法正常显示的 然后binwalk分析一波： 同样的没有什么问题 最后就是放到 stegslove里面试一试了 简单的科普一下png的知识 png支持RGBA四个通道，每个通道占8个二进制位，隐写文件或数据一般都在各个通道的低位，因为低位的变化不会引起较大的视觉变化，图片看上去还是原来的图片，但是你不知道是在哪个通道，这里有4个通道，如果藏在一个通道的低位的话，有四种可能，如果藏在两个通道的低位的话，可能进行各种运算操作后出现新的图片，加减乘除与或异或 发现Red plane 0是空的，按理来说应该也是”雪花“的，所以应该是有问题的 然后 Analyse - Data Extract，查看该通道，得知是LSB隐写 后面得知就是吧Alpha、Red、Green、Blue 0通道进行异或处理就能够得到flag了，可以通过stegslove获得，下面说一下通过python编写脚本进行色道分离异或处理的方法： #代码参考自合天智汇 import cv2 import numpy as np import os def lowbit(x):