main index

Lumix & Linux...? Beh, non c'è molto da dire, comunque provo a riassumere qui quel poco che serve sapere.

Clicca qui per le altre pagine che ho dedicato alla fotografia digitale e alla Panasonic Lumix DMC FZ20.


A grande richiesta, cominciamo col manuale della FZ20 (in inglese), formato PDF.


Formato dei file prodotti dalla FZ20

La FZ20 tira fuori tre tipi di file: JPEG (fotografie e miniature dei video), TIFF (fotografie), MOV (filmati, flip-animation, commenti audio alle fotografie).

File JPEG (estensione JPG): questo è un formato così famoso e diffuso che non c'è bisogno di commenti. C'è solo da notare che per caricare in memoria dei file JPEG alquanto grandi (di un megabyte o più) richiederà più tempo dei JPEG cui tipicamente siamo abituati... Qualunque programma capace di leggere file JPEG va bene. Per lavorare sulle immagini (ritagliare, ridurre, cambiare contrasto, etc) io preferisco Gimp sotto Linux.

In mancanza di meglio, per leggere i dati nel blocco EXIF dei JPEG prodotti dalla fotocamera, è sufficiente l'utility exif.py presente nel pacchetto kdeaddons3-konqueror del KDE (per cui probabilmente ce l'avete già installato). In varie distribuzioni di Linux ci sono vari viewer gratuiti che leggono le informazioni EXIF, come ad esempio Pixie, Digikam, etc. E infine ci sono un cumulo di altre librerie e utility gratuite come exif/libexif.
Per visualizzare immediatamente il primo frame dei video sul display LCD, la FZ20 salva anche un JPEG da 320×240 (con lo stesso nome del file .MOV ma con ovvia estensione .JPG).

I file TIFF prodotti dalla FZ20 si possono comodamente leggere da Gimp o da altre utility grafiche; è meno famoso del JPEG ma è abbastanza supportato. Quando la fotocamera salva un TIFF (che risulterà un gran bel malloppone di quattordici megabyte), ci accoda pure un JPEG a compressione "normale". Ebbene, le differenze tra il TIFF ed un JPEG a compressione "fine" sono praticamente minuscole. Dopo le prime prove (proprio per saggiare la differenza) comincio a pensare che è un formato che probabilmente non userò mai...!

Piccolo riassuntino:

I file MOV dei filmati hanno una compressione relativamente bassa (sia per non incidere troppo sulla qualità, sia per la velocità di compressione e salvataggio che deve rispettare il "real-time" per evitare di perdere frame). Per visualizzarli sotto Linux può andare bene anche MPlayer (anzi: va così bene che non mi sono neppure preoccupato di verificare se su altri player si può usare).

Il formato MOV è un "contenitore"; la FZ20 vi salva dentro una sequenza QuickTime di immagini JPEG (!!) e uno stream audio mono da 8 kHz in formato PCM non compresso. Con mencoder (che sta nel pacchetto MPlayer) si può convertire in un altro formato (AVI, MPEG, etc) e con un diverso schema di compressione (DIVX, MPEG4, etc). Al momento non ho ancora investigato i dettagli, perché per me è sufficiente poterli vedere su PC.

Le "flip-animation" hanno una traccia audio finta (sono infatti senza audio), e pure possono essere comodamente visualizzati con MPlayer.
È vero che anche xanim 2.80.2-beta riesce a visualizzare i .MOV in questione, ma visto che è un software che non viene più aggiornato fin dall'anno 2000, direi che possiamo lasciarlo perdere. (n.b.: anche Broadcast 2000c (del 2001) riesce a caricare e correttamente visualizzare/editare i .MOV).

Anche i commenti audio delle foto sono salvati in formato MOV e per questi è sufficiente usare l'opzione -novideo come ad esempio:
mplayer -novideo p1000003.mov

Questo trucchetto è richiesto perché nei .MOV dei commenti è salvato anche un finto stream video di un solo frame (da 640×480).


Collegare la Lumix FZ20 a un PC con Linux

La FZ20 si può collegare in due modi: il modo classico "PC" o il modo "PTP".

In modo "PC" risulta una USB-storage, identica ad una "chiavetta USB" (pen-drive), visibile a pressoché qualsiasi distribuzione Linux degli ultimissimi anni. Avendo installato il supporto per hotplug vedremo i file comparire sotto /media (dove vengono auto-montati cdrom e floppy disk), più precisamente nella directory:
/media/usb-storage-odd-Panasonic-DMCFZ20:0:0:0p1/dcim/100_pana

Attenzione: in alcune distribuzioni Linux vecchie e ammaccate (come la SuSE 9.1), può essere necessario aspettare la bellezza di sei minuti dall'inserimento del connettore (momento in cui sulla fotocamera compare il simbolo del collegamento USB) fino alla comparsa della finestra con le directories della memoria Secure Digital (DCIM, etc), anziché i trenta secondi scarsi nel caso peggiore (come avviene per esempio con la mia secure-digital Sandisk Ultra II da 512Mb). Il riconoscimento è pressoché immediato (infatti con dmesg vediamo subito usb 1-1: new full speed USB device using address 3... usb 1-1: Product: DMC-FZ20... usb 1-1: Manufacturer: Panasonic... - l'identificatore USB 32 bit della FZ20, da /proc/bus/usb risulta 04da:2374), ma l'emulazione SCSI ci mette un po' di tempo a "svegliarsi" (rimane per qualche minuto fermo sulla riga "sda:" perché tenta ripetutamente di leggere gli ultimi settori dichiarati dalla Secure Digital; suppongo che lo faccia per essere sicuro che la seek sul disco funzioni) e dopo qualche segnalazione di errore (sempre nel dmesg infatti vediamo end_request: I/O error, dev sda, sector...) finalmente si decide a dire Attached scsi removable disk sda at... Attached scsi generic sg0 at... - e finalmente il servizio hotplug si decide a riconoscerlo come disco e a presentare una finestra con le directory della fotocamera. Anche con questa lunga attesa e nonostante gli errori (che ho verificato che non influiranno per nulla sul trasferimento dei file), funziona tutto. Nel mio caso (SuSE 9.1, come detto sopra) ho trovato la directory già automaticamente montata sotto /media/usb... e ho trasferito (alla canonica velocità della USB 1.1, cioè circa un megabyte al secondo) le immagini sul PC.

No, non vi siete sbagliati: la SecureDigital originale Panasonic da 16Mb distribuita con la fotocamera risulta in realtà di poco più di 14Mb (29121 settori da 512 bytes, ma una volta formattata risultano 14448 kbytes utili divisi in 903 clusters da 16k, per un totale teorico di 14794752 bytes).
Non ci meraviglia affatto che per motivi commerciali si tenda ovunque ad arrotondare per eccesso (molto eccesso) qualsiasi capacità... Forse tu sei troppo giovane per ricordare i famosi dischi da 40 megabytes "cioè 20 mega con Stacker" :-) E poi, l'ardisco del mio notebook, dichiarato da "30 gigabyte", non è forse un soffio più grande dei trenta miliardi di bytes (per cui una volta formattato risulta poco più di 29 milioni di kilobytes)? :-)
La secure digital Sandisk Ultra II da 512Mb pure è arrotondata per difetto: si tratta di 990865 settori da 512 byte, per un totale di poco più di 507 milioni di bytes.

Piccola parentesi: ho fatto anche un test di velocità, usando:
LANG= time wc < /dev/sda
507322880
15.74user 9.15system 11:07.91elapsed 3%CPU (0avgtext+0avgdata 0maxresident)k


Ossia: 507 milioni di bytes totali di storage (anche se si chiama "512Mb") letti sequenzialmente dalla fotocamera attraverso il cavo USB (notare che è USB 1.1) in poco più di undici minuti, a una media di quasi 760 kb/sec. La media è un filino inferiore al massimo teorico della USB 1.1 perché nel frattempo ho continuato ad utilizzare il computer in questione (che era un vecchio Celeron/1000). In condizioni normali (cioè usando il cavo per recuperare le fotografie) pare infatti che si possa ottenere una velocità prossima al megabyte al secondo.

Il modo "PTP" aggiunge solo qualche funzionalità che ancora non ho investigato (si tratta di usare gphoto2 con libptp2).

Visto che al 99,9% degli utenti interessa solo trasferire le foto dalla fotocamera al PC, concludo qui con due sole considerazioni:

  1. il trasferimento avviene in standard USB 1.1 per cui, anche se la collegate ad un PC che ha una USB 2.0, in entrambi i modi (PC e PTP) la velocità di trasferimento è approssimativamente un megabyte al secondo (cioè ci vogliono nove-dieci minuti per svuotare una Secure Digital da 512Mb piena di foto e video fino all'orlo); a questo punto io preferisco usare il modo "PC" in modo da poter scaricare le foto su pressoché qualsiasi computer dotato di porta USB (e magari di usare di tanto in tanto la fotocamera come "chiavetta USB" formato gigante... non sarà velocissima, certo, ma dentro ci ho messo pur sempre una Secure Digital da 512 megabyte);

  2. l'alternativa è comprare uno di quei lettori multi-formato su porta USB 2.0, ma per adesso non mi va di tenere troppa ferraglia in giro (e spendere soldi per guadagnare qualche minuto di tempo ad ogni travaso). In modo USB 2.0, su una macchina Pentium III, il "travaso" avviene a circa 4-5 megabyte al secondo, ma occorrerà tirar fuori ogni volta la secure digital dalla fotocamera.

Fotocamere digitali, trucchi, consigli, etc: clicca qui Trucchi e trucchetti

Il comando jpegtran disponibile praticamente in qualsiasi versione di Linux - fa parte infatti del pacchetto jpeg (jpeg-6b o simili) installato praticamente per default da chiunque - permette di cambiare alcuni parametri di un file JPEG senza toccare lo stream compresso dell'immagine (dunque senza perdita di qualità... il che è diverso nel caso di caricare/modificare/risalvare un file JPEG).

Esempio: jpegtran -rotate 270 p1030001.jpg > immagine.jpg
crea un nuovo file contenente la foto ruotata di 270 gradi.

Alcuni suggerimenti che NON alterano la qualità finale del JPEG:

C'è fra parentesi anche la possibilità di eliminare le tabelle dei colori dal file JPEG per ridurlo in bianco e nero (con -grayscale); in questo caso c'è perdita di informazioni di immagine (per i più tecnici, viene eliminato il canale della "crominanza", lasciando solo quello della "luminanza"), quindi tenetevi sempre una copia di backup dell'immagine originale... Comunque è preferibile lasciare che sia la fotocamera stessa a decidere come processare l'immagine in bianco e nero; se lo fa la FZ20 allora verrà meglio perché terrà presente anche il bilanciamento del bianco e tutto il resto.

Si possono fare più operazioni in un colpo solo; per esempio, creando uno script per la shell contenente: jpegtran -optimize -progressive -rotate 270 $1 >ok.$1

se la si invoca dandogli come input p1000001.jpg allora creerà un file ok.p1000001.jpg ridotto al minimo e ruotato di 270º in senso orario (cioè 90º in senso antiorario).


Click here for... SURPRISE!

e-mail - continua (next page)