ImageMagick prestazioni ridimensionamento batch

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; 

Sto provando a generare ~ 30 colture da un originale utilizzando un comando (l'utilizzo di un comando è significativamente più rapido rispetto all'utilizzo di un singolo comando per ogni ritaglio). Tuttavia, questo richiede un po '(~ 30s) per finire. Qualche suggerimento per accelerare questo? Il comando di ridimensionamento può sfruttare le GPU tramite OpenCL?

Aggiornamento:

• Utilizzando -thumbnail anziché -resize migliora cose
• (Grazie a @AR per la punta) compilazione ImageMagick con libjpeg-turbo migliora anche i tempi del 20%

Answer 1

Dovresti controllare se l'installazione di ImageMagick viene fornita con il supporto OpenCL:

convert -list configure | grep FEATURES 

Se lo fa (come il mio), si dovrebbe vedere qualcosa di simile:

FEATURES  HDRI OpenCL 

Questo comando

convert -version 

dovrebbe anche dare informazioni sulle funzioni supportate.

Se non si deve cercare dopo aver ottenuto la versione più recente di ImageMagick con il supporto OpenCL compilato. O se si crea il pacchetto da soli dai sorgenti, assicurarsi che OpenCL venga utilizzato.

---

Aggiornamento:

Oh attesa. C'è un'altra funzionalità che potrebbe aiutarti, chiamata OpenMP (per il multiprocessore ).

Quando OpenMP è abilitato, i comandi ImageMagick possono essere eseguiti in parallelo su tutti i core del sistema. Quindi se hai un sistema quad-core e ridimensiona un'immagine, il ridimensionamento avviene su 4 core (o anche 8 se hai hyperthreading).

Ora è possibile utilizzare anche l'opzione integrata -bench per rendere ImageMagick un punto di riferimento per il comando. Ad esempio:

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

Questo comando con -resize 500% dice ImageMagick per eseguire il comando convert per ridimensionare l'immagine incorporato IM logo: da 500% in ciascuna direzione. La parte -bench 10 dice per eseguire lo stesso comando di 10 volte in un ciclo e quindi stampare i risultati delle prestazioni:

• Dal momento che non ho OpenMP abilitato, ho avuto solo 1 filo (Performance[1]:).
• Segnala che ha eseguito 10 iterazioni (10i).
• La velocità era di circa 0,7 iterazioni al secondo (0.689ips).
• Il tempo totale assegnato dall'utente era 14.420 secondi.

Si dovrebbe capire come il vostro sistema è impostato per quanto riguarda i limiti delle risorse con questo comando:

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

È possibile visualizzare le impostazioni del mio sistema corrente (default - Non li ho tweak). Ognuna delle parole chiave nelle intestazioni delle colonne è possibile utilizzare pimp your system.

• Il files definisce il massimo dei file che ImageMagick utilizzerà contemporaneamente aperto.
• I limiti delle risorse memory, map, area e disk sono definiti in byte. Per impostando su valori diversi è possibile utilizzare prefissi SI, .e.g 500 MB).

Se avuto OpenMP per ImageMagick su questo sistema, ho potuto eseguire

convert -limit thread 2 

per consentire 2 fili paralleli, rieseguire il riferimento e vedere se fa davvero differenza, e se sì, quanto. L'ho potuto impostare il limite a 4 o addirittura 8 e ripetere la palestra ....

---

Infine, si potrebbe sperimentare con il formato interno della cache di pixel di ImageMagick, chiamato MPC (Magick Pixel Cache). Alcuni dicono che per le grandi operazioni le prestazioni migliorano qui, ma non ho esperienza personale con esso.

convertire il vostro foto di base per MPC prima:

convert input.jpeg input.mpc 

e solo allora eseguire:

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

e vedere se questo consente di risparmiare in modo significativo in tempo.

Molto probabilmente è possibile utilizzare questo formato MPC anche "in linea" (utilizzando lo speciale mpr: notazione), simile a come è stato applicato il trucco di utilizzare il (programma di registro di memoria) formato mpr: che legge l'immagine in un nome registro di memoria. Ma non ho mai provato questa tecnica per un problema del mondo reale, quindi non posso dire come funziona nella vita reale.

---

Aggiornamento 2:

più Un'idea:

primo assegno per la versione esatta di ImageMagick: eseguire convert -version.

Nel caso il vostro ImageMagick ha un Q16 (o anche Q32 o Q64) nella sua stringa di versione (significato, i suoi processi interni prendere in considerazione tutte le immagini di avere profondità del canale a 16 bit, che richiede il doppio di memoria rispetto al Q8) - questo è il default al giorno d'oggi - puoi provare quali sono i benefici che otterrai raggiungendo una Q8-build. (Si paga le prestazioni vince con perdite di qualità, e si dovrà verificare se è possibile vivere con esso o no ....)

Answer 2

È tempo di CPU sta andando a 3 compiti:

• decompressione JPEG;
• ridimensionamento;
• JPEG ricompressione

(Ritaglio si prende forse l'1% del vostro tempo.)

per la decodifica JPEG, basta farlo una volta, tenere il risultato in RAM, e il riutilizzo per ogni uscita. (Dettagli sotto.) In questo modo, il costo sarà insignificante.

Per codificare JPEG, utilizzare libjpeg-turbo; stessa API, ma un aumento di velocità 2-4x se si utilizza l'hardware x86- {32,64} o ARM.

Per ridimensionare, ImageMagick è noto per l'utilizzo di ~ 100 volte la CPU di qualsiasi altro software eccetto PhotoShop e GIMP. Ciò include tutti i visualizzatori di foto. Sta facendo più funzioni trigonometriche per pixel, mentre tutti gli altri fanno solo una moltiplicazione. A volte, se guardi i pixel vicino a un bordo dell'immagine, puoi vedere che ImageMagick sceglie un colore migliore rispetto ai suoi concorrenti. Ma se pensate che HTML5, Flash, Silverlight, Java, GD (popolare con le applicazioni web Perl, PHP e Python) siano a posto, allora non avete bisogno di tale pseudo-intelligenza artificiale (intelligenza artificiale). Potrebbe essere possibile lanciare GPU (OpenCL) o più CPU (OpenMP) in ImageMagick, ma perché preoccuparsi?

Per l'alta efficienza, l'equivalente di ImageMagick (di fatto standard) è Imlib2. È utilizzabile da quasi tutti gli ambienti OS/linguaggio di ImageMagick.

Il tuo "convertire" comando di shell è equivalente a 10-20 linee di un linguaggio di alto livello chiamando Imlib2: decomprimere JPEG, e poi ripetutamente ritagliare, ridimensionare e comprimere JPEG.

Un esempio senza coltura (o uscite multiple) è: Stretch, resize, or thumbnail an image using Perl

fatemi sapere se volete altri esempi.

Answer 3

In ritardo alla festa, ma questo è il mio metodo attuale se qualcuno ha lo stesso problema. Se si stanno elaborando in batch trasformazioni di base ma più di molte migliaia di immagini, nella mia esperienza non si ottiene molto beneficio da openMP che risulta essere utile per trasformazioni complesse di tipo "multicoring". La mia soluzione è uno script bash per generare i singoli processi in parallelo.

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

Converte tutti i file TIF nella directory 'tif' in gif nella directory 'giftif'. Se devi interrompere questo script, riprenderà da dove è stato interrotto la volta successiva. Questo mastica tutti i 16 core nel mio MBP ed è di circa 12-14 volte più veloce del metodo single core mentre attualmente sto convertendo 150.000 immagini.