Tralatro ho scoperto or ora che esiste un piccolo escamotage che aggiunge il supporto per l'alpha channel delle png anche ad IE...
http://webfx.eae.net/dhtml/pngbehavior/pngbehavior.html
Saluti!
Tralatro ho scoperto or ora che esiste un piccolo escamotage che aggiunge il supporto per l'alpha channel delle png anche ad IE...
http://webfx.eae.net/dhtml/pngbehavior/pngbehavior.html
Saluti!
"Le uniche cose che sbagli sono quelle che non provi a fare."
Atipica
Mi stai dando ragione!Originariamente inviato da Shores
Allora:
1)Il punto non è se mi sta simpatico o meno il Guglielmo Cancelli, il punto è che per fortuna gli standard della rete non li fa lui, quindi, proprio come mi fa incazzare Netscape 4 che non supporta correttamente neanche una metà dei CSS1, nella stessa maniera mi fa incazzare IE che non supporta la trasparenza delle PNG, visto che nelle parole di Microsoft il "completo supporto per PNG" esiste dalla versione 4...
Quindi, IE per windows non supporta la trasparenza, ma tutti gli altri browser importanti si? Allora, in questo caso è lui a non supportare qualcosa di importante, e mi dà molto fastidio che come tutti sono pronti a sparare (giustamente!) a zero su N4 non si faccia altrettanto su IE, quando mostra delle pecche gravi, in questo caso forse meno gravi di quelle che quotidianamente riguardano la sicurezza del browser Microsoft...
In conclusione, è l'equazione "non supportato da IE"="non supportato" che mi infastidisce, indipendentemente da quanto sia comune IE è bene che si ricordi che NON E' IE A FARE GLI STANDARD...
Ti stà sù Bill Gates e non vuoi che Internet Explorer sia Il browser più usato dagli internauti!(cmq ti capisco ci sono passato anch'io!)
Internet explorer (PC) non definisce nessuno standard (infatti se leggi meglio il mio thread ti accorgerai che uso il termine "pressochè inutilizzabile" e "molti browsers ad oggi") , anzi Netscape4 (usato ancora oggi da molti internauti), non supporta per niente l'alpha png , così come alcune vecchie versioni di "opera".
Queste cose vanno purtroppo dette e chi in un caso reale dovesse pubblicare sul web una immagine png con alpha channel e tutti gli annessi e connessi (tipo antialias e drop shadow) , sappia che alcuni (direi la maggior parte)dei browsers ad oggi in uso (IE tutte , Ne4 , ed altri) , non supportano la trasparenza alpha del formato png , e alle loro belle immagini nel caso dovessero venire visualizzate su uno di questi browsers , verrà aggiunta una pagina di sfondo "standard" , di colore variabile a seconda del browsers!
Sinceramente continuo a non afferrare in pieno!2)Quello che è errato nel tuo discorso precedente è il modo in cui analizzi se un tipo di compressione è con perdita o meno.
La definizione di fattore di perdita è il rapporto di corrispondenza tra i dati forniti all'algoritmo di compressione e i dati restituiti all'uscita della decompressione.
Quello che sto dicendo è che l'algoritmo di compressione usato nelle PNG è SEMPRE senza perdita alcuna, ovvero nelle PNG-24 o 32 ti restituisce esattamente i 24 o 32 bit originari, e nelle PNG-8 ti restituisce ESATTAMENTE gli 8 bit originari.
Il fatto che poi una quantizzazione del colore a 24 bit sia sufficiente a dare all'occhio umano la percezione di una sfumatura continua, mentre a 8 bit ciò non accada, e l'immagine appaia decisamente differente per esempio dall'originale che hai acquisito con lo scanner, non ha ALCUNCHE' A CHE VEDERE CON LA PRESENZA DI UN ALGORITMO DI COMPRESSIONE, nè con perdita nè senza.
Saluti!
Comunque cerco di spiegarmi meglio (visto che nemmeno io sono evidentemente riuscito a spiegare completamente il concetto!)
Allora premesso che i colori (visti da un punto di vista analogico) sono infiniti , quando vengono campionati in una immagine digitale , subiscono una ovvia e drastica riduzione!
C'è un sistema di rappresentazione dei colori delle immagini digitali che si chiama RGB in cui i colori (per via adittiva) vengono rappresentati da subpixels di colore rosso , verde , blù , che combinati assieme restituiscono (è solo un effetto ottico a differenza del metodo CMYK , dove il colore viene determinato ,per via "in parte" sottrattiva e quindi acquisisce "fisicamente" un colore)un ben preciso colore. (determinabile , nel caso del metodo RGB con la tecnica del baricentro).
http://www.boscarol.com/index.html
Ora i bit utilizzati in una immagine digitale (cioè costituita da punti rappresentati in codice binario) , di fatto determinano le possibili combinazioni matematiche (binarie)possibili per quella immagine e quindi i colori.
Non stà nè a te nè a me stabilire se una profondità di colore di 24bit (corrispondenti a circa 16.5Mil. di colori) sia sufficiente o meno a rappresentare gli "infiniti" colori che costituivano l'immagine analogica originaria , (ad esempio LAB può lavorare anche a 16bit/canale = 48bit totali overo billions colors!) , quello che c'è da dire è che il formato png24 (o png32 nella versione con alpha channel) , data una immagine digitale RGBa32bit , dopo la compressione , restituisce esattamente la stessa identica immagine digitale di partenza (pngRGBa32) , senza nessuna perdita d'informazione ne geometrica (come ad esempio per il jpg) , e neppure nei colori (che rimangono sempre gli stessi , ovvero 8+8+8=24bit color depth +8bit=alpha channel = 32bit totali) , però l'immagine digitale di partenza , se confrontata col la png32 di destinazione è notevolmente più pesante in bytes!
Cioè il png32 effettua compressione "intelligente" (tanto che la Macromedia , arricchito dei livelli , utilizza il png come formato di lavoro per "fireworks").
Discorso a parte va fatto ovviamente per il png8!
8bit significano max256colori e ovviamente una immagine RGBa32 , salvata in png8 sarà soggetta oltre che a compressione atta a ridurne le dimensioni in bytes , anche ad una drastica riduzione dei colori che da 16.5Milioni , passeranno a max256 (più ulteriori eventuali 8bit di diether).
Il formato png8 quindi NON GENERA PER NIENTE (cmq non lo avevo mai detto prima!) un file uguale all'originale (come nel caso del png32) , ma un file estremamente ridotto in termini di colori , che comunque va paragonato al "gif" e che rispetto a quest'ultimo è tremendamente più efficente!
Quindi png8 vs gif = sempre meglio png8! (a parte gif animate ovviamente!)
png32 vs jpeg = non paragonabili! Il png32 comprime intelligentemente l'immagine senza nessuna pedita d'informazione geometrica , il jpg invece nel comprimere le immagini perde anche informazioni (pur mantenendo la stessa profondità di colore).
Se devo pubblicare l'immagine sul web ovviamente il formato jpg riesce a comprimere in bytes molto più del png32 , quindi fino a quando non ci sarà la "banda larga" disponibile per tutti , in una immagine con molti colori è ancora preferibile il jpg al png32.
Per lavoro o scambio il png32 è il massimo!
(es. devo importare un immagine raster+alpha in flash?
userò il png32 )
(devo spedire una immagine ad un amico?
png32!)
Ciao e Buone Feste!
Ciao ,Originariamente inviato da Shores
Tralatro ho scoperto or ora che esiste un piccolo escamotage che aggiunge il supporto per l'alpha channel delle png anche ad IE...
http://webfx.eae.net/dhtml/pngbehavior/pngbehavior.html
Saluti!
Guarda che esiste un metodo molto più efficente di usare l'alpha png in Internet Explorer!
Su questo forum se ne parla da tanto tempo ormai (basta che fai una ricerca) ed il metodo consiste nell'usare png32 dentro le swf movies (flash).
http://www.macromedia.com/support/fl...nt_bitmaps.htm
Ciao buone feste!
Mmmm, mi sa che non parlo italiano, ma tant'è:
1)IE per WINDOWS (permettimi, il PC non è windows, sul PC girano anche Linux e tanti altri sistemi operativi...) non supporta correttamente la trasparenza delle PNG, ma con un piccolo escamotage (quello che segnalavo, e che se tu l'avessi letto avresti scoperto che permette di usare i tag IMG con le PNG trasparenti sotto IE windows SENZA cambiare nulla, solo aggiungendo UNA RIGA al foglio di stile, altro che USARE FLASH, che scherziamo!!!!!!) si riescono a visualizzare correttamente, gli altri browser che contano ancora qualcosa lo supportano tutti: Opera 7, Netscape 7, Mozilla, Galeon, Konqueror, praticamente tutti TRANNE Netscape 4, che comunque è sempre meno utilizzato e faremmo bene a lasciar morire, visto che non supporta praticamente nulla degli standard del web (niente CSS1!!!). Quindi, E' SEMPLICEMENTE FALSO che non si possano usare ADESSO, OGGI, le PNG trasparenti.
2)La compressione non ha NULLA A CHE VEDERE CON LA DIGITALIZZAZIONE DI UNA IMMAGINE. Ribadisco, la compressione prende dei dati binari, li trasforma in modo da comprimerli, e poi li ritrasforma all'arrivo per decomprimerli. Tutto ciò non ha NULLA A CHE FARE CON QUANTI BIT DI COLORE INTENDI USARE, tanto che puoi comprimere anche qualcosa che non sia una immagine...
Quindi:
A)L'immagine originale è SOLO quella analogica, e QUALSIASI DIGITALIZZAZIONE presenterà un degrado rispetto all'originale, indipendentemente da quale formato noi useremo per memorizzarla, e indipendentemente da qualsiasi algoritmo di compressione, nemmeno PNG-32 è identico all'originale.
B)Una volta che NOI abbiamo prodotto un flusso di bit che secondo NOI rappresenta una immagine, un algoritmo di compressione cercherà di comprimere questi dati in modo da diminuirne la dimensione. L'UNICO MODO CORRETTO DI VALUTARE LA PERDITA DI QUALITA' IMPOSTA DA UNA COMPRESSIONE E' VALUTARE LA CORRISPONDENZA TRA I BIT CHE GLI HO FORNITO E QUELLI CHE MI RESTITUISCE, qualsiasi altro metodo non ha senso.
Dopodichè, resta pur convinto delle tue posizioni, ma non ti lascerò affermare cose decisamente scorrette senza farlo notare; più precisamente:
1)Il canale alpha delle PNG si può usare da oggi, premurandosi di correggere il BUG di IE per windows (non è Bill a starmi antipatico, ma quello di IE è PROPRIO UN BUG!)
2)La compressione di PNG è SEMPRE senza perdita alcuna di informazione, indipendentemente da qualsiasi variante di PNG tu scelga di usare; questo naturalmente non cambia affatto qualsiasi considerazione estetica in merito allla scelta di quando utilizzare PNG-24 e quando PNG-8.
Saluti.
"Le uniche cose che sbagli sono quelle che non provi a fare."
Atipica
Ciao ,Originariamente inviato da Shores
Mmmm, mi sa che non parlo italiano, ma tant'è:
1)IE per WINDOWS (permettimi, il PC non è windows, sul PC girano anche Linux e tanti altri sistemi operativi...) non supporta correttamente la trasparenza delle PNG, ma con un piccolo escamotage (quello che segnalavo, e che se tu l'avessi letto avresti scoperto che permette di usare i tag IMG con le PNG trasparenti sotto IE windows SENZA cambiare nulla, solo aggiungendo UNA RIGA al foglio di stile, altro che USARE FLASH, che scherziamo!!!!!!) si riescono a visualizzare correttamente, gli altri browser che contano ancora qualcosa lo supportano tutti: Opera 7, Netscape 7, Mozilla, Galeon, Konqueror, praticamente tutti TRANNE Netscape 4, che comunque è sempre meno utilizzato e faremmo bene a lasciar morire, visto che non supporta praticamente nulla degli standard del web (niente CSS1!!!). Quindi, E' SEMPLICEMENTE FALSO che non si possano usare ADESSO, OGGI, le PNG trasparenti.
2)La compressione non ha NULLA A CHE VEDERE CON LA DIGITALIZZAZIONE DI UNA IMMAGINE. Ribadisco, la compressione prende dei dati binari, li trasforma in modo da comprimerli, e poi li ritrasforma all'arrivo per decomprimerli. Tutto ciò non ha NULLA A CHE FARE CON QUANTI BIT DI COLORE INTENDI USARE, tanto che puoi comprimere anche qualcosa che non sia una immagine...
Quindi:
A)L'immagine originale è SOLO quella analogica, e QUALSIASI DIGITALIZZAZIONE presenterà un degrado rispetto all'originale, indipendentemente da quale formato noi useremo per memorizzarla, e indipendentemente da qualsiasi algoritmo di compressione, nemmeno PNG-32 è identico all'originale.
B)Una volta che NOI abbiamo prodotto un flusso di bit che secondo NOI rappresenta una immagine, un algoritmo di compressione cercherà di comprimere questi dati in modo da diminuirne la dimensione. L'UNICO MODO CORRETTO DI VALUTARE LA PERDITA DI QUALITA' IMPOSTA DA UNA COMPRESSIONE E' VALUTARE LA CORRISPONDENZA TRA I BIT CHE GLI HO FORNITO E QUELLI CHE MI RESTITUISCE, qualsiasi altro metodo non ha senso.
Dopodichè, resta pur convinto delle tue posizioni, ma non ti lascerò affermare cose decisamente scorrette senza farlo notare; più precisamente:
1)Il canale alpha delle PNG si può usare da oggi, premurandosi di correggere il BUG di IE per windows (non è Bill a starmi antipatico, ma quello di IE è PROPRIO UN BUG!)
2)La compressione di PNG è SEMPRE senza perdita alcuna di informazione, indipendentemente da qualsiasi variante di PNG tu scelga di usare; questo naturalmente non cambia affatto qualsiasi considerazione estetica in merito allla scelta di quando utilizzare PNG-24 e quando PNG-8.
Saluti.
hai ragione!
Buone Feste
PS . nei "PC" il browser "Internet Explorer" è associato ad un sistema operativo che si chiama "Windows" , anche se su un PC naturalmente puoi installare anche altri sistemi operativi ed altri browsers .
Il fatto di chiamarlo "Internet explorer per Pc" era solamente ( non ci vuole una laurea in ingegneria per capirlo!) per distinguere IE parte PC dallo stesso IE parte "mac" , che invece supporta benissimo la trasparenza alpha (ed anche la "color correction" ) del png32.
Tale browser (IE per Mac) di fatto gira su un sistema operativo "non windows" , quindi la contrapposizione PC vs Mac , non mi sembrava del tutto fuori luogo!
Buone Feste!
Scusa , ma sono post su post che stò affermando la stessa cosa:
2)La compressione di PNG è SEMPRE senza perdita alcuna di informazione, indipendentemente da qualsiasi variante di PNG tu scelga di usare; questo naturalmente non cambia affatto qualsiasi considerazione estetica in merito allla scelta di quando utilizzare PNG-24 e quando PNG-8.
Saluti.
(prima risposta)
"Ma il png lavora anche a 8bit (come il gif) , a 8bit lavora senza perdita d'informazione geometrica (è lossless), ma siccome 8bit generano al massimo 256colori , è ovvio che se l'immagine ne contiene molti di più , nonostante la non perdita d'informazione geometrica , la mancanza di colori si farà sentire eccome! (come per il gif)."
(secondo post)
"La compressione Png32 è una compressione intelligente poichè di un file avente certe caratteristiche (es un file RGBa a 24bit color depth + alpha), non scarica nessuna informazione (ne geometrica , ne di colore , e neppure di alpha) , quindi la compressione del png32 è una compressione "intelligente" , cioè è una compressione che diminuisce i bytes senza scartare niente (ne colordepth che rimane 24bit e neppure trasparenza alpha che rimane 8bit). "
(terzo post)
"Discorso a parte va fatto ovviamente per il png8!
8bit significano max256colori e ovviamente una immagine RGBa32 , salvata in png8 sarà soggetta oltre che a compressione atta a ridurne le dimensioni in bytes , anche ad una drastica riduzione dei colori che da 16.5Milioni , passeranno a max256 (più ulteriori eventuali 8bit di diether).
Il formato png8 quindi NON GENERA PER NIENTE (cmq non lo avevo mai detto prima!) un file uguale all'originale (come nel caso del png32) , ma un file estremamente ridotto in termini di colori , che comunque va paragonato al "gif" e che rispetto a quest'ultimo è tremendamente più efficente!
Quindi png8 vs gif = sempre meglio png8! (a parte gif animate ovviamente!) "
Mi diresti per favore dove trovi dei concetti sbagliati? (così cerco di corregermi).
Ciao Buone feste!
L'unico fatto che non hai chiaro è semplicemente che la distinzione lossy / lossless non ha NIENTE a che vedere con la profondità di colore; gli algoritmi di compressione, soprattutto quelli lossless, sono un qualcosa che in gran parte non ha NULLA a che vedere con i dati he vengono effettivamente compressi e decompressi.
Quindi, il tuo errore sta nel tirare in ballo la profondità di colore in una discussione sulla qualità della compressione di PNG; le due cose non hanno NULLA a che vedere, tanto che uno dei post dell'utente che ha iniziato la discussione recitava proprio qualcosa tipo "Scusami, ma una cosa è parlare di png16 e png24 un'altra è parlare di compressione, tenendo sempre in considerazione png16", il che indicava chiaramente che l'attenzione era sulla compressione, e non sulla profondità di colore...
Dopodichè, buone feste!
"Le uniche cose che sbagli sono quelle che non provi a fare."
Atipica
Ciao ,Originariamente inviato da Shores
L'unico fatto che non hai chiaro è semplicemente che la distinzione lossy / lossless non ha NIENTE a che vedere con la profondità di colore; gli algoritmi di compressione, soprattutto quelli lossless, sono un qualcosa che in gran parte non ha NULLA a che vedere con i dati he vengono effettivamente compressi e decompressi.
Quindi, il tuo errore sta nel tirare in ballo la profondità di colore in una discussione sulla qualità della compressione di PNG; le due cose non hanno NULLA a che vedere, tanto che uno dei post dell'utente che ha iniziato la discussione recitava proprio qualcosa tipo "Scusami, ma una cosa è parlare di png16 e png24 un'altra è parlare di compressione, tenendo sempre in considerazione png16", il che indicava chiaramente che l'attenzione era sulla compressione, e non sulla profondità di colore...
Dopodichè, buone feste!
Oh finalmente un pò di chiarezza!
Non mi sembra di avere affermato che compressione e color depth sono equivalenti nei file png!(se qualcuno ha inteso una cosa simile , allora per favore rilegga i miei posts alla luce di questo nuovo concetto).
"Una cosa è la compressione del formato png che è sempre loosless , cioè priva di deformazioni geometriche , sia nel caso del png24 che nel caso del png8.
Altra cosa è invece la profondità di colore , che comunque nel caso di una riduzione (es 24>8bit) degrada comunque l'immagine , non in maniera geometrica (cioè tutti i pixel rimangono al loro posto , magari con un colore diverso , ma mantengono comunque la stessa posizione nello spazio)."
Cioè in pratica una cambiamento nella profondità di colore provoca un diverso numero di bytes per quella immagine , ma non comporta nessuna compressione .
Buone Feste a te!
Ciao