写了个 webp 转 jpg 的小工具

find . -iname '*.webp' -exec bash -c 'ffmpeg -y -i "$1" "${1%.*}.jpg"' _ {} \;

作者好心, 你们在这秀? 不是谁都会 bash,装个 linux? 谁都知道 ffmpeg, 你在让人家下载个 ffmpeg?

@goxxoo 现在看图软件基本都支持 webp 格式了吧，只要能看，一般就能转换。

又不是什么新格式，苹果的 HDR 格式转换才麻烦。

@augustheart #20 我都把定律（原因）发给你了，怎么谜语人了？

再深入解释就是，CPU 密集型应用都在做计算，多开的协程、线程只会在那个空等待，不会实现并发的效果。

多出来的上下文切换反而还会增加额外的开销。所以开 100 没意义，Java 有个 API: Runtime availableProcessors() 就是处理器数量，设置成这个也能跑满 CPU 。

CPU 密集型应用，没法空出手来去干其他活

用 go 写其实麻烦点，用 python 还不需要编译（当然你可能考虑到批量性能这一点）

不行, 我这很多小大姐姐都不知道, 经常问, 改名, 她们连后缀名都不知道怎么显示出来, 你让她们装个软件看图?
不是所有人都有计算机知识

@tool2dx

go 编译后的 exe 是最方便的, 比 python 方便多了,再给她们电脑上装个 py 环境?

好东西，已下载

@goxxoo 汗，看图软件还是要安装一个的吧。好歹是效率工具。

@tool2dx 你跟她们讲效率?一堆女人一句话就淹死你

@wxf666 没看代码,但估计还是有点用的. 读 webp, 写 jpg. 图片多的话, 也算 io 密集了

@diagnostics 不开协程，楼主就是一个队列逐个执行。开协程，go 就会根据系统核心数调度，本质上就是一个线程池。go 的协程不太会出现同时运行大量线程导致的开销。所以我下面也说了，反正 goroutine 便宜，下面也有人说了，为什么不设置为 GOMAXPROCS 。
我的说法，本身就是基于目前系统上已经普及多核 cpu 的现状，我不觉得我的说法有大问题。

@diagnostics 虽然看不懂你在说什么，但是我的实践告诉我图片编码可以并发

@goxxoo 好办，改一改，双击启动后弹出一个目录选择对话框，让小姐姐选择目录。至少我的观察，到这步很多小姐姐是没问题的。反正这招对我家的小/老姐姐够用了。

暂时没有这反馈, 我可不想找事, 上赶着不是买卖 哈哈 她们用这还行, 都是懒狗, 能点一下的绝对不点第二下

我就弱问下，无损是怎么做到的？ jpg 常用的都是有损压缩，编译软件保存时一般都会设置压缩率。你是通过设置一个很大的压缩率来做到无损的吗？还是用了某种无损的 jpg 格式？

@abcysn 当然不是无损，虽然没用过 golang ，但就这一句 jpeg.Encode(outputFile, img, nil)，应该是默认参数 75 吧。作者大概没考虑过编码质量的问题，

现在主要用的这个图片转换工具，感觉蛮方便的：
https://imagestool.com/zh_CN/

@augustheart #33 不是开不开协程的问题，是 100 的问题，需要设置为 GOMAXPROCS ，协程便宜不代表可以随便滥用，都是你这种程序员的话，代码得多捞，他开 100 个，你开 100 个，加起来是多少个呢？

@BYDH 能并发，但并发数 100 和 GOMAXPROCS 相比，前者不会更高，只会更差。