blog.csdn.net
jaycaoln
Web前端
|
bilibili
女朋友和工作
获得徽章 5
- 1.png本身是支持无损压缩的
2.png8(灰度图像(r=g=b)就是使用png8,能表示256种颜色)
3.png24(rgb分别8bit存储)
4.png32(rgba分别8bit存储，所以支持256种透明效果，这里就可以完美避开像gif有的锯齿问题了)
5.组成部分包括：头部数据+调色板数据+数据块，头部数据中png的十六进制编码。可用于判断图片是否为Png格式
6.采用的压缩技术是预测差分编码+deflate压缩重复值进行存储
7.渐变色，颜色差异不大，压缩效果会很好
8.常用减少Png体积的方法：
i.小于256种颜色的，直接用索引，透明色也放在索引表中
ii.对于透明色，可以将其rgb设置为一样的值
灰度图像
1.r=g=b就是灰度图像，所以我们只需要8位就能存储了。
2.灰度处理的方法。最好的方案是获取每个像素的rgb转换为亮度Y，按照0.3 * r + 0.59 * g + 0.11 * b进行加权平均得到一个值进行替换。（因为人眼对亮度更敏感，所以yuv是更合理的方式）展开赞过 评论1 - ### ffmpeg
需求背景是将gif图的背景保持为透明色，并进行一定尺寸的改变。ffmpeg -hide_banner -v warning -i a.gif -filter_complex “
[0:v] scale=320:-1:flags=lanczos,
split [a][b];
[a]palettegen=reserve_transparent=on:transparency_color=ffffff [p];
[b][p] paletteuse”
out.gif
1.-hide_banner 隐藏多余不必要信息 就是转换过程的信息输出
2.filter_complex就是滤镜
3.scale=320:-1:flags=lanczos
比例滤镜会将输出调整为320像素宽，并在保留长宽比的同时自动确定高度。
flags=lanczos
一个取代默认（目前是bilinear）定标器的lanczos定标器缩放比例。推荐它的原因是你使用lanczos或bicubic来缩放画面要比bilinear优越的多。如果你不这样做的话，你的输入会模糊的多。
4.split [a][b];
将后面ab过滤器都在一个命令中完成
5.palettegen主要用于彩色统计
max_color用于限制色板大小，越小对压缩越有帮助，最大256
reserver_transparent保留透明度，考虑到可能会有透明通道，尽量不改transparency_color设置透明通道的背景色
stats_mode默认为full，可能会导致内存爆炸，所以一般使用diff跟single，diff的话会在gif编码的时候进行画板比对，所以其实用不用都会被过滤
6.palettuse就是运用滤镜
这个滤镜有点复杂，但是是抖动的关键dither
blog.csdn.netffmpeg.org
但是gif本身还是太大了，可以考虑转换为动态webp。展开评论点赞 - 重新理了下编码
1.ASCII是最早的一种编码方式，规定一个字节存储(8个bit)，也就是00000000到11111111，最多只能存储256个字符。ASCII只规定了前128个运来存英语，后面128个扩展的，用于存储图形、特殊字符等。
2.为了存储汉字，256是不够用的，于是出现了GB2312，采用两个字节进行存储。第一个字节称为高字节（从0xA1-0xF7）,第二个字节为低字节（从0xA1-0xFE），约可以存储7000多个简体汉字。
3.因为56个名族，扩充GBK得到GB18030，有70,244个汉字
4.ANSI指的是扩展的ASCII编码，不同的国家有不同的标准， 即GB2312、GBK、GB18030、Big5(繁体)、Shift_JIS(日文) ，英文用一个字符表示，中文用2个或者4个字符表示
5.为了统一各国标准，出现了Unicode(字符集，就是字典)，每一个字符对应一个唯一二进制代码，最多存储10FFFF(转换为二进制就是1114111)个字符。
6.Unicode规定了二进制对应关系，计算机都是以二进制进行存储的。于是便出现了各种存储方法，utf-8，utf-16等
7.utf-8规定的存放方式如下图：0000 0000-0000 007F用一个字节存储。0001 0000-0010 FFFF用4个字节存储。
比如'严'的 Unicode 是4E25（0100111000100101），对应第三行的模板，套入模板是11100100 10111000 10100101，转换为16进制就是E4B8A5
8.utf-8和GBK转换的逻辑便是：
Utf-8====编码====Unicode=====编码=====GBK
Utf-8====解码====Unicode===解码=======GBK
参考：www.cjzzc.com zhuanlan.zhihu.com 展开赞过 评论3 - redux源码nextListener如何理解？
源码精简如图1，维护者说nextListener的存在是因为在dispatch的过程中发生subscribe和unsubscribe的操作，导致每一次listeners的改变，避免listener执行的不确定性。这个可以理解。
既然就是为了解决不稳定性，为何不能只用一个currentListeners解决写成图2？展开评论点赞
