@AlphaTr 哈哈，是的。手机拍微距这个技能，我刚 get 的时候也很意外。

@AlphaTr
另外你这个拿什么拍的？像素点拍得很清楚啊？
还是拍完局部放大的？

@AlphaTr
嗯，这个看得很清楚。
看来各家都有点黑魔法。
希望这个技术 /成本门槛能早日降下来。

@dxgfalcongbit

你说的没错。其实离远一点，或者放大一点，或者动态画面，都能改善很多。

但我的需求，一方面是职业习惯，做过古早的手机游戏，搞过初代 NDS，搞过 UI，就对像素比较苛刻一点。
CRT 年代就开始看像素点，从 112px 的诺基亚一路过来，算是职业病吧。

我使用距离近很多，我现在到屏幕大概 60cm，就正常桌子的距离。
在这个距离，部分颜色，色相 0~60、160~220、270~330，有几段我是可以明显看到网点的。
还有部分灰色也是，估计跟它本身色阶有关。

其实还是因为我这个需求本身比较特殊，适用范围比较窄。

@AlphaTr

看了，的确不错。比我手头这台强出太多了。
辛苦你拍这么多图。

不过我有个几个疑问再请教一下哦。
因为拍摄跟实际看还是有区别的，所以我也就只能根据照片来提问。

一个是它这个像素感觉一行宽，然后有一行窄的。
圆点那个图的园的边缘就挺明显。
文字的话有些竖线边缘也能看到虚线。

另外在文字，粗体的那个，aedb 这类圆环的横笔画部分，感觉也有点插值造成的点。
比如白底 240 蓝色 270 紫色那两个的 equal，eqa 的横笔画，都感觉当中有几个亮点。
不知道你实际距离看感觉怎么样。

另外竖线那张放大，是有单独的白色像素，还是三色混的白色，拍照糊一块儿了？

感觉大法也有点自己的黑科技在里头。

@Sapp 这样哦，几寸啊？
我因为希望同时实现更多显示内容，而不是高精度，所以我基本排除了 27 那类。

@songjiaxin2008 不是指缺字的问题，而是字体不一致。
比如整篇文章原本是萍方字体，个别字替代为图片 /svg/嵌入字体，比如雅黑，那看上去有可能会有点不同。
不同字体常见问题，比如笔画粗细，中宫大小，基线高低，默认行距，等等问题。

极端例子，比如我看安卓用户，有些会用很个性化的字体，手写体之类的，忽然出现个替换字体就很明显。
我之前看到的情况是替换了 30 左右，非常高频，比如的得地基本都换了，导致整篇文字基线起伏连绵。

可能发生率不高，或者一般人注意不到。我就是提一下有这个可能性。

万一碰到用户缺字体回退到不同字体，或者渲染设置不一样的话，视觉体验可能会很差。
好像见过几次类似的页面。

好像是有一点延迟，过几分钟就自动好了。

@wiix 锐化这个当然关过了，症状依旧。

@AlphaTr
对了，你方便的话可以拿我那个测试图去看看效果嘛？
就这张
https://s2.ax1x.com/2019/12/01/QmDW7T.png
缩放到原大，看看横线竖线的显示情况，还有字体。

@dxgfalcongbit 是，有听说过小米随机面板的情况。

@CEBBCAT 歪个楼。

我觉得我这个帖子，收藏也好，感谢也好，都随意。
要图这点东西，我就直接去其它网站撒网了。

但你提的问题我觉得是对的，因为我也不喜欢首页热门老是推一些没有价值的破事儿或者抽奖推广。
跟喂鱼喂鸽子似的，撒点棒子面儿就围起一群人，挺微妙的。

之前看 B 站的算法其实是加权重的，有些行为比如播放数，那个就权重低一点，收藏肯定就高一点。
但 B 站现在强推 3 连，我觉得也很蠢。收藏不应该是一个高频的行为，点赞投币就够了。

反正人家的地盘，还是让站长 @Livid 自己拿主意呗。

@Sapp
我看 rtings 有一台 LG 评价很适合当显示器，但跟国内型号不一致，不大敢下手。

@dxgfalcongbit
你这个三个链接很有参考价值，看来是通病，病根有人说好像就是面板的水准不行，bit 数不足。

@AlphaTr 恭喜恭喜，索尼大法好。

@dxgfalcongbit
是的，我店里大致观察了一下，其它型号也有不存在这个问题的。
只能说这个型号，这个批次，我买到的这台，中奖。

我是直接写了个 python 的 snippet，自动模板。
开头加两行
#!/usr/bin/env python3
# -*- coding: utf-8 -*-

之前也没多想，就放着呗。

我是 sublime 出现这个情况需要满足多个条件。
我头部声明一般都保留，需要去掉声明才会报错。
同时我如果用的一个自定义 build，加了-um，也不会出现这个错误。

感觉开头的这个声明，在处理 utf8 的时候，直接就处理了逃逸，把\xe5 给解决掉了。
找了一下，好像依据是这个。
我理解就是不加这行话，py3 把文件当 utf8 来读，读到意外的字符就报错了。
加了这段话之后，多做了一步转义加成，于是把违禁字符先给解决了，然后才开始运行。

Handling of escape sequences should continue to work as it does now, but with all possible source code encodings, that is standard string literals (both 8-bit and Unicode) are subject to escape sequence expansion while raw string literals only expand a very small subset of escape sequences.

[PEP 263 -- Defining Python Source Code Encodings | Python.org]( https://www.python.org/dev/peps/pep-0263/)