2009-05-17 4 views
18

Sto scrivendo un'applicazione che ha bisogno di ridimensionare grandi quantità di immagini ... e queste sono le mie esigenze:più veloce/C++ immagine C ridimensionamento biblioteca

  • C/C++
  • supporto jpeg/png almeno
  • veloce
  • Cross-Platform

Finora le mie opzioni sono:

  • OpenCV
  • CImg
  • ImageMagick
  • GraphicsMagick (si dice di essere veloce)
  • Diavolo
  • GIL da Boost
  • CxImage
  • Imlib2 (si dice di essere veloce)
  • Altri?

Tutti questi sarebbe ottenere il lavoro fatto, ma io sto cercando il più veloce qui, e io non sono riuscito a trovare nessuna benchmark sulle loro prestazioni.

+10

Il ridimensionamento (come negli interi caricamenti di flickr del mese scorso, ad esempio) di immagini suona come un'applicazione altamente specializzata, quindi mi chiedo perché la multipiattaforma sia così importante? Se si può fare affidamento su hardware specifico, probabilmente si sarà in grado di andare così velocemente sulla parte del ridimensionamento che si dovrebbe seriamente iniziare a pensare a come leggere/scrivere tutti quei dati abbastanza velocemente. – Chris

+1

"Non sono stato in grado di trovare alcun punto di riferimento": puoi sempre andare in panchina, arkali tu stesso e poi condividere i tuoi risultati qui :-) – lothar

+0

@chris Mi rendo conto che questa è una vecchia domanda ma con una CPU e immagini generiche su un locale il ridimensionamento del disco è quasi certamente un problema legato al calcolo. Ora, se intendi specializzate (ad esempio CUDA) e non hardware specifico, puoi essere in grado di farlo vincolare all'IO. – Yaur

risposta

13

Dai uno sguardo allo Intel IPP (Integrated Performance Primitives) (il collegamento Wiki è migliore di quello Intel ...) funziona anche su AMD e ha funzioni per ridimensionare le immagini (bilineare, vicino più prossimo, ecc.) E funziona su Linux e Windows.

Non è gratuito (ma non rompere la banca), ma è il più veloce che si possa trovare.

+1

Se l'immagine viene decodificata, l'IPP è una buona scelta. Tuttavia, potrebbe essere più veloce decodificando e ridimensionando in un unico passaggio. Non so come usare IPP per ridimensionare senza decodificare prima la bitmap 1: 1. – kcwu

+2

pensa per un momento a questa affermazione. Quale parte di farlo in un singolo (complicato) passo lo renderà più veloce? Le routine di decodifica dell'immagine devono ancora decodificare ogni pixel affinché le routine di filtro possano filtrarle. Anche se la loro era una libreria che lo ha fatto in un unico passaggio - il nostro benchmarking delle routine IPP indicherebbe che un 2pass con IPP sarebbe probabilmente più veloce comunque. –

+0

forse perché nel primo passaggio può utilizzare i dati già nella cache della cpu – CiNN

0

Se siete in cerca di roba gratis, e vogliono fare le cose in fretta, cercare di sviluppare un plugin Gimp C-compilato: questo è molto facile, e credo che Gimp fa un buon lavoro a ridimensionamento:

Questo potrebbe non essere il più veloce da ridimensionare, ma il più economico (gratuito) e il più veloce da sviluppare.

Dai uno sguardo allo there.

+0

Oppure chiamate il resizer tramite un plugin Python. –

+0

Gimp è una GUI. Penso che la domanda riguardi una libreria che può essere usata da C/C++. So che Gimp può essere controllato da script, ma non sarà veloce. – guettli

+0

Si potrebbe pensare che sia lento a causa del tempo necessario per il lancio, ma il ridimensionamento usando Gimp è molto veloce, e se lo si tiene caricato in memoria, forse questo non è il più veloce, ma è gratuito ** e ** molto veloce. Prova da solo potresti essere sorpreso;) –

0

Se stai cercando open source, che ne dici di FreeImage? Per le cose commerciali, uso Snowbound. Entrambi sono abbastanza veloci e capaci di diversi formati di immagine e algoritmi di ridimensionamento.

+1

La licenza pubblica FreeImage non impedisce l'uso commerciale. – darklon

4
commento

@ Chris di Becke:.?

"pensare per un attimo su questa affermazione Quale parte di farlo in un unico passaggio (complicato) sta per rendere più veloce le procedure di decodifica dell'immagine ancora bisogno di decodificare ogni pixel in modo che le routine di filtro li filtrino. "

Non è sempre il caso. Ad esempio, quando decodifica un JPEG puoi chiedere alla libreria JPEG di darti un'immagine di 1/2, 1/4, 1/8 (o qualcosa del genere, è da un po 'che non guardo nei dettagli) che può fai a meno di dover decodificare i dettagli in più, a causa del modo in cui funziona JPEG. Può essere molto più veloce di una decodifica completa + scala.

(Ovviamente potrebbe essere necessario scalare un po 'in seguito se l'immagine più piccola non è la dimensione esatta che si desidera.)

(Scusate posso postare solo questa risposta come commento a causa di non reputaton. La prima volta ho provato a postare nulla qui. Se qualcuno vuole pubblicare questo o qualcosa di simile, come un commento e cancellare la mia risposta, non esitate!)

+0

Ha senso, l'algoritmo di ridimensionamento darà risultati migliori con più dati (solo a un certo livello piccolo non ha importanza), ma poi è necessario lavorare con tutti i diversi metodi di compressione (BMP, GIF, PNG, JPEG) e scrivere una versione specifica. –

+0

Penso che JPEG sia l'unico formato che può essere ottimizzato in questo modo. È strutturato in modo che i diversi livelli di dettaglio possano essere separati prima della decodifica completa. –

+0

Lavorare in blocchi significa anche che è possibile sovrapporre la decodifica e la ricodifica. Ad esempio, libvips (vedere la risposta di @ bithive) eseguirà lo streaming delle immagini, eseguendo la decodifica, il processo e la ricodifica in parallelo. Per molte operazioni, la decodifica/ricodifica è un passo limitatore di velocità a thread singolo, quindi questo può dare un grande aumento di velocità. – user894763

5

Se IPP fa what you need (ad esempio, la funzione di ridimensionamento nella sezione 12), quindi dubito troverai codice x86 significativamente più veloce in qualsiasi altro posto. Tenete presente che potrebbe ricadere su "implementazioni di riferimento" più lente se eseguito su CPU AMD.

Se la CPU non soddisfa i requisiti di prestazione, è possibile prendere in considerazione il ridimensionamento su una GPU utilizzando OpenGL (l'implementazione più semplice utilizzando la mappatura della trama trarrebbe vantaggio dagli interpolatori hardware, per un filtraggio più complesso utilizzare il codice shader GLSL). La capacità della GPU di fare questo genere di cose circa cento volte più velocemente di una CPU (dare o prendere uno zero) deve essere confrontata con il trasferimento dei dati relativamente lento da e verso la scheda (in genere un gigabyte o due al secondo al massimo).

9

Dai un'occhiata a VIPS. È il più veloce che ho trovato finora.

+0

Non ho usato VIPS da solo. Ma sembra essere veloce (e LGPL): http://www.vips.ecs.soton.ac.uk/index.php?title=Speed_and_Memory_Use – guettli