这是一个创建于 3060 天前的主题，其中的信息可能已经有所发展或是发生改变。
每周有大概 12 个 g 的 tif 文件，要转成 png 存服务器，现在处理一遍 12g 的要 8 个小时，程序是以前 c#做的，打算提高些效率，不知道有没有人有好办法
第 1 条附言 · 2016-08-02 19:01:28 +08:00
现在是用的 freeimage 开源项目来处理，不知道有没有更好的处理方法
 |
1
fcicq 2016-08-02 17:05:14 +08:00  2
典型的加 CPU 个数就足够解决的问题
|
 |
2
Srar 2016-08-02 17:48:47 +08:00 1
GPU 加速？
|
 |
3
cxbig 2016-08-02 17:51:37 +08:00
同 subnet 开一个机器专门处理，完了扔掉。
|
 |
4
lllooo 2016-08-02 17:52:38 +08:00
加 CPU ，程序用 C 重写一遍，队列加大并行数。
|
|
5
lllooo 2016-08-02 17:54:02 +08:00 5
还有一个奇葩的方法。写个程序，然后公司员工安装上，自动转，然后上传。
|
 |
6
undeflife 2016-08-02 18:00:44 +08:00
既然是每周累积的 为什么不在 tif 文件产生的时候就完成这个处理步骤而一定要集中处理？
|
 |
8
nellace OP @fcicq 下载是开了一台 16g 内存电脑专门处理，处理程序是用 freeimage 开源项目处理，就是不知道还有没有其他的办法
|
 |
10
xmoiduts 2016-08-02 19:07:16 +08:00 via Android
租用按量云计算？一台机子 8 小时， 10 台机子就 1 小时了。
|
 |
11
lhbc 2016-08-02 19:19:08 +08:00 1
ImageMagick + GPU
|
 |
13
hellov22ex 2016-08-02 19:39:34 +08:00 1
天河 2 ？
|
 |
14
czheo 2016-08-02 19:43:50 +08:00 via iPhone
加机器
|
 |
15
3dwelcome 2016-08-02 19:48:13 +08:00 via Android
好奇什么图片、竟然是 tif 格式？
|
 |
16
moult 2016-08-02 20:01:52 +08:00
先把图片传到七牛或者又拍云，然后换个格式再下载回来，并删除文件。其实这种办法和租用云服务器类似，可能瓶颈在带宽，如果租用云服务器的话，务必租关机不计费的机器。
排除云端方案的话，那就只有本地了。要么加 CPU 核心，或者上 GPU ，要么就组“集群”，也就是 5L 的方案。 |
 |
17
skydiver 2016-08-02 20:14:41 +08:00 1
写个 Makefile ，调用 ImageMagick ，然后 make -j32
|
|
18
skydiver 2016-08-02 20:19:11 +08:00
而且 8 个小时一点都不多好吧……
|
 |
19
cfans1993 2016-08-02 20:35:49 +08:00 via Android
找数字公司商量一下，能不能租万把台 pc 几分钟
|
 |
20
larsenlouis 2016-08-02 22:22:26 +08:00 3
安装 imagemagick 和 parallel ，一条命令搞定。
find . -name '*.tif' | parallel convert {} {}.png imagemagick 用 c 语言写的图片处理瑞士军刀 parallel 并行的执行计算任务 我用的样图是 http://olympus-esystem.jp/products/e1/sample/image/sample01.tif ， 15.3MiB 复制为 10 份，在一台 i7-4790 16GRAM 上的双核、 2G RAM ubuntu 虚拟机上跑 real 0m15.724s user 0m26.748s sys 0m0.520s 大约 9.73MiB/s ， 50GiB 图片大概要 1.5 小时。 |
 |
21
herozhang 2016-08-02 22:22:53 +08:00 via iPhone
直觉是程序写的效率问题，再来就是并行处理。
|
|
22
herozhang 2016-08-02 23:00:56 +08:00 1
刚测试了一下，用 imagemagick 的 conver
用 photoshop 生成了一个 600M 的 tiff 文件 test.tiff > time convert test.tif test.png convert test.tif test.png 18.92s user 1.19s system 99% cpu 20.123 total 20 秒-600M 50G 算下来也就是 1700 秒=0.47 小时 如果开并行，应该是接近线性的时间关系。 硬件平台： mid2014 MBP i7 CPU |
 |
23
ins 2016-08-02 23:29:02 +08:00
....8 小时 知足吧兄弟...
|
 |
24
msg7086 2016-08-02 23:30:32 +08:00 1
要便宜的话弄几台 x5650 的洋垃圾，要处理的时候开机然后并行跑，价格便宜量又足。
|
|
25
nellace OP 1
@3dwelcome 出版行业一般都是存 tif ，因为 tif 对白底黑字，白色面积较大的情况压缩率高，同等大小更清晰，反过来要是黑底白字那文件就更大了，考虑浏览器不支持 所以要再转 png 保存
|
 |
29
coderluan 2016-08-02 23:49:16 +08:00
imagemagick
|
 |
30
wclebb 2016-08-03 02:02:32 +08:00 via iPhone
不知道用 ps 的批处理感觉是怎样的……
|
 |
31
xenme 2016-08-03 08:27:41 +08:00 via iPhone 1
先找瓶颈么，找到了再对应优化
|
 |
32
designer 2016-08-03 08:55:21 +08:00
图喵 表示太恐怖了
|
 |
33
CupTools 2016-08-03 08:58:30 +08:00 1
学校有人用 sed | awk | > | cat 去转换 BIND zones ， 3 亿纪录花了一晚上
我看了看他的 bash script ，各种打开文件关闭文件管道 不慢才怪 同楼上 先找瓶颈 |
|
34
nellace OP |
 |
36
123s 2016-08-03 09:57:42 +08:00
加入收藏
|
 |
37
sgissb1 2016-08-03 10:41:37 +08:00
其实 c#写的也问题不大，只要正对某个“平台”选择特定的平台编译就好了。
然后看瓶颈，是 io 瓶颈，就改 ssd ，用 ssd 做转换任务中的临时盘，转换完成了，再搬会机械盘。 如果是内存，就加内存。是 cpu 就加 cpu 。 实在没有其他办法，你也只能考虑用 c 重写，或者楼上几位说的用 gpu 。 一般服务端优化的套路大致从这几个入手 |
 |
39
bleaker 2016-08-03 11:24:24 +08:00
这个场景蛮适合用七牛的，存储和转码基本是白菜价，和电费差不多了。。
|
 |
40
zqiyun 2016-08-03 13:12:27 +08:00
又不用你盯着， 8 小时就 8 小时呗，睡一觉不就完成了
|
Select Language