你已经两步确认了

特此声明，其他网站的 imn1 基本都不是我，🐶
我用这个 id 时，四位基本都分光了……

@phpfpm
还有一个是旋转的图也能判别，我忘了是哪个，不过网络图片这个问题不常见，摄影的才比较多

@phpfpm
呃，我想起 RadialVariance/ColorMoment 是用在什么场合较佳了
aHash/pHash/dHash 对于有较大水印的图判断不准，多数为 False，但这两个能判断出是相似的图(True)

@phpfpm #21
有点没看明白
你的程序是 compare(pic1, pic2)，在里面 hash 然后比较，这样的么？
这样 compare(pic1, pic3)的话，pic1 不是又要重新 hash 一次？

应该转成两个步骤
hash1=img_hash(pic1)
hash2=img_hash(pic2)
hash3=img_hash(pic3)
……
然后入库
用数据库的值 compare(hash1, hash2)，这个不需要多次 hash 了

@Rxianbei #16
这里涉及财经，我不是专业人士，所说不能作准，仅参考
百度控股没有产出和实务，主要是投资和控股，我称之为“事务”，纯粹为了方便说明，和词义本身无关
百度网讯有产出和实务，进行实际工作的操作，我称之为“业务”，同上，也是为了方便说明

在一个地区，想控告该地区一个公司的“业务”有问题，但这个公司的控股公司在该地区只有“事务”，没法告
一个公司 A，在所属地区 AA 以外做了投资，那个获得投资的公司 B （位于地区 BB ），业务不符合 AA 法律、但符合 BB 法律，只要业务不影响 AA，是无法干预的，除非 AA 的法律很霸道，也规管了这种投资。美国有这种可能（我不清楚美国法律），但也不敢随意使用，因为这样会影响其他投资人，打击投资信心，基本不影响美国的还是倾向不理，因为即使告倒了，最多只是撤资，难以做更严厉处罚，对美国利益不大，仅斥责的可能性比诉讼大

简单说，用 pythonw.exe 执行的，没有输出，用 python.exe 执行的有输出，跟扩展名是 py 还是 pyw 无关

@Rxianbei #14
唉，你还真是较真
百度在国内应该是“百度在线 XXXX”还是“百度网讯 XXXX”，忘了，在美上市那个，是“百度公司”还是“百度控股”？反正是英属什么群岛注册那个
两者是子母还是兄弟，我没有去详究，前者不需要遵守美国法律，后者遵守就可以了，在美国也告不了前者

百度旗下有一大堆公司的，并不是业务不同公司不同，更多是不同地区的税和法导致不同
用程序员的词汇就是，相同的数据，前端、客户端不同，给手机用的网页就加上“请安装 APP 查看更多”，给桌面用的网页就没有这个，但背后的数据是相同的

@Rxianbei
百度在不同的地区，法人不同（不同公司 /子公司），它只需要这个法人遵守当地法律就够了
例如百度 CN 和百度 JP （名字只是例子），你在日本起诉百度 CN 是没有用的，因为百度 CN 没有在日本注册和业务

如果只是百万级汉明不需要几天啊，我觉得#1 说得对，你是否每次都算一遍？
你应该缓存 hash 值的
然后建议分段，如果有分类别什么的，那将大大降低循环次数

windows 有个软件 Similar Images，32bit，可以缓存 hash，作者应该弃坑了，好几年没更新，百万级也就小时级别（不过一次跑百万可能会崩，只能分段）
我自己写的 python 也不用那么久，只是估计，没试过百万，不过我是 hash 和匹配分开（整理时顺便 hash 入库，目前约 50M 张），然后匹配是家常便饭，经常跑小量（千张到万张）匹配，主要是入库时做去重，已经整理入库的就不需要互相比较了

说说算法，常见的 hash 有这几种
cv2.img_hash_PHash
cv2.img_hash_AverageHash
cv2.img_hash_RadialVarianceHash
cv2.img_hash_MarrHildrethHash
cv2.img_hash_ColorMomentHash
cv2.img_hash_BlockMeanHash
cv2 就是 opencv，BlockMean 最快，但极其不准，基本弃了，RadialVariance/ColorMoment 较慢，但还是有点用，ahash/phash 速度适中，MarrHildrethHash 我很少用，主要是搞不清它什么场合更佳

我个人的经验是，aHahs/pHash 中其中一个匹配（ OR ），ColorMomentHash/RadialVarianceHash 中其中一个匹配（ OR ），这两组 AND 的话，基本就确定重复了 —— 指没有漏判，然后找出的结果中只有很少是错判，错判不到千分之一（分母是全体，包含不重复的）
不过临界值还是要自己调，aHash/pHash/ColorMomentHash 我都是用 3，RadialVarianceHash 我用 0.95 ，全部都比网上代码样例的建议值宽松很多，单独一个算法用这个临界值的话误判会更大，但我组合起来用误判就很小了，这样比单独一个 hash 使用更严格临界值结果还好 —— 原理是图片质量不高的话，应该宽松些，这样不会漏掉，但很多误判，然后用组合降低误判。如果图片质量很高，例如全部都是没有 PS 的摄影作品（ raw 或近似 raw ）的话，可以适当调高临界值，甚至只用一种算法也够了

还有一种模式匹配算法，不过只适合小图找大图（就是大图里面的一部分），或者有裁切的图找原图，不适合找相似的图，此处不详说了

从技术上说，人脸识别，或者类似（广义）的图形算法，理论上缓存特征串比缓存图片本身更方便
一来特征串比图片本身容量小，二来比较前参照和样本两个都要求取特征串的，已经有特征串可以节省一点时间和算力（每次都把参考图形算一遍是重复劳动）
特征串一般是个 hash 值（或矩阵），并不能复原图形，但盲猜公安方面不会提供这个，也是提供图形本身，因为 hash 根据算法不同就不同，公安不能确定调用者使用哪种算法

所以，具体还是要看 SDK 是怎么做的
如果只是对比、鉴定（ T or F ），多是直接获取一个 id+参考图片，然后算一遍再对比，期间可以留存参考图片的 id 和 hash，下次就不需要再重新算参考图片的 hash 了（因为这个图片是不变的），当然是否缓存图片本身就是另话
寻找的话（匹配搜索），就不太可能去大量获取了，多是样本算一遍 hash，然后在已知一堆 hash 里面做匹配

我自己写过一个匹配艺人的，就是上述方案

人很好，但很难相处，因为大部分人是向着“完成”的目标，而不是“极致”
老板能忍受他，也算是个好老板了

这样的同事，要换一种思维 /方法和他相处

因地制宜

我觉得这是两种传统管理思想，很难说哪种更好
1.中央集权，中国为代表大家都熟悉，不用多说
2.封建层级管理（注意封建不是贬义词，也和国内课本讲的不同），就是中心管土地领主、领主管地方事务，中心并不容易插手地方事务（虽然可以，但甚少）
实际除了中国，大部分地方都是这种方式，不仅欧美，连古印度、古埃及、中东都大多是这种，延续至今

中国自汉武帝削 /撤藩王后，基本就不算“封建制度”了，是强势中央集权制度，虽然之后藩王类似还有断断续续出现，但基本没能改变，延续至今
某个地方的人持有欧美管理思想，回归后不理解和不接受这种管理方式（我不讨论好坏，我只是觉得两者不同而已，评判要从其他方面），但中国近两千年都是如此管理的

题外
李氏朝鲜和中国晋朝，两个有点类似，一个是两班，一个是贵族，权力相当大，可以和王叫板，但又和土地分封不同，有时间再去考究

@Raven316 #12
想了想，应该是你所说的“日程”和我理解不一样
你所说的应该是类似项目管理的 item，项目管理自然就是同一件事
我理解的是日历管理的日程（事件 /任务），这个就方方面面，事情多了去，完全不能确定是关联事件

第一句说明你的需求不高
笔记本是满足需求高于你的“大部分的移动需求”的那些人

#23 很精辟，赞

@Raven316 #2
16:00 - 17:00 总结会议
17:00 打卡下班
17:00 - 18:00 买菜
-----------
这些日程不是同一件事，是没有依赖关系的，所以肯定需要一个字段表明是有关联的同一件事
这个字段的表述方式就决定了算法，如果是父子级（或前置项）表述，自然就是拓扑等方法；
如果是 path 方式表述，如：
庆生宴 /买菜
庆生宴 /准备 /食材清洗
庆生宴 /准备 /食材预处理
庆生宴 /准备 /调料准备
庆生宴 /做菜
……
有 xpath selector 等方法，当然日程不会写这么细，只是举个例子

跟老婆说，电话营销的人，不需要尊重，因为他们会引起夫妻矛盾，🐶