Kalibrering og kompromiser

Hehe - skulle naturligvis have generaliseret til "display" - det er samme problem.

 

tvkartoffel skrev:   Jeg prøvede at gøre som anbefalet. Altså justere dekoderen først via colorkontrollen og baseret på rød luminans. Juryen voterer stadig om det virker. En af dagene prøver jeg at nulstille colorkontrollen, som Otto mener er det rigtige , og rekalibrere via CMSen.   Rationalet med rød virker sådan set fornuftigt nok. Desværre er jeg ikke helt sikker på hvad color kontrollen i virkeligheden gør. Jeg synes ikke rigtig, ud fra det jeg kan måle, at den stiller på saturation, sådan som jeg har forestillet mig. Ellers har jeg lavet det i rækkefølgen valg af farvetemp preset, Brightness, contrast, valg af gammapreset (jeg opgav gammaEQen for denne gang),  RGB, Hvid, CMY, RGBCMY luminans.   ...   Subjektivt ser det meget bedre ud nu, om end en smule koldt. Jeg spekulerer på om den indledende indstilling af farvedekoderen via rød, der endte med at colorkontrollen blev reguleret en del ned, er årsag til dette.

Uden at kende dit setup er mit gæt, at farvekontrollen (COLOR) ikke nødvendigvis påvirker gamut'en specielt meget - hvis overhovedet. Det er i min optik ikke nok at måle på kanten af gamut'en - altså primær og sekundærfarverne - det er nemlig meget muligt, at farvekontrollen arbejder på mætning eller farvestyrken inde i gamut'en. Det kan måske også forklare, at du synes at billedet er koldt (eller måske i virkeligheden undermættet?)(*). Hvilket måleinstrument bruger du? Hvilken software?

 

Hvis du bruger ColorHCFR: Prøv at udlæse RGB-måledata mens du måler. Sker der noget med RGB-værdierne, når du skruer på COLOR med et rødt (100% mættet + 75% luminans) testbillede (AVSHD testskiven) på skærmen? Sker der noget, når du gør det samme men denne gang med et 50% mættet rødt testbillede (samme skive)?

 

(*) En anden forklaring kunne være, at der anvendes et colorimeter, der er ældet i det røde filter og dermed måler for meget rødt, hvorved kalibreringsresultatet giver en gråtoneskala, der er for blå.

På forhånd udskyld for et langt svar tangerende til off-topic - men problemstillingen omkring områder som ikke måles direkte på (f.eks. hudfarver) ved kalibrering triggede mig...

 

Et kvalificeret gæt er, at hudtonekontrollen påvirker det område, som jeg har markeret med "Hudfarver" i BT.709-gamut'en herunder:

Det betyder nok desværre, at det ikke er ligetil at finde testmønstre, der rammer hudfarverne, da der typisk kun måles på primær- og sekundærfarverne, der ligger på de stiplede linier.

 

Som du selv har konstateret, skal der måske ikke røres ved hudtonekontrollen - men spørgsmålet er naturligvis, hvordan fabriksindstillingen påvirker farvedekodningen i forhold til BT.709-standarden. En måde er at anvende et veldefineret testmønster (mht. kromaticitet, (x, y)), som ligger i hudtoneområdet. Jeg ville beregne nogle forskellige RGB-mønstre ud fra (x, y)-koordinaterne og lave mine egne testmønstre til en afspiller, som jeg stoler på. På den måde kunne man så forsøge at finde det område som kontrollen virker på. 

 

Problemet er, at hvis den kalibrerede display-gamut ikke overholder BT.709, så vil man ikke kunne ramme den forventede (x, y)-koordinat - der ville man så være nødt til at beregne et nyt target - men alt andet lige kan man måske med lidt omtanke stadig vurdere, hvordan kontrollen fungerer.

 

Hudfarveområdet i gamut'en er i forvejen et udsat område - og hvis man f.eks. ikke rammer den gamma-værdi, der er anvendt ved colorgrading-processen, vil man få synlige afvigelser i hudfarveområdet. Problemet indtil nu er, at BT.709 ikke (direkte) siger noget om rendering intent, og dermed siger standarden ikke noget om, hvilken gamma-værdi, vi skal sigte efter. En misforståelse indtil nu er, at fordi BT.709 for en del af gammakurven bruger en eksponent på 0,45 for kameraet, så er det blevet fortolket som om gamma skal være 1/0,45 = 2.22 for displayet.

 

BT.709 tager dog udgangspunkt i at displayet er en CRT-skærm med en simpel eksponentialfunktion med en eksponent ("gamma") på 2,5 [1]. For nylig skulle man dog endelig have vedtaget en eksponent på 2,4 [2] for fremtidig brug.

 

Problemet er, at hvis der ved colorgrading er anvendt gamma=2,4, og vi kalibrerer til gamma=2,2, så vil vi introducere fejl i farvedekodningen. Jeg har forsøgsvis beregnet afvigelsen for et system med en perfekt BT.709-gamut + hvidpunkt med en gamma på 2,2 i forhold til et tilsvarende BT.709-colorgrading setup med gamma på 2,4.

 

Der er simuleret godt 37000 farvekombinationer i alt (hvor der er kromatisk overlap pga. opløsningen i afbildningen midles fejlen(**)). Afvigelserne er beregnet iflg. dE94 [3], som bruges til at estimere fejl i farvegengivelse (som udgangspunkt en mere "striks" metode (tre dimensioner, L+C+H) end den dE-angivelse, der anvendes ved vurdering af gråtoneskalaen (to dimensioner, a+b, eller grundlaget herfor, f.eks. x+y eller evt. u+v)):

 

Man kan se, at hudfarveområdet er udsat - kun overgået af det blå område, som vi dog nok ikke er så følsomme overfor variationer i.

 

Det, som det betyder er, at hudfarvekontrollen måske kan have en gavnlig effekt afh. gamma-fejlen - men det vil uden tvivl kræve en masse analyse at afgøre værdien af den - og så er der jo også lige det aberdabei, at vi faktisk ikke ved, hvilken gamma, der er anvendt ved colorgrading-processen for et givent stykke billedmateriale.

 

OT: Ovennævnte metode til at estimere dE94 som funktion af gamma-afvigelsen tager iøvrigt udgangspunkt i en kort diskussion, jeg havde med sotti fra CalMAN om hvorvidt gamma-afvigelser ville påvirke hue/tint (vi var enige om satuation blev påvirket). Min formodning var, at kun farver som lå i hvidpunktet eller på de stiplede linier ud fra hvidpunktet (jf. første illustration) kunne reproduceres korrekt mht. hue/tint ved afvigende gamma. For at vise fejlen i farvegengivelsen mellem linierne (og dermed i de områder, som ikke måles direkte ved kalibrerering, fordi der ikke findes testmønstre jf. snakken om hudfarver højere oppe), afbilledede jeg den faktiske dH (afvigelsen i hue/tint) iflg. dE1994-standarden(***), og billedet viser en nogenlunde overensstemmelse med min første antagelse(*), når der anvendes gamma=2,2 i stedet for gamma=2,4:

 

Hvis man i stedet blot beregner fejlen i hue/tint på baggrund af (x, y)-koordinatet (som er skabt ud fra RGB), får man den lineære sammenhæng, jeg havde forventet:

 

Man kan se, at linierne, der stråler ud fra hvidpunktet mod primær- og sekundærfarverne er mindst fejlbehæftede - men også at de forskellige områder er ramt ulige mht. hue/tint-fejl. Hudfarverne ser ud til at være drejet mod uret (grøn farvemarkering) - altså over mod grøn (overordnet set - det er mere kompliceret, se senere), når der anvendes gamma=2,2 på kildemateriale mastered til gamma=2,4. Tilsvarende vil for høj gamma tilføje for meget rød til hudfarver (indsat lille billede).

 

For at teste tesen har jeg kontrolmålt på testbilledet med ansigtet på ColorHCFR test-DVD'en:

 

På billedet kan man se, hvor jeg udvalgte en hudfarve og målte gentagne gange med to forskellige gamma-indstillinger. Der blev taget højde for små forskelle i hvidpunktet og målingerne pr. gamma blev midlet over et antal målinger.

 

Resultatet kan ses i animationen herunder:

 

Som forventet betyder lavere gamma lavere mætning og en drejning mod grøn i hudfarveområdet. Beregning af vinkelforskellen (som beskriver forskellen i hue/tint mellem de to målinger af samme position på billedet med forskellig gamma) giver ca. 1 grad, hvilket understøtter den teoretiske model ("dH(x;y)") vist ovenfor, som angiver en drejning i samme retning (mod grøn).

 

{følgende afsnit er under løbende review}

 

Lad os tage udgangspunkt i hudfarven (x; y) = (0.494; 0.353) fra eksemplet ovenfor og se, hvad der sker, hvis vi laver en "boreprøve" ned i gamut'en: Med andre ord - hvis vi ser på gamut'en som afbilledet lige ovenfor, stikker vi en probe ned i den ("ind i skærmen") og ser, hvor om det er muligt at ramme samme farve (x; y) hele vejen fra det den lyseste nuance til den mørkeste nuance.

 

Gamut'en er ikke lige "tyk" over det hele - og faktisk er det sådan, at hudfarveområdet reelt set ser ud til at have den laveste population af farver i hele gamut'en. Jeg har forsøgt at afbilde dette forhold herunder:

 

 

Jeg har fremstillet afbildningen ved at gennemregne 101*101*101 lineært fordelte RGB-kombinationer, altså ca. 1.03 millioner farver. Jo mere pastelagtige farverne bliver, jo højere population af farver - og altså bedre mulighed for at ramme den ønskede farve - uanset lysstyrken af den ønskede farve.

 

Vi ved også, at lysstyrken i gamut'ens hjørner ikke er lige så høj som i hvidpunktet, hvor den er 1.000. I det røde hjørne (primærfarven rød) er lysstyrken Y(R) = 0.2126 og for de andre gælder at Y(G) = 0.7152 og Y(B) = 0.0722 for BT.709-standarden med hvidpunktet i D65. Det betyder, at hudfarverne således har en lysstyrke et sted mellem 0.2126 og 1.0000.

 

Den hudfarve, som vi undersøger her, ligger med en maksimal lysstyrke på Y(0.494; 0.353) < 0.300.

 

Nu forholder det sig uheldigvis således, at der i digitale systemer nødvendigvis må ske matematiske afrundinger, når man forsøger at repræsentere signaler fra den analoge verden. Det betyder også, at vi ikke kan undgå, at der indføres fejl, når vi omsætter farver i et kamera eller en scanner til digital information. Derudover indføres der yderligere fejl, når vi laver RGB-værdierne om til digital component (YCbCr), som er det format, er anvendes ved lagring på digitale medier og transmission af video-streams. Konvertering fra YCbCr til RGB indfører yderligere fejl og endelig vil panel-driveren alt andet lige indføre fejl sammen med de fysiske begrænsninger i den anvendte panelteknologi. Jeg medtager ikke problemer indført i forbindelse med kompression i øvrigt (men det er ikke uden betydning - i det mindste vil højere kompression, så vidt jeg lige kan regne ud, synliggøre problemerne yderligere, mere om det længere nede).

 

Jeg har i det følgende forsøgt at simulere afrundingsproblemerne med signalkæden, og som udgangspunkt har jeg valgt at bruge gamma=2.4 for kilden (dvs. at displayet anvendt til mastering-processsen er kalibreret til gamma=2.4 - ikke at kilde materialet bruger gamma=2.4 - det er en væsentlig forskel). Der anvendes en simpel potensfunktion som gamma gennem hele signalkæden og ikke BT.709-gamma med et lineært stykke i bunden. Grunden til dette er, at det er gamma'en på displayet, der anvendes til colourgrading, der betragtes som "input-gamma" og som dermed skal holdes op mod bruger-displayets gamma. Begge forventes at være kalibreret til en flad gamma med eksponenten 2.5 (eller 2.4, jf. tidligere diskussion). 

 

Der simuleres sampling med 12 bits nøjagtighed pr. RGB-komponent, hvilket svarer til state-of-the-art digitale HD-kameraer i dag.

 

For den udvalgte hudfarve betyder det, at hvis vi afbilleder det, som jeg vil kalde "kromabalancen" (analogt til hvidbalancen er det den aktuelle R-, G- eller B-værdis størrelse i forhold til den forventede størrelse), ser vi, at RGB-værdierne svinger med en afvigelse mellem 0 og -3 (billedet til venstre). Det højre billede viser analysen, hvis der regnes med decimaler: Det er interessant at se, at der er indbygget en fejl (selvom source- og target-gamma er ens) i konverteringen fra RGB til YCbCr og tilbage til RGB igen, således at hudfarver får et grønt/cyan stik - men dog så lidt (ca. 1% fejl), at det ikke bør kunne ses i praksis (****).

 

Det ser måske slemt ud, men man kan sige, at en afvigelse i toppen af skalaen (hvor der er højest lysstyrke) er procentmæssig mindre end samme afvigelse i bunden af lysstyrkeskalaen er. Vi kan afbilde det således:

Vi ser altså en afvigelse i omegnen af et par procent - ikke noget man skulle bemærke normalt (her kunne vi vælge at anvende dE94 som indikator for fejlens størrelse - men jeg har som sagt efter ovenstående undersøgelse ikke en klar fornemmelse af, om man kan bruge dE94 til noget som helst fornuftigt i denne sammenhæng).

 

Hvis vi nu kalibrerer vores display i brugerens ende af signalkæden til gamma=2.22 (i stedet for 2.4 som ovenfor), som mange anbefaler, ser vi dette billede for den udvalgte farve: 

For de høje lysstyrker mangler farven nu rødt indhold, hvilket betyder, at grøn og blå er dominerende. Dette betyder bl.a., at farven trækkes mod venstre i gamut'en (hvilket stemmer overens med en lavere mætning, som vi ved indtræder ved lavere gamma). For de lave lysstyrker er rød lidt mere dominerende.

 

Dette kunne være en indikator for, at man i mørke områder med hudfarver (f.eks. på halsen, under kæben, i hårgrænser o.l.) vil se for kraftige røde farver, mens man i lysere område vil få et grønligt eller cyan stik i billedet - evt. arrangeret i bånd, hvor der ellers skulle være en fin hudfarvegradient.

 

Tilsvarende kan vi afbilde en for høj gamma:

Vi ser en indikator af problemer med et rødligt stik i lyse hudområder og et grønligt eller cyan stik i mørke områder af huden. Jeg har lavet samme analyse for for den anden hudfarve i måleeksemplet ovenfor og ser helt samme fænomen. Tilsvarende resultat ses for mere pastelagtige hudfarver.

 

Jeg har fundet et eksempel på billedfejl, der kunne stamme fra (bl.a.) dette fænomen – og derefter tydeliggjort af kompression i signalet:

 

{slut på afsnit under løbende review}

 

[1] Digital Video and HDTV, Algorithms and Interfaces, Charles Poynton.

[2] Poynton's Vector: 12 Gamma estimation, Charles Poynton.

[3] Useful Color Equation, Bruce Lindbloom (http://brucelindbloom.com/)

 

(*) Beregning af dH giver tilsyneladende en ulineær afbildning af hue/tint-fejlen - og jeg synes ikke lige, at jeg kan se, at jeg har lavet en fejl i beregningerne - men man kan selvfølgelig aldrig vide, selvom det ikke er første gang, at det bliver påpeget svagheder ved delta-E-metoderne, som nogle gange giver modstridende vejledning i kalibreringen, og derfor ikke nødvendigvis kan tages for gode varer... Jeg vil undersøge det nærmere - men hvis dE94 opfører sig så forkert mht. hue/tint, som jeg lige synes at det ud til, så bør  man være varsom, når man bruge den parameter til kalibrering (kan kun anvendes på kanten af gamut'en).

 

(**) At fejlen midles betyder, at fejlene fra flere nærtliggende farver (x;y) opsummeres og divideres med antallet af farver, der indgår i opsummeringen. Desuden sker der automatisk en midling over de forskellige mulige lysstyrker pr. farve (bestemt af den mindste afstand mellem RGB-værdierne i systemet). Jokeren i spillet er, at en farve defineret ved sin kromaticitet (x;y) i praksis ikke er den samme, når lysstyrken Y varieres. Dette skyldes afrundingsfejl i hele signalkæden/processerne fra skabelsen af det digitale signal (f.eks. i kamera eller scanner) til det rammer panelet som RGB-værdier. En stor fejlkilde er RGB->YCbCr->RGB - og her spiller gamma'en også en ikke ubetydelig rolle - specielt, hvis der ikke anvendes samme gamma på begge sider af konverteringen (RGB->YCbCr->RGB).

 

(***) Hue/tint-komponenten i dE94 kan tilsyneladende kun anvendes, hvis man måler på 100% mættede farver, hvilket er den normale procedure. Så snart man måler inde i gamut'en begynder dH at give værdier, som ikke giver mening: Der begynder at blive rapporteret om hue/tint-fejl, hvor der ikke er fejl, hvilket stemmer overens med afbildningen af "dH" iflg. dE94-metoden vist ovenfor (første billede i OT-afsnittet).

 

(****) Beregningerne skal gennemgåes i detaljer flere gange for at bekræfte dette. Fejlen kan ikke ses ved ens input- og output-gamma i gamut'en (jf. grafikken ovenfor, der viser grønt stik i hudfarver ved for lav output-gamma hhv. rødt stik i hudfarver ved for høj output-gamma) - men det ser ud til at kunne skyldes, at RGB->YCbCr->RGB ikke medregnes - der er ene og alene fokus på gamma'ens "egenfejl". Fejlen kan også stamme fra det anvendte matematikbibliotek, som anvendes ved simuleringen.

 

EDIT: Jeg fortsætter med at tilrette dette indlæg, i takt med, at jeg bliver klogere.