Newsgroup: it.comp.grafica.photoshop
Titolo: domanda sensata?

E' possibile abbassare la risoluzione di un immagine(e quindi la pesantezza
in byte) lasciando inalterate le dimensioni dell'immagine stessa espresse in
pixels?
Cioè quando applico zoom actual pixels le dimensioni (in pix.) sia
dell'immagine originale con risoluzione data da scanner che dell' immagine
risultante con risoluzione abbassata devono essere uguali.
GRAZIE  da Zingo

 wrote in message
cTMe4.27186$I3.2...@news.infostrada.it...

Se vuoi una risposta sintetica: no. Non si può fare. Le due immagini
peserebbero comunque allo stesso modo, salvo piccolissime differenze dovute
al tipo di formato (e relativa compressione). Il fatto è che le dimensioni
del file dipendono proprio dal numero di pixel dell'immagine. Se vuoi una
risposta più 'scientifica' ho bisogno di un po' di tempo per organizzarla
come si deve...
ciao,
.d-ego.

 pixels?
Allora.. ci son due tipi di compressioni dell'immagine... 1)LOSSY
2)NON-LOSSY
I formati "LOSSY" (con "perdita" di informazione) comprimono molto a scapito
della perdita di "informazione" (leggi pixels ^__^)
I formati "LOSSILESS" comprimono poco (o nulla..nella peggiore delle ipotesi
in cui la struttura dell'immagine è tale che non è possibile applicare
nessuno degli algoritmi di compressione) ma non alterano nemmeno un pixel
dell'immagine stessa.
Ti faccio un esempio pratico (e banale.. nel senso che poi gli algoritmi di
compressione sono moltissimi e assai più complessi)
Devo fare delle estrazioni di 10 palline numerate e devo trovare una maniera
"efficiente" per elencarle occupando meno spazio possibile
(Ho iniziato male, mi sembra uno di quegli esempi scolastici sulle
probabilità ^___^)
Bene.. se mi limitassi a scrivere l'elenco delle 10 palline estratte,
occuperei per ogni estrazione dieci "caselle" (una per ogni pallina)
Io decido che è troppo spazio .. e mi invento un "CRITERIO" conoscendo il
quale potrò ricostruire la sequenza di 10 palline estratte, ma risparmierò
spazio quando dovrò custodire l'informazione su elenco ^_^
Così..(per fare un esempio) decido di usare le caselle "accoppiate" e far sì
che la prima identifichi il numero di cifre dello stesso tipo ripetute... e
la seconda la cifra stessa....
Ok.. giro la ruota ^___^ e faccio la prima estrazione
Le palline hanno questi numeri: 1,1,1,1,1,2,2,2,1,1.
In base al  "criterio" scelto,  per elencare le 10 palline di cui sopra mi
basterebbe fare così.
5,1 - 3,2 - 2,1
(si legga: 5 palline con cifra uno..3 palline con cifra 2... 2 palline con
cifra uno)
Come si può notare sono arrivato ad una compressione di poco inferiore al 50
% ^___^ (ho usato 6 "caselle" invece delle 10 originali) e ciò SENZA perdita
di informazioni.. nel senso che l'elenco è ancora corretto..(non può dare
origine ad altri risultati errati..)
Di certo sono stato fortunato.. le cifre erano poche e si ripetevano
spesso...
Se (in base al "criterio" scelto) avessi avuto meno fortuna... e queste
palline : 1,2,3,2,1,1,2,3,4,5 il secondo metodo di rappresentazione avrebbe
addirittura aumentato lo spazio necessario alla codifica delle informazioni
(pur non alterandole)
Infatti avrei dovuto codificarlo così: 1,1 (una cifra 1) 1,2 (una cifra 2)
1,3 (una cifra 3) 1,2 (una cifra 2) 2,1 (due cifre 1) 1,2 - 1,3 - 1,4 - 1,5
in totale ben 18 caselle contro le 10 originali !_!
Allora avrei dovuto (per quello esistono tanti formati di compressione
^___^) trovare un'altra "via" (ad esempio... con una cifra indico il numero
iniziale di una sequenza [crescente o decrescente non mi importa], con le
seconda cifra il numero finale della stessa sequenza)
In questo caso.. la serie di numeri di cui sopra può essere così
rappresentata (dio.. ma che ho fumato ???? ^_____^) : 1,3 - 2,1 - 1,5
Ecco ^__^ di nuovo compressione prossima al 50 % (6 numeri per
rappresentarne 10) ^__^
Ok.. fin qui ho esemplificato le compressioni di tipo NON-LOSSY (senza
perdita di informazione)
Ma passiamo quindi alle LOSSY ^___^
Dato che il tipo di sequenze numeriche può essere molto diverso.. ed è assai
diffice che si susseguano serie crescenti o decrescenti di numeri.. avrei
potuto ricorrere ad un "criterio" più generico che, a discapito della
"fedeltà" dell'informazione originale, mi permetta in ogni situazione di
risparmiare "caselle" (od.. alla peggio.. non far aumentare lo spazio
occupato)  ^__^
Quindi.. potrei "decidere" a priori che almeno due cifre successive della
sequenza vengano ritenute uguali  (anche se non lo sono) e tornare per
l'elencazione delle estrazioni al primo "criterio".. cioè di utilizzare la
prima cifra come numero di cifre uguali in sequenza... e la seconda ad
identificare la cifra stessa....
Nel caso della prima sequenza esemplificata la compressione funzionerebbe
perfettamente, senza perdita di informazione tra l'altro ^____^
(l'elenco sarebbe lo stesso del  primo esempio .. in quanto ci sono davvero
SEMPRE almeno due cifre che si ripetono in quella sequenza)
Nel secondo caso... la perdita di informazione ci sarebbe ed altererebbe
l'elenco in modo sostanziale ^____^
Così... usando questo sistema LOSSY.. dovrei codificare la sequenza
1,2,3,2,1,1,2,3,4,5
in questo modo
2,1 (due cifre 1... anche se in realtà non è così... ma il mio "criterio"
presume che almeno due cifre siano in sequenza... e quindi "lima" l'elenco ,
praticamente ignorando la cifra 2 dopo l'uno iniziale) - 2,3 (due cifre 3..
anche se nemmeno qui è così .. e si perde altra informazione ^_^) - 2,1 (2
cifre uno... qui è ESATTO ^____^) - 2,2 - 2,4
Praticamente.. non avrei nessuna compressione (ma nemmeno aumento di
caselle) ma la sequenza che poi ricostruirei dall'elenco sarebbe questa :
1,1,3,3,1,1,2,2,4,4   VERSIONE RICOSTRUITA col criterio LOSSY
1,2,3,2,1,1,2,3,4,5   VERSIONE ORIGINALE ^___^
1,x,3,x,1,x,2,x,4,x     PERDITA DI  metà dell'informazione ^_________^
Spero qualcuno ci abbia capito qualcosa.. ho fatto gran caos ma quanto
spiegato è davvero ciò che sta dietro alla compressione delle informazioni
^_______^
ciao
X_X
chriS

 wrote in message
gbVe4.29052$I3.3...@news.infostrada.it...

Okkey. Ma credo che Zingo stesse chiedendo un'altra cosa. Io ho interpretato
la sua domanda così: mettiamo di avere un'immagine 100x100 pixel e di
salvarla due volte, nello stesso formato, con due densità diverse (per es.
la prima 100dpi e la seconda 50dpi) mantenendo fissa la dimensione di
100x100 pixel. Otterrei due file di diversa dimensione? Nello specifico il
secondo (50 dpi) sarebbe più leggero?
Se questa era la domanda  di Zingo la risposta è: NO. I due file peserebbero
uguale.
Perciò, Zingo, se il tuo problema è quello di alleggerire un file immagine,
senza ridurne le dimensioni in pixel, non devi ridurre la risoluzione, ma
trovare il formato di compressione che più ti soddisfa.
In pratica, come ha spiegato chriS, Jpeg è un formato lossy, perde in
qualità tutto quello che guadagna in spazio, gif e tif compresso sono
non-lossy, comprimono poco o niente senza perdita di qualità.
Ora sta a te la scelta. A proposito ho capito bene quello che avevi chiesto?
--
.d-ego.
d-...@NOSPAMciaoweb.it

d-ego ha scritto nel messaggio
+ADw-0R3f4.31687+ACQ-I3.344737+
AEA-news.infostrada.it
+AD4-...
+AD4-Okkey. Ma credo che Zingo stesse chiedendo un'altra cosa. Io ho
interpretato
+AD4-la sua domanda cos+AOw-: mettiamo di avere un'immagine 100x100 pixel e di
+AD4-salvarla due volte, nello stesso formato, con due densit+AOA- diverse (per
es.
+AD4-la prima 100dpi e la seconda 50dpi) mantenendo fissa la dimensione di
+AD4-100x100 pixel. Otterrei due file di diversa dimensione? Nello specifico
il
+AD4-secondo (50 dpi) sarebbe pi+APk- leggero?
+AD4-
+AD4-Se questa era la domanda  di Zingo la risposta +AOg-: NO. I due file
peserebbero
+AD4-uguale.
E no. Riducendo la risoluzione (dpi) ottieni un file piu' piccolo in
byte (meno pesante) anche mantenendo constanti le dimensioni lineari
(pixel, centimetri, pollici....). Perdi pero' anche qualita' (meno
particolare sull'immagine).
Ciao
Giuseppe
labgraf+AEA-spm.it

 pixels?
