导出的文件带个 srgb 色彩 icc, 然后 honeyview 中挂载对应 icc 应该就可以

我用 xnview, 它里面有两个选项, 一个是挂载什么 icc 来解析图片, 另一个是如果没有 icc, 默认用什么 icc

如果 honeyview 默认是 srgb icc 的话, 看看 ps 那边设置对没有. 看你截图好像没啥问题, ps 名字里面也没有 * 标记. 偏好设置里设置的是 srgb + preceptual 吗?

@Shazoo 一开始我觉得 op 的想法不行, 后来看到你这个还觉得挺靠谱. 用气动的确实可以

@zhouweiluan anker 有一款和你这个几乎一模一样…… 不是说你这个不好，就是感觉可能芯片用的都是一样的

如 LS 所说 sklearn 里面有, 找缩放的部分
这个要手写也简单, 主要分为两部分
1. rgb 转为灰度图, 这个有公式
2. 转完之后是一个 0 - 255 的小数, // 16 即可

gruvbox yyds

不是全域快门

@flmwswd 我猜反正就是有一个爆栈了…… 没有多的报错, 但是如果我的 main 里面 sleep 一下的话, 这些东西就能跑完. 上面大佬提到说给一个可控的阻塞, 就能实现和 sleep 不可控阻塞一样的效果.

原理上来说现在是搞明白了, 就是 main 里面的语句遇到 goroutine 就只管开协程然后继续往下跑. 如果 main 里面没有阻塞, 那 main 就会先跑完, 然后那些 goroutine 都跳过去了

以我的例子为例, 如果将 塞数据、用数据作为两个函数分别执行的话, main 函数里应该是这样的吧:

1. 第一个 for 之前
2. 第一个 for, 生成第一个函数的一个 goroutine
2a. 第一个 goroutine 开始跑
3. 不管第一个 goroutine 跑的怎么样了, 我进入第二个 for, 开启第二个函数的 goroutine
3a. 第二个 goroutine 开始跑
4. 继续往下看 main 有无阻塞, 没阻塞就啥都跑不出来. 有阻塞就等阻塞结束, 然后等待的这个期间, 其他 goroutine “趁机” 跑完

所以原来的写法, 就是每一次 for 循环都会加入一个 goroutine 并行跑. 这个迭代对象的内容少一些就可以正常跑完, 一旦多了, 新建的比消耗的速度快, 迟早会爆掉

所以原来的写法处理少量数据还行, 大量的就不行了, 但思路上也不应该每一次 for 循环都创建 goroutine, 这是明显的错误写法. 另一方面, 我创建了 1000 个写的 goroutine 和 1000 个读的 goroutine 又能怎么样呢, channel 不是只有一份嘛 😂…… 等于说只是大家抢着往这个 channel 队列里面塞东西和拿东西罢了, 但是这个 channel 的进出口只有一个啊……

所以思路上应该是一开始就建立比如 20 、50 个 goroutine 用来写到对应数量的 channel 里, 然后若干其他的 goroutine 用来读和处理, 这样才能“并行”起来对吧. (并且一旦某个 channel 没有数据之后还要关掉)

由于这个例子里面, 很多人反应 新建文件夹 和 移动文件容易造成问题, (而且没准我真的遇到了问题只是自己不能判断是否是线程安全问题造成的), 所以后面我准备换一个缩略图的例子试一下. 假设一个文件夹内有 6w 张图片, 我准备试一下看看如何用并行的方式去处理这些图片

@seers 大佬说的对…… 我看教程里面就是给了个返回信号 (同时也说了 main 其实也是个协程)…… 但我有点懵不知道咋给
目前的想法是, 多给一个 done chan bool 类型, 事情做完了就 bool <- true, 但是这玩意怎么给到外面我再想想……

@Frankcox 谢谢大佬的回复, 我照着实现了一下

关于 sync.Map 我搜了一下, 主要是为了解决 map 线程不安全的问题而设立了 sync.Map. 这个我在代码里用到了文件夹是否存在的判断上面. 如果没有相关文件夹, 我要建立一个新的文件夹并保存, 并在 map 里放入一个对应的名字. 如果不用 sync.Map 往 map 里面写东西的时候可能会乱掉

我用大佬的写法确实跑成功了, 但是文件数量一多 (比如 2w), 还是会 runtime: failed to create new OS thread 错误 😂

目前情况是, 用 waitgroup, 并通过循环 Add 文件处理操作任务, 在循环外 wait 所有任务结束

这种写法可以跑, 但是文件数量太多的话就会 runtime: failed to create new OS thread 报错

如果一个文件夹包含 2w 个 .txt 文件和 2w 个 .abc 文件, 非并发可以跑完, 耗时 1.5 - 2.3 s; waitgroup 方式报错, 感觉是创建了太多携程. 目前还不知道有没有办法创建指定的携程数量去处理这些任务

另一方面, 如果降低文件数量, 比如只包含 2k 个 .txt 文件 和 2k 个 .abc 文件, 这个时候 waitgroup 也可以跑了. 非并发和并发分别耗时 250+ ms 和 160+ ms. 并发的是会快一些 (都是空文件, 也都是直接移动文件而非复制, 应该没什么 io 压力所以区别还没有那么明显)

@flmwswd 还有这么多讲究, 学习了. 我用 3L 的方法引入了 waitgroup, 并且把 dealInfo 扔到 getInfo 内部的循环里面去, 程序可以跑了.

不过当我对一个有 2w .txt 和 2w .abc 的文件夹进行操作的时候, 报错 runtime: failed to create new OS thread 了, 这个是因为创建太多携程的关系吗.

我理想中的携程应该有一个池子或者队列往里塞任务, 然后不断从池子里面拿东西出来处理, 直到池子 /队列清空. 不知道代码后面发生了什么……

@masterclock 谢谢大佬指点, 这确实是我另外的一个困惑点…… 因为上面看到了 waitgroup 就去搜了下, 然后发现 wg.Add(1) 是在一个循环里面, 而这个循环又包了一个 go func(), wg.Wait 则放在循环外面, 然后我就又懵逼了. 因为目前的写法主函数里面没有循环, wg.Add 加不起来……


于是下一个点是, 如果只用 waitgroup 就可以让 goroutine 并发完成的话, 那 channel 一般要在什么场合使用啊

看看系统偏好里的图标就知道了……这一代的图标都是什么破玩意……

我是佳能的，为了打 A3 画幅的还特意买了个大的。现在打证件照可以用

你别说，我自认比一般影楼的效果好。因为我墨水、相纸均原厂，我还做了色彩管理，比影楼差就奇怪了

唔, 上面忘了说. 用的时候跟一个 -p 参数加路径, 就可以把这个路径下面的所有文件遍历并放到对应文件夹内
例如 `dealer.go -p ~/Desktop/zhangsan`
如果上面大佬的命令行可用, 估计你也是在类 unix 环境下了, 文件夹权限控制应该问题不大

@DylanZ 来晚了来晚了, 我也不知道之前大佬什么时候提交的. 我是 go 小白选手, 随便写了个能用的但是远不及 LS 大佬的简单

代码放这了 https://pastebin.com/bXZNA9D1 有效期 7 天. 但我感觉写得很烂…… 仅供参考哈哈. 我这个显然是单线程的, 如果文件很多, 大佬们应该可以随便写多线程的

@ngbdsb 哦哦，我转过弯来了。有道理哈

py go 随便写一个就行吧。蹲一个大佬，明早没人回复我就写一个