Il blog di Sandro Rizzetto

Implementare una nuova photogalleries: gioie e dolori

 

Era un po’ di tempo che avevo intenzione di rinnovare il mio motore di visualizzazione dei miei Foto Album a cui avevo messo mano qualche anno fa, ma che ancora non mi convinceva per la responsiveness sui device mobile. Ed inoltre il rendering sia della griglia che della foto era diversa a seconda dell’età del’album visto che all’inizio generavo thumbnails e foto a risoluzioni molto più basse.

Durante una giornata uggiosa ho preso quindi la decisione di trovare una libreria che mi piacesse e di implementarla dentro la mia architettura che si basa su pagine asp.net e un database mssql che contiene le oltre 12000 foto con i loro metadati, mentre i jpg veri e propri sono sul filesystem secondo una certa gerarchia di cartelle. Scriversela da soli? Non sono mai stato un amante di javascript/jquery e ci avrei messo troppo tempo, inoltre ormai implementare tutti i controlli cross-browser, cross-devices, gesture touch, infinite risoluzioni, retina/nonretina, ecc. è veramente un lavoro enorme e preferisco fare una donation nella speranza che l’autore retribuito porti avanti gli sviluppi.

Devo dire che la ricerca è stata piuttosto breve in quanto sono capitato quasi subito sulla libreria nanogallery2 che mi sembrava avere tutte le feature che mi servivano e soprattutto (cosa fondamentale) una buona documentazione.

Layout

Il primo scoglio o decisione da prendere è stato che tipo di layout implementare per la griglia; io finora avevo usato sempre una griglia con height fissa e width proporzionale ma dettata da un maxwidth non superabile; quindi le foto verticali venivano visualizzate correttamente (con lo spazio a lato), mentre i panorami veniva compressi con un brutto effetto estetico. Il numero di colonne era anch’esso fisso e settato a 4 e spesso la scelta delle foto e il loro ordinamento era dettato da ciò: ad esempio se avevo 4 foto dello stesso argomento, della stessa cromia o aspect ratio cercavo di metterle tutte sulla stessa riga; sono infatti sempre stato molto attento al fatto che una photogallery avesse sia un senso di racconto, che di aspetto estetico piacevole. Odio che i vari album di Google Photo o Amazon Photo privilegiano la data di scatto e gli album non hanno mai l’opzione “sort by name” .

image
Il vecchio layout; la foto 2 è strechata, le verticali occupano lo stesso spazio avendo del bianco attorno

Dico subito che questo layout non sono riuscito a riprodurlo uguale con la nanogallery2; le opzioni sono infatti:

Grid = una griglia con width e height ben definite (es. 300x200); le immagini verticali e i panorami vengono tagliati prendendo la parte centrale; soprattutto per le “portrait” l’opzione non mi piaceva molto, si rischia infatti di avere un thumbail che non “inquadra” parti che fanno capire di cosa si tratta

imageimage

 

Cascading (detta anche Mansory): la width è prefissata e la height è calcolata: ne viene fuori un layout “disordinato”, con le foto non in riga, ma molto alla moda

imageimage

 

Justified: è quello che ho scelto io, ovvero height fissa e width autocalcolata; qui gli aspect ratio sono sempre rispettati, ma esteticamente varie foto verticali vicine tra di loro non sono il massimo.

imageimage

Una delle opzioni che avrei potuto percorrere è quella di generare i thumbnail che hanno width < height con del bianco ai lati fino a farli diventare simili alle foto 3:2 (che sono la stragrande maggioranza). Con il programma Fast Stone Resizer la cosa è possibile settando l’opzione Smart Filling (si può scegliere addirittura il colore del fill), ma purtroppo come vedremo in seguito non è scriptabile via batch.

image

 

Scelta l’opzione del “meno peggio” mi sono scontrato subito con una feature mancante e un presunto bug. Intanto non è possibile mantenere il numero di colonne sempre fisso a 4, lo si può fare dividendo lo spazio totale del tuo div per quel numero e creando i thumbnail di quella dimensioni (es. spazio = 1170px, creando thumbnail da circa 290px lui le allinea 4 a 4). Sempre che non abbiamo vicine foto verticali o panorami e allora il conto fa a farsi friggere perché lui (tenendo fede al mode justify) farà sempre di tutto per farcene stare un numero sufficiente per riempire il div.

image

Quindi tutto il mio certosino lavoro di anni di crere album “ottimizzati” per 4 a 4 è andato a farsi benedire!

Il bug a cui invece mi riferisco è relativo a due parametri chiamati thumbnailGutterWidth e thumbnailGutterHeight che dovrebbero servire a tenere le foto un po’ piú staccate (una specie di padding delle celle virtuali che contengono le foto). Io qualsiasi numero metta ottengo sempre risultati catastrofici! Quindi o non ho capito come si usa, o mi devo tenere le grid troppo impaccate.

Label e Album a più livelli

Per label, l’autore intende un titolo e una description che possono venir renderizzati uno sotto l’altro. Io la Description (che potrei prendere dal campo exif Caption di Lightroom dal quale estraggo tutte le informazioni) non la gestisco… è giá tanto se riesco a inventarmi un titolo. Ho pensato molto se farlo apparire anche sulla griglia, ma in alcune galleries i titoli sono tutti uguali, mentre altre li hanno così lunghi che verrebbe tagliato. Segnalo l’impossibilità di scegeliere font e colore ma solo fontsize (anche se un Arial bianco è quello che si vede meglio), mentre è possibile variare la posizione delle label dentro la foto o fuori.

Alla fine ho scelto al momento di non visualizzarle, ma ho predisposto il DB con un flag per decidere gallery per gallery se attivarle o no. Cosa che già faccio automaticamente per le gallery che sono album padre di sottogallery.

 

image
Titolo con position “onBottom” eventualmente attivabile con un flag

image
Un album padre di sottoalbum, con in automatico il nome dell’album child visualizzato con parametro “overImageOnBottom

La libreria supporta già la gestione di album e sottoalbum settando per ogni foto un id diverso (data-ngid) e mettendo nel parametro data-ngalbumid il suo album di riferimento. La mia struttura gerarchica di parent-child non era proprio adatta al rendering che ci sarebbe voluto per gestire tutto con la libreria. Per fortuna esiste un parametro chiamato data-ngdest che definisce la destination-url al click sul thumnail in luogo della visualizzazione della foto. Tramite questo parametro quindi le immagini che sono “la copertina” di un sottoalbum lo aprono invece che visualizzare loro stesse.

Lightbox della foto

Cliccando sulla griglia una thumbnail, la foto viene renderizzata su uno sfondo nero con molte possibilità di interazione. Io ho limitato togliendo vari comandi, sotto ho pulito tutto lasciando solo il Title, in alto a sinistra il contatore con il “play” dello slideshow automatico e in alto a destra i vari comandi di zoom, fullscreen, info e share.

image

La navigazione, oltre allo slideshow automatico, avviene con le due freccie dx e sx ai lati della foto o con un swipe che su mobile ovviamente si ottiene con il touch.

Cliccando sulla icona i di info si apre un popup dove è possibile visualizzare i dati exif che sono stati passati dentro ogni tag <a href> che compone il record della foto.

imageimage

La struttura è già predisposta per contenere molti dati exif (data-ngexif*): non ho apprezzato che abbiano chiamato exposure quello che probabilmente intendevano essere il campo dove mettere il tempo di otturazione (era meglio un shutterspeed). Se si vogliono esporre più dati è possibile sfruttare il campo ng-customdata in cui si passa un dictionary key/value. Io l’ho usato per il tipo di lente, visto che la lunghezza focale non basta a farmi ricordare con che obiettivo ho scattato la foto.

Purtroppo l’impaginazione di questi dati era oscena: tutto su una riga, senza label e in ordine casuale… si riesce in un attimo a metterci mano, ma purtroppo toccando il sorgente js dovremmo ricordarcene in caso di nuove versioni (sarebbe stato bello un template esterno).

Rigenerazione Thumbnails

Come spiegato poc’anzi, per avere una buona probabilità che le griglia dell’indice abbia 4 foto devo avere dei thumbnails da circa 300 pixel di larghezza, mentre in precedenza erano di dimensioni inferiori. Per ricreare circa 12000 foto, sparpagliate in 470 folders era ovviamente necessario ricorrere a un software che potesse essere chiamato da riga di comando e scriptabile in un batch.

Purtroppo i due software che di solito uso per questo tipo di operazioni (il già citato FastStone e il vecchio ma sempre buono PixResizer), non hanno questa opzione e mi sono dovuto quindi rivolgere ad un tool che si è rivelato potentissimo e con una miriade di opzioni: ImageMagick.

Ci ho messo un po’ a capire l’esatta sintassi del comando, in quanto la versione 7 è completamente diversa dalla 6, ma per compatibilità con la versione legacy hanno lasciato alcune modalità della precedente; aggiunto il fatto che mezza documentazione si riferisce alla 6 e alcuna alla 7, si tirano un po’ di ostie… Inoltre essendo un tool nato sotto Unix il “gobbling” delle wildcard (come vengono espansi ad es un *.jpg) funziona in modo diverso sotto dos e quindi bisogna prestare attenzione da dove si lancia il comando

es. se sono nella directory “temp” che contiene due subdir images e preview una cosa del tipo

resize images\*.jpg  preview\*.jpg  non fa quello che ci aspetta ovvero prendere i jpg della cartella images e salvarli ridimensionati nella previews. Bisogna per forza ENTRARE nella images con un cd images e poi lanciare resize *.jpg  preview\*.jpg (pseudocodice, il comando non si chiama resize)

la sintassi corretta per fare un resize di tutte le foto con un’altezza fissa di 200px (e width calcolata) è questa

magick nomesource.jpg –resize x200 nomedest.jpg

ho scoperto che l’opzione –thumbnail al posto della –resize genera file molto più piccoli, infatti strippa tutte le informazioni non necessarie alla visualizzazione (exif, altri metadati, gps, ecc.)

Mettendo tutto in un batch che esplode tutti i file di una cartella si ottiene quindi  (le “ “ sono necessarie se i nomi dei folder o dei files hanno dentro degli spazi)

cd \root\…\nomealbum\images
for %%a in (*.jpg) DO magick "%%a" -thumbnail x200 "..\preview\%%a"

Batch che ho ovviamente generato in automatico dal database con una semplice query sql

image

Lanciato il batch, in una 20ina di minuti 12541 foto sono state correttamente ridimensionate.

Conclusioni

Al momento sono abbastanza soddisfatto. La libreria offre moltissimi metodi di animazioni sia sulle transizioni che sull’entrata o sull’hover dei thumbnail. Non sono mai stato un grandissimo fan, dato che su device poco performanti rallentano molto la visualizzazione e alla lunga stanca, ma magari in futuro qualche cosina si potrebbe aggiungere.

Se la nuova visualizzazione vi piace (o vi fa schifo), trovate dei bug, o volete darmi un feedback, lasciate un commento qui sotto…

Aggiungi Commento

Copyright © 1997-2019 Sandro Rizzetto | All Rights Reserved | Riproduzione delle fotografie vietata | Powered by me