una soluzione per la risoluzione

[marco0608]

Salve a tutti,
sono un arzillo vecchietto e avrei bisogno di una mano: devo scoprire come trovare la risoluzione (dpix e dpiy) di un'immagine (JPG) (in realtà di tante, ma quando ho capito come fare per una ....)
So che la risoluzione in dpi non è una caratteristica dell'immagine, la caratteristica semmai è la sua misura in pixel (es: 1908x477).
OK. Però se apro l'immagine con Gimp, esso mi dice che la risoluzione è 200x200 dpi. La domanda, e scusate la prolissità, è quindi la seguente: come fa Gimp a dirmi la risoluzione? Che funzione usa, se usa una funzione?
Perché io non posso ottenere l'informazione che Gimp, evidentemente, ottiene?
Vi ringrazio per qualsiasi aiuto vogliate darmi
Marco

[Master FO]

Ma con che linguaggio lo vuoi fare?

[banryu79]

Se parliamo di formato JPEG, mi pare che il valore dei dpi sia memorizzato nei metadati dell'immagine stessa, percui basta leggero da li. Questo è il "cosa" fare, per il "come" dipende dal linguaggio di programmazione, se devi realizzare un programma.

Sennò su Windows basta fare click destro sull'immagine, proprietà, riepilogo, avanzate: vengono visualizzati alcuni valori relativi ai metadati dell'immagine, tra cui i dpi.

[marco0608]

Grazie a Master FO e a banryu79.
IL linguaggio non è così importante, potrebbe essere anche C++ ma VB andrebbe meglio.
banryu79 mi dice che il dato che cerco (200 per 200dpi) è nel file jpg.
Io non sono un grande esperto nell'analisi del contenuto dei files grafici, ma un tentativo di questo genere l'avevo fatto: per file jpg generati da photoshop, ad esempio, ero anche riuscito a farlo funzionare; ma la soluzione funzionava solo per quei files lì, se prendevo un JPG generato da una macchinetta digitale, ad esempio, saltava tutto: la posizione che andavo a cercare all'interno del file non conteneva più il dato cercato. (possibile anche che abbia toppato tutto, ti ripeto, non sono un gran ché in questa cosa ...)
Comunque grazie mille per le vostre risposte e se avete altre idee, vi ringrazio anticipatamente anche per quelle

[cdimauro]

Non c'è una posizione fissa per questi metadati, perché il JPEG non li prevede.

In genere i programmi che generano file di questo tipo utilizzano un particolare tag JPEG che identifica la presenza di un blocco di dati di tipo "commento".

Il problema nasce proprio dal fatto che JPEG non ha mai standardizzato null'altro rispetto alle informazioni che trovi nello stream di dati normalmente, per cui in questa porzione di file ognuno può scriverci quello che vuole nel suo particolare formato.

Quindi, ricapitolando: recuperare il blocco di dati dei commenti è molto semplice (perché lo stream dati di JPEG è semplice da gestire: basta saltarli tutti e fermarsi davanti al tag dei commenti, appunto), ma poi devi scrivere un parser (XML, se non ricordo male, per Adobe) ed estrarti le informazioni che ti servono.

Il tutto sperando che altri programmi che generano JPEG adottino lo stesso formato.

[wingman87]

Non credo abbia senso memorizzare i dpi da qualche parte, riporto da wikipedia il motivo:

I DPI si riferiscono sempre a una densità "fisica" dei punti sia che siano stampati o visualizzati su un monitor, per una immagine digitale memorizzata in un computer parlare di DPI non ha nessun senso fino al momento in cui non viene stampata.

Quindi credo che il valore che ti mostra GIMP sia basato sulla dimensione del monitor e la sua risoluzione.

[banryu79]

Qui c'è un'utility freeware che pare legga i tag Exif presenti in una jpeg:
http://www.kiwiczech.net/index.php?menu=353&sub=4

Non so cosa devi farci con questa informazioni, forse è più facile indicarti una soluzione valida se ci racconti cosa devi fare, a che scopo vuoi recuperare queste info.

[marco0608]

Grazie a tutti.
Cdimauro mi dà la spiegazione al perché le mie 3 righe di codice funzionavano solo con file di photoshop. Grazie: adesso perderò qualche nottata a vedere se riesco a scrivere un parser XML come mi suggerisci.
Sì, hai ragione tu, banryu79 (ho scaricato il programmino, ora me lo studio un po'), te lo dico volentieri: ho sviluppato un catalogo fotografico per i miei clienti (orafi). Questi hanno assolutamente bisogno che l'immagine stampata sia identica in dimensioni a quella reale (1:1).
Per fare questo ho bisogno di sapere, quando carico l'immagine, le sue dimensioni in mm (non in pixel, ovviamente, poiché senza la "densità", come mi ricorda wingman87, i pixel non mi dicono nulla ...).
Le dimensioni in pixel le ho, se avessi anche i dpix e dpiy potrei facilmente trasformare i pixel in mm e stampare, di conseguenza, su qualsivoglia stampante immagini in grandezza naturale.
Le immagini sono scansionate in genere con risoluzione di 200dpi, ma solo in genere, purtroppo ... A volte anche 150, a volte 300 ecc...
Grazie ancora a tutti, siete forti: oggi sono più vicino alla soluzione di quanto lo sia stato mai in questi mesi ...

[cdimauro]

Non so che esperienza hai di programmazione, ma scrivere un parser XML non è complicato, specialmente col linguaggio e/o lo strumento giusto.

Ad esempio in Python lo si fa con poche righe di codice. Guardati l'esempio che c'è poco dopo la descrizione della classe ElementTree.

Poiché hai parlato di C++ e VB, puoi dare un'occhiata agli esempi di XmlSerializer.Deserialize.

[rеpne scasb]

■

[banryu79]

Originariamente inviato da rеpne scasb

... Eric Hamilton non sarebbe contento.

Ehm... chi?

e comunque: Repne!!!

[marco0608]

Grazie a tutti, a Cdimauro e a rеpne scasb.
Sì, rеpne scasb, io so veramente poco di Hamilton, ma ieri notte mi sono aperto una ventina di file jpg e li ho un po' studiati.
Dopo vari tentativi e sconcertanti contonate sono arrivato alla conclusione che gli offset che tu mi indichi (quasi, per me sono 15 e 17) sono quelli delle risoluzioni che cerco. Ora tu me lo confermi: grazie così il problema l'abbiamo risolto.
interessante però la precisazione che mi fai: "...quindi se leggerai la word con una CPU intel ricordati di scambiare nella word il primo byte con il secondo byte che leggi. " Per questo io prendo l'offset 15 e 17?
In genere le cpu che trovo sono proprio intel (per intel intendi proprio Intel o x86?)
Secondo te, dovessi incontrare cpu non-intel dovrei andare all'offset 14 e 16?
Grazie e scusa l'ignoranza, sto imparando ....

Queste le tre righe di codice che ho scritto e che, pare, funzionino ...

li_FileNum = FileOpen(as_nome_imm, StreamMode!, Read!, Shared!)
if as_h_v='V' then
ll_pos = FileSeek( li_FileNum, 17, FromBeginning!)
else
ll_pos = FileSeek( li_FileNum, 15, FromBeginning!)
end if
fileread(li_FileNum, ls_dpix)

li_ris=asc(left(ls_dpix, 1))

messagebox("E", li_ris)

fileclose(li_FileNum)

Grazie ancora a tutti

[cdimauro]

Originariamente inviato da banryu79

Ehm... chi?

e comunque: Repne!!!

http://www.jpeg.org/jpeg/index.html

@marco0608: per ogni dato che non sia un byte devi eseguire un "byte-swap" della "word" letta, oppure leggi un byte alla volta (dal più significativo al meno significativo) e ricostruisci la "word" tenendo conto del "peso" di ogni byte.

[marco0608]

Certo, Cdimauro, hai ragione ...
Si vede che ieri notte avevo più sonno del solito ...
Grazie e ciao

p.s.:
qui il codice corretto (servisse mai a qualcuno ...)

integer li_FileNum, li_ris, i, li_valore
string ls_dpix[]
long ll_pos

li_FileNum = FileOpen(as_nome_imm, StreamMode!, Read!, Shared!, Replace!)
for i= 1 to 2
if as_h_v='V' then
ll_pos = FileSeek( li_FileNum, 15+i, FromBeginning!)
else
ll_pos = FileSeek( li_FileNum, 13+i, FromBeginning!)
end if
fileread(li_FileNum, ls_dpix[i])
next
li_ris=asc(ls_dpix[2])+asc(ls_dpix[1])*256

//messagebox("E", li_ris)

fileclose(li_FileNum)
return li_ris

[LMCH]

Originariamente inviato da banryu79

Qui c'è un'utility freeware che pare legga i tag Exif presenti in una jpeg:
http://www.kiwiczech.net/index.php?menu=353&sub=4

C'è anche una libreria in C++ che legge sia i tag "standard" che quelli di vari produttori di macchine fotografiche:
http://www.exiv2.org/
Supporta parecchi formati di immagine ed oltre ai tag Exif, legge anche IPTC ed XMP.

[marco0608]

Grazie LMCH.
Ho scaricato la libreria, adesso guardo come implementarla...
Ciao a tutti e grazie ancora: erano mesi che cercavo questa soluzione ...