2012-07-30 16 views
14
 
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; 

मैं एक कमांड का उपयोग करके मूल से ~ 30 फसलों को उत्पन्न करने की कोशिश कर रहा हूं (प्रत्येक आदेश के लिए एक कमांड का उपयोग करने से एक कमांड का उपयोग करना काफी तेज है)। हालांकि, इसे खत्म करने में काफी समय लग रहा है (~ 30s)। इसे गति देने के लिए कोई सुझाव? क्या आकार बदलने का आदेश ओपनसीएल के माध्यम से जीपीयू का लाभ उठा सकता है?ImageMagick बैच आकार बदलने का प्रदर्शन

अद्यतन:

  • -Thumbnail का उपयोग -resize के बजाय चीजों को बेहतर बनाता है
  • (धन्यवाद टिप के लिए @AR करने के लिए) libjpeg-टर्बो के साथ ImageMagick संकलन भी 20% से गुना बेहतर बनाता है

उत्तर

33

आपको यह जांचना चाहिए कि आपकी छवि मैगिक स्थापना ओपनसीएल समर्थन के साथ आता है:

convert -list configure | grep FEATURES 
FEATURES  HDRI OpenCL 

यह आदेश

convert -version 

भी समर्थित सुविधाओं के बारे में जानकारी देना चाहिए: 510,403,210 यह (मेरे जैसे) है, तो आप कुछ इस तरह देखना चाहिए।

यदि आपको छविमैजिक का नवीनतम संस्करण प्राप्त करने की आवश्यकता नहीं है, जिसमें ओपनसीएल समर्थन संकलित है या यदि आप स्वयं को स्रोतों से पैकेज बनाते हैं, तो सुनिश्चित करें कि ओपनसीएल का उपयोग किया जाता है।


अद्यतन:

ओह इंतजार। एक और विशेषता है जो आपकी मदद कर सकती है, जिसे ओपनएमपी (बहु-प्रसंस्करण के लिए) कहा जा सकता है।

जब ओपनएमपी सक्षम है, तो ImageMagick आदेश आपके सिस्टम के सभी कोरों पर समानांतर में निष्पादित कर सकते हैं। तो यदि आपके पास क्वाड-कोर सिस्टम है, और एक छवि का आकार बदलता है, तो आकार 4 कोर पर होता है (या यदि आपके पास हाइपरथ्रेडिंग है तो 8 भी)।

अब आप ImageMagick को अपने आदेश के लिए बेंचमार्क चलाने के लिए अंतर्निहित -bench विकल्प का भी उपयोग कर सकते हैं। उदाहरण के लिए:

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

यह आदेश -resize 500% साथ ImageMagick बताता प्रत्येक दिशा में 500% द्वारा निर्मित आईएम logo: छवि को मापना convert आदेश को चलाने के लिए। -bench 10 हिस्सा यह बताता है एक पाश में है कि एक ही आदेश को चलाने के लिए 10 बार और फिर प्रिंट प्रदर्शन परिणाम:

  • जब से मैं OpenMP सक्षम हो, तो मैं केवल 1 धागा (Performance[1]:) था नहीं है।
  • यह रिपोर्ट करता है कि यह 10 पुनरावृत्तियों (10i) चला गया।
  • गति प्रति सेकंड लगभग 0.7 पुनरावृत्तियों (0.689ips) थी।
  • कुल उपयोगकर्ता-आवंटित समय 14.420 सेकंड था।

आप पता करना चाहिए कि आपके सिस्टम इस आदेश के साथ संसाधन सीमा के बारे में की स्थापना की है:

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

आप अपने मौजूदा सिस्टम सेटिंग देख सकते हैं (चूक - मैं उन्हें tweak नहीं था)। कॉलम हेडर में से प्रत्येक कीवर्ड आप अपने सिस्टम को पंप कर सकते हैं।

  • files को परिभाषित करता है अधिकतम समवर्ती खोला जो ImageMagick उपयोग होगा फ़ाइलें।
  • memory, map, area और disk संसाधन सीमा बाइट्स में परिभाषित की गई है। सेटिंग उन्हें विभिन्न मानों पर सेट करने के लिए आप एसआई उपसर्ग, .e.g 500MB का उपयोग कर सकते हैं)।

अगर मैं इस सिस्टम पर ImageMagick के लिए OpenMP थी, मैं आदेश, 2 समानांतर धागे सक्षम बेंचमार्क फिर से चलाने के लिए और देखने के लिए

convert -limit thread 2 

चला सकते हैं, तो यह वास्तव में एक बनाता है अंतर, और यदि ऐसा है तो कितना। मैं 4 या यहाँ तक कि 8 सीमा निर्धारित और अभ्यास दोहरा सकते ....


अंत में, यदि आप ImageMagick के पिक्सेल कैश के आंतरिक प्रारूप के साथ प्रयोग कर सकता है, कहा जाता है MPC (Magick पिक्सेल कैश)। कुछ लोग कहते हैं कि बड़े परिचालनों के लिए प्रदर्शन यहां सुधारता है, लेकिन मेरे पास इसका कोई व्यक्तिगत अनुभव नहीं है।

पहले एमपीसी के लिए अपने आधार चित्र कन्वर्ट:

convert input.jpeg input.mpc 

और उसके बाद ही चलाएँ:

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

करें और देखें कि यह आप में काफी बचत होती है समय पर।

अधिकांश आप इस एमपीसी प्रारूप भी "इनलाइन" (विशेष mpr: अंकन का उपयोग), आप कैसे mpr: प्रारूप (स्मृति कार्यक्रम रजिस्टर) का उपयोग करने का चाल लागू किया के समान है कि एक नामित में छवि पढ़ता उपयोग कर सकते हैं की संभावना मेमोरी रजिस्टर लेकिन मैंने इस तकनीक को वास्तविक दुनिया की समस्या के लिए कभी भी कोशिश नहीं की है, इसलिए मैं यह नहीं कह सकता कि यह वास्तविक जीवन में कैसे काम करता है।


अद्यतन 2:

एक और विचार:

अपने सटीक ImageMagick संस्करण के लिए पहले जांच कर लें: चलाने convert -version।यह वह जगह है -

मामले में अपने ImageMagick एक Q16 (या यहां तक ​​Q32 या Q64) ने अपने संस्करण स्ट्रिंग (अर्थात, वह अपनी आंतरिक प्रक्रियाओं सभी छवियों 16bit चैनल गहराई है, जो डबल स्मृति Q8 की तुलना में की आवश्यकता है के लिए विचार करना) में है डिफ़ॉल्ट आजकल - आप परीक्षण कर सकते हैं कि Q8-build पर स्विच करके आप कौन से प्रदर्शन लाभ प्राप्त करेंगे। (आप भुगतान करेंगे अपने प्रदर्शन गुणवत्ता नुकसान के साथ जीतता है, और यदि आप इसके साथ या नहीं रह सकता जाँच करने के लिए होगा ....)

+0

आपकी प्रतिक्रिया के लिए धन्यवाद। मुझे शायद ध्यान दिया जाना चाहिए कि मेरी ImageMagick स्थापना में OpenMP सक्षम है। दूसरे शब्दों में, कमांड एकाधिक कोरों में समानांतर है। इसे गति देने का कोई और तरीका? – mantithetical

+0

@ मंथिथिकल: स्टैक ओवरफ्लो पर, कोई कहता है कि 'धन्यवाद' आम तौर पर उत्तर देने वाले उत्तर होते हैं जो अंतर्दृष्टिपूर्ण होते हैं। :-) –

+0

@ mantithetical: ऊपर मेरा अद्यतन उत्तर देखें ... –

11

आप CPU समय जा रहा है 3 करने के लिए कार्य:

  • जेपीईजी डिकंप्रेशन;
  • आकार बदलें;
  • जेपीईजी recompression

(ही फसल अपने समय के शायद 1% लेता है।)

जेपीईजी को डिकोड करने के लिए, बस इसे एक बार करते हैं, रैम में परिणाम पकड़ है, और प्रत्येक उत्पादन के लिए पुन: उपयोग। (नीचे विवरण।) इस तरह, लागत महत्वहीन होगी।

जेपीईजी को एन्कोड करने के लिए, libjpeg-turbo का उपयोग करें; एक ही एपीआई, लेकिन यदि आप x86- {32,64} या एआरएम हार्डवेयर का उपयोग करते हैं तो 2-4x स्पीडअप।

आकार बदलने के लिए, ImageMagick फोटोशॉप और जीआईएमपी को छोड़कर ~ 100x जितना अधिक CPU का उपयोग करने के लिए जाना जाता है। इसमें सभी फोटो दर्शक शामिल हैं। यह प्रति पिक्सेल एकाधिक त्रिकोणमितीय कार्य कर रहा है, जबकि हर कोई सिर्फ एक गुणा करता है। कभी-कभी, यदि आप छवि में किनारे के पास पिक्सल देखते हैं, तो आप छवि मैजिक अपने प्रतिस्पर्धियों की तुलना में बेहतर रंग चुन सकते हैं। लेकिन अगर आपको लगता है कि एचटीएमएल 5, फ्लैश, सिल्वरलाइट, जावा, जीडी (पर्ल, पीएचपी, और पायथन वेब ऐप के साथ लोकप्रिय) आदि ठीक दिखते हैं, तो आपको ऐसी छद्म-एआई (कृत्रिम बुद्धि) की आवश्यकता नहीं है। आप जीपीयू (ओपनसीएल) हॉर्स पावर या अधिक सीपीयू (ओपनएमपी) को ImageMagick में फेंकने में सक्षम हो सकते हैं, लेकिन परेशान क्यों हो?

उच्च दक्षता के लिए, ImageMagick (डी फैक्टो मानक) के बराबर Imlib2 है। यह छविमैजिक के रूप में लगभग ओएस/भाषा वातावरण से उपयोग योग्य है।

आपका "कन्वर्ट" शेल कमांड उच्च स्तर की भाषा कॉलिंग की 10-20 लाइनों के बराबर है Ilib2: जेपीईजी को डिकंप्रेस करें, और फिर बार-बार फसल, आकार बदलें और जेपीईजी को संपीड़ित करें।

फसल (या एकाधिक आउटपुट) के बिना एक उदाहरण है: Stretch, resize, or thumbnail an image using Perl

मुझे पता है अगर आप अन्य उदाहरण चाहते हैं।

+0

आपके लिए प्रतिक्रिया के लिए धन्यवाद। Imlib2 पर जाने का विकल्प नहीं है। Libjpeg-turbo के साथ ImageMagick का उपयोग करने का कोई तरीका है? – mantithetical

+0

@AR: मुझे आपके कथन के बारे में निश्चित नहीं है। छवि मैजिक 'आकार के लिए एकाधिक त्रिकोणमितीय कार्यों को प्रति पिक्सेल' और 'छद्म-एआई' आकार बदलने के लिए। क्या यह केवल तभी नहीं है जब आप 'एडैप्टिव-रीसाइज' चुनते हैं? –

+0

नहीं, यदि आप किसी भी तरह का ईडब्ल्यूए करते हैं, तो भार प्रति गणना पिक्सेल की गणना की जाती है, जो ट्रिग का उपयोग करती है। –

0

पार्टी के लिए देर हो चुकी है लेकिन अगर कोई भी एक ही समस्या है तो यह मेरी वर्तमान विधि है। यदि आप बैच प्रोसेसिंग मूल रूप से ट्रांसफॉर्म कर रहे हैं लेकिन कई हज़ारों छवियों में, मेरे अनुभव में आपको ओपनएमपी से ज्यादा लाभ नहीं मिलता है जो 'जटिल' बड़े जटिल परिवर्तनों के लिए अच्छा होता है। मेरा समाधान समानांतर में व्यक्तिगत प्रक्रियाओं को उत्पन्न करने के लिए एक बैश स्क्रिप्ट है।

#!/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 

यह सभी टीआईएफ फाइलों को 'उपहार' निर्देशिका में 'उपहार' निर्देशिका में gifs में परिवर्तित करता है। अगर आपको इस स्क्रिप्ट को रोकना है, तो यह अगली बार छोड़ दिया जाएगा जहां यह अगली बार छोड़ दिया जाएगा। यह मेरे एमबीपी में सभी 16 कोरों को चबाता है और एकल कोर विधि से लगभग 12-14x तेज है जबकि मैं वर्तमान में 150,000 छवियों को परिवर्तित कर रहा हूं।

संबंधित मुद्दे