Guide: Velsignelse eller forbannelse?

[eschilvold]

HDR. Tre bokstaver som, når de stilles sammen, frambringer alt fra halsløs jubel til gretten fordømmelse blant verdens fotografer.

 

Les mer

[Freem@n]

Flott artikkel. Har sett mange "urealistiske"/stygge HDR-bilder, men her har teknikken blitt brukt sparsommelig og tilført bildene verdi.

 

Men ved å overeksponere negativfilm kan man oppnå samme resultat med kun et bilde. Ikke rart enkelte bryllupsfotografer sverger til Fuji 400H.

[Toa]

En dag blir forhåpentligvis kameraene så gode at denne teknikken blir unødvendig...

[Gjest Slettet-Pqy3rC]

Jeg har K-7 hus som har HDR integrert noe som gir en mulighet til å raskt teste ut prinsippet med ulike motiver. Bevegelige motiver er, som artikkelen nevner, umulige å fange med denne teknikken. Det bringer en brått til å innse at vi har mye vind her i landet.

 

I det hele tatt er det relativt sparsommelig med naturlige situasjoner hvor HDR kan benyttes, men når en slik situasjon først oppstår blir resultatet ofte imponerende.

 

Uansett er det kjekt å vite om muligheten. Fin artikkel forøvrig.

 

Ang flyttall;

Når artikkelen først tar opp disse kan en jo nevne at de ikke dekker alle tall i området, f.eks er tallet 0.1 ikke mulig å gjengi eksakt med flyt tall. Alle ting har sine fordeler og ulemper.

Endret 8. januar 2010 av Slettet-Pqy3rC

[EskeRahn]

Fin artikel!

 

Men mon ikke der vil komme tekniske løsninger på den første del af problematiken?

 

Multieksponeringer, kan man jo godt forestille sig foregår 'samtidigt'!

 

Det optimale ville være hvis et sensor-punkt kunne aflevere ENTEN hvor fyldt det var (hvor mange fotoner der var registreret) ELLER hvor længe den var om at blive fyldt. Så skal den selvfølgelig også aflevere et flag-bit der siger om det er mængde(n) eller tid(t) den afleverer. Så er resten rent forholdsvis simpelt regnearbejde for at lave et HDR-billede.

 

Altså antag at et billede med eksponeringstid T og en sensor der kan rumme op til N foton-registreringer. Ja da vil man så afhængigt af flag-bit skulle lagre n eller N*T/t i HDR billedet. (I princippet i hvert fald). Hvor 0≤n≤N og 0≤t≤T

 

Hvor eksponeringstiden selvfølgelig skal være lang nok til at få fornuftige detaljer i mørke områder.

 

...Men det løser selvfølgelig ikke alle problemer. Det løser ikke bevægelse i motivet i ikke-lyse områder inden for eksponeringstiden. Så -også her- er en så lysfølsom som muligt chip og optik ønskværdig, så eksponeringstiden kan holdes nede.

[bwyan]

Gleder meg alt til neste del!

Fin artikkel med en god "sunn" holdning til temaet. HDR temaet blir ofte så polarisert, og blir fort veldig hat/elsk. Her: http://www.luminous-landscape.com/essays/hdr-plea.shtml beskrives HDR som et "glorified ND filter" som jeg synes var ganske bra begrep. Her er også mye fine eksempler.

[Simen1]

Flott artikkel!

 

Det optimale ville være hvis et sensor-punkt kunne aflevere ENTEN hvor fyldt det var (hvor mange fotoner der var registreret) ELLER hvor længe den var om at blive fyldt. Så skal den selvfølgelig også aflevere et flag-bit der siger om det er mængde(n) eller tid(t) den afleverer. Så er resten rent forholdsvis simpelt regnearbejde for at lave et HDR-billede.

Jeg har tenkt på den teknikken før, men har sett for meg en stor hindring: En klokkekrets som skal telle tid er en relativt komplisert krets som krever ganske mange transistorer per piksel. I tillegg måte det kreves et komplisert nett av ledere for å lese av disse stoppeklokkene. Det vil altså gå svært hardt ut over sensitivt piksel-areal, kompleksitet, pris og hastighet.

 

Men nå nettopp kom jeg på en alternativ metode å løse problemet på. En metode som krever langt mindre plass og er langt enklere å lese fra brikken. Løsningen er som følger: En krets utenfor pixel-arrayet distribuerer en jevnt økende spenning fra 0 til 100% i løpet av lukkertida. Tiden fra 0 til 100% settes altså lik lukkertida. I hver piksel har man en sekundær kondensator som lagrer denne spenninga. I det øyeblikket primærkondensatoren er full så vil en transistor sperre for ytterligere lading av den sekundære kondensatoren. Dermed vil spenninga i den sekundære kondensatoren representere hvor stor andel av lukkertida som måtte til for å fylle primærkondensatoren. Dette vil selvsagt kreve at et ekstra sett med kondensatorer må leses av for hvert bilde. Det kan gjøres med de allerede eksisterende A/D-konvertorene på brikken, sekvensielt etter lesingen av primærkondensatorene. Denne løsningen er langt mindre kompleks og går ikke så hardt ut over piksel-areal, pris og hastighet som løsningen i forrige avsnitt. Løsningen vil også være relativt enkel å behandle i prosessoren fordi man får to bilder: Det normale + tidsbildet som bare må syes sammen til ett HDR-bilde før det lagres i et passende råformat. Hvem kan tipse sensor-utviklere om denne løsningen?

[tomsi42]

Fin artikel!

 

Men mon ikke der vil komme tekniske løsninger på den første del af problematiken?

 

...

Hvorfor gjøre det så vanskelig. Hvorfor ikke lese av sensoren X ganger i løpet av eksponeringen ?

[Sutekh]

Finnes det ikke kompaktkameraer som gjør akkurat det? Men da for å bedre lavlysytelse, ikke dynamikk.

[knutinh]

Jeg synes kanskje at artikkelen fokuserte litt vel mye på filformater og flyttallenes fordeler i første halvdel. Jeg synes kanskje at det er det minst fascinerende og relevante ved HDR? Det er lett å representere et tall med vilkårlig nøyaktighet i en PC. Det er vanskelig å måle en fysisk verdi med vilkårlig nøyaktighet, eller å gjenskape den med vilkårlig nøyaktighet.

 

Det er interessant at folk nevner analog film med "soft klipping". Også interessant med filtre foran objektivet for å selektivt redusere intensiteten på f.eks himmelen.

 

-k

Endret 8. januar 2010 av knutinh

[maliNorway]

Flott artikkel. Gleder meg til fortsettelsen. Gi oss flere slike gode temaartikler!

[inaktiv000]

Skulle til å si akkurat det samme som maliNorway Tydelig at forfatter har truffet bra her, og gjort en god jobb

[ventle]

Jeg forsto ikke helt dette avsnittet:

 

Grunne til at dette er mulig, er at HDR-filer er basert på en annen metode for lagring av data enn tradisjonelle filer. HDR-filene er basert på flyttall, eller floating point numbers, som det heter på engelsk.

 

Ved å ta i bruk flyttall, har man befridd langringen av bilder fra begrensningene knyttet til det å kun kunne bruke vanlige tall. Med flyttall, som tar i bruk desimaler og eksponenter, kan man beskrive et nær sagt uendelig antall nyanser. Sagt på en litt banal måte: Man har ikke lenger kun 25 og 26, for eksempel, men også 25,5 eller 25, 546784, eller 25,879856389, og så videre.

 

Hva har egentlig flyttall med saken å gjøre? Hovedpoenget er vel at man ved å gå fra 16 til 32 bits fargedybde får drøyt 4 milliarder mulige nyanser mellom sort (0) og hvit (1) for hver kanal, fremfor 65000 som man har med 16 bits (per kanal). Dette har med bitdybden, eller ordlengde som det også kalles, og ikke hvorvidt ordet er representert som ett flyttall eller heltall i programkoden.

[inaktiv000]

Tipper det går på at flyttall gir et mye større spenn i hvilke verdier man kan representere - mye større verdier eller mye mer nøyaktige (lave) verdier.

[siDDis]

Eit kult program for å jobbe med HDR bileter er http://qtpfsgui.sourceforge.net/

[ventle]

Tipper det går på at flyttall gir et mye større spenn i hvilke verdier man kan representere - mye større verdier eller mye mer nøyaktige (lave) verdier.

Nei, har du 32 bits til rådighet har du 4 milliarder mulige verdier, uansett om det er representert som flyttall eller heltall i programkoden, så det gir nøyaktig like mange muligheter om man hadde programmert det som heltall. Sluttproduktet er uansett en nyanse som befinner seg ett sted mellom sort og hvit, som i sin ekleste form kan kalles tallet 0 for sort og tallet 1 for hvit, og både 8 og 16-bits fargedybde er i den forstand like mye, eller like lite flyttall i denne sammenhengen. Så mitt spørsmål gjenstår: hvordan kan det å representere en 32-bits fargeverdi som flyttall gi nye/flere muligheter kontra å representere det som heltall, all den tid begge alternativer gir nøyaktig like mange nyanser mellom sort og hvit, og det uansett ikke er noe som heter hverken heltall eller flyttall, bare ord i maskinkode?

Endret 9. januar 2010 av ventle

[inaktiv000]

De kan representere samme antall ulike verdier (ca), men de små tallene ligger mye tettere enn de store. På den måten kan man både representere små tall mye mer nøyaktig, samt mye høyere tall enn dersom man bruker heltall.

 

Sett på en annen måte, får man en annerledes "palett" med flyttall enn heltall - istedet for å ha en fast avstand mellom de ulike "fargene", har man noen farger som ligger tett, og noen med stor avstand. Forskjellen på ytterpunktene ("mørkest" og "lysest") blir langt større.

 

Er ikke sikker på om flyttallet representerer intensitet, så derfor har jeg satt noen av verdiene i hermetegn

[fredderen]

Ikke for å rake ned på HDR, jeg har skutt det mange ganger. Men GND filtre er mye bedre, se her... David noton er jo også da en fantastisk fotograf. Når man bruker GND filtre kan man ha et spenn på opp til 3 f-stop, spesial bestiller man filtre fra Lee - da kan man få filtre som har opp til 4 f-stopp spenn. Kombinerer man da 2 filtre har man et spenn på 8 f-stopp, kombinerer man 3 filtre, har man et spenn på 12 f-stopp. Men dette koster og blir fort dyr, men er et bedre alternativ enn HDR i de fleste tilfeller. Igjen, se her.

[Thunderhead]

Merkelig artikkel må jeg si, virker på meg som om forfatteren misliker HDR sterkt og benytter en hver anledning til å fremhever de negative sidene, begrensningene og problemene unødvendig mye. Ellers er det masse prat og mye gjentagelser, men lite substans, og når det først gis litt skryt dukker det ofte opp et "men".

 

Ellers er det brukt spalteplass på en del lite relevant informasjon, f.eks om flyttall, som ikke har noen betydning da de skjer inne i programmet, som gjerne kunne vært erstattet med mer matnyttig informasjon. F.eks at detaljerte opplysninger om kamerainnstillinger utover det diffuse uttrykket "eksponeringskompensasjon", samt hvor mange bilder man optimalt bør ta, glimrer med sitt fravær.

 

Kjenner man til litt av prinsippet med HDR og hva det gjør og ikke gjør, er det faktisk ikke så overveldende skremmende og vanskelig som jeg får inntrykk av her.

[EskeRahn]

.

.

.

Jeg har tenkt på den teknikken før, men har sett for meg en stor hindring: En klokkekrets som skal telle tid er en relativt komplisert krets som krever ganske mange transistorer per piksel. I tillegg måte det kreves et komplisert nett av ledere for å lese av disse stoppeklokkene.

.

.

Hvorfor skulle der være behov for en "klokkekrets" per celle?

Det alternativ du beskriver svarer jo 'bare' til at man gemmer tiden ved at oplade en kondensator, og det er sikkert et glimrende simpel måde at implementere det på.