[CppOOP]

Originariamente inviato da emmeti71: Bepoc, forse la mia interpretazione è capziosa, ma ho inteso il suo post come “maggiore è la profondità in bit di campionamento, maggiore è la gamma dinamica” Io per gamma dinamica più estesa intendo, per esempio una gamma che va da -16EV a +16EV rispetto a una -12EV +12EV. Considero, forse sbagliando, la gamma dinamica una caratteristica del Sensore, non del processore che elabora ciò che il sensore aquisisce. Mi sta bene che una profondità di campionamento maggiore mi da la possibilità di sfruttare più sfumature, questo è palese, ma sempre nello stesso range “bianco” -“nero”

Beh… rileggendo quello che ho letto, anche con l’aggiunta delle spiegazioni di bepoc (che mi hanno aiutato a interpretare meglio quello che intendevo)… non avevo esplicitato il passaggio del fattore di scala. e qui avevo creato equivoci… scusate [fr1] con gamma dinamica (Dynamic Range) intendo (forse sbagliando anche qui :im ) il rapporto fra l’intensità di luce più forte registrata e la più bassa… se il rapporto di scala è fisso e lineare (come spiegato da bepoc) si può esprimere in bit. Per esempio con fattore di scala 1 e 8 bit il rapporto fra l’intensità più alta registrabile e la più bassa è 256. Quindi si ha una gamma dinamica di 8 STOP o 8 EV. Anche perchè la corrispondenza dei bit (valore max, valore min) è comunque una caratteristica del sensore… il convertitore a valle del sensore sarà infatti sempre tarato secondo la gamma del sensore… Ovviamente potrei aver sbagliato tutto di nuovo 🙂 [fr1] Ma spero questa volta di essermi espresso più precisamente.

[MoSfEt]

Originariamente inviato da emmeti71: … Considero, forse sbagliando, la gamma dinamica una caratteristica del Sensore, non del processore che elabora ciò che il sensore aquisisce. Mi sta bene che una profondità di campionamento maggiore mi da la possibilità di sfruttare più sfumature, questo è palese, ma sempre nello stesso range “bianco” -“nero”

E’ una mezza verità. Se da un lato è vero che la gamma dinamica analogica acquisita dai fotositi restituisce valori in un range di tensioni continuo tra i due estremi [Vmin, Vmax], dall’altro è vero che il convertitore A/D (elemento fondamentale del processore d’immagine) può vanificare, a causa della sua scarsa precisione la dinamica dell’elettronica analogica (la più “prelibata” per gli svliluppi e le possibilità di utilizzo ed alla quale ritengo tu abbia fatto riferimento). Nel progetto dei DSP il primo aspetto è legato all’elettronica analogia, la quale deve essere in grado di rispondere alle sollecitazioni previste dalle specifiche di progetto, poi è necessario abbinare un convertitore A/D che abbia una profondità di campionamento tale da rendere “sufficientemente” apprezzabile la fedeltà di risposta dell’elemento analogico. Sarebbe altrettanto inutile (per la fotografia comune) abbinare un convertitore A/D a 16 bit ad un sensore la cui risposta è fedele solo in un range ristretto di frequenze / intensità del segnale esterno come abbinare un convertitore A/D da pochi bit ad un sensore con una risposta esemplare su tutto l’arco delle frequenze visibili e per una ampia gamma di intensità del segnale. Vero è che la risoluzione del convertitore ha senso nei limiti del rapporto segnale / rumore, oltre perderebbe di significato, ma stare al di sotto di questa risoluzione ottimale significa al tempo stesso ridurre la gamma operativa potenziale del sensore. Mi scuso per essere andato tremendamente OT! Buona giornata a tutti! [bir] [can] [lo]

[emmeti71]

Originariamente inviato da MoSfEt: E’ una mezza verità. Se da un lato è vero che la gamma dinamica analogica acquisita dai fotositi restituisce valori in un range di tensioni continuo tra i due estremi [Vmin, Vmax], dall’altro è vero che il convertitore A/D (elemento fondamentale del processore d’immagine) può vanificare, a causa della sua scarsa precisione la dinamica dell’elettronica analogica (la più “prelibata” per gli svliluppi e le possibilità di utilizzo ed alla quale ritengo tu abbia fatto riferimento).

Appunto! Il processore, nella migliore delle ipotesi, restituisce il 100% della gamma dinamica registrata dal sensore. Se mal progettato mettiamo che ne restituisca l’80%, verso ombra o verso sole, ma non ne puù mai restituire il 120%!

[CppOOP]

Originariamente inviato da emmeti71: Appunto! Il processore, nella migliore delle ipotesi, restituisce il 100% della gamma dinamica registrata dal sensore. Se mal progettato mettiamo che ne restituisca l’80%, verso ombra o verso sole, ma non ne puù mai restituire il 120%!

Ops [oop] Continuo a non spiegarmi… o forse ci siamo troppo allontanati dal discorso iniziale… Appunto il sensore registra un “tot” di luce, ma se noi facciamo più scatti con esposizione diverse andiamo a tarare la luce che finisce sul sensore ogni volta inserendo parte della dinamica della scena nella dinamica del sensore; Poi ricostruendo la dinamica reale come descritto da bepoc ci troviamo con livelli di luce che sono descritti con numeri che partono da 0 e arrivano a X dove X è un numero che può essere scritto (numeri interi) solo con un numero di bit maggiore di quello della macchina… Poi si può rimappare e riportare ai classici 8/16 bit, ma si perdono ovviamente particolari… daltronde… non si avrebbe comunque come visualizzarli…

[emmeti71]

Originariamente inviato da CppOOP: Ops [oop] Continuo a non spiegarmi… o forse ci siamo troppo allontanati dal discorso iniziale… Appunto il sensore registra un “tot” di luce, ma se noi facciamo più scatti con esposizione diverse andiamo a tarare la luce che finisce sul sensore ogni volta inserendo parte della dinamica della scena nella dinamica del sensore; Poi ricostruendo la dinamica reale come descritto da bepoc ci troviamo con livelli di luce che sono descritti con numeri che partono da 0 e arrivano a X dove X è un numero che può essere scritto (numeri interi) solo con un numero di bit maggiore di quello della macchina…

su questo non ci piove! e neanche sulla spigazione di bepoc sul suo concetto di gamma dinamica estesa, che condivido. A me ha tratto in inganno il discorso dei 14bit. mega ot: come dice bepoc sono un tardo sofista, che le mele le compra a chili e non a metri, misurate una dietro l’altra 😀 fine mega ot

[CppOOP]

Originariamente inviato da emmeti71: mega ot: come dice bepoc sono un tardo sofista, che le mele le compra a chili e non a metri, misurate una dietro l’altra 😀 fine mega ot

Prima di finirla così… un fisico relativista troverebbe più comodo esprimere la massa delle mele in metri 🙂 Cmq, tornando al vero topic originario… Per Mac c’è HDRtist, l’ho installato dopo che Qtpfsgui aveva cominciato a non funzionarmi a seguito di un aggiornamento del Mac… Ora Qtpfsgui uso una nuova versione, la 1.9.3 e funziona… ha molte più opzioni di HDRtist. Un confronto diretto mai fatto, mi ricordo spesso problemi di “ghosting” molto forti con Qtpfsgui, ma è anche vero che HDRtist lo usato solo in un paio di occasioni in cui era impossibile ghosting (i lego in interni…)… Però ora prima di postare lo faccio 🙂 [IMG]public/imgsforum/2010/3/_pregamma_1_reinhard05_brightness_-7.11_chromatic_adaptation_1.3_light_adaptation_11.jpg[/IMG] Mi piace più quella di HDRtist… ce da dire però che Qtpfsgui ha moooolte più opzioni… e permette un maggior controllo, quindi forse uno bravo ottiene migliori risultati con Qtpfsgui. HDRtist è decisamente più semplice. Quindi per forza da meno potenzialità, ma magari ci si riesce ad ottenere risultati migliori.

[elio114]

questa dpp 1- 0 1+ [IMG]public/imgsforum/2010/3/HDR-UNA.jpg[/IMG]

[elio114]

queste sono 3 dpp sembra migliore piu luminosa stesso procedimento photomatix [IMG]public/imgsforum/2010/3/HDR-169.jpg[/IMG]

[elio114]

questa sono tre [IMG]public/imgsforum/2010/3/HDR-148A.jpg[/IMG]

[totysal]

che colori mi prende

[EnricoX]

Quello che non riesco a capire è il processo per cui le immagini che vedo come HDR hanno questo “feeling” così innaturale, quasi un 3D ipercromatico… Non dovrebbe essere così… o mi sbaglio? [lo]

[emmeti71]

benchè wikipedia non sia la bibbia, trovo molto interessante questa voce: http://en.wikipedia.org/wiki/Tone_mapping non l’avevo letta prima di oggi, però, ci sono molti punti che avevo già discusso in chat e sul forum che mi trovano concorde.

[tecnico73]

Originariamente inviato da Tauro: io a volte cambio l’esposizione con photoshop ne faccio una a +1 e una a -1 poi le apro tutte con un software hdr comunque secondo me non e la stessa cosa che avere tre raw direttamente scattati, non c’è bisogno sempre del cavalletto usi l’esposizione a forcella (bracketing)e hai tre immagini con diverse esposizioni

il vero problema per realizzare un hdr non sta nell’ esposizione perché quella si può modificare da software o usare programmi che utilizzano un solo scatto, ancor meglio tre o più raw con diversa esposizione la vera difficoltà sta nel fare inquadrature multiple identiche e questa operazione da fare a mano libera è una cosa difficilissima o quasi impossibile l’unica vera soluzione e il cavalletto

[tecnico73]

Originariamente inviato da Aron78: si possono fare anche più di 3 esposizioni differenti o no ? intendo si può fare a -2; -1; 0; +1; +2 o solo -1;0;+1 ? Immagino che Photomatrix lavori meglio con 5 foto anzichè con tre. P.S. Ok da oggi in poi il click diventa scatto. Promesso! (o)

i migliori risultati si ottengono “a parere mio” con più di tre scatti con esposizione con incrementi di 1/2 generati direttamente dalla fotocamera

[tecnico73]

quoto pienamente le parole di CppOOP e bepoc, ci si mette un po a comprendere cosa significa hdr e quale sono i risultati che ci si attende da questa tecnica infatti anche io tra tutte le immagini in hdr di veri hdr ne ho solo tre di foto realizzate con questa tecnica http://www.flickr.com/photos/30827349@N02/4393442634/in/set-72157622441332082/ sono enfatizzati, sturati i colori solo per renderli più scenografici ma realizzati da un minimo di 3 esposizione differenti, tutti gli altri sono finti hdr

[Autore]

Post