Newsgroup: it.comp.www.php
Titolo: Libreria GD e foto di grandi dimensioni

Secondo voi è fattibile creare un programma che gestisca bene il
ridimensionamento di immagini in ingresso superiori ai 10 megabyte
(con la libreria GD)?
Il mio dubbio è che il server si impalli per il troppo carico di
lavoro, c'è da dire che tutto resterebbe su un server interno
all'azienda e non collegato a internet.
--
Stucco
http://www.vstucco.it



Tutto e` possibile, basta averne le risorse.
Con file del genere dovrai sicuramente avere tanta RAM, un buon
processore, e aumentare il timeout degli script e l'allocazione di memoria
dell'interprete PHP.
Se sono JPEG da 10 Mb ricordati che potrebbero arrivare a occupare qualche
centinaio di Gb, e che se le copi con le GD devi raddoppiare questa
quantita`.
Insomma, ci vuole uno studio dietro, ma non e` impossibile.
Bye.

Stucco ha scritto:

Sei vincolato realmente all'uso della GD, o è una preferenza / comodità? 
(trattandosi di un server locale mi dà l'idea di essere abbastanza 
libera la scelta)
Qualche tempo fa, per diletto, avevo provato a realizzare un meccanismo 
di image hosting che riconvertiva le immagini in jpeg2000, quindi 
un'operazione decisamente pesante (con immagini di 1-2mb).
Ad ogni modo, il dato interessante è che rispetto al punto di partenza 
iniziale ero riuscito ad ottimizzare (ricompilando con varie flags) il 
programma di conversione letteralmente decimando il tempo necessario.
Io avevo utilizzato jasper, comunque puoi sempre ricompilare le gd2 o 
qualsiasi altro programma.
-- 
Fabio
http://www.ilbello.com

 Insomma, ci vuole uno studio dietro, ma non e` impossibile.
Qualche centinaio di Gb durante il ridimensionamento o anche dopo?!?
gli originali dovrebbero essere dei tif
--
Stucco
http://www.vstucco.it

 gli originali dovrebbero essere dei tif
Se sono tiff sono poco/nulla compresse, quindi una da 10 Mb arriva al
massimo a 20-25 Mb.
Bye.

 Qualche centinaio di Gb durante il ridimensionamento o anche dopo?!?
Me ne sono accorto adesso... Intendevo qualche centinaio di Mb,
naturalmente... :)
Bye.

(con la libreria GD)?
Mi sembra che GD lavori in-memory, quindi ti servira' parecchia RAM.
Viceversa, *mi sembra* che ImageMagick lavori a memoria semicostante
(O(W) anziche' O(W*H)).
Leonardo
-- 
 What do you make, so fair and bright;
 What do you build with sails for flight;
 What do you weave with wool so white?

 naturalmente... :)
Ma qualche centinaio di Mb intendi durante il salvataggio o dopo il
salvataggio?  durante vero? perchè se io carico un tif o un jpg che è
10 mega durante l'elaborazione potrà crescere, ma dopo tornerà 10 mega
se non faccio particolari operazione sull'immagine. confermi?
I giga mi avevano fatto rizzare i capelli hihihi
--
Stucco
http://www.vstucco.it

 se non faccio particolari operazione sull'immagine. confermi?
Allora, facciamo un po' di chiarezza.
Alle GD non interessa niente la dimensione del file su disco, ma il numero
di pixel e la loro profondita`.
Se hai un'immagine 1024x768 a 24 bit, saranno 1024x768x3 bytes occupati
(circa 2 Mb). Se fai immagini 40.000x30.000 a 24 bit piu` 8 di alpha
channel, andrai a occupare 1.200.000.000 x 4 = 4.800.000.000 bytes, quindi
quasi 5 Gb.
Ogni oggetto immagine di GD occupa memoria in base a questi calcoli,
quindi se carichi un'immagine da 1024x768 e la ridimensioni a 640x480 con
imagecopyresampled(), occuperai 2 Mb per la prima immagine, piu` 700 Kb per
la seconda, totale circa 3 Mb (piu` qualche Kb per i dati temporanei della
libreria e dell'interprete PHP).
Bye.

 (O(W) anziche' O(W*H)).
Mi interesserebbe capire bene questa cosa.
Riesci a spiegarla piů da utonto ? :-)
Grazie comunque !
R.

Riesci a spiegarla più da utonto ? :-)
Per ricampionare una foto, diciamo, da 8000x6000 a 1000x750, puoi fare in
due modi: carichi tutto in memoria, per cui ti serve una quantita' di RAM
che varia con il prodotto di larghezza e altezza; e, probabilmente, anche
con il prodotto di larghezza e altezza della destinazione.
Per cui 8000x6000 = 48 megapixel = 144 megabyte di memoria... piu' quella
che ti serve per l'immagine destinazione di 1000x750 (altri 2 Mb circa).
Con questa strategia la memoria e' proporzionale a W e H e quindi si dice
che il dispendio e' O(W*H).
Ma in un caso del genere puoi immagazzinare lo "stato" del ricampionatore
(l'equivalente di due righe di dati) e una riga di input, e con quello di
volta in volta decidere come aggiornarlo e se inviare una riga in output;
il ricampionatore potra' essere leggermente meno efficiente, ma ti occupa
soltanto 4*W pixel-equivalenti, qualunque sia H. Nell'esempio di prima ti
bastano 32 kilopixel, ossia 96 Kb, anziche' 144 Mb.
Altre strategie possono essere quella di considerare 8000x6000 come dieci
strisce di 8000x600, da ricampionare a 1000x75. O in cinquanta strisce di
8000x120. Cosi' fai 50 ricampionamenti da 2.88 Mb invece di uno da 144.
La memoria che ti serve aumenta solo quanto aumenta la larghezza; quindi,
non e' costante, pero' e' "semi-costante". Aumenta meno di quanto farebbe
se andasse come W*H.
Specie se lavori in JPEG su standard output e' conveniente, perche' inizi
subito a mandare qualcosa al client che "crede" che tu abbia finito in un
tempo 50 volte inferiore; in realta' mentre scarica le prime 120 righe tu
stai ancora a ricampionare le seconde 120, e cosi' via.
Di sicuro le gdlib usano la strategia in-memory, W*H. Altre utility, e mi
PARE (non sono sicuro) che ImageMagick sia fra queste, usano W.


 PARE (non sono sicuro) che ImageMagick sia fra queste, usano W.
Chiarissimo e interessantissimo, ti ringrazio molto !
R.