Vitbalans och vb-bracketing

[xrvjorn]

Jag hittade följande definiton på Nikons site:

"When the white balance bracketing option is selected, pressing the shutter release button will cause the camera to take three photographs; one at optimal white balance, one with a slight red tinge to the image, and a third photograph with a slight blue tinge to the image."

Det här sätter myror i huvudet på mig - är det inte så att vitbalansinställningen är en parameter som påverkar konverteringen mellan raw och jpeg?

I så fall borde vitbalans-bracketing innebära att kameran bara behöver ta en enda bild, och sedan skapa tre jpeg-filer utifrån samma rådata.

Är det jag eller Nikon som har fått något om bakfoten?

 

[PerPula]

Det är väl så att kameran mäter fram det optimla vitbalansvärdet i Auto läget. Men precis som med exponering så kan ju kameran ta fel i speciella ljus situationer. Det har inte med de olika formaten att göra...

 

[xrvjorn]

PerPula skrev:
Det är väl så att kameran mäter fram det optimla vitbalansvärdet i Auto läget. Men precis som med exponering så kan ju kameran ta fel i speciella ljus situationer. Det har inte med de olika formaten att göra...

Nja, det var inte det jag menade. Vitbalansinställningen ska ju inte påverka sensorn. Om man tar tre bilder med olika vb-inställning borde man alltså få samma information från sensorn, och därmed likadana raw-filer. Varför då ta tre bilder? Verkar ju helknäppt.

Det som har med formaten att göra, är att färgvärdena i raw-filer inte påverkas vb-inställningen medan färgvärdena i jpeg-filer gör det.

 

[ture]

Jag håller med dig, det borde bara behövas en exponering. Jag har ingen Nikon-digital att verifiera med, men en snabb test visar att en EOS10D bara gör en exponering men producerar tre JPEG-filer (kör man RAW funkar WB-bracketing inte alls).

 

[pablito]

ture skrev:
(kör man RAW funkar (läs: behövs) WB-bracketing inte alls).

samma sak gäller d100. nef-filerna är till för att läsas in i View- eller Capture-programmen där de rätta värdena sen kalkuleras. (har jag för mig)

jag har märkt dock att kameran har svårt att hitta rätt WB i A-läget, brukar bli tvungan att köra "PRE"- funktionen och mäta av en yta innan jag kör igång.

 

[xrvjorn]

Tre jpeg borde väl ta ungefär samma plats som en raw-fil, eller? I så fall är en kvalificerad gissning att ni som har DSLR inte använder vb-bracketing utan kör med raw-filer i stället vid de tillfällena när bracketing skulle varit aktuellt.

 

[hmoss]

Jag tror att det förhåller sig så här..

Ett av syftena med RAW formatet är att kameran slipper arbeta med processorintensiva konverteringar till bildformat och att istället låta datorn (via Capture el. liknande) göra det. Andra självklara syften är givetvis att alla behandlingsbara data följer med, t.ex. vitbalans, så att man kan styra dessa vid konvertering.

Att låta kameran först generera RAW-data och sedan räkna fram tre olika jpeg-ar med olika vitbalansvärden är ett större processor-jobb än att generera tra olika jpeg-filer direkt från bilddata. Jag skulle tro att man undviker en del beräkningsarbete av RAW-karaktär när man går direkt på jpeg istället.

Alltså, bracketing (eller varför inte kalla det gaffling som det heter på svenska) av vitbalansvärdet vid jpeg sparar processorkraft i kameran och gör den snabbare.

 

[thodan]

Meningslöst med WB-BKT och AEB?

Finns det någon situation där wb-bracketing och exponeringsbracketing är användbart när man kör dslr? Vitbalansen i en raw-fil kan ju justeras hur som helst och även exponeringen några steg upp och ned.

Vad är dina erfarenheter?

 

[hmoss]

Re: Meningslöst med WB-BKT och AEB?

[Jag måste erkänna utan omsvep att jag alltid varit dålig på att använda gaffling, fast fler av mina kameror haft finessen. Jag har en olustig känsla av att min "bild" kommer att försvinna mellan exponeringarna helt enkelt.. =)

Men jag håller med i vad du säger.. RAW-formatet lämnar med så mycket bildinformation och CCD:n i den nyare dslr:en är så omfångsrik att man kommer att finna samma möjlighet att variera i sin RAW-fil (och dessutom utan att riskera de jag alltid inbillat mig att jag tappar..)

Däremot kör jag, tyvärr, inte alltid RAW-format. Jag har inte vant mig vid det "merarbete" av rätt trist natur (tycker jag) som det är att ställa dessa parametrar vid konverteringen i datorn.

Så, hur man än vänder sig..

 

[Damocles]

Att låta kameran först generera RAW-data och sedan räkna fram tre olika jpeg-ar med olika vitbalansvärden är ett större processor-jobb än att generera tra olika jpeg-filer direkt från bilddata. Jag skulle tro att man undviker en del beräkningsarbete av RAW-karaktär när man går direkt på jpeg istället.

Raw == bilddata.
Det finns inget gå direkt på Jpeg, dom två alternativ ovan är precis samma sak. Såvida du inte bara glömt att ange att det ena var i kameran och det andra i datorn.

Direkt på jpeg?? Har du tänkt på var informationen som görs till jpeg'en kommer ifrån, jupps, raw från sensor som sedan genomgår en bayerinterpolation där också färgtemp sätts.

Detta görs för varje jpeg du tar, raw är bara direkt raw data ut från sensor, jpeg görs av samma data som raw består av om du använder jpeg.

Dock brukar en Raw fil vara delvis komprimerad, och i vissa fall innehålla en jpeg dessutom. Så viss bearbetning sker iaf.

 

[hmoss]

Damocles skrev:

Det finns inget gå direkt på Jpeg

Förvisso inte, i den bemärkelsen att man inte hoppar över de råa bilddata som eljest skulle kunna sparas som RAW.
Men.. och detta är bara min teori, jag föreställer mig att om kameran är inställd på att generera en jpeg fil så finns det gott om råa data som aldrig kommer att behöva behandlas/beräknas.

Jag tror fortfarande att det tar mer kraft och tid för kamerans processor att göra tre olika beräkningar med samma rådata än att göra tre oliak jpeg-filer från tre olika uppsättningar rådata. Och jag tror att det är syftet med att det vid gaffling görs tre olika exponeringar.

Å andra sidan är jag inte klar över om du i ditt svar håller med om det eller inte.

 

[thodan]

hmoss skrev:
... Och jag tror att det är syftet med att det vid gaffling görs tre olika exponeringar.

Men det är inte så det fungerar. I alla fall inte med en 10D. Vid gaffling av vitbalansen görs det _en_ exponering. Du tar en bild men kameran sparar tre jpg-filer med olika färgtemperatur.

Det är därför hela det här med VB-gaffling verkar så onödigt. Tryck av en raw-fil istället så kan du gaffla hur mycket vitbalans som helst hemma vid datorn.

 

[hmoss]

thodan skrev:
Men det är inte så det fungerar. I alla fall inte med en 10D. Vid gaffling av vitbalansen görs det _en_ exponering.

Aha.. visste inte det.. (är ju på Nikon-sidan bevars) men då handlar det väl bara om att de som inte har mjukvaran för att hantera RAW i datorn ändå har möjligheten att låta kamerans processor utföra en gaffling?

 

[xrvjorn]

hmoss skrev:
Men.. och detta är bara min teori, jag föreställer mig att om kameran är inställd på att generera en jpeg fil så finns det gott om råa data som aldrig kommer att behöva behandlas/beräknas.

Alla pixlar i sensorn används som indata till jpeg-kompressionen (som är en form av signalbehandling). Man hoppar inte över någon information även om en del av den försvinner i själva kompressionen.

hmoss skrev:
Jag tror fortfarande att det tar mer kraft och tid för kamerans processor att göra tre olika beräkningar med samma rådata än att göra tre oliak jpeg-filer från tre olika uppsättningar rådata. Och jag tror att det är syftet med att det vid gaffling görs tre olika exponeringar.

Nja, det skulle bara kunna vara så om sekvensen

1) Läs in rådata (=exponera)
2) Gör jpeg-fil
3) Läs in rådata (=exponera)
4) Gör jpeg-fil
5) Läs in rådata (=exponera)
6) Gör jpeg-fil

går snabbare att utföra än sekvensen

1) Läs in rådata (=exponera)
2) Gör jpeg-fil
3) Gör jpeg-fil
4) Gör jpeg-fil

vilket bara kan vara fallet om inläsningen av rådata (exponeringen) tar negativ tid, vilket ju är en omöjlighet.

 

[hmoss]

Men å andra sidan.. om inte bildinformation som finns i mängden rådata (som alltså bevaras i RAW-filen) gick förlorad när man sparade tiff, jpeg o.s.v. så skulle inte RAW vara en förutsättning för att kunna välja vilken bildinformation som skall göras om till pixeldata, dvs RGB.

Alltså bör vi åtminstone kunna enas om att RAW innehåller en mängd bildinformation som inte den vanliga jpeg filen "har kvar", även om den givetvis från början härrör från CCD:ns samtliga signaler.
Anta att målet, d.v.s. den jpeg.ade fil som skall genereras med hänsyn taget till vilka parametrar den skall genereras med, styr vilka data i RAW-filen som behöver belasta processorns beräkningskapacitet och att andra data inte beaktas.

Processorn gör sannolikt en sak i taget, d.v.s. efter att ha räknat fram en jpeg med viss WB måste den på nytt läsa in sina grunddata från den exponerade filen vilket alldeles säkert tar lika lång tid som att exponera om, d.v.s få nya data från CCD:n o.s.v.

Jag tycker således att det finns kloka skäl till att hålla sig till prestanda-orsaken, även om jag ser att invändingarna är likaså kloka i sig.

 

[xrvjorn]

hmoss skrev:
Men å andra sidan.. om inte bildinformation som finns i mängden rådata (som alltså bevaras i RAW-filen) gick förlorad när man sparade tiff, jpeg o.s.v. så skulle inte RAW vara en förutsättning för att kunna välja vilken bildinformation som skall göras om till pixeldata, dvs RGB.

Visst går bilddata förlorad i kompressionsprocessen, men inte på väg till den. All sensordata används alltså som indata även om all data inte finns med i utdata. Om indata hade varit samma som utdata, hade ju processen inte gjort något. Hur det går till i detalj kan man bl a läsa i Mark Nelsons utmärkta bok: http://dogma.net/markn/tdcb/tdcb.htm

hmoss skrev:

Processorn gör sannolikt en sak i taget, d.v.s. efter att ha räknat fram en jpeg med viss WB måste den på nytt läsa in sina grunddata från den exponerade filen vilket alldeles säkert tar lika lång tid som att exponera om, d.v.s få nya data från CCD:n o.s.v.

Nja, så funkar det inte med datorer och programmering. Data går inte sönder när man behandlar dem, dvs man "tuggar" inte sönder rådata när man använder dem i exvis en kompressionsalgoritm. Därför behöver man inte skapa en fil som man sedan läser in flera gånger. Man låter helt enkelt bli att radera rådata mellan jpeg-komprimeringarna utan lämnar det kvar i SDRAM:et utan att blanda in det slöare CF-kortet.

Mer info: http://www.dpreview.com/reviews/canoneos10d/page11.asp

En gång i tiden fanns det förvisso datorer som fungerade så att man förbrukade data när man avläste minnet (s k "destruktiv läsning") men det var i datorernas barndom, långt innan mikroprocessorn var påtänkt.

 

[hmoss]

Jag ser att du och jag talar om helt olika saker. Gör inte du det?

RAW-filen innehåller information som kastas bort långt innan kompressionen sätter in o.s.v. och du kan inte få tillbaka t.ex. vitbalansinformationen när du väl gjort om RAW till något annat oavsett om du komprimerar resultatet eller ej.

Jag sade redan inledningsvis att mina antaganden byggde på tro och inte fakta, och de kan således vara felaktiga. Däremot kolliderar de såvitt jag kan se inte med dina åsikter om datorers arbetssätt, om programmering och om teknologisk utveckling.

 

[Damocles]

Nu kommer jag och lägger mig i igen.

Altså, TIFF är en komprimerad fil som kan innehålla full upplösning samt omfånget, 16bit/8bit, etc. Dock är TIFF'en redan vitbalanserad, kontrast och ev. uppskärpning har också gjorts, och om du då vidarebetare den i datorn har du inte samma utgångsdata, så i den bemärkelsen får du en förlust av data.

JPEG är både vitbalanserad, skärpt, och har dessutom än komprimering som ger förluster.

RAW, är det rena sensordatat från sensorn, och bayer interpolering samt vitbalans kompensation göres då i datorn, men då arbetar du från obehandlat data och har då fulla informationen när du gör varje exponering.

Processorn gör sannolikt en sak i taget, d.v.s. efter att ha räknat fram en jpeg med viss WB måste den på nytt läsa in sina grunddata från den exponerade filen vilket alldeles säkert tar lika lång tid som att exponera om, d.v.s få nya data från CCD:n o.s.v.

När väl ccd(CMOS när man talar om 10D) är utläst är den tömd, men då ligger allt rawdata i kamerans arbetsminne.
Och detta är tillräckligt snabbt för att du fördröjningen är totalt oväsentlig i sammanhanget.
Vi talar om en hastighet av typ 600MB - 1GB / sekund under optimala förhållanden. Altså, du kan läsa ur motsvarande 100 RAW filer / sekund ur det.
Det som tar tid är skrivningen till minneskortet vilka är klart mycket långsammare.

När detta göres i kameran så läser den ur sensors RAW data och sparar detta i arbetsminnet, från vilket den sedan kan dra in och behandla det(göra om till JPEG, etc), spelar ingen roll hur många jpegar den gör igentligen, det är skrivningen till kortet som tar tid, inte behandling av rawdata. Rawdatat ligger kvar obehandlat tills skrivningen av dom 3 vitbalanserade jpeg'arna är klara skulle jag gissa på. JPEG'arna byggs upp som separata kopior.

En 10D är väsentligt snabbare på att behandla raw data än vad en vanlig dator är generellt, detta för att den har en cpu som är specialbyggd just för dessa operationer.

 

[hmoss]

Damocles skrev:
Nu kommer jag och lägger mig i igen.

Vilket absolut inte gör något, eftersom du sitter på en hel del lärorik information.. =)

Iden är ju att resonemangen skall låta oss lära av varandra.

Frågan som återstår är väl då bara den ursprungliga, nämligen varför kameran utrustats med möjligheten att göra gafflingar av vitbalans när all data finns i RAW-formatet.

Är det kanske såsom jag föreslog tidigare: För att de som inte har mjukvaran för att hantera RAW i datorn ändå skall ha möjligheten att låta kamerans processor utföra en gaffling?

//H

 

[xrvjorn]

hmoss skrev:
Jag ser att du och jag talar om helt olika saker. Gör inte du det?

Kanske vi har snackat förbi varandra på någon vänster men nu har iaf Damocles rett ut begreppen snyggt och tydligt.

hmoss skrev:
Är det kanske såsom jag föreslog tidigare: För att de som inte har mjukvaran för att hantera RAW i datorn ändå skall ha möjligheten att låta kamerans processor utföra en gaffling?

Det låter ganska rimligt - nu är vi t o m överens