Newsgroup: it.comp.lang.delphi
Titolo: Propietà immagini

Salve a tutti,
ho il seguente problema, utilizzo un oggetto di tipo "TImage" per caricare
dei files BMP o JPG da visualizzare in un form. Vorrei mostrate nella parte
bassa del form tutte le proprietà dell'immagine caricata come numero di
colori, dimensione file, numero di pixel, ecc.. insomma tutto ciò che può
essere utile conoscere. L'oggetto TImage, però non ha tutte queste
proprietà, come posso fare a recuperare le informazioni?
Grazie a tutti
--------------------------------
Inviato via 
http://usenet.libero.it

 Grazie a tutti
Ciao


    ABLS Team (
www.abls.it
)
········································


E' possibile caricare anche immagini di tipo JPEG...devi aggiungere la unit
"JPEG" alla clausola «uses» della unit in cui è contenuta la definizione del
tuo form sul quale stai lavorando.
Ciao!



[CUT]
Ho provato ha cercare, ma non credo ci siano propietà che ritornano le
caratteristiche dell'immagine. Altre strade?
Ciao
Max



Ops! Scusate.
Paolo
Ciao.

caratteristiche dell'immagine. Altre strade?
Prova a cercare qui: 
http://www.efg2.com/Lab/Library/Delphi/Graphics/index.html
Morde.
morde [at] programmer [.] net

 caratteristiche dell'immagine. Altre strade?
Di quali informazioni hai espressamente bisogno?
Ciao!


 Di quali informazioni hai espressamente bisogno?
[CUT]
Numero di colori
anche se RGB o altro
dpi
Grandezza File
Bit depth
Grado di Compressione x Jpg
Trasparenza x Jpg
e tutto quello che si può sapere di un file immagine... per ora non mi viene
in mente altro


 definizione del tuo form sul quale stai lavorando.
Non solo... TImage di per sé contiene un TGraphic. Ci sono "componenti"
che in realtą sono classi di TGraphic, per esempio TGifImage, e quindi
possono essere usati come si usano i bmp e i jpg.
Spero di non aver detto troppe castronerie :)
--
Jax

 in mente altro
vediamo se ti posso essere d'aiuto...
Per il numero di colori o ti fai una procedura te o la trovi già pronta da
qualcun'altro
Le Jpeg sono solo RGB (ma non ne sono sicuro al 100%)
il bit depth lo puoi trovare dalla proprietà pixelformat (attenzione che le
Jpg possono essere solo 24 o 8 bit)
La grandezza del file devi fare il controllo diretto sul file, ad esempio
con findfirst (ricordati di fare il findclose)
La % compressione non credo sia salvata negli header dei Jpg. Credo quindi
che sia una info non rintracciabile.
La trasparenza la puoi ricavare dalla proprietà transparent del Tgraphic.
Non so se la trasparenza ha significato nelle Jpeg con compressione a
perdita. Non so se l'oggetto TJpeg supporti anche le Jpeg con compressione
senza perdita (che potrebbe essere significativo solo in questo caso).
Ciao
Matteo

Mi metto a lavoro grazie...


 senza perdita (che potrebbe essere significativo solo in questo caso).
Non esiste Jpeg senza perdita, che io sappia.

 No, possono essere anche grayscale.
Credo che Photoshop possa salvare anche in CMYK
--
Jax

 Non esiste Jpeg senza perdita, che io sappia.
esiste esiste. nelle specifiche RFC originali esisteva pure quello. poi le
varie implementazioni hanno saltato questa feature. Ne sono sicuro perchè
l'ho letto in una rivista (Rassegna Grafica) dove parlavano del nuovo
(quando lo lessi, il formato era appena uscito... magari ora è già
"vecchio".. eheh) formato Jpeg2000, dove hanno fatto un "riassunto delle
puntate precedenti" parlando di come è nato il formato Jpeg.
Ciao ciao
Matteo

Ciao
"Jax" <rispo...@newsgroup.grazie> ha scritto nel messaggio
news:t3gT9.5319$0v.1...@news1.tin.it...

Ho provato ora sul PC di un mio collega che fa il grafico.
Sì, confermo quello che hai detto. E' possibile avere Jpeg CMJK. Non sono
invece sicuro che l'oggetto TJpeg riesca a leggerle. non ho mai provato.
Ciao
Matteo

 puntate precedenti" parlando di come è nato il formato Jpeg.
Allora sono poco informato...
Da quello che so io, per salvare un file come JPG devi operare una
trasformazione dei dati dell'originale (DCT), e questo procedimento,
eseguito su numeri floating-point, altera SEMPRE l'immagine, in quanto
introduce una certa approssimazione.
Puo' essere che mi manchi qualche informazione sulla definizione dello
standard, ma quando ho dato l'esame di "elaborazione e trasmissione delle
immagini" ce l'avevano venduta cosi'...

esiste esiste. nelle specifiche RFC originali esisteva pure quello. 
Esiste o esisteva ?
Anch'io, che sappia, non esiste un JPG senza perdita di informazione.
La compressione alla base e` data-loss, che io sappia (altrimenti,
d'altronde, non si avrebbero compressioni cosi` spinte per immagini
cosi` ricche di colori).

Ciao
"Andrea Laforgia" <x@x.x> ha scritto nel messaggio
news:8v802vge3nkpos237...@4ax.com...

Se si definisce un formato e poi il mercato non lo sviluppa, è come se non
ci fosse. Ma il formato originale lo prevedeva:
http://rfc-2035.rfcindex.net/rfc-2035.htm
The JPEG standard defines four modes of operation: the sequential DCT
   mode, the progressive DCT mode, **the lossless mode**, and the
   hierarchical mode.
Ciao
Matteo

ci fosse. Ma il formato originale lo prevedeva:
Scusa Matteo, vediamo di non prenderci per i fondelli ;-)
Qualcuno afferma che il formato non esiste, qualcun altro afferma che
il formato "esiste esiste".  Poi si scopre che, invece, ne esisteva la
specifica; La RFC originale, infatti, riporta la possibilita` di
implementare un formato senza perdita di informazione.  Ripeto la
domanda: esistono, a tutt'oggi, implementazioni dell'algoritmo jpeg
senza perdita di informazione ?

Ciao
"Andrea Laforgia" <x@x.x> ha scritto nel messaggio
news:68o72vckreuaj69rl...@4ax.com...

Mi spiace della tua risposta.
Non è mia intenzione prende per i fondelli te o chiunque altro.
In risposta alla tua:
"Anch'io, che sappia, non esiste un JPG senza perdita di informazione.
La compressione alla base e` data-loss, che io sappia (altrimenti,
d'altronde, non si avrebbero compressioni cosi` spinte per immagini
cosi` ricche di colori)."
Ho risposto citandoti la RFC originale (quindi dovrebbe essere la fonte più
autorevole) che lo prevedeva.
A mia memoria non mi ricordo di aver mai visto una JPG lossless e
rifacendomi all'articolo su "Rassegna Grafica", loro stessi dicevano che era
una feature dello standard JPG non sviluppato dagli encoder e decoder.
Poi, se sia stato sviluppato o meno (con certezza al 100%), non ti so
rispondere: non mi occupo di grafica.
Ciao
Matteo