Jumping Jack Flash weblog

Hacking my renault app

Posted in Uncategorized by jumpjack on 4 ottobre 2021

L’app “MyRenault” permette, molto goffamente e con metodi arcani, misteriosi e imperscrutabili, di conoscere qualche dato sui propri mezzi elettrici ed ibiridi Renault. “Arcani e misteriosi” perchè tutte le volte che non funziona (e sono tante), l’unico messaggio di errore disponibile è “ops!”.

Quindi ho cercato di fare un po’ di reverse engineering dell’app, partendo da questa pagina, molto contorta e poco utile, passando per una decina di sorgenti Python di app alternative amatoriali, per poi finalmente approdare a un paio di script Javascript, che da soli non possono funzionare perchè progettati per agganciarsi a Google Assistant o alla schermata Widget dell’iphone, ma che almeno posso capire perchè scritti in un linguaggio che conosco.

Ne è scaturita una prima pagina in HTML+javascript, che funziona… ma solo una volta su 10: le altre 9 volte dà un errore 401 di autenticazione all’utlimo step, quello di lettura del numero di account Renault.

Questo è il processo di login che ho dedotto studiando le suddette pagine, ma evidentemente c’è un qualche errore da qualche parte, pr cui non funziona sempre:

login-schematic.png

Successivamente ho finalmente scoperto anche uno script PHP: anche se non si può utilizzare in locale ma serve per forza un server, almeno funziona il 90% delle volte (qualche volta fanno comunque le bizze i server Renault). E’ uno script ancora molto rozzo e primitivo, al punto che l’autore stesso ne sconsisglia l’uso online su un vero server, soprattutto perchè non ha nessuna misura di sicurezza, e chiunque lo usasse potrebbe accedere ai dati della vostra auto. Quindi ne ho derivata una mia versione, che ho chiamato RenaultPHP_LC , che implementa almeno qualche livello base di sicurezza: le password non sono memorizzate sul server, quindi ognuno deve specificare le sue quando usa lo script. Al momento le password sono scritte in chiaro nell’url… poi si vedrà se riuscirò a implementare un metodo un po’ più sicuro, una volta finita la sperimentazione, o se magari, una volta capito bene come funziona il login, farò prima a tornare alla pagina HTML e sistemarla.

Ecco quali sono i vari step di login effettuati tramite PHP, specificando l’url chiamato, il tipo di chiamata (GET e o POST) e il contenuto del payload; le chiamate che possono essere anche di tipo “GET” accettano i parametri dell’header anche passati tramite url.

Login Renault

Recupero token JWT

  • Tipo: GET o POST
  • url: https://accounts.eu1.gigya.com/accounts.getJWT
  • Header (array con nomi per i campi):
    • login_token = cookie Renault (cookieValue)
    • ApiKey = GIGYAKEY
    • fields = “data.personId,data.gigyaDataCenter”, // nota: questa è una stringa contenente i nomi dei campi desiderati
    • expiration = 87000
  • Payload: vuoto
  • Risultato: token JWT in campo id_token

Richiesta accountId

Richiesta numero telaio (VIN)

=== Manca in codice PHP ===

Da altri sorgenti:

Invio comando (action):

Struttura del payload rappresentata come oggetto JSON:

{
   "data":{
      "type":"NOME_ENDPOINT",
      "attributes":{
         "action":"NOME AZIONE", // in genere ricalca il nome dell'endpoint ma senza trattino
         "PARAMETRO":"VALORE PARAMETRO"
      }
   }
}

Esempio di azione per accendere aria condizionata:

Stringa del payload:

‘{“data”:{“type”:”HvacStart”,”attributes”:{“action”:”start”,”targetTemperature”:”21″}}}’;

In formato strutturato:

{
   "data":{
      "type":"HvacStart",
      "attributes":{
         "action":"start", 
         "targetTemperature":"20"
      }
   }
}

Con la Renault Captur il comando di accensione dell’aria condizionata non sembra funzionare (aomeno sulla mia), mentre funziona quello per avviare la ricarica.


Stabilizzazione video a 360°

Posted in Uncategorized by jumpjack on 9 agosto 2021

Ricerca di un algoritmo di stabilizzazione per video a 360°/panoramici/equirettangolari

Stabilizzare un video a 360° “mosso” o “ballonzolante” non è cosa semplice: programmi come Deshaker (plugin di Virtual Dub) o altri sono progettati per video tradizionali “piatti”, quindi il loro algoritmo non funziona, perchè si limita a calcolare, in modo più o meno complesso, di quanto si sposta l’immagine a destra e a sinistra tra un frame e l’altro.

Ma mentre in un video piatto tutti i pixel si spostano nella stessa direzione, in un video equirettangolare uno spostamento della telecamera si traduce in spostamenti di pixel molto complessi secondo le linee della proiezione equirettangolare:

In un video standard, se il pixel centrale si muove in una direzione, tutti gli altri si muovono nella stessa direzione:

In un video equirettangolare, se il pixel centrale si muova in una direzione, tutti gli altri si muovono in modi “strani” secondo le line della griglia equirettangolare:

Per poter stabilizzare un video 360/equirettangolare, sto allora cercando di applicare un’ “idea di algoritmo” trovata in rete: analizzare solo una piccola porzione del frame, e poi applicare al frame intero la necessaria rotazione o traslazione usando un apposito programma in grado di gestire immagini/frame equirettangolari: FFMpeg, che ad esempio usa questo generico comando qui sotto per ruotre il frame equirettangolare (ER) “input.png” sull’asse verticale (yaw) di 1°, sull’asse orizzontale destra-sinistra (pitch) di 2°, e sull’asse orizzontale avanti-dietro (roll) di 3°

ffmpeg -i input.png -vf v360=e:e:yaw=1:pitch=2:roll=3 -y output.png

Quello che serve per stabilizzare un video ER è:

  1. Ottenere dal video originale in formato ER (original.avi) una versione “piatta” , composta dai soli subframe che rappresentano una piccola parte, spianata, dell’intera sfera (flat.avi)
  2. Estrarre i singoli fotogrammi ER del video originale (ER_frame-xxxxxxx.png)
  3. Elaborare flat.avi tramite Deshaker, ottenendo un file di stabil.log con i valori di scostamento X e Y, e i valori di rotazione (Roll).
  4. Calcolare gli angoli Yaw e Pitch a partire dagli scostamenti X e Y
  5. Elaborare i singoli fotogrammi ER (ER_frame-xxxxxxx.png) per ruotarli in base ai valori di Yaw, Pitch e Roll ottenuti; chiamaremo questi frame s_ER_frame-xxxxxxx.png
  6. Unire i nuovi fotogrammi ruotati per formare il video ER stabilizzato finale (stabil.avi)

I vari comandi di FFMpeg necessari sono:

  • 1) ffmpeg -i full.mp4 -ss 0 -t 5 -vf v360=e:flat -y flat.avi sotto-video piatto
  • 2) ffmpeg -i original.avi -ss 0 -t 5 -y ER_frame-%07d.png singoli frame ER
  • 5) ffmpeg -i ER_frame-%07d.png -vf v360=yaw=YAW:pitch=PITCH:roll=ROLL -y s_ER_frame-%07d.png rotazione/stabilizzazione dei frame ER
  • 6) ffmpeg -i s_ER_frame-%07d.png -y stabilized.avi creazione del video dai frame singoli

L’elaborazione-chiave, però, la 5, non può essere eseguita nativamente da FFMpeg, perchè è necessario leggere i dati contenuti nel log di deshaker, trasformarli in Yaw, Pitch e Roll, e applicarli ai vari fotogrammi; serve quindi un programma che esegua ripetutamente il comando 5 creando gli opportuni valori da passare a FFMPEG

Al momento sono riuscito a eseguire i punti 1), 2), e 3, ottenendo la versione stabilizzata del sotto-video piano (flat.avi); sto cercando di capire come processare i valori di Deshaker per eseguire opportunamente il comando 5.

Questo è il video ER di prova che sto cercando di stabilizzare, una ripresa del viale che porta alla chiesa di San Biagio a Montepulciano:

Questo il sotto-video spianato estratto con FFMpeg:

E questo il risultato della stabilizzazione con Virtual Dub + Deshaker:

Ho lasciato visibili i bordi neri aggiunti da Virtualdub per evidenziare in che modo i fotogrammi vengono spostati e ruotati dal filtro per mantenere stabile il punto centrale. Purtroppo dal video stabilizzato si nota che il video originale a 360° presenta una forte distorsione/compressione nella parte bassa del fotogramma, cosa che probabilmente dipende dal fatto di usare il generico filtro V360 di FFMpeg piuttosto che uno che tiene effettivamente conto delle ottiche della mia fotocamera…che però non conosco.

Comunque, adesso resta da capire come elaborare i dati del file deshaker.log per ottenere i necessari angoli di rotazione Yaw, Pitch e Roll.

I dati del file che mi interessano sono le prime 4 colonne (il formato è descritto qui):

ItemDescription
Frame numberFrame number of the source video. For interlaced video, the frame number will have an ‘A’ or ‘B’ appended, depending on the field.
Pan XThe number of horizontal panning pixels between (the middle line of) the previous frame and current frame.
Pan YThe number of vertical panning pixels between (the middle line of) the previous frame and current frame.
RotationThe number of degrees of rotation between (the middle line of) the previous frame and current frame.

Bisogna vedere in che modo FFMpeg gestisce i tre parametri.

Partendo da un generico frame:

applico questo comando per cambiare lo Yaw di +30°:

ffmpeg -i frame0000002.png -vf v360=e:e:yaw=30 -y frame0000002-yaw30.png
  • -vf: applica filtro video
  • v360: filtro per immagini fisheye ed equirettangolari
  • e:e “converte” da equirettangolare a equirettangolare
  • yaw=30: indovina?

Il risultato è il seguente, cioè un’immagine spostata a sinistra:

Confronto diretto:

Quindi:

  • Yaw >0: aumenta lo Yaw della telecamera, cioè è come se l’inquadratura si spostasse a destra

Applichiamo invece un pitch di +30°:

 ffmpeg -i frame0000002.png -vf v360=e:e:pitch=30 -y frame0000002-pitch30.png 

Distorsione a parte, se ci concentriamo sul centro dell’immagine notiamo che la strada si abbassa, quindi è come se la telecamera si alzasse:

Quindi:

  • Pitch >0: aumenta il pitch della telecamera, che quindi guarda verso l’alto

Per quanto riguarda l’angolo di roll:

  ffmpeg -i frame0000002.png -vf v360=e:e:roll=30 -y frame0000002-roll30.png 

Anche qui bisogna concentrarsi sul punto centrale dell’immagine: vediamo allora che è come se la telecamera ruotasse in senso orario:

Quindi:

  • Roll>0: Telecamera ruota in senso orario

Riassumento quindi abbiamo trovato che per FFMpeg i valori di Yaw, Pitch e Roll sono relativi alla direzione di spostamento della telecamera, con questa convenzione:

  • Yaw>0: telecamera verso destra
  • Pitch>0: telecamera verso l’alto
  • Roll>0: telecamera ruota in senso orario

Analizziamo ora il comportamento del filtro deshaker. Le prime righe del log della stabilizzazione di flat.avi contengono questi dati:

  1      65.82    5.20  -0.315 0.98586                         #      1.43    9.32 
  2     -25.09    0.13  -0.089 0.99884                         #      6.62   21.85 
  3     -23.35   -4.22   0.105 1.00603                         #      2.57   20.68 
  4     -23.06   -1.78   0.437 0.99862                         #      2.23   16.27 

In realtà questi dati sono un po’ fuorvianti, perchè al primo frame non deve ovviamente essere apportata nessuna correzione, essendo quello iniziale e quindi di riferimento; evidentemente, ma poco ovviamente, questa numerazione segue lo standard C/C++, cioè parte da zero, e in più la prima riga, in cui tutte le correzioni sarebbero zero, è stata omessa.

Quindi la riga n.1 dice che, frame n.2 mostra queste differenze rispetto al frame n.1:

  • X = +65.82 pixel
  • Y = +5.20 pixel
  • R = -0.315 gradi

Andiamo ad esaminare visivamente i primi due frame:

Vediamo che a un valore positivo di X corrisponde uno spostamento verso sinistra dell’immagine, cioè verso destra della telecamera; quindi:

  • il segno dello scostamento orizzontale usato da Deshaker è coerente con quello usato da FFMpeg:
    • X>0 : telecamera verso destra

Lo scostamento verticale di 5.2 pixel non è apprezzabile nelle miniature di frame che inserisco qui sul blog, quindi vado a cercare due frame che abbiamo un offset verticale più grande nel log di deshaker:

  9     -40.04  -44.13  -2.390 1.00274                         #      7.69    8.58 

Qui, nel passaggio dal frame 8 al frame 9, sono apprezzabili tutti e 3 gli spostamenti: X, Y e Roll. Nel passare da 8 a 9, la telecamera si è spostata a sinistra, in alto ed ha ruotato in senso antiorario, per cui confrontare i due frame a occhio staticamente è complicato, mentre si vede facilmente in un’animazione:

Ne risulta che anche Y e Roll sono coerenti con FFMpeg, quindi in conclusione:

Deshaker.log

  • X>0 : telecamera a destra
  • Y>0: telecamera in alto
  • Roll >0: rotazione in senso orario

E’ molto importante ricordarsi, però, che quelli riportati in deshaker.log sono i valori rilevati; quindi per applicarli per stabilizzare un frame, bisognerà applicarli con segno opposto.

Riepilogando:

In FFMpeg applicando valori positivi si ottiene una modifica del video come da questo elenco:

  • Yaw>0: telecamera verso destra
  • Pitch>0: telecamera verso l’alto
  • Roll>0: telecamera ruota in senso orario

Virtualdub rileva questi valori tra un frame e il precedente:

  • X>0 : telecamera a destra
  • Y>0: telecamera in alto
  • Roll >0: rotazione in senso orario

In corrispondenza di questi valori rilevati da Virtual Dub bisognerà applicare con FFMpeg valori di segno opposto.

Non solo: i valori rilevati X e Y sono espressi in pixel, mentre le rotazioni applicate da FFMpeg devono essere espresse in gradi, quindi bisogna fare una conversione.

Considerando che un’immagine ER orizzontalmente spazia su 360° e verticalmente su 180°, dovrebbe voler dire che per ricavare Yaw e Pitch da X e Y bisogna calcolare la proporzione tra gli scostamenti e le dimensioni dell’immagine, quindi:

  • X : Largh = Yaw : 360
  • Y : Alt = Pitch : 180

Questo sempre se la relazione è lineare, cosa di cui non sono sicuro dal momento che siamo in trigonometria sferica, ma non mi viene in mente niente di meglio; quindi avremo:

  • Yaw = 360 * (X/Largh)
  • Pitch = 180 * (Y/Alt)

Considerando che in un video ER la larghezza è sempre il doppio dell’altezza, possiamo scrivere anche:

  • Yaw = 360 * X / Largh
  • Pitch = 360 * Y / Largh

E, visto che larghezza e altezza del frame sono ovviamente costanti, possiamo definire la costante K = 360 / Largh e semplificare il calcolo (cosa non da poco, visto che andrà eseguito migliaia di volte, una per ogni frame):

  • Yaw = K * X
  • Pitch = K * Y

Il Roll rilevato da Virtual Dub è invece già espresso in gradi.

Concludendo:

L‘algoritmo da implementare in un programma di stabilizzazione di video 360/equirettangolari basato sull’output di Deshaker e su FFMPeg deve applicare al frame numero N i valori di Yaw, Pitch e Roll calcolati in base alla riga numero N-1


Sequenza di comandi (includendo anche quella di conversione da formato fisheye/sferico a equirettangolare) da provare:

0) ffmpeg -i F:\documenti-video\montepulciano-sanbiagio(1).mp4 -ss 0 -t 5 -vf v360=fisheye:e:ih_fov=235:iv_fov=235:pitch=-90,v360=e:e:yaw=-90,scale=640:-1 -y -vcodec mpeg4 original.avi

1) ffmpeg -i original.avi -vf v360=e:flat -y flat.avi

2) ffmpeg -i original.avi -y ER_frame-%07d.png

5) ffmpeg -i ER_frame-%07d.png -vf v360=yaw=-YAW:pitch=-PITCH:roll=-ROLL -y s_ER_frame-%07d.png (tramite script/programma, o suando la funzione SENDCMD di FFmpeg)

6) ffmpeg -i s_ER_frame-%07d.png -y stabilized.avi

Le prime prove non hanno dato i risultati sperati, un po’ perchè i valori di pitch sembrano eccessivi, un po’ perchè è difficile mantenere il sincronismo tra frame e output di deshaker, perchè nelle varie conversioni sembra che vadano persi alcuni frame.


Nel frattempo però ho anche trovato un programma free/opensource che forse riesce a fare la stabilizzazione senza però costringere a scaricare centinaia e centinaia di MB come per DaVinci Resolve, Action Director o altri programmi mastodontici: Shotcut sta in uno zip di circa 80MB, e sembra dare risultati abbastanza buoni: il video finale non è proprio stabilissimo, ma sicuramente meglio dell’originale, e probabilmente funzionerebbe anche meglio su un video di partenza non distorto. Qui forse c’è qualche suggerimento su come creare i file specifici per calibrare la fotocamera da usare con FFMpeg, che richiede due file, xmap.pgm e ymap.pgm, anche se bisogna compilarsi da soli un sorgente C.

Ma tornando a shotcut, la procedura da seguire è:

  • Importare il video ER
  • Aggiungere il filtro “360 stabilizer”
  • Opzionalmente aggiungere, prima dello stabilizer, il filtro “360 transformer”, che permette di centrare a piacere il video su un certo punto:
  • Analogamente a Deshaker per Virtual Dub, anche qui bisogna eseguire una prima volta il filtro in modalità analisi; per farlo, spuntare l’apposita casella e avviare la riproduzione premendo spazio:
  • Alla seconda riproduzione, togliere la spunta per vedere il risultato finale.

Durante l’elaborazione si può osservare come Shotcut analizzi il video in 3 punti-chiave: al centro, a sinistra (yaw=-90) e a destra (yaw=+90), perchè analizzando al centro può vedere solo i cambi di Yaw e Pitch, mentre per vedere i cambi di roll può o analizzare la rotazione intorno al centro, oppure più semplicemente analizzare la traslazione verticale appunto nei punti a destra e a sinistra dell’osservatore.

Ecco quindi il video originale, centrato stavolta sulla direzione di moto, e il il risultato della stabilizzazione con Shotcut:

Anche se visto così fs venite un po’ il mal di mare, se si va di nuovo a estrarre il video “spianato” relativo alla parte della strada, si nota una discreta stabilizzazione.

Particolare “flat” del video equirettangolare di partenza:

Stabilizzazione fatta con Virtual Dub:

Stabilizzazione fatta con Shotcut:

La stabilizzazione fatta da Shotcut risulta deciamente migliore, tanto che solo questa evidenzia la deformazione/schiacciamento presente nel video originale, nella parte bassa del frame (notare come si schiaccia il parabrezza della macchina).

Questa “scoperta” dello schiacciamento suggerisce che probabilmente è molto meglio utilizzare le fotocamere 360 per riprendere frontalmente piuttosto che verso l’alto o verso il basso, perchè in questo modo il punto centrale dell’immagine è anche quello meno distorto, mentre il bordo distorto verrebbe solo intravisto dalla visione periferica dell’occhio.

Tagged with: , ,

Foto 3d a 180° o 360° (VR180 o VR360)

Posted in Uncategorized by jumpjack on 3 luglio 2021

Una foto panoramica può essere “a 360°” o “a 180°”; in realtà, trattandosi di trigonometria tridimensionale, bisognerebbe parlare di steradianti… ma non ne parla mai nessuno nei siti che trattano questi argomenti, quindi bisogna adattarsi a questa terminologia:

  • Foto a 360°: copre l’intera sfera, quindi l’elevazione va da -90° a +90°, e l’azimuth va da -180 a +180°; per intenderci, sono le foto di Google Street View
  • Foto a 180°: è in sostanza un “grosso fisheye”, che copre mezza sfera: l’elevazione va sempre da -90° a +90°, ma l’azimuth va da -90° a + 90°

Quindi in pratica quel “180” o “360” si riferisce ai gradi di azimuth coperti, mentre quelli di elevazione vanno sempre da un “polo” all’altro.

Veniamo ora all’effetto 3d: su una foto a 360° non lo si può ottenere, quantomeno non in modo semplice, perchè se si fanno due foto a 360° da due punti distanti 6.4mm (la distanza interpupillare), solo metà sfera mostrerà correttamente l’effetto 3d, mentre l’altra metà lo mostrerà invertito, perchè i due punti di vista sono in sostanza scambiati tra destra e sinistra quando le fotocamere inquadrano “dietro”; ovviamente si potrebbe correggere la cosa via SW, ma comunque al confine tra le due semisfere l’effetto 3d sarebbe scarso e confuso, col risultato che girando lo sguardo intorno a 360°, nel momento della transizione da un emisfero all’altro si avrebbe un effetto piuttosto sgradevole.

Questo problema è stato risolto, o meglio aggirato, inventando le foto “VR180”, cioè foto panoramiche 3d che coprono solo metà dell’orizzonte; cosa che in teoria non è neanche tanto malvagia, perchè foto così si possono guardare, in un visore 3d, anche seduti sul divano, senza bisogno di una sedia girevole o di stare in piedi per vedere anche dietro di noi; in più, non bisogna nascondersi sotto alla macchina fotografica per non comparire nella foto…

Chiaramente anche nel caso di foto VR180 c’è distorsione agli estremi destro e sinistro della sfera, ma appunto queste foto sono pensate per essere guardate senza girarsi “troppo” intorno, ma solo per avere un effetto immersivo frontale, dato dall’ “avvolgenza” della semisfericità, sommata alla tridimensionalità.

Come realizzare le foto

Realizzare una foto VR180 è tecnicamente facile, se il soggetto non è in movimento, perchè basta una sola macchina fotografica; se invece il soggetto si muove, ne servono due che scattino contemporaneamente, oppure una specifica fotocamera per scatti VR180, di fatto composta da due fotocamere affiancate sincronizzate. In ogni caso, alla fine avremo due immagini quadrate, ognuna delle quali contiene le foto semisferiche a 180° dei due punti di vista dei due occhi. Esempi di macchine fotografiche di questo tipo: Lenovo Mirage , VUZE XR , KANDAO QooCam

Come vedere le foto

Una volta scattate le due foto, usando una o due macchine fotografiche, come guardarle in modo 3d-panoramico-immersivo? Serve ovviamente un visore VR, ma serve anche che la foto sia formattata in un modo specifico, e che nel visore sia installato un SW compatibile con quello specifico formato… e qui le cose si fanno complicatissime.

Più avanti trovate una spiegazione dettagliata; qui limitiamoci all’essenziale:

Metodo1 – partendo da due foto separate

Una volta scaricati questi file, bisognerà incollare nel file dell’occhio destro la foto semisferica quadrata relativa all’occhio destro, e idem per l’occhio sinistro.

Fatto ciò, bisogna aprire VR180, cliccare su “unisci immagini”, e trascinare contemporaneamente sulla finestra del programma i TRE file: le due immagini e il file .bin contenente i metadati. NOTA: è fondamentale che i file abbiano tutti lo stesso nome di base, seguito da -left, -right e meta, quindi per esempio:

  • prova-left.jpg
  • prova-right.jpg
  • prova-meta.bin

Fatto ciò, cliccare sul tasto ESPORTA per ottenere il file prova-merged.vr.jpg .

Per vedere questo file con un visore VR cardboard, occorre l’app Cardboard Camera ; una volta installata, copiare il suddetto file nella cartella phone/DCIM/cardboard sul cellulare, e riavviare l’app Cardboard Camera per vederla.

Metodo 2 – Partendo da una foto cardboard pre-esistente

Partiamo da un’immagine cardboard pre-esistente, ad esempio questa:

Un’immagine cardboard, anche se completa sui 360° di azimuth, è sempre incompleta verticalmente, perchè viene effettuata ruotando su sè stessi di 180° ma senza alzare o abbassare il telefono, quindi non è propriamente una foto sferica, ma solo panoramica; diciamo una 360×90 o qualcosa del genere. Se andiamo infatti a convertirla in una vera immagine VR360 di tipo top/bottom, cioè due immagini equirettangolari sovrapposte, vedremo che le due metà non sono complete:

Metodo 3 – Partendo da due foto fisheye

Applicando una lente fisheye su un qualunque cellulare è possibile ottenere una foto di questo tipo:

Bisognerà scattarne anche una seconda, corrispondente al punto di vista dell’occhio destro, cioè spostandosi a destra di circa 6.5 cm:

Bisogna poi convertire le due foto in formato equirettangolare, ma per farlo occorre prima ritagliare solo la parte di interesse: un quadrato circoscritto all’immagine; purtroppo le lenti a clip che si applicano ai cellulari non sono mai precise, quindi bisogna “immaginare” dove arriverebbe il cerchio del fisheye se fosse completo; l’importante è che la foto sia esattamente quadrata e il cerchio esattamente centrato:

Una volta che abbiamo le due immagini quadrate, possiamo finalmente convertirle in equirettangolari, ad esempio usando ffmpeg:

ffmpeg -i left-crop.jpg -vf v360=fisheye:e:ih_fov=190:iv_fov=190 -y left-equi.jpg

La “e” dopo “fisheye” indica proprio il formato equirettangolare 360×180

Il risultato sarà quindi una foto rettangolare con rapporto 2:1, e “riproiettata”:

Lo stesso faremo ovviamente per l’immagine destra:

Una volta che abbiamo le due immagini quadrate riproiettate, dobbiamo unirle in una immagine singola, mettendo l’immagine sinistra in alto e la destra in basso:

Per farlo possiamo usare di nuovo ffmpeg:

ffmpeg -i left-equi.jpg -i right-equi.jpg -vf v360=e:e:out_stereo=tb -y top-bottom.jpg

Infine dovremo passare l’immagine top/bottom al programma che la trasformerà in formato Google Cardboard: equiToVr180Photo, che fa parte della suite di tool VR180PhotoTools (https://github.com/Vargol/VR180PhotoTools):

equiToVr180Photo.exe -f tb -i immagine-top-bottom.jpg -o cardboard.vr.jpg  -v 190x190

In realtà il tool accetta una varietà di formati in ingresso “tb” è appunto il formato top-bottom (=immagine sinistra in alto, immagine destra in basso), ma accetta anche “bt” (botton-top), “lr” (left-right) e “rl” (right-left).

Per verificare se l’immagine ottenuta è effettivamente compatibile con Google Cardboard, prima di copiarla sul cellulare, possiamo fare in due modi:

  • La carichiamo sul Google Cardboard Converter ufficiale, che, se l’immagine è compatibile, restituirà di nuovo un’immagine equirettangolate top/bottom; in rari casi però questa pagina accetta immagini che poi non sono però accettate dall’app sul telefono
  • La carichiamo sul Cardboard Converter NON ufficiale (sorgenti), basato sempre però su quello ufficiale, con la differenza che dovrebbe preservare le dimensioni originali dell’immagine. Il vantaggio è che questo funziona anche offline (ma solo su browser che non hanno limitazioni CORS, come Firefox)
  • La carichiamo nel programma Google VR 180 Creator, che permette di dividere un’immagine cardboard in due immagini separate; in teoria il programma permetterebbe anche di creare un’immagine cardboard a partire da due immagini separate, ma purtroppo necessita anche di un terzo file -meta.bin che la documentazione non spiega come creare.

Dettagli tecnici

Qui sotto un esempio di foto VR180 di tipo Cardboard VR, scaricata da questo repository github:

Sfortunatamente/ovviamente, quando viene caricata su WordPress, l’immagine viene rielaborata rovinandone i dati EXIF indispensabili per essere correttamente interpretata, quindi bisogna memorizzare questo tipo di foto su server che non ne modifichino niente:

Immagine VR180 in formato Google Cardboard: https://win98.altervista.org/360/test3.jpg

L’immagine può essere scaricata anche direttamente da github: https://github.com/imrivera/google-photos-vr180-test/blob/master/test3.jpg

Aperta in un normale visualizzatore di immagini, quest’immagine appare come qui sopra, semplicemente un quadrato rosso con dentro scritto “LEFT EYE”, ma in realtà, nascosta nei metadata EXIF, c’è anche l’immagine per l’occhio destro:

Questo infatti è il formato utilizzato da Google Cardboard Camera: un’ “immagine nell’immagine”, accoppiate tramite metadati exif.

Una volta scaricata l’immagine, bisogna:

  • scomporla in 3 file tramite l’app per PC Google VR180 Creator, che creerà un file jpg per l’occhio destro e uno per il sinistro
  • aprire il file -left.jpg in Paint
  • incollare l’immagine relativa all’occhio sinistro; deve essere semisferica quadrata (ottenuta tramite obiettivo fisheye o camera grandangolare)
  • ripetere per l’immagine destra
  • Utilizzare di nuovo VR180, stavolta per ricombinare insieme le due immagini in un’unica immagine .vr.jpg

Tutto questo procedimento può essere eseguito automaticamente in una volta sola usando questo script Windows/DOS:

:: Crea immagine cardboard a partire da due fisheye
:: %1: Nome base immagine (pippo-left.jpg --> pippo)


:: Converte i fisheye in equirettangolari:
ffmpeg -i %~n1-left.jpg  -vf v360=fisheye:e:ih_fov=190:iv_fov=190 -y %~n1-left-equi.jpg
ffmpeg -i %~n1-right.jpg -vf v360=fisheye:e:ih_fov=190:iv_fov=190 -y %~n1-right-equi.jpg

:: Crea immagine VR360 in formato top-bottom:
ffmpeg -i %~n1-left-equi.jpg -i %~n1-right-equi.jpg -vf v360=e:e:out_stereo=tb -y %~n1-TD.jpg

:: Usa l'immagine VR360 per creare immagine cardboard:
equiToVr180Photo.exe -i %~n1-TD.jpg -f tb -v 360x180 -o %~n1.vr.jpg

E’ sufficiente salvare quanto sopra nel file “crea.bat” , memorizzare nella stessa cartelle immagini fisheye quadrate immagine-left.jpg e immagine-right.jpg, e poi lanciare lo script usando la sintassi:

crea immagine

Lo script troverà automaticamente i file che iniziano con “immagine” e terminano con “-left.jpg” e “right.jpg”, e creerà un’immagine cardboard con nome immagine.vr.jpg.

Chiaramente lo script va personalizzato per specificare il FOV (Field Of View) effettivamente coperto dalle immagini fisheye, qui specificato come 190°.

I software

PC

  • Google VR180 creator: https://arvr.google.com/vr180/apps/ – Programma per PC per estrarre da immagini cardboard le due immagini per i due occhi, nonchè per convertirle/reinserirle per ricreare l’immagine Cardboard a partire da 3 file -left.jpg, -right.jpg e -meta.bin (ma nessuno sa quale sia il formato del file .bin, quindi è inutile).

VR180PhotoTools (https://github.com/Vargol/VR180PhotoTools) – contiene 2 tool:

vr180ToEquiPhoto.exe: Prende una foto nel formato Google Cardboard Camera (di tipo .vr.jpg) e la converte in “VR180 equirettangolare 3d” o “equirettangolare doppia top-bottom”

equiToVr180Photo.exe: Crea una foto Cardboard a partire da una immagine “VR180 equirettangolare 3d”

Un immagine VR180 3d ha questo aspetto se copre solo l’area 180×180:

Se invece copre l’intera sfera 360×180:

Android

Dismessa da google insieme al suo visore, è visibile sul Play Store solo a chi l’ha già installata in precedenza; permette di realizzare foto sferiche 360×180 [tridimensionali , da verificare]

Visualizzatori online immagini carboard .vr.jpg

Altro

  • WebXR API Emulator – Emulatore vr cardboard per PC (Chrome, Firefox):

Estensione che permette di visualizzare sul browser web del PC pagine VR 3d, che normalmente sarebbero visibili solo su un cellulare con browser che supporta la VR, come ad esempio questa o altre come queste.

Per sviluppatori

<rdf:Description rdf:about="" xmlns:GPano="http://ns.google.com/photos/1.0/panorama/">
    <GPano:UsePanoramaViewer>True</GPano:UsePanoramaViewer>
    <GPano:CaptureSoftware>Photo Sphere</GPano:CaptureSoftware>
    <GPano:StitchingSoftware>Photo Sphere</GPano:StitchingSoftware>
    <GPano:ProjectionType>equirectangular</GPano:ProjectionType>   Unica proiezione supportata ufficialmente da google
    <GPano:PoseHeadingDegrees>350.0</GPano:PoseHeadingDegrees>    Serve solo per visualizzare foto in Google Maps
    <GPano:InitialViewHeadingDegrees>90.0</GPano:InitialViewHeadingDegrees>
    <GPano:InitialViewPitchDegrees>0.0</GPano:InitialViewPitchDegrees>
    <GPano:InitialViewRollDegrees>0.0</GPano:InitialViewRollDegrees>
    <GPano:InitialHorizontalFOVDegrees>75.0</GPano:InitialHorizontalFOVDegrees>
    <GPano:CroppedAreaLeftPixels>0</GPano:CroppedAreaLeftPixels>
    <GPano:CroppedAreaTopPixels>0</GPano:CroppedAreaTopPixels>
    <GPano:CroppedAreaImageWidthPixels>4000</GPano:CroppedAreaImageWidthPixels>
    <GPano:CroppedAreaImageHeightPixels>2000</GPano:CroppedAreaImageHeightPixels>
    <GPano:FullPanoWidthPixels>4000</GPano:FullPanoWidthPixels>
    <GPano:FullPanoHeightPixels>2000</GPano:FullPanoHeightPixels>
    <GPano:FirstPhotoDate>2012-11-07T21:03:13.465Z</GPano:FirstPhotoDate>
    <GPano:LastPhotoDate>2012-11-07T21:04:10.897Z</GPano:LastPhotoDate>
    <GPano:SourcePhotosCount>50</GPano:SourcePhotosCount>
    <GPano:ExposureLockUsed>False</GPano:ExposureLockUsed>
</rdf:Description>

Quindi in sostanza basta quanto segue (oltre all’immagine dell’occhio destro memorizzata nella tag XMP-GImage, ed eventualmente l’audio in XMP-GAudio):

<rdf:Description rdf:about="" xmlns:GPano="http://ns.google.com/photos/1.0/panorama/">
    <GPano:ProjectionType>equirectangular</GPano:ProjectionType>
    <GPano:CroppedAreaLeftPixels>0</GPano:CroppedAreaLeftPixels>
    <GPano:CroppedAreaTopPixels>0</GPano:CroppedAreaTopPixels>
    <GPano:CroppedAreaImageWidthPixels>4000</GPano:CroppedAreaImageWidthPixels>
    <GPano:CroppedAreaImageHeightPixels>2000</GPano:CroppedAreaImageHeightPixels>
    <GPano:FullPanoWidthPixels>4000</GPano:FullPanoWidthPixels>
    <GPano:FullPanoHeightPixels>2000</GPano:FullPanoHeightPixels>
</rdf:Description>

La logica è la seguente, per i due tipi di immagine: sfera completa (usata in Google Street View) o cilindro/panorama (usata in Google Cardboard):

Sfera completa StreetView:

Google PhotoSphere/StreetView EXIF parameters

Cilindro cardboard:

L’unica differenza sta quindi nei due parametri CroppedAreaLeftPixels e CroppedAreaTopPixels: nella sfera completa sono relativi all’angolo alto-sinistra dell’immagine equirettangolari, mentre nella striscia cardboard il secondo sembra in sostanza essere uguale alla metà dell’altezza dell’immagine visibile, quindi probabilmente non viene nemmeno usato, chissà.

Quest’altra pagina di Google fornisce un formato un po’ più complesso/completo: https://developers.google.com/vr/reference/cardboard-camera-vr-photo-format

<x:xmpmeta xmlns:x="adobe:ns:meta/" xmptk="Adobe XMP">
  <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description
       xmlns:GImage="http://ns.google.com/photos/1.0/image/"
       xmlns:GPano="http://ns.google.com/photos/1.0/panorama/"
       xmlns:GAudio="http://ns.google.com/photos/1.0/audio/"
       xmlns:xmpNote="http://ns.adobe.com/xmp/note/"
       GImage:Mime="image/jpeg"
       GPano:CroppedAreaLeftPixels="7530"
       GPano:CroppedAreaTopPixels="1809"
       GPano:CroppedAreaImageWidthPixels="1046"
       GPano:CroppedAreaImageHeightPixels="1746"
       GPano:FullPanoWidthPixels="10740"
       GPano:FullPanoHeightPixels="5370"
       GPano:InitialViewHeadingDegrees="269"
       GAudio:Mime="audio/mp4"
       xmpNote:HasExtendedXMP="fe3edd169aebc146ca7aceb5cd15294d" />
  </rdf:RDF>
</x:xmpmeta>

Per quanto riguarda immagine dell’occhio destro e audio, sono memorizzati nelle suddette tag GIMage e GAudio, in questo modo:

   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <rdf:Description
        xmlns:GImage="http://ns.google.com/photos/1.0/image/"
        xmlns:GAudio="http://ns.google.com/photos/1.0/audio/"
        GImage:Data="Base64EncodedImageData"
        GAudio:Data="Base64EncodedAudioData" />
  </rdf:RDF>

  • File batch DOS per creare foto VR180 per cardboard a partire da:
    • .mpo
    • .jps
    • .pns
    • .ssi
    • 2D panoramas
    • left and right vr360 cameras
    • 3D insta360 evo (from .jpeg .insp)

Si serve di exiftool, ffmpeg e exiv2

  • Minuscola pagina web per visualizzare immagini equirettangolari; in locale funziona solo su firefox, per chrome bisogna caricarla su un server per evitare problemi di cross-origin; utilizza la libreria A-Frame:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
  <meta http-equiv="content-type" content="text/html; charset=utf-8">
  <meta name="generator" content="PSPad editor, www.pspad.com">
  <title></title>
  </head>
  <body>
https://aframe.io/releases/0.6.1/aframe.min.js
<a-scene>
  <a-assets>
    <img id="panorama" src="image.jpg" crossorigin />
  </a-assets>
  <a-sky src="#panorama" rotation="0 -90 0"></a-sky>
</a-scene>
  </body>
</html>
  • Pagina ufficiale Google del formato delle immagini Cardboard .vr.jpg: link
  • Contenuto del file -meta.bin che Google VR180 associa alle immagini destra e sinistra estratte da un’immagine .vr.jpg (immagini 3000×3000):

0A 0F 08 F0 2E 10 B8 17 18 B8 17 20 B8 17 28 EE 05 12 00 (19 byte)

  • Sensori in uso su camere 360
    • Sony IMX214: 13 MPixel
    • Sony IMX206: 18 Mpixel
  • PICAM360: camera modulare

Comando Linux EXIFTOOL per estrarre la “seconda foto” o “foto nascosta” da una foto Google VR180 (ad esempio scattata con una macchinetta Lenovo Mirage o VUZE XR o KANDAO QooCam ):

exiftool -config gimage.config -b -XMP-GImage:Data $1.jpg | base64 --decode > othereye.jpg 
  • Comandi vari per FFMPEG di conversione video VR180 o VR360 verso altri formati: link

Altri comandi FFMPEG:

Da L/R a 2160P singolo:

ffmpeg -i L.mov -i R.mov -i Audio.wav -filter_complex "[0]subtitles=subs.srt,scale=3840x1080:flags=lanczos,setsar=1[l];[1]subtitles=subs.srt,scale=3840x1080:flags=lanczos,setsar=1[r];[l][r]vstack" -crf 18 -c:v libx265 -pix_fmt yuv422p -map 2:a -c:a aac -b:a 320k -metadata:s:v stereo_mode=left_right movie_3dpv.mp4
ffmpeg -i input.mp4 -vf "[in] pad=4iw:ih:iw/2:0 [right]; movie=input.mp4, pad=2iw:ih:iw/2:0 [left]; [left][right] overlay=main_w/2:0 [out]" -c:v libx264 -preset medium -crf 23 -acodec copy output.mp4

Script python per estrarre immagine destra e audio da immagine Cardboard: https://edward.io/blog/extracting-google-cardboard-photos.html

Listato completo:

import base64
from libxmp.utils import file_to_dict


xmp = file_to_dict(image_file)
right_image = base64.b64decode(xmp['http://ns.google.com/photos/1.0/image/'][1][1])
audio = base64.b64decode(xmp['http://ns.google.com/photos/1.0/audio/'][1][1])

open('right_image.jpg', 'w').write(right_image)
open('audio.aac', 'w').write(audio)

FFMPEG

  • Usare FFMPEG per riproiettare un fisheye generico (anche oltre 180°) in un’immagine equirettangolare (da qui); però FFMPEG non mette i dati exif per permettere ai programmi di interpretare l’immagine risultante come panorama; per i video si può usare https://github.com/google/spatial-media/releases/tag/v2.1 , ma per le immagini serve ExifFixer (anche online), oppure questa riga, da usare con ExifTools:
exiftool -ProjectionType="equirectangular" out.jpg

Script FFMPEG (antecedente a filtro VR360):

rem Parametri di input dell'utente: dimensioni dell'immagine e angolo del fisheye:
set "FF=c:\ffmpeg\ffmpeg" :: Path to FFmpeg
set "IN=IMG_077.jpg" :: Fisheye input image or video, must be square - L'input può essere sia un'immagine che un video
set "OUT=out.jpg" :: Equirectangular output image or video
set "SQ=3648" :: Size of square fisheye input image - L'immagine fisheye deve essere quadrata: questa è la larghezza
set "FOV=235" :: Fisheye field of view in degrees  - CAMPO VISIVO DELL'OBIETTIVO FISHEYE
set "Q=2" :: Size divider for output image, use 1 for best quality, or a bigger value for faster computing

rem Parametri autocalcolati:
set /a "H=%SQ%/%Q%" :: Height of equirectangular image
set /a "W=2%H%" :: Width of equirectangular image is always twice the height set /a "A=%H%%FOV%/360" :: Height of equirectangular image that is actually filled with data, the lower part of the output image remains black


rem Crea l'algoritmo di rimappatura: una volta calcolati per una fotocamera, valgono sempre:
rem Create the xmap file for remapping from fisheye to equirectangular
%FF% -f lavfi -i nullsrc=size=%W%x%H% -vf format=pix_fmts=gray16le,^
geq='%SQ%/2(1-Y/%A%sin(X2PI/%W%))' -frames 1 -y xmap1.pgm

rem Create the ymap file for remapping from fisheye to equirectangular
%FF% -f lavfi -i nullsrc=size=%W%x%H% -vf format=pix_fmts=gray16le,^
geq='%SQ%/2(1-Y/%A%cos(X2PI/%W%))' -frames 1 -y ymap1.pgm

rem Riga effettiva della riproiezione:
rem Remap from fisheye to equirectangular
%FF% -i %IN% -i xmap1.pgm -i ymap1.pgm -filter_complex "format=pix_fmts=rgb24,remap" -y %OUT%

pause
  • Uno script FFMEPG più breve si basa sul nuovo filtro 360 ora disponibile:
set "FF=c:\ffmpeg\ffmpeg" :: Path to FFmpeg
set "IN=1200.png" :: Input image or video
set "FOV=180" :: Input field of view in degrees
set "C=green" :: Color for filling unused area
set "OUT=out.png" :: Equirectangular output image or video
%FF% -i %IN% -vf drawbox=w=1:h=1:color=%C%,v360=input=fisheye:id_fov=%FOV%:output=equirect:pitch=-90 -y %OUT%
pause

Script base per convertire un’immagine “double fisheye” (Samsung gear360) in equirettangolare: per immagine ideale, in cui i due scatti sono perfettamente centrati e con FOV=180°:

ffmpeg -i input_file -vf v360=dfisheye:equirectangular  -y output_file 

Anche abbreviabile in:

ffmpeg -i input_file -vf v360=dfisheye:e -y output_file 

Da semisfera fisheye 235° orientata verso il basso a equirettangolare:

ffmpeg -i input.jpg -vf v360=fisheye:e:pitch=90:ih_fov=235:iv_fov=235 -y output.jpg

Da semisfera verso l’alto a equirettangolare:

ffmpeg -i input.jpg -vf v360=fisheye:e:pitch=90:ih_fov=235:iv_fov=235 -y output.jpg

Da semisfera orizzontale a equirettangolare:

ffmpeg -i input.jpg -vf v360=fisheye:e:pitch=0:ih_fov=235:iv_fov=235 -y output.jpg

Thread su forum ricotheta con sorgenti javascript per convertire immagini dualfisheye:

https://community.theta360.guide/t/displaying-thetas-dual-fisheye-video-with-three-js/1160

Relativi sorgenti su github (per node.js): https://github.com/izmhr/ThetaSphericalMapping

Immagini cardboard di esempio

link1 link2 link3

Procedimento per visualizzazione online di panorama 360×180 3d (VR180) partendo da immagini tonde singole:

  • Riproiettare in equirettangolare (programma da trovare (forse qui), o mio beta, o FFMPEG); si ottiene un’immagine rettangolare ed equirettangolare per ogni immagine tonda/quadrata.
  • Incollare le due immagini rettangolari in una singola immagine quadrata, mettendone una sopra e una sotto
  • Caricare l’immagine risultante in questa pagina: https://spano.pyrik.dev/

Foto 360 2d embedded in WordPress

In wordpress.com, anche in versione free, è possibile inserire nelle pagine una foto panoramica a 360° utilizzando quelli che vengono chiamati “shortcodes“; nel caso specifico, lo shortcode è “vr”, ed ha il formato:

(vr url=percorso_completo_a_file view=360)

(Sostituire le parentesi tonde con parentesi quadre)

Questa sotto per esempio è la vista panoramica interattiva di questa foto (lago di Nemi), in formato equirettangolare e senza bisogno di metadati EXIF.

Tagged with: , , , , ,

Dati storici e grafici zone/colori regioni covid-19

Posted in Senza categoria by jumpjack on 18 giugno 2021

Ho cercato in lungo e in largo per mesi, ma senza successo: sembra che a nessuno interessi sapere quali sono stati i colori delle varie regioni d’Italia nel corso della pandemia di Sars-Cov-2. Eppure è un dato semplicemente fondamentale, per capire quanti e quali effetti le chiusure hanno avuto sulla diffusione del contagio, altrimenti cosa abbiamo chiuso a fare?!?

Dopo queste lunghe ricerche, il meglio che sono riuscito a trovare sono 3 o 4 repository github, che contengono questi dati in formati più o meno esotici: si va dal file di 30 MB (180 MB scompattati) da scaricare dal sito ufficiale della protezione civile, al file che contiene solo i dati del 2021, a quello che contiene dati sbagliati, parziali o a vanvera… ce n’è per tutti i gusti!

Questi sono i repository che ho trovato finora:

  1. Dati ufficiali Protezione civile (File (30MB zip, 180 MB unzippato)) – Dati ufficiali di Stato
  2. covid19italia (file) – Estratto del file della protezione civile, coi soli colori
  3. CloudItaly (file) – File json ragguppato per ordinanze, parte da gennaio 2021
  4. imcatta (file) – file CSV ordinato per regione, parte dall’inizio (nov 2020)

E questi sono 3 pagine che creano 3 tipi di grafici diverse in base alle fonti disponibili di dati (sul file originale da 30MB non riesco a lavorare, è troppo grosso e pieno di decine di MB di dati che non mi servono):

  1. (nessun grafico disponibile)
  2. Grafico da fonte 2 (errori vari)
  3. Grafico da fonte 3 (solo 2021)
  4. Grafico da fonte 4 (completo)

Dal repository n.4 ho ricavato il grafico in apertura di articolo. Dal primo repository invece ho ricavato un’altra pagina che mostra l’andamento del contagio dall’inizio fino ad oggi; esistono decine di siti che riportano questo grafico, ma per qulche motivo anche in questo caso manca un dato fondamentale: la previsione dell’andamento futuro! Non si tratta di magia o di astrologia, ma di “metodi matematici applicati all’ingegneria”, o di “regressione lineare o quadratica”; in parole semplici: esistono formule matematiche che permettono di “prevedere il futuro”.

Se a inizio pandemia queste formule prevedevano un’apocalisse di 7 miliardi di contagiati nel mondo nel giro di 8-10 mesi, accompagnati forse da quasi 1 miliardo di morti, fortunatamente la previsione è stata annullata grazie all’applicazione delle restrizioni (mascherina, distanziamento, disinfettante, chiusure,….), e quindi dopo un anno e mezzo la pandemia non è riuscita a infettare tutti gli abitanti del pianeta.

Queste erano le proiezioni per le varie ondate, in caso non fossero state introdotte restrizioni (realizzate tramite questa pagina):

Ad oggi, 18 giugno 2021, le proiezioni danno un contagio azzerato entro fine giugno, ma dipende molto dal momento in cui viene fatto partire il calcolo della regressione lineare:

Purtroppo il modello previsionale funziona bene solo in assenza di “fattori modificanti esterni”: ergo, funziona bene solo per prevedere fino a quanto CRESCERA’ il livello di contagio in MANCANZA di restrizioni; quando invece le restirizioni sono applicate, essendo applicate in modi diversi in regioni diverse, e seguite in modi diversi da persone diverse, il modello può prevedere molto poco; se poi si aggiungono i vaccini, ormai somministrati in modo del tutto casuale, e si tiene conto anche dei novax che non si vaccineranno mai, e delle varianti forse-vaccino-resistenti ,ecco chesi può al massimo andare “a intuito”: il grafico mostra attuale mostra che, sia in andamento quadratico che lineare, i contagi andranno a zero entro fine luglio se tutto rimane come ora. Ma chi lo sa…

Ciò che si può fare è prestare attenzione ai cambi di pendenza della curva, che indicano il subentrare di una qualche nuova condizione al contorno a “disturbarne” l’andamento ideale:

Nei mesi precedenti ra pittosto facile individuare i “Punti critici”:

Dall’ultimo picco di aprile 2021, invece, tuto è diventato più caotico, ma fortunatamente sempre tendenzialmente in discesa sul lungo termine:

Ma la cosa che più conta è che il nuovo calo di contagi tendnte a zero ha una causa ben diersa rispetto a quella dell’estate 2020: all’epoca uscivamo da mesi e mesi di reclusioni e restrizioni, mentre ora siamo esattamente nella situazione opposta: a un CALO delle restrizioni corrisponde un CALO dei contagi; ovviamente è merito dei vaccini:

Riferimenti normativi:

Diario elettrico Renault Captur plugin – 11 giugno 2021: i freni non funzionano in discesa

Posted in auto elettriche by jumpjack on 11 giugno 2021

Che quest’auto abbia problemi di Qualità tanto gravi da collocarla al di sotto il livello dei peggiori prodotti cinesi ormai è assodato, ma adesso ho trovato un ulteriore, gravissimo bug del SW, che, analogamente ad altri già segnalati, potrebbe causare incidenti e feriti: il servofreno è difettoso.

Se capita di partire da fermi in discesa senza innestare la marcia, rimanendo cioè in N, e si “ingrana” la marcia B solo dopo (in realtà non si innesta niente di meccanico, è una marcia eletronica), il servofreno non si attiva, quindi per frenare è necessario spingere il pedale con forza, quando invece normalmente basta appena sfiorare il pedale per “inchiodare”, specie se si sta procedendo a bassa velocità.


Gli altri problemi di sicurezza riscontrati sono:

Cambio marcia in salita ad alta velocità (autostrada) in fuori-giri: la centralina può scalare verso una marcia più bassa quando il veicolo si muove a velocità eccessiva per quella marcia; a giudicare dal rumore, (non ho fatto misurazioni precise tramite OBD e non c’è un contagiri sul cruscotto), sembra che il motore arrivi a 6000 giri e oltre. Considerando che l’auto è una plugin e quindi tecnicamente neanche ha bisogno di collegare il motore termico alle ruote, è un problema davvero assurdo. RISCHIO ROTTURA MOTORE; RISCHIO INCIDENTE.

Innesto freno a mano e marcia di parcheggio (P) con veicolo in marcia: se si toglie la cintura a veicolo in movimento e poi ci si ferma, alla ripartenza, dopo un tempo variabile tra 1 e 15 secondi, si innestano da soli la marcia P e il freno a mano; a volte si innesta solo il freno a mano, e la marcia P si nnesta dopo qualche altro secondo. E’ possibile che il problema si verifichi solo in salita, non ho verificato. Quindi è meglio non approfittare di una sosta al semaforo per togliersi/mettersi un giacchetto, o prendere qualcosa sul sedile posteriore, per esempio. RISCHIO ROTTURA CAMBIO, RISCHIO TAMPONAMENTO.

Mancata separazione pavimento tra guidatore e passeggero posteriore: in caso un oggetto cada sul pavimento dal sedile posteriore, non c’è un impedimento fisico che eviti che l’oggetto rotoli fino ai pedali. Potrebbe quindi risultare impossibile frenare. RISCHIO INCIDENTE.

False segnalazioni di emergenza: càpita che in presenza di pedoni sul marciapiede che NON stanno attraversando, parta l’allarme rosso visivo e sonoro che invita a frenare immediatamente; non mi è ancora capitato che l’auto freni anche (è dotata di frenata automatica), ma visto che l’allarme parte, penso che potrebbe succedere; questi falsi allarmi durano in genere però meno di 1 secondo, quindi forse non fa in tempo a innescarsi la frenata automatica. RISCHIO TAMPONAMENTO.

Adattatore jack audio per telefono fisso Alcatel-Lucent 8029

Posted in elettricita, hacking, hardware by jumpjack on 7 giugno 2021

Il telefono Alcatel-Lucent 8029 dispone di una presa audio per la connessione di una cuffia, che però ha un pinout molto particolare, col quale non funziona nessuna delle cuffie, con o senza microfono, che ho provato; dopo lunghe ricerche e numerosi test, alla fine ho scoperto che ha lo stesso pinout della antica XBOX 360.

Di jack audio esiste una molteplice varietà, a partire dal numero di contatti; si parla di tipo “TS”, “TRS”, o “TRRS”:

Il suddetto telefono ha un connettore TRS a 3 contatti, mappato in questo modo:

Esistono in commercio adattatori che permettono di collegare a questo tipo di jack una cuffia con connettori sdoppiati:

La XBOX aveva però un connettore da 2.5mm, mentre il telefono alcatel ha un connettore da 3.5mm, quindi serve un ulteriore adattatore: da 3.5mm maschio a 2.5 mm femmina:

Immagine 1 - Adattatore Jack Audio da 2.5mm Femmina a 3.5mm Maschio in Metallo - Nuovo

Non ha importanza se è a 3 o 4 pin: tecnicamente dovrebbe essere da 3, ma anche usando quello da 4, i due anelli più vicini al filo vengono automaticamente cortocircuitati dall’adattatore XBOX.

Esiste una molteplicità di connettori/sdoppiatori, con vari “sessi” e varie mappature:

  • doppio maschio a singola femmina: su un maschio c’è il microfono, sull’altro c’è la cuffia, la femmina unisce entrambi; i due maschi vanno a PC (in genere fissi) con jack cuffia/mic separati, la femmina va ad auricolare per cellulari, che ha jack singolo
3.5 MM Cavo audio stereo 1 a 2 MASCHIO Donna Y SPLITTER MIC JACK per cuffie  | eBay
  • doppia femmina a singolo maschio:
    • tipo 1: stereo splitter, con due femmine che portano entrambe il segnale stereo proveniente dal jack maschio a 3 pin; serve a permettere a due persone di ascoltare la stessa sorgente usando due cuffie separate; si riconosce perchè sui jack femmina non sono riportati i due simboli di microfono e altoparlante, e il jack maschio ha solo 3 pin
  • tipo 2: mic/headset splitter, con una femmina che supporta l’inserimento di una cuffia e l’altra che supporta l’inserimento del microfono; si riconoscono per i simboli di microfono e cuffie sulle due femmine, e il jack maschio ha 4 pin: questo cavo può essere usato solo sui PC che hanno questo simbolo sul jack, rappresentante una cuffia con microfono integrato;
PcV 05  Headsetadapter  MiniPhone 35 mm 4polig (M)

sembra che il nome di questi adattatori con maschio a 4 pin sia Y-05, o PCV-05 (se della Sennheiser), o altro, comunque con “-05” alla fine; il PCV-05 viene dichiarato “compatibile Mac e Iphone”.

Esiste però anche una variante “PCV-07”, esteriormente apparentemente uguale, a parte i colori; questo viene dichiarato “compatibile Mac e PS4”:

Sennheiser Pcv 07 Combo Audio Adapter (506497)

Esistono anche gli adattatori compatti SPTM1 (Sleeve = Ground) e SPTM2 (Sleeve = Mic), di cui il produttore fornisce anche lo schema/pinout:

Anche il produttore Galamino fornisce il pinout per il suo adattatore PMP35: è di tipo CTIA, cioè con microfono sullo sleeve:

Sembra però che alcuni connettori per PC col simbolo della cuffia microfonata in realtà consentano solo la connessione alternativa di cuffie oppure microfono, ma è da verificare; secondo questa teoria, inoltre, sul Ring ci sarebbero 5V necessari ad alimentare il microfono.

I connettori a 4pin/3anelli hanno la particolarità di avere due mappature possibili, diverse e incompatibili tra loro: il CTIA, con microfono sullo Sleeve, e l’OMTP, con massa sullo Sleeve:

Lo standard CTIA (microfono su sleeve) dovrebbe essere quello in uso nei notebook (PC portatili).

Le specifiche ufficiali android (femmina su cell, maschio su cuffia) indicano di usare queste resistenze tra i vari contatti per implementare i comandi a pulsante:

Sul notebook della HP “Elitebook” è presente una singola porta audio marcata come “combo”, a cui riesce difficile far riconoscere un microfono esterno: al momento ci sono riuscito solo inserendoci un vecchio adattatore Nokia AD-43, il cui pinout per ora è sconosciuto.

Nokia AD-43+HS-45: Amazon.co.uk: Electronics

L’adattatore può funzionare sia da solo, come microfono, sia aggiungendoci un auricolare Nokia HS-45; il PC però non riconosce l’auricolare, per cui per poter usare microfono esterno e cuffia contemporaneamente, al momento l’unico metodo che ho trovato è connettere il suddetto AD-43 al jack combo, e il jack audio di una cuffia audio+mic alla porta Line In della docking station a cui collego il PC… Il problma però è che funziona per pochi secondi, poi, anche se continua ad essere rilevato nella finestra di configurazione audio, il PC non registra nessun segnale dal microfono.

L’AD-43, che funzionava ad esempio col Nokia N-95, è dotato di ben 7 tasti:

1 – Riaggancia

2 – play/pause

3 – avanti

4 – indietro

5 – volume su

6 – volume giu

7 – ?

E’ presente anche un piccolo switch che serve presumibilmente a cambiare la modalità di funzionamento.

Il NOKIA N95 aveva questo pinout:

http://www.nokia-tuning.net/?s=pinout_n95av

Colonnine di ricarica veloce in autostrada (stavolta per davvero)

Posted in auto elettriche by jumpjack on 7 giugno 2021

Quanto consuma una “barca” elettrica?

Posted in batterie by jumpjack on 10 Maggio 2021
Vola sul Garda e non inquina, ecco la «Tesla» acquatica svedese

Dipende ovviamente dal tipo di imbarcazione: qui analizziamo il fuoribordo Torqeedo Deep Blue 50R della Feltrinelli di Gargnano, un 7.7 metri dotato di alette che lo rendono in sostanza un piccolo aliscafo:

Vola sul Garda e non inquina, ecco la «Tesla» acquatica svedese

La Tesla non c’entra assolutamente niente, è solo diventato sinonimo di auto elettrica…

In realtà la barca monta batterie da 40 kWh di una BMW i3, che garantisono un’autonomia di 105 km: significa un consumo di circa 400 Wh/km, contro i 150-200 di un’auto elettrica; francamente mi sembrano molto pochi, ma forse contribuisce il fatto delle alette da aliscafo, che riducono l’attrito al minimo, nonchè una velocità massima di 25 nodi, con punte di 30. Il sollevamento sulle ali avviene a 15 nodi.

In realtà esistono anche diverse varianti di questo fuoribordo, con motori da 35 fino a 100 kW:

La batteria però è la stessa per tutti i modelli, da 40 kWh, per 278 kg di peso (143 Wh/kg e 143 Wh/L):

Scheda tecnica: link

La batteria “può ricaricarsi fino al 75% in 1.5 ore se dotata degli opportuni caricabatterie multipli” , dice la brochure, il che significa 20 kW di ricarica.

In realtà su alcuni modelli meno potenti è disponibile anche una batteria più piccola da 10 kWh, della BMW i8:

Volendo, poi, è dispomnibile anche un “range extender portatile”, un generatore da 25 kWh, che però pesa quasi mezza tonnellata:

Monta invece 8 batterie da 30 kWh della BMW i3 un traghetto elettrico canadese:

Catalogo imbarcazioni elettriche Torqueedo: link

Quanto consuma il riscaldamento in un mezzo elettrico?

Posted in auto elettriche, energia by jumpjack on 19 aprile 2021

Una prima risposta generica è “esattamente quanto consuma in un’auto a benzina”.

Solo che su un’auto a benzina questo consumo aggiuntivo non viene immediatamente percepito, perchè l’autonomia di un’auto a motore termico è virtualmente inifinita, essendo di 800 km con un pieno ed essendo possibile fare il pieno in 5 minuti ad ogni angolo di strada.

Questo però fa passare del tutto inosservati gli euro in più che se ne vanno in riscaldamento ad ogni viaggio.

Quanti sono questi euro per ogni viaggio? Per saperlo, dobbiamo determinare i consumi aggiuntivi in termini di kWh, dopodichè si tratterà solo di convertire i kWh in euro: direttamente, nel caso di auto elettriche, o “passando” per l’equivalente in litri di benzina, in caso di auto termiche.

Ecco una ricerca utile in tal senso:

Annual Variation in Energy Consumption of an Electric Vehicle Used for Commuting (Anatole Desreveaux) – Variazione annuale dei consumi energetici di un veicolo elettrico per pendolari

Questa ricerca analizza 6 percorsi diversi effettuati nel corso di un anno: due urbani, due extraurbani e due autostradali:

Il consumo “standard”, senza aria condizionata e riscaldamento, è riportato in questa figura:

Questi 6 pecorrsi sono stati poi monitorati nell’arco di 12 mesi: il seguente grafico mostra come variano i consumi per i percorsi 1 (148 kWh/km normalmente) e 6 (248 kWh/km normalmente):

Si osserva un aumento notevole dei consumi perlopiù a causa del riscaldamento, nei mesi invernali; l’articolo dice:

  • +33% in winter due to heating
  • +15% in summer due to air conditioning
  • The urban commuting driving cycle is more affected by the comfort subsystem than extra-urban trips

Ossia:

  • +33% di consumi in inverno
  • +15% di consumi in estate
  • Ciclo urbano più influenzato rispetto ai cicli extraurbani

Tuttavia questi risultati sono ovviamente pesantemente influenzati dal clima locale: questa ricerca è stata svolta in Francia, nella città di Lille… dove in sostanza l’estate non esiste: la temperatura massima ad agosto è di 23°! Lille infatti si trova nell’estremo nord della Francia:

In compenso, le temperature invernali tra +1° e +6° sono abbastanza simili a quelle “italiane medie” (tenendo conto però che in Italia come altrove ci sono sia città di mare a basse latitudini che di montagna ad alte latitudini). Diciamo quindi che questa ricerca è utile, per l’Italia, solo per conoscere i consumi da riscaldamento, che abbiamo visto ad ammontare fino al 33% in più rispetto al “normale”; questo significa che:

  • su un’auto elettrica con un consumo medio di 150 kWh/km e un’autonomia standard di 400 km (60 kWh di batteria) , l’autonomia invernale scende da 400 a 300 km, perchè si passa da 150 a 200 Wh/km
  • su un’auto a benzina, il fatto di consumare il 33% di energia in più si traduce in un 33% di benzina consumata in più; per un costo di 1,5E/litro, e un consumo standard di 5L/100km (20 km/L), si passerebbe a 6,65L/100 km (15 km/L); quindi, volendo ipotizzare che l’autonomia resti costante di 400 km, per percorrerli si pagherebbero 30 euro “normalmente” ma d’inverno si passerebbe da un costo di 30 euro a un costo di 40 euro. C’è tuttavia un fattore importante da aggiungere al conteggio: in realtà le auto a benzina non consumano più energia d’inverno per alimentare il riscaldamento: lo fanno sempre, tutto l’anno; questo perchè non usano pompe di calore o resistenze elettriche, ma il calore prodotto “automaticamente” dal motore… che lo produce sempre, anche d’estate; solo che d’estate non viene dirottato nell’abitacolo per riscaldarlo.

Per quanto detto qui sopra, risulta quindi che è vero che le auto elettriche hanno autonomia ridotta d’inverno, ma è anche vero che le auto a benzina consumano inutilmente il 33% di benzina (ed euro) in più per 9 mesi all’anno, quando il calore prodotto dal motore non serve a niente.

In più, sulle auto elettriche è possibile preriscaldare l’abitacolo, i sedili e il volante automaticamente, prima di iniziare un viaggio, quando l’auto è ancora in carica, senza quindi incidere sull’autonomia (se il viaggio è breve), almeno per il viaggio di andata; per il viaggio di ritorno ovviamente è possibile solo se all’arrivo è stato possibile mettere l’auto in carica.

Capacità attuali e future delle batterie al litio

Posted in batterie by jumpjack on 1 aprile 2021

Interessante fonte tecnica sulle possibili capacità dei vari tipi di batterie al litio:

Eurobat 2030 – Battery Innovation Roadmap

A pagina 23 ci sono questi dati di capacità per anodo e catodo:

Anodo
C350 – 360 mAh/g       
Si(SiOX)/C400 – 900 mAh/g   
LTO150 mAh/g        
Catodo
NMC 111160 mAh/g
NMC 532  175 mAh/g
NMC 622  180 mAh/g
NMC 811  175 – 200 mAh/g
NCA200 mAh/g
LFP150 mAh/g
LMO      105 – 120 mAh/g

Purtroppo sono espresse in mAh/g anzichè in Wh/kg, e il valore finale di Wh/kg ottenibile dipende dal tipo di accoppiamento scelto per anodo e catodo, da cui dipende la tensione massima di cella; purtroppo questo dato qui non viene fornito.

Comunque inserisco questo breve articolo per riferimento futuro.

Altro dato interessante e l’assegnazione di un “numero di generazione” (ufficiale?) ai vari tipi di batterie NMC/NCM:

  • Generation 2a. NMC 111 / 100% C
  • Generation 2b: NMC 523 -622 /100% C
  • Generation 3a: NMC 622 / C+ Si (5-10%)
  • Generation 3b: NMC 811 / Si/C composite

Infine c’è questa “tabella della speranza” che mostra le auspicabili capacità delle batterie nel 2030:

Tagged with: , , , , , ,