Non preoccuparti per il Photoshop. Regge benissimo quelle dimensioni a 300dpi. Preoccupati del tuo Hardware, piuttosto. Con meno di 4GB di RAM avrai qualche problemino.
Se superi i 2GB di file size, dovrai usare un formato speciale del Photoshop. Il Large Document Format (Save as) che ti consente di eccedere il limite di 2GB.
Per ottimizzare il tutto evita quanto segue:
a) non abusare di smart objects (aggiungono informazioni al file ed aumentano il peso finale).
b) merge tutti i livelli che non abbisognano più di modifiche.
c) non usare la massimizzazione di compatibilità per vecchie versioni.
d) rasterizza tutto quanto non necessita più di modifiche.
/* edit */
zedda zedda, è da un pò che ti seguo e mi piacciono le tue risposte. Certo, più per le informazioni che per il tono. Però mi vanno bene così in quanto fanno fare alle mie, che reputo sgraziate, una meno brutta figura.
punto per punto:
1) ho risposto alla preoccupazione della Nostra circa il Photoshop e la sua capacità di gestire 6m di cartellone non alla sua intenzione di lavorare a 300dpi. Saprai meglio di me che non vi è UN solo ed unico modo di fare le cose e molto dipende dal flusso lavorativo della intera catena del valore. In mancanza di info circa carta, tavola, target, accordi con la stampa etc in tutta sincerità mi son attenuto a quello che ho letto della domanda.
Dipende poi tu cosa intendi per cartelloni.
Una scansione di foto aeree viene realizzata a 24-bit color 7.5 microns (~3300 DPI). E' un esempio tra tanti in diversi campi di applicazione dell'imaging.
2) appunto. cfr supra
4) qui sei andato in polemica inutile. Ma è tua scelta e carattere ed io sono l'ultimo a poter parlare in quanto nella classifica di coloro che polemizzano vengo subito dietro di te.
5) http://www.globalsecurity.org/intell/systems/nitfs.htm (formato per 17GB di immagine). Prego vedere di quale campo di applicazioni stiamo parlando.
Le immagini di quelle dimensioni si gestiscono come si gestiscono tutte le altre.
Alla apertura di una immagine solo l'header è caricato in memoria. L'header contiene le informazioni necessarie per determinare la corretta struttura del file. Viene interrogato in questo stadio anche l'index (è un array associativo, o hash, con coppie chiavi->valore integers).
Quando l'applicazione riceve una richiesta di lettura di x numeri di bytes da un offset #n nel file compresso (perché rimane compresso), questa prima calcola i limiti dei numeri di segmenti che contengono i dati richiesti (i segmenti compressi sono di una dimensione fissa) poi apre una 'view' dal file (in altre parole, un subset della totalità dei dati contenuti in essa), ed è questa 'view' che viene caricata in memoria tenendo conto di volta in volta quali dati sono già in cache e quindi possono essere recuperati e non caricati. Questi segmenti sono estratti dunque dall'index e allineati sul disk block e di qui caricati in memoria.
In tutta sincerità dunque ho dubbi sulla dinamica come da te paventata per il semplice fatto che l'accesso al file è asincrono e, quindi, dinamico e non vedo come una immagine di 2GB ti occupi 100GB di RAM (ma quale sistema supporta 100GB di RAM? Io sono rimasto a 32GB su 64 bit) compresa la compressione implicita nel formato di file .ps della quale non conosco le specifiche ma che, a primo acchito, non mi pare poter essere ragionevolmente nel rapporto da te stimato.
Questo a quanto ne so. Non ho il sapere tutto dell'universo tra le mie mani e quindi sono pronto ad ascoltare obiezioni, spiegazioni e ricredermi. Magari, però, con un tono un tantinello diverso e più dialettico, che ne dici?
/* end edit */