Re: Antibufala e Antiantibufala...
Inviato da Tuttle il 29/11/2007 14:14:53
Ciao a tutti.
Vorrei portare il mio contributo alla discussione sperando vi sia utile.
Userò qualche scorciatoia che mi permette il mio lavoro. Un normalissimo calcolatore della posizione solare - che tiene conto dell'equazione del tempo, dell'azimuth solare e dell'elevazione misurata verticalmente dal piano dell'orizzonte alla posizione in altezza del sole (pitch o elevation). Sono strumenti che ci evitano di fare a mano equazioni non alla portata di tutti (in special modo in fase di verifica) e soprattutto ci evitano errori pacchiani e ci sollevano da tiritere infinite.
Come si sa infatti la velocità di proiezione delle ombre non è costante nel tempo e varia di ora in ora e di giorno in giorno (e di loco in loco) a causa della rotazione terrestre e della sua orbita ellitica (legge di Keplero).
Da precisare quindi che NON ESISTE sovrapponibilità delle proiezioni d'ombra fra un giorno ed un altro e tantomeno da un mese all'altro... Lo spostamento della posizione solare per ogni giorno nella medesima località ci restituisce tutt'altro che linearità ma il cosidetto ANALEMMA. (vedi immagine sotto)
L'immagine mostra la posizione del sole alla stessa ora e nel medesimo giorno della settimana ma nei diversi giorni dell'anno. Questa rappresentazione nello specifico mostra le ore 9:00 del mattino (in grecia), dal 7 gennaio 2003 al 20 dicembre 2003.
Bisogna quindi fare I conti con l'orbita terrestre che produce appunto una variazione sinusoidale (che si traduce spazialmente nell'analemma) fra il rapporto minuti/ore e giorno dell'anno:
Quindi consigliare di effettuare verifiche sulla qualsiasi in un ora qualsiasi di un giorno qualunque equivale a dire una inesattezza abbastanza grossolana.
Detto questo andiamo a questo link:
http://www.srrb.noaa.gov/highlights/sunrise/azel.html
Inseriamo la città di New York - o se si preferisce inseriamo direttamente le coordinate Lat/Long della posizione che si vuole calcolare. Va settato anche il DST (ora legale) che in questo stato entra in vigore alle 2:00AM della seconda domenica di Marzo e finisce sempre alle 2:00AM della prima domenica di Novembre. Ergo l'11 settembre 2001 era in vigore l'ora legale.
Vanno inserite poi la data e l'ora esatta del giorno da verificare.
La prima verifica che andremo a fare è quella dell'orario presunto dallo studio di Sigmatau sulla foto di Zafar. Se ho capito bene si dichiara che le 18:50 sono l'orario di scatto. Segue citazione dello stesso sigmatau.
“si evince che la direzione dell’ombra è quella indicata sulla mappa dal segmento AC. L’ora corrispondente sarebbe t6= 6.50 p.m., vale a dire oltre un’ora e mezza dopo il crollo del Wtc7 “
Inserendo questi dati nel calcolatore ci vengono restituiti due dati sensibili:
Azimuth Solare: 272.81
Elevazione Solare: 3.46
Da evidenziare immediatamente che l'elevazione solare alle 18:50 è a soli 3.46° dal tramonto – ormai prossimo, ovvero il sole è molto basso, quasi sulla linea dell'orizzonte (per capirsi il crepuscolo inizia ai valori negativi di elevazione) e la luce è molto calda.
L'altro parametro che va inserito nel calcolatore sono I 271.81° di azimuth solare che uniti ai 3,46° di elevazione avrebbero proiettato la luce solare direttamente sulle facciate degli edifici in primo piano nella foto di Zafar con il sole bello stampato nei riflessi delle pareti a specchio.
Uno scatto in queste condizioni di luce potrebbe essere questo, sempre dalla collezione Zafar:
http://www.amanzafar.com/WTC/wtc-6.jpg
Questi sono solo apprezzamenti di tipo “fotografico” che già portano a risultati diversi da quelli di Sigma... in quanto la foto in analisi presenta un sole ben più alto (la proiezione delle ombre sugli angoli dell'edificio è sintomo di una posizione del sole ben più alta di 3.46°) e la temperatura del colore restituita dalla pellicola non mostra certo il classico “calore” di un tramonto ma ancora luce particolarmente fredda. (la temperatura colore nell'analisi fotografica in esterni è sempre cosa da non sottovalutare)
Per verificare definitivamente l'analisi di Sigmatau userò gli strumenti che il mio mestiere mi mette a disposizione.
1)Roof/Top/Basement Map USGS (outline vettoriali degli ingombri degli edifici)
2)Building 3D map USGS (estrusione procedurale degli edifici basata su dati USGS)
3)Ambiente 3D (ArcGis/ArcScene/R10.5)
4)Simulatore Azimuthale di proiezione della luce integrato. (Sky Module)
Da sottolineare che I dati topografici sono quelli dai quali vengono restituite tutte le mappe locali nonché I dati GIS inseriti nei navigatori satellitari. Quindi non stiamo parlando di mappe fatte in casa ma di layer GIS definitivi.
Gli step da 1 e 3 li avevo già eseguiti tempo addietro per degli studi sui video degli attacchi alle torri gemelle e per altri progetti di analisi di diversa natura.
La prima figura è una vista TOP (orto) che mostra la mappa GIS dell'area orientata al Nord e l'integrazione dei dati “Buildings” 3D all'interno del modello. Da precisare che l'operazione di orientamento è sempre ad opera dei software che restituiscono già le mappe orientate all'interno di spazi polarizzati ovviamente al nord. Non c'è quindi nessuna operazione manuale ma è tutto LINKATO in partenza.
Per la posizione della fotocamera virtuale mi avvalgo dello scatto di Zafar precedente quello in analisi (vedi foto sotto), dal quale si evince facilmente la sua posizione. La sua posizione era a circa 2230mt dal punto di fuoco a quota terreno (più o meno alla stessa quota della zona fotografata).
Posizione di scatto (POV):
La fotocamera realizzata quindi dovrà montare un teleobiettivo spinto (o ottica zoom) per poter riprodurre quel tipo di geometrie proposte dalla foto in analisi.
Una volta posizionata la camera è bastato “zoomare” fino a circa 250mm sulla scala dei 35mm per ottenere la medesima proiezione degli edifici riprodotta dalla foto reale.
Ora non ci rimane che programmare il sole virtuale andando ad inserire I medesimi parametri del calcolatore solare. Nel simulatore possiamo inserire direttamente I valori di azimuth (+180°) e di pitch solare o semplicemente scegliere l'orario dai menù a tendina. I risultati saranno ovviamente I medesimi.
Dati inseriti nel modello:
Primo test:
ORE 18:50 - LAT: 40°,43',0” LONG: 74°,1',0” - UTC+5 – DST ON
Equazione del tempo: 3.55
Solar Declintaion: 4.25
Azimuth: 272.81
Elevation: 3.46
RISULTATO:
Comparazione con la foto di Zafar:
Come si vede non c'è nessuna corrispondenza con la foto di zafar. Le ombre sono ormai assenti sulle facciate in primo piano, l'edificio 7 è coperto dalle ombre per la sua metà - il sole è bassissimo (prossimo al tramonto) e la luce è arancione.
Per ottenere la proiezione esatta delle ombre presenti nella foto di Zafar dobbiamo andare molto indietro a valori di azimuth di circa 243° e elevazione solare di ben 30/33°. Stiamo parlando di una piccola fascia oraria che va dalle 16:09 PM alle 16:20PM.
Ecco il risultato impostando come orario le 16:09PM
Secondo test:
ORE 16:09 - LAT: 40°,43',0” LONG: 74°,1',0” - UTC+5 – DST ON
Equazione del tempo: 3.51
Solar Declintaion: 4.29
Azimuth: 243.91
Elevation: 32.95 (!!!)
RISULTATO:
Comparazione con la foto di Zafar
Come si evince chiaramente c'è la totale corrispondenza delle proiezioni d'ombra su tutti gli edifici coinvolti. Da sottolineare che nel modello sono stati eliminati gli edifici crollati che avrebbero modificato alcune proiezioni interne.
Per ottenere questi test ho usato dati e metodi/modelli reali e nessun modello matematico autoprodotto. Sono test che chiunque può fare con un po di pazienza e di buona volontà. I dati ottenuti nel calcolatore sono stati incrociati con quelli ottenuti nel simulatore. I risultati sono stati identici.
Veniamo ora agli ultimi ragionamenti scaturiti dal video postato da Ashoka.
E' stato presentato questo video come prova di manipolazione VFX sulla sequenza originale.
http://thewebfairy.com/911/7/Bld7.wmv
Si dice accanto al video
“...natural clouds aren't geometric...
E' ovvio che colui che scrisse questo commento si riferiva agli artefatti della compressione del video analizzato. Ovvero questi:
Ma ailoro non si tratta altro che di normalissimi artefatti interni a macroblocchi, sintomo classico e conosciuto, presente in tutti I video compressi malamente. Chiunque “spippoli” con youtube sa che una volta compressi I video producono questo tipo di squadrettature....non serve essere esperti di video per capire questo semplice dato di fatto.
Ma come se non bastasse lo stesso sito afferma che il file originale dal quale è stato estrapolato il formato “windows media” è un mov (QuickTime) di appena 320x240 pixel. Si tratta quindi di una tripla compressione. La prima per il grab in macchina, la seconda per l'export in QT Sorenson e la terza per il nuovo export da QT Sorenson a Windows Media Video.
Ma se si apre il file QT e lo si osserva nel suo aspetto originale (senza ingrandire la finestra) la qualiltà del segnale è molto più alta e la squadrettatura molto minore.
Queste persone quindi avanzano ipotesi a casaccio osservando un normale fenomeno conosciuto ormai a tutti....la compressione!!!
La cosa ancora più ridicola è l'ipotesi di un fotoritocco in rotoscoping (frame by frame) ormai inutilizziata da decenni. Tecnica poi improponibile su riprese fatte a mano su decine di angolazioni differenti.
Esistono ormai da anni tecniche di integrazione di materiale virtuale in ambiente reale denominate "motion tracking/match moving". Si tratta di tracciare in triangolazione 3D i movimenti della camera (tramite dei target scelti nella sequenza) per poi trasformarli in parametri di camera virtuale all'interno di un software 3D ove generare e compositare un eventuale fumo particellare (si vedano applicativi come MatchMover o simili. E' l'unica tecnica possibile in questo ambito ma di certo non esiste un solo video (o foto) ove sia presente questa tecnica che rimane assolutamente distinguibile da qualsiasi esperto di postproduzione, senza ovviamente tener conto che dichiarare che decine di foto e di video siano stati sottoposti a fumo particellare integrato è a dir poco ridicolo.
Spero di essere stato utile.
Ciao.
Pier.
Vorrei portare il mio contributo alla discussione sperando vi sia utile.
Userò qualche scorciatoia che mi permette il mio lavoro. Un normalissimo calcolatore della posizione solare - che tiene conto dell'equazione del tempo, dell'azimuth solare e dell'elevazione misurata verticalmente dal piano dell'orizzonte alla posizione in altezza del sole (pitch o elevation). Sono strumenti che ci evitano di fare a mano equazioni non alla portata di tutti (in special modo in fase di verifica) e soprattutto ci evitano errori pacchiani e ci sollevano da tiritere infinite.
Come si sa infatti la velocità di proiezione delle ombre non è costante nel tempo e varia di ora in ora e di giorno in giorno (e di loco in loco) a causa della rotazione terrestre e della sua orbita ellitica (legge di Keplero).
Da precisare quindi che NON ESISTE sovrapponibilità delle proiezioni d'ombra fra un giorno ed un altro e tantomeno da un mese all'altro... Lo spostamento della posizione solare per ogni giorno nella medesima località ci restituisce tutt'altro che linearità ma il cosidetto ANALEMMA. (vedi immagine sotto)
L'immagine mostra la posizione del sole alla stessa ora e nel medesimo giorno della settimana ma nei diversi giorni dell'anno. Questa rappresentazione nello specifico mostra le ore 9:00 del mattino (in grecia), dal 7 gennaio 2003 al 20 dicembre 2003.
Bisogna quindi fare I conti con l'orbita terrestre che produce appunto una variazione sinusoidale (che si traduce spazialmente nell'analemma) fra il rapporto minuti/ore e giorno dell'anno:
Quindi consigliare di effettuare verifiche sulla qualsiasi in un ora qualsiasi di un giorno qualunque equivale a dire una inesattezza abbastanza grossolana.
Detto questo andiamo a questo link:
http://www.srrb.noaa.gov/highlights/sunrise/azel.html
Inseriamo la città di New York - o se si preferisce inseriamo direttamente le coordinate Lat/Long della posizione che si vuole calcolare. Va settato anche il DST (ora legale) che in questo stato entra in vigore alle 2:00AM della seconda domenica di Marzo e finisce sempre alle 2:00AM della prima domenica di Novembre. Ergo l'11 settembre 2001 era in vigore l'ora legale.
Vanno inserite poi la data e l'ora esatta del giorno da verificare.
La prima verifica che andremo a fare è quella dell'orario presunto dallo studio di Sigmatau sulla foto di Zafar. Se ho capito bene si dichiara che le 18:50 sono l'orario di scatto. Segue citazione dello stesso sigmatau.
“si evince che la direzione dell’ombra è quella indicata sulla mappa dal segmento AC. L’ora corrispondente sarebbe t6= 6.50 p.m., vale a dire oltre un’ora e mezza dopo il crollo del Wtc7 “
Inserendo questi dati nel calcolatore ci vengono restituiti due dati sensibili:
Azimuth Solare: 272.81
Elevazione Solare: 3.46
Da evidenziare immediatamente che l'elevazione solare alle 18:50 è a soli 3.46° dal tramonto – ormai prossimo, ovvero il sole è molto basso, quasi sulla linea dell'orizzonte (per capirsi il crepuscolo inizia ai valori negativi di elevazione) e la luce è molto calda.
L'altro parametro che va inserito nel calcolatore sono I 271.81° di azimuth solare che uniti ai 3,46° di elevazione avrebbero proiettato la luce solare direttamente sulle facciate degli edifici in primo piano nella foto di Zafar con il sole bello stampato nei riflessi delle pareti a specchio.
Uno scatto in queste condizioni di luce potrebbe essere questo, sempre dalla collezione Zafar:
http://www.amanzafar.com/WTC/wtc-6.jpg
Questi sono solo apprezzamenti di tipo “fotografico” che già portano a risultati diversi da quelli di Sigma... in quanto la foto in analisi presenta un sole ben più alto (la proiezione delle ombre sugli angoli dell'edificio è sintomo di una posizione del sole ben più alta di 3.46°) e la temperatura del colore restituita dalla pellicola non mostra certo il classico “calore” di un tramonto ma ancora luce particolarmente fredda. (la temperatura colore nell'analisi fotografica in esterni è sempre cosa da non sottovalutare)
Per verificare definitivamente l'analisi di Sigmatau userò gli strumenti che il mio mestiere mi mette a disposizione.
1)Roof/Top/Basement Map USGS (outline vettoriali degli ingombri degli edifici)
2)Building 3D map USGS (estrusione procedurale degli edifici basata su dati USGS)
3)Ambiente 3D (ArcGis/ArcScene/R10.5)
4)Simulatore Azimuthale di proiezione della luce integrato. (Sky Module)
Da sottolineare che I dati topografici sono quelli dai quali vengono restituite tutte le mappe locali nonché I dati GIS inseriti nei navigatori satellitari. Quindi non stiamo parlando di mappe fatte in casa ma di layer GIS definitivi.
Gli step da 1 e 3 li avevo già eseguiti tempo addietro per degli studi sui video degli attacchi alle torri gemelle e per altri progetti di analisi di diversa natura.
La prima figura è una vista TOP (orto) che mostra la mappa GIS dell'area orientata al Nord e l'integrazione dei dati “Buildings” 3D all'interno del modello. Da precisare che l'operazione di orientamento è sempre ad opera dei software che restituiscono già le mappe orientate all'interno di spazi polarizzati ovviamente al nord. Non c'è quindi nessuna operazione manuale ma è tutto LINKATO in partenza.
Per la posizione della fotocamera virtuale mi avvalgo dello scatto di Zafar precedente quello in analisi (vedi foto sotto), dal quale si evince facilmente la sua posizione. La sua posizione era a circa 2230mt dal punto di fuoco a quota terreno (più o meno alla stessa quota della zona fotografata).
Posizione di scatto (POV):
La fotocamera realizzata quindi dovrà montare un teleobiettivo spinto (o ottica zoom) per poter riprodurre quel tipo di geometrie proposte dalla foto in analisi.
Una volta posizionata la camera è bastato “zoomare” fino a circa 250mm sulla scala dei 35mm per ottenere la medesima proiezione degli edifici riprodotta dalla foto reale.
Ora non ci rimane che programmare il sole virtuale andando ad inserire I medesimi parametri del calcolatore solare. Nel simulatore possiamo inserire direttamente I valori di azimuth (+180°) e di pitch solare o semplicemente scegliere l'orario dai menù a tendina. I risultati saranno ovviamente I medesimi.
Dati inseriti nel modello:
Primo test:
ORE 18:50 - LAT: 40°,43',0” LONG: 74°,1',0” - UTC+5 – DST ON
Equazione del tempo: 3.55
Solar Declintaion: 4.25
Azimuth: 272.81
Elevation: 3.46
RISULTATO:
Comparazione con la foto di Zafar:
Come si vede non c'è nessuna corrispondenza con la foto di zafar. Le ombre sono ormai assenti sulle facciate in primo piano, l'edificio 7 è coperto dalle ombre per la sua metà - il sole è bassissimo (prossimo al tramonto) e la luce è arancione.
Per ottenere la proiezione esatta delle ombre presenti nella foto di Zafar dobbiamo andare molto indietro a valori di azimuth di circa 243° e elevazione solare di ben 30/33°. Stiamo parlando di una piccola fascia oraria che va dalle 16:09 PM alle 16:20PM.
Ecco il risultato impostando come orario le 16:09PM
Secondo test:
ORE 16:09 - LAT: 40°,43',0” LONG: 74°,1',0” - UTC+5 – DST ON
Equazione del tempo: 3.51
Solar Declintaion: 4.29
Azimuth: 243.91
Elevation: 32.95 (!!!)
RISULTATO:
Comparazione con la foto di Zafar
Come si evince chiaramente c'è la totale corrispondenza delle proiezioni d'ombra su tutti gli edifici coinvolti. Da sottolineare che nel modello sono stati eliminati gli edifici crollati che avrebbero modificato alcune proiezioni interne.
Per ottenere questi test ho usato dati e metodi/modelli reali e nessun modello matematico autoprodotto. Sono test che chiunque può fare con un po di pazienza e di buona volontà. I dati ottenuti nel calcolatore sono stati incrociati con quelli ottenuti nel simulatore. I risultati sono stati identici.
Veniamo ora agli ultimi ragionamenti scaturiti dal video postato da Ashoka.
E' stato presentato questo video come prova di manipolazione VFX sulla sequenza originale.
http://thewebfairy.com/911/7/Bld7.wmv
Si dice accanto al video
“...natural clouds aren't geometric...
E' ovvio che colui che scrisse questo commento si riferiva agli artefatti della compressione del video analizzato. Ovvero questi:
Ma ailoro non si tratta altro che di normalissimi artefatti interni a macroblocchi, sintomo classico e conosciuto, presente in tutti I video compressi malamente. Chiunque “spippoli” con youtube sa che una volta compressi I video producono questo tipo di squadrettature....non serve essere esperti di video per capire questo semplice dato di fatto.
Ma come se non bastasse lo stesso sito afferma che il file originale dal quale è stato estrapolato il formato “windows media” è un mov (QuickTime) di appena 320x240 pixel. Si tratta quindi di una tripla compressione. La prima per il grab in macchina, la seconda per l'export in QT Sorenson e la terza per il nuovo export da QT Sorenson a Windows Media Video.
Ma se si apre il file QT e lo si osserva nel suo aspetto originale (senza ingrandire la finestra) la qualiltà del segnale è molto più alta e la squadrettatura molto minore.
Queste persone quindi avanzano ipotesi a casaccio osservando un normale fenomeno conosciuto ormai a tutti....la compressione!!!
La cosa ancora più ridicola è l'ipotesi di un fotoritocco in rotoscoping (frame by frame) ormai inutilizziata da decenni. Tecnica poi improponibile su riprese fatte a mano su decine di angolazioni differenti.
Esistono ormai da anni tecniche di integrazione di materiale virtuale in ambiente reale denominate "motion tracking/match moving". Si tratta di tracciare in triangolazione 3D i movimenti della camera (tramite dei target scelti nella sequenza) per poi trasformarli in parametri di camera virtuale all'interno di un software 3D ove generare e compositare un eventuale fumo particellare (si vedano applicativi come MatchMover o simili. E' l'unica tecnica possibile in questo ambito ma di certo non esiste un solo video (o foto) ove sia presente questa tecnica che rimane assolutamente distinguibile da qualsiasi esperto di postproduzione, senza ovviamente tener conto che dichiarare che decine di foto e di video siano stati sottoposti a fumo particellare integrato è a dir poco ridicolo.
Spero di essere stato utile.
Ciao.
Pier.
Messaggio orinale: https://old.luogocomune.net/site/newbb/viewtopic.php?forum=5&topic_id=3839&post_id=104585