Hiệu suất thay đổi kích thước hàng loạt của ImageMagick

Question

 
convert \ 
    original.jpg \ 
    -quality 85 \ 
    -colorspace rgb \ 
    -profile /var/tmp/sRGB.icm \ 
    -strip \ 
    -profile /var/tmp/sRGB.icm \ 
    -filter Lanczos \ 
    -write mpr:17JPCONV1-original \ 
    +delete \ 
mpr:17JPCONV1-original -crop '3000x2001+0+491' -resize '190x126!>' -write thumbWide.jpg +delete \ 
mpr:17JPCONV1-original -crop '2981x2983+8+0' -resize '75x75!>' -write thumbStandard.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '163x163!>' -write hpSmall.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '1024x1019!>' -write jumbo.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '190x189!>' -write articleInline.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '2048x2037!>' -write superJumbo.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '592x589!>' -write tmagArticle.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '3000x2983!>' -write popup.jpg +delete \ 
mpr:17JPCONV1-original -crop '2981x2983+8+0' -resize '640x640!>' -write square640.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x1689+0+647' -resize '3000x1688!>' -write videoSmall.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '503x500!>' -write slide.jpg +delete \ 
mpr:17JPCONV1-original -crop '2981x2983+8+0' -resize '151x151!>' -write moth.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2001+0+491' -resize '337x225!>' -write hpMedium.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2001+0+491' -resize '395x264!>' -write sfSpan.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x1689+0+647' -resize '3000x1688!>' -write videoLarge.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x1689+0+647' -resize '511x288!>' -write hpLarge.jpg +delete \ 
mpr:17JPCONV1-original -crop '2981x2983+8+0' -resize '320x320!>' -write square320.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x1689+0+647' -resize '600x338!>' -write articleLarge.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2001+0+491' -resize '3000x2000!>' -write videoThumb.jpg +delete \ 
mpr:17JPCONV1-original -crop '2981x2983+8+0' -resize '150x150!>' -write thumbLarge.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '533x530!>' -write blog533.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '151x151!>' -write blogSmallInline.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '362x360!>' -write tmagSF.jpg +delete \ 
mpr:17JPCONV1-original -crop '2981x2983+8+0' -resize '190x190!>' -write filmstrip.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '480x478!>' -write blog480.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x2983+0+0' -resize '427x425!>' -write blog427.jpg +delete \ 
mpr:17JPCONV1-original -crop '2981x2983+8+0' -resize '50x50!>' -write blogSmallThumb.jpg +delete \ 
mpr:17JPCONV1-original -crop '3000x1401+0+791' -resize '151x70!>' miniMoth.jpg; 

Tôi đang cố gắng tạo ~ 30 vụ từ bản gốc bằng một lệnh (sử dụng một lệnh nhanh hơn đáng kể so với sử dụng một lệnh cho mỗi lần cắt). Tuy nhiên, việc này mất khá nhiều thời gian (~ 30 giây) để hoàn thành. Bất kỳ đề xuất để tăng tốc độ này lên? Lệnh thay đổi kích thước có thể tận dụng lợi thế của GPU thông qua OpenCL không?

Cập nhật:

• Sử dụng -thumbnail thay vì -resize cải thiện điều
• (Nhờ @AR for the tip) Biên soạn ImageMagick với libjpeg-turbo cũng cải thiện lần 20%

Answer 1

Bạn nên kiểm tra xem cài đặt ImageMagick của bạn có hỗ trợ OpenCL không:

convert -list configure | grep FEATURES 

Nếu nó (như tôi), bạn sẽ thấy một cái gì đó như thế này:

FEATURES  HDRI OpenCL 

Lệnh này

convert -version 

cũng nên cung cấp thông tin về các tính năng được hỗ trợ.

Nếu không, bạn nên chăm sóc phiên bản mới nhất của ImageMagick có hỗ trợ OpenCL được biên soạn. Hoặc nếu bạn tự xây dựng gói từ nguồn, hãy đảm bảo OpenCL được sử dụng.

---

Cập nhật:

Oh chờ đợi. Có một tính năng khác có thể giúp bạn, được gọi là OpenMP (đối với đa xử lý).

Khi OpenMP được bật, lệnh ImageMagick có thể thực thi song song trên tất cả các lõi của hệ thống của bạn. Vì vậy, nếu bạn có một hệ thống quad-core, và thay đổi kích thước một hình ảnh, việc thay đổi kích thước xảy ra trên 4 lõi (hoặc thậm chí 8 nếu bạn có siêu phân luồng).

Bây giờ bạn cũng có thể sử dụng tùy chọn dựng sẵn -bench để ImageMagick chạy điểm chuẩn cho lệnh của bạn. Ví dụ:

convert logo: -resize 500% -bench 10 logo.png 
    Performance[1]: 10i 0.689ips 1.000e 14.420u 0:14.510 

Lệnh này với -resize 500% nói với ImageMagick để chạy các lệnh convert quy mô được xây dựng trong IM logo: hình ảnh bằng 500% theo mỗi hướng. Phần -bench 10 nói với nó để chạy cùng lệnh 10 lần trong một vòng lặp và sau đó in kết quả thực hiện:

• Vì tôi không có OpenMP được kích hoạt, tôi chỉ có 1 chủ đề (Performance[1]:).
• Nó báo cáo rằng nó chạy 10 lần lặp (10i).
• Tốc độ gần 0,7 lần lặp/giây (0.689ips).
• Tổng thời gian người dùng phân bổ là 14.420 giây.

Bạn nên tìm hiểu làm thế nào hệ thống của bạn được thiết lập liên quan đến giới hạn tài nguyên với lệnh này:

 
identify -list resource 
    File  Area  Memory  Map  Disk Thread   Time 
    -------------------------------------------------------------------- 
    192 4.295GB  2GiB 4GiB unlimited   1 unlimited 

Bạn có thể thấy các thiết lập hệ thống hiện tại của tôi (mặc định - Tôi không tinh chỉnh chúng). Mỗi từ khóa trong tiêu đề cột bạn có thể sử dụng hệ thống của bạn.

• files xác định các tệp được mở đồng thời tối đa mà ImageMagick sẽ sử dụng.
• Số memory, map, area và disk giới hạn tài nguyên được xác định bằng byte. Để đặt chúng thành các giá trị khác nhau, bạn có thể sử dụng tiền tố SI, .e.g 500MB).

Nếu tôi có OpenMP cho ImageMagick trên hệ thống này, tôi có thể chạy

convert -limit thread 2 

để cho phép 2 đề song song, tái chạy benchmark và xem nếu nó thực sự làm cho một sự khác biệt, và nếu có thì bao nhiêu. Tôi có thể thiết lập giới hạn đến 4 hoặc thậm chí 8 và lặp lại các excercise ....

---

Cuối cùng, bạn có thể thử nghiệm với các định dạng nội bộ của bộ nhớ cache điểm ảnh ImageMagick, được gọi là MPC (Magick Pixel Cache). Một số người nói rằng đối với các hoạt động lớn hiệu suất cải thiện ở đây, nhưng tôi không có kinh nghiệm cá nhân với nó.

Chuyển đổi hình ảnh cơ sở của bạn cho MPC đầu tiên:

convert input.jpeg input.mpc 

và chỉ sau đó chạy:

convert input.mpc [...your long-long-long list of crops...] 

và xem nếu điều này giúp bạn tiết kiệm đáng kể về thời gian.

Nhiều khả năng bạn có thể sử dụng định dạng này MPC thậm chí "inline" (sử dụng mpr: ký hiệu đặc biệt), tương tự như cách bạn áp dụng các thủ thuật của việc sử dụng các định dạng mpr: (chương trình bộ nhớ đăng ký) mà đọc hình ảnh vào một tên bộ nhớ đăng ký. Nhưng tôi chưa bao giờ thử kỹ thuật này với một vấn đề thế giới thực, vì vậy tôi không thể nói nó hoạt động ra sao trong cuộc sống thực.

---

Cập nhật 2:

hơn Một ý tưởng:

séc đầu tiên cho phiên bản ImageMagick chính xác của bạn: chạy convert -version.

Trong trường hợp ImageMagick của bạn có một Q16 (hoặc thậm chí Q32 hoặc Q64) trong chuỗi phiên bản của nó (có nghĩa là, các quy trình nội bộ của mình xem xét tất cả các hình ảnh có chiều sâu kênh 16bit, đòi hỏi bộ nhớ tăng gấp đôi so với Q8) - đây là mặc định hiện nay - bạn có thể kiểm tra những lợi ích hiệu suất mà bạn sẽ đạt được bằng cách chuyển sang phiên bản Q8. (Bạn sẽ trả hiệu suất của bạn thắng với tổn thất chất lượng, và bạn sẽ phải kiểm tra xem bạn có thể sống với nó hay không ....)

Answer 2

Bạn thời gian CPU sẽ đến 3 nhiệm vụ:

• Giải nén JPEG;
• đổi kích thước;
• JPEG nén lại

(Cắt thân mất có lẽ 1% thời gian của bạn.)

Để giải mã JPEG, chỉ làm điều đó một lần, giữ kết quả trong RAM, và tái sử dụng cho mỗi đầu ra. (Chi tiết bên dưới.) Bằng cách đó, chi phí sẽ không đáng kể.

Để mã hóa JPEG, hãy sử dụng libjpeg-turbo; cùng một API, nhưng tăng tốc 2-4x nếu bạn sử dụng phần cứng x86- {32,64} hoặc ARM.

Để thay đổi kích thước, ImageMagick nổi tiếng về việc sử dụng ~ 100x CPU nhiều như bất kỳ phần mềm nào khác ngoại trừ PhotoShop và GIMP. Điều đó bao gồm tất cả người xem ảnh. Nó thực hiện nhiều hàm lượng giác trên mỗi pixel, trong khi mọi người khác chỉ thực hiện một phép nhân. Đôi khi, nếu bạn nhìn vào các điểm ảnh gần cạnh trong hình ảnh, bạn có thể thấy ImageMagick chọn màu tốt hơn so với các đối thủ cạnh tranh của nó. Nhưng nếu bạn nghĩ rằng HTML5, Flash, Silverlight, Java, GD (phổ biến với Perl, PHP, và các ứng dụng web Python) vv trông tốt, sau đó bạn không cần giả như vậy AI (trí thông minh nhân tạo). Bạn có thể ném mã lực GPU (OpenCL) hoặc nhiều CPU (OpenMP) vào ImageMagick, nhưng tại sao lại bận tâm?

Để có hiệu quả cao, tương đương với ImageMagick (tiêu chuẩn thực tế) là Imlib2. Có thể sử dụng được từ hầu hết các môi trường hệ điều hành/ngôn ngữ như ImageMagick.

Lệnh shell "chuyển đổi" của bạn tương đương với 10-20 dòng của ngôn ngữ cấp cao gọi Imlib2: giải nén JPEG, sau đó liên tục cắt, thay đổi kích thước và nén JPEG.

Một ví dụ mà không cây trồng (hoặc nhiều đầu ra) là: Stretch, resize, or thumbnail an image using Perl

Hãy cho tôi biết nếu bạn muốn ví dụ khác.

Answer 3

Muộn cho bữa tiệc nhưng đây là phương pháp hiện tại của tôi nếu có ai có cùng vấn đề. Nếu bạn đang xử lý hàng loạt các biến đổi cơ bản nhưng trên hàng nghìn hình ảnh, theo kinh nghiệm của tôi, bạn sẽ không nhận được nhiều lợi ích từ openMP mà các đường nối trở nên tốt cho các phép biến đổi phức tạp 'đa chiều'. Giải pháp của tôi là một tập lệnh bash để sinh ra các quy trình riêng lẻ song song.

#!/bin/bash 
counter=0 
for i in tif/*.TIF; 
do 
    y=${i%.TIF} 
    ((counter++)) 
    if [ -s gif$y.gif ];then 
     : 
    else 
     gm convert $i gif$y.gif & 
    fi 
    if [ $counter -eq 30 ];then 
     ((counter =0)) 
     wait 
    fi 
done 
wait 

này chuyển đổi tất cả các file TIF trong thư mục 'tif' vào gifs trong thư mục 'giftif'. Nếu bạn phải dừng tập lệnh này, nó sẽ tiếp tục ở nơi nó bị tắt trong lần sau. Điều này nhai lên tất cả 16 lõi trong MBP của tôi và là khoảng 12-14x nhanh hơn so với phương pháp lõi đơn trong khi tôi hiện đang chuyển đổi 150.000 hình ảnh.