Hvis hvidpunktet er meget skævt, kan det være en fordel at få den løseligt på plads først, inden du går i gang med RGBCMY. Tjek evt. både 75 og 100% windows, og hvis de er skæve i forhold til hinanden, så er det at det erfarne øje må træde til...

 

jeg vil prøve at gøre det på den måde som du foreslår og se om det gør det lettere. Indtil videre har det været lidt ustruktureret og lettere enerverende fordi de forskellige kontroller påvirker hinanden.

 

Jeg ved allerede nu at gamutten ikke kan komme på plads. Det ser ud til at jeg får problemer med blå og specielt grøn. Luminansen for alle primær og sekundærfarver kan jeg få til at ramme meget fint.  I vejledningen til calman anbefales det at indgå det kompromis at der lægges vægt på luminans for primærfarverne og hue for sekundærfarverne. Hvad mener du (eller andre interesserede) om det?

 

Hvidbalancen ser ud til at kunne blive rigtig god selvom de tilgængelige kontroller er lidt sparsomme ( kun to punkter).

 

Projektoren har en funktion der hedder "super white". Det er ikke det samme som PC-levels vs video-levels, som er en separat indstilling. Min første indskydelse er at slå det fra, men nu så jeg så avforums anmeldelse af søstermodellen tw3600. Der anbefales det at lade det være slået til da man så kan vise "hvidere end hvid". - Det var min opfattelse at man bevidst burde skjule/klippe BTB og WTW da evt billedinformation der bevidst er skjult i produktionen?

Hvis "super white" er slået fra klipper den over level 235 men til gengæld er billedet mere lysstærkt.

 

MVH

Det lyder fornuftigt. Og uden at det skal lyde for snobbet, så finder du ikke nogen hér der kan give dig bedre generelle råd end folkene bag Calman, så hvis du følger deres råd men stadig har problemer, så skyldes det specifikke detaljer omkring den pågældende projektor, som man skal have erfaringer med netop dén for at kunne svare på. Jeg tror du må indse at det er dig selv der er prøvekluden... Til gengæld lærer du noget nyt 

 

tvkartoffel skrev: Hvidbalancen ser ud til at kunne blive rigtig god selvom de tilgængelige kontroller er lidt sparsomme ( kun to punkter).

For the record: To justeringspunkter ville være én for meget hvis projektoren var optimalt designet... I takt med at kalibrering er blevet populært er der blevet en konsensus om at det er godt at have mange justeringspunkter, men reelt er det kun en fordel hvis projektoren ikke fra starten er designet til at levere korrekte farver. Mange justeringspunkter giver en bedre brandslukning, dvs. du kan kompensere for de fejl projektoren har, men det er langt bedre at fjerne fejlene, end at kompensere for dem. Det er LANGT bedre at have én eller to punkter og et grundlæggende lineært forløb, end at have et ujævnt forløb og 20 punkter til at korrigere for det.

Bare lidt baggrundsinfo, ikke noget der har så meget praktisk betydning for dig...

Hvad angår den grønne, så er det en "fejl" i dekoderen eller et bevidst valg fra Epson. Hvis man sætter den over i X.V. mode kan den godt ramme den rigtige grøn. Mærkeligt nok har mit Panasonic TV noget af det samme.

Jeg er i den grad enig med dig i at det ville have været bedre hvis jeg ikke skulle forsøge at kompensere for fejl der er indbygget på fabrikken.

 

MVH

 

Det er fornuftigt at fokusere på rød (og gul), da hudfarver indeholder mere rødt end blåt - og det er ganske givet rationalet bag anbefalingen.

 

Derudover er tint ikke normalt en funktion, der giver megen værdi - den "tilhører" NTSC-standarden - så fokusér i stedet på hvidbalancen, gamma og primærfarverne i gamut'en. Hvis matematikken er lavet korrekt i TV'et, placerer sekundærfarverne sig rigtigt derefter - afh. af primærfarvernes kromaticitet og placering af hvidpunktet - og implementeringen af paneldriveren iøvrigt.

 

Farvefiltre er som udgangspunkt ikke nøjagtige nok - med mindre man bruger et billigt måleinstrument - så kan et blåt filter måske være bedre til lige netop den deldisciplin (tint/hue).

 

EDIT: rettede slåfejl

 

Tak for indspark.

 

Først og fremmest er det ikke et TV. Det er en projektor - Epson tw3200 ;-)

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.

Jeg har ikke kunne få saturation på plads for blå og grøn, men hue, luminans for alle primær og sekundær farver, og gråskalaen belv ret godt.

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.

 

Farvefiltre har jeg opgivet. Jeg får et ny resultat hver gang jeg har prøvet på mit eget TV.

 

MVH

tvkartoffel

En god grund til at fokusere på hue/tint for sekundærfarverne kunne f.eks. være at ramme bedre gengivelse af hudfarver. Hue/tint for primærfarverne er naturligvis slet ikke uvæsentlige - specielt den røde jf. argumentet for bedre gengivelse af hudfarver. Derudover kan jeg ikke se nogen grund til at prioritere som nævnt - men måske stammer det råd fra "gamle dage", hvor man ikke kunne ændre på primærfarvernes hue/tint, da de var bestemt af kromaticiteten af den anvendte farveteknologi i displayet (farvefiltre + baggrundbelysning eller fosforerne). Tint/hue-kontrollen kunne derimod flytte på sekundærfarverne.

 

tvkartoffel skrev: Hvidbalancen ser ud til at kunne blive rigtig god selvom de tilgængelige kontroller er lidt sparsomme ( kun to punkter).

Som Otto siger - to (eller ét) punkter er rigeligt, hvis gråtoneforløbet ellers er lineært. Når det er sagt, er formålet med flere punkter lige så meget at ramme gamma korrekt som at ramme en pæn gråtoneskala (men det er med i handlen). Spørgsmålet er så, hvad "korrekt gamma" betyder - men den diskussion kan vi evt. komme tilbage til.

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å.

Ang. gamma og gråtone, så fik jeg meget fine dE værdier for gråtoneskalaen, men gamma har et pænt stort dyk. Lige som på dette billede jag har snuppet fra AVforums:

Mine er lidt værre men tendensen er den samme. Jeg har en 7 punkt gammaEQ til rådighed ud over den 2 punkts justering til gråskalaen. Måske jeg kan vinde lidt med den.

 

MVH

 

Mange gange ser man dette, når displayet brænder ud - altså når kontrasten står for højt. Måske er noget iris i spil (kender som sagt ikke projektoren)?

 

Jeg bruger et nyere I1 Display LT. Jeg krydser fingre for at det ikke er filtrene den er gal med, men jeg har ikke nogen mulighed for at kontrollere det andet end ved at bedømme resultatet.

 

Ang. dykket i gammaen, så har jeg slået irisen fra, så det er ikke det. Det er meget tydeligt at den simpelt hen er udreguleret. GammaEQ ser derfor ikke ud til at kunne benyttes til noget fornuftigt.

 

Det skal så siges at jeg har nullet det hele og alene kalibreret gråskalaen. Det har subjektivt givet et bedre billede og den kolde/undermættede kvaltet er forsvundet.

 

MVH

 

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/" rel="nofollow - 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.

 

Der er ikke ander for end at jeg må forsøge mig med en gul saturation skala i HCFR. Jeg vil vædde på at der dukker noget op i den. Nu så jeg tilfældigvis noget af braveheart i går aftes og det er tydeligt at hudfarvekontrollen også påvirker grøn (træer og græs) rigtig meget.

 

Jeg var ikke klar over at gammaen kunne lave så mange ulykker. Det er så ikke ret smart at der ikke har været en fast definition da man så ikke kan vide hvilken man bør sigte efter. Det er så lidt spøjst at der er valgt 2.4 nu, hvis det er tilfældet, når nu alle har rendt rund og forsøgt at ramme 2.2. Generelt er det min opfattelse at der flyder mange misforståelser rundt på diverse AVfora fordi ingen stiller sprøgsmålstegn og meget få kender de virkelige berundelser for at gøre som det anbefales (f.eks at vælge gamma 2,2). 

Problemstillingen er (U)heldigvis ikke ret relevant for mit vedkommende da jeg ikke ejer et display der kan vise hverken 2.2, 2.4 eller noget der i mellem.

 

I det hele taget har øvelsen indtil videre været at indgå de mindst dårlige kompromiser og undersøge havd de forskellige kontroller gør. Det lader til at det faktisk er det der er kunsten, og ikke bare at tvinge en farvet prik hen i en target firkant.

Jeg er stadig lidt forundret over hvor lidt interesse der er omkring emnet, specielt set i forhold til hvor meget der er at hente selv med en lille indsats som at få grå/hvid på plads og set i forhold til hvad der ellers bliver fyret af på udstyr.

 

Edit: Har du et bud på om calman eller HCFR er bedst egnet til at lave RGB balance, Jeg får markant forskellige resultater alt efter om det er den ene eller anden jeg bruger. RGB følges flot ad i begge, men hvis den er linealret i HCFR, så rapporterer calman at der mangler niveau op til 30 IRE. Hænger det sammen med at calman refererer til 100 IRE?

 

MVH

tvkartoffel

Jeg tror du har ret i, at undersøgelse af hudtonekontrollen mht. gul kan være interessant, når du har konstateret, at hudtonekontrollen også påvirker grøn. Fortæl om dine fund.

 

 

Jeg lader lige tankerne flyde...

 

Gamma er et særdeles svært område at forstå - og det er mit indtryk, at de færreste har en helt klar idé om, hvad gamma'en egentligt betyder. Jeg ser gamma'en som hjertet i billedgengivelsen - og hvis man skal vælge én graf/kurve, som beskriver displayets farvegengivelse, må RGB-luma-kurven (den krumme kurve, hvor krumningen er et udtryk for gamma'en) være det mest beskrivende, da RGB-luma-kurven ud over gamma også indeholder hvidbalancen (som så kan illustreres bedre på den måde, som vi plejer at gøre).

 

Den anden nødvendige afbildning er gamut'en, som fortæller os, hvordan displayets filtre + lyskilde, fosfor eller OLED'er er skruet sammen. Gennem primærfarvernes og hvidpunktets kromaticiteter er gamut'en den "afgrænsende faktor" for farvegengivelsen gennem definition/beregning af de koefficienter, som displayet (evt. gennem kalibrering) skal bringes til at anvende ved farvedekodningen for at ramme BT.709-gamut'en og de korrekte lysstyrker. Vi bruger CMS'en til at kalibrere gamut'en, og det er en proces der aldrig kan udvide den medfødte/native gamut eller øge lysstyrken - kun det modsatte.

 

Mht. at man nu tilsyneladende går efter at gøre gamma 2,4 til referencen i studiet, så er det måske ikke så meget anderledes end tidligere, hvor 2,5 åbenbart underforstået var det, som man anvendte (eller burde anvende) på CRT-monitorer. CRT-monitorerne er af gode grunde (og jf. Poynton) på vej ud af mastering-processen, så det er måske årsagen til, at man nu griber chancen for at blive (mere) enige om gamma. At gamma skulle blive 2,4 betyder ikke noget negativt for billedgengivelsen som sådan, når blot displayet kalibreres til samme gamma, da det er mastering-processen, der bestemmer hvordan farvegengivelsen og lys/mørke i billedet skal være - men det er vigtigt at man beskriver hele kæden fra ende til anden for at kunne præsentere indholdet som forventet til forbrugeren (jf. rendering intent).

 

Et problem kan dog være, at en display-gamma på 2,5 (2,4) på mange displays vil medføre klipning af små RGB-værdier (eller klipning af shadow details - men det påvirker altså også farvegengivelsen) - og det kan være en forklaring på, at gamma=2,2 (eller lavere) har været populært.

Slutresultatet bliver en ikke-flad end-to-end-gamma på ca. 1,25 (1,20), som er højest i den lave ende af gråtoneskalaen, og som skønnes at passe til "almindelige" omgivelser for en TV-stue frem for en "bat cave", hvor den lave ende af gamma-kurven påvirkes tydeligt af reflektioner (det har jeg vist eksperimenteret med og målt tidligere på et eller to TV). Naturligvis er alle TV-stuer ikke ens indrettet - og dette udgør endnu en fejlkilde i forhold til korrekt farvegengivelse.

 

Jeg har opdateret min post ovenfor et par gange (og gør det nok igen): Jeg kom lidt længere ud af en tangent (gamma'en er iøvrigt tangenten til luma-kurven...), hvor jeg har fundet lidt flere interessante problemstillinger omkring bl.a. delta-E, hudfarver med overdreven solbrændthed eller et grønligt stik i visse dele af billedet (f.eks. hudfarver) som funktion af afvigende gamma i forhold til colourgrading-processen.

 

Jeg fik aldig rundet tråden helt af. Som du måske har set er der lige det aber dabei at jeg har værret lidt uhledig med mit lærred. Lige PT er det hele pillet ned så jeg kan ikke måle på noget som helst. Jeg vender tilbage til tråden på jeg får et andet lærred. Desværre har jeg ikke gemt de sidste målinger. Det kunne ellers have været meget sjovt at se hvor meget lærredet påvirker billedet.

 

Ellers har det været interessant læsning, omend lidt tungt :-)

 

MVH

I mellemtiden har jeg opdateret mit indlæg ovenfor med nogle illustrationer af en enkel test af tesen om gammaens indflydelse på den faktisk farvegengivelse - specielt mht. påvirkrning af hudfarver.

 

 

Jeg kan ikke lige huske om CalMAN har samme valgmulighed (jeg har kun en gammel CalMAN v3 selv, som jeg meget, meget sjældent bruger) - men jeg synes at kunne huske, at CalMAN bruger længere tid på måling af mørke testmønstre, hvilket kan tyde på, at der filtreres mere på det aflæste signal.

 

Bruger du de samme testmønstre med de to software-pakker?

 

 

I Hcfr kan man i nogen grad selv vælge hvordan den skal læse ved mørke testbilleder. Alt efter indstilling kan det tage op til et minu at læse de mørkeste af dem og den bliver så hurtigere og hurtligere jo lysere de er. I calman synes jeg sjovt nok at indstillingerne er mere forvirrende og jeg har nogen gange ret svært ved at forstå hvad de mener i hjælpen så jeg er ikke 100 på hvilke indstillinger der kan laves. Uanset hvad er calman markant langsommere end hcfr. Jeg synes ikke det fremgår klart nongen steder om det skyldes at softwaren i sig selv er langsom eller om der foretages længere/flere målinger. Jeg har brugt de indbyggede testbillder på PCen så de er ikke de samme men man skulle da tro at de er ens nok til ikke at få påfaldende afvigelser.

På projektoren har jeg brugt AVS HD disken men der har jeg ikke fået lavet en sammligning endnu, så det er da muligt at årsagen skal findes i testbillederne.

 

Bortset fra det er jeg i gang med at undersøge om jeg skal gå over til HTPC i stedet for dedikeret afspillerhardware. Det vil potentielt give mig nogle helt andre muligheder da Mediaplayer classic  HT kan bruges som afspiller i Mediaportal. MPCHT kan i følge dokumentationen læse icc skærm profiler. Min foreløbige vurdering er at man tvinge den til at overholde det rigtige farverum selv på en skærm der har for stor gamut hvis der er bundet en icc profil til skærmen. Jeg er kun lige startet på det men det ser lovende ud. Hvis det går som jeg håber kan jeg komme helt uden om at tvinge gamutten på plads i projektoren og nøjes med at lave RGB balancen og så profilere den i PCen i stedet. Det er ret meget på Betastadie lige nu og det er ret svært at få hjælp til det der hvor folk må formodes at vide noget om skærmprofilering (phosee.dk og fotostart.dk). Min eneste bekymring er at om jeg reelt får en lavere farve opløsning ved at gøre det på denne måde, men der er ikke andet for end at prøve at se hvordan det ser ud.

 

MVH

 

Jeg tror ikke at HCFR i det hele taget bliver opdateret mere. Den seneste version er ret gammel og understøtter ikke hovedparten af de nye metere.

 

MVH

 

Hmmm - grafikkort er ikke nødvendigvis veldefinerede - de har alle mulige features, som de prøver at overgå hinanden med. Alt andet lige vil det være bedre at bruge én og samme testgenerator til at sammenligne f.eks. software-pakkerne.

 

tvkartoffel skrev: Bortset fra det er jeg i gang med at undersøge om jeg skal gå over til HTPC i stedet for dedikeret afspillerhardware. Det vil potentielt give mig nogle helt andre muligheder da Mediaplayer classic  HT kan bruges som afspiller i Mediaportal. MPCHT kan i følge dokumentationen læse icc skærm profiler. Min foreløbige vurdering er at man tvinge den til at overholde det rigtige farverum selv på en skærm der har for stor gamut hvis der er bundet en icc profil til skærmen. Jeg er kun lige startet på det men det ser lovende ud. Hvis det går som jeg håber kan jeg komme helt uden om at tvinge gamutten på plads i projektoren og nøjes med at lave RGB balancen og så profilere den i PCen i stedet. Det er ret meget på Betastadie lige nu og det er ret svært at få hjælp til det der hvor folk må formodes at vide noget om skærmprofilering (phosee.dk og fotostart.dk). Min eneste bekymring er at om jeg reelt får en lavere farve opløsning ved at gøre det på denne måde, men der er ikke andet for end at prøve at se hvordan det ser ud.

-------------
/lars

 

tvkartoffel skrev: ... Uanset hvad er calman markant langsommere end hcfr. Jeg synes ikke det fremgår klart nongen steder om det skyldes at softwaren i sig selv er langsom eller om der foretages længere/flere målinger.

 

En af udfordringerne i ColorHCFR er, at noget tyder på, at softwaren ser ud til at midle målingerne ukritisk, hvorimod CalMAN laver en statistisk analyse af måledata (og tilhørende sortering i måledata), før de (evt.) indgår i midlingen. Pga. at der potentielt kasseres mange måledata, kan en måling i den mørke ende af gråtoneskalen komme til at tage lang tid.

 

Potentielle problemer med måledata betyder, at man i ColorHCFR får allermest ud af at bruge "combined histogram for free measures" og dermed lave midlingen manuelt ud fra det overblik, som den grafiske præsentation af historikken giver. Man vil derudover også være bedst tjent med at lave en optisk vurdering af gråtoneskalen efterfølgende, med afsæt i den lyse ende. Problemet er så, at et sweep af gråtoneskalaen ikke nødvendigvis giver så pænt et billede af hvidbalancen og gamma'en (specielt i den mørke ende), som man (med rette) kunne forvente.

 

I CalMAN (her v3) synes jeg til gengæld heller ikke, at den måde som man opbygger målingen af gråtoneskalen er idéel: Man kan blive ved med at måle et enkelt punkt, indtil det ligger, hvor man ønsker det og så gå videre til næste punkt. Med denne manuelle styring af måleprocessen får man ret let et pænt måleresultat - men brugt rigtigt minder det om ColorHCFRs model - desværre bare uden historik.

 

Derudover er en stor forskel på de to software-pakker, at ColorHCFR som udgangspunkt regner på fejl  ("dE") i forhold til reference-gamut'en, hvor CalMAN arbejder med muligheden for at bruge en custom-gamut (med lidt kreativitet kan man gøre ca. det samme i ColorHCFR): Det er to forskellige skoler med hver deres skare af tilhængere.

 

Der er iøvrigt en OK gennemgang af CalMAN, ChromaPure og ColorHCFR http://www.hometheaterhifi.com/diy/813-diy-calibration-overview.html - her - dog ikke med fokus på målenøjagtighed.

 

Der er lavet en sammenligning mellem CalMAN of ColorHCFR http://www.avsforum.com/avs-vb/showthread.php?t=1102255 - her - som dog i starten er fejlbehæftet. Efter korrektion af fejl-40 er forskellene som forventet: Størst variation for lave lysstyrker - og ellers ret små forskelle i øvrigt. Der nævnes i tråden, at for i2pro bliver måledata upålidelige under 3.7[cd/m^2], hvilket i store træk svarer til, at vi plejer at sige, at for under 20% til 30% stimuli skal man ikke regne med måledata. Visse andre sensorer er mere følsomme - men mindre nøjagtige og stabile.

Jeg har ikke prøvet at bruge combined histogram i HCFR, da det først gik op for mig hvordan det skulle bruges i går aftes. Det ser unægteligt noget lættere ud men om jeg kan få kalibreringer der måler mere ioveresstemmelse med hvad jeg ser vil tiden vise. Generelt graviterer jeg dog mod at bruge HCFR da jeg synes det er nemmere og hurtigere at bruge så det ville være fint hivs jeg kunne få det sidste på plads med HCFR og ikke jag og var i tvivl om kvaliteten af målingerne.

 

Angående det med HTPC så forstår jeg ikke kommentaren om at "kalibrere displayets gråtoneskala i en "wide gamut", da der kun kan skæres fra i gamut'en - ikke tilføjes."

 

Min tanke var jeg ville kalibrere gråtoneskala og gamma i hardware på projektoren først. Det vil give mig en gamut der er for stor da projektoren bare er sådan.

Derefter vil jeg profilere projektoren og binde den resulterende icc profil til den. Hvis jeg så bruger MPCHC som afspiller, der som du ved kan læse en icc profil, kan jeg direkte i afspilleren vælge om den skal overholde HDTV, NTSC eller PAL. Ved at læse icc profilen skulle jeg kunne kompensere for at gammaen ikke kan komme helt på plads i hardware og at projektorens native gamut er for stor. Jeg kunne evt (grov) kalibrere gamutten i harware også så der ikke skal kompenseres så meget i software og så jeg ikke mister så meget opløsning.

Lyder det ikke som en rimelig fremgangsmåde?

 

Jeg har set at man også kan gøre noget lignende via shaderen men det ser unægtelig noget mere indvolveret ud. Jeg synes at kunne ane at det er sådan du gjorde?

 

MVH

 

 

 

Hej.

 

Tager lige denne gamle tråd op igen, da jeg har et par spørgsmål til Calman som jeg ikke kan finde svaret på i hjælpen.

Dels kunne jeg godt tænke mig at høre hvad der menes om funktionen "Black Level Compensation".

Der er delte meninger om hvorvidt man bør benytte den, men jeg kan ikke finde nogen overhovedet der skriver noget om hvorfor der gør som de gør. Jeg prøvede igår at kalibrere  med epsons gamma equalizer, med Gamma Formula sat til "Power" og Black Level Compensation slået til. I meget mørke film som Harry Potter 7 er giver det mere "hul igennem" så billedet ikke forsvinder så meget ind i skyggerne, men også et lidt mere mælket indtryk.

 

 

 

 

 

Hidtil har jeg lavet gamma til sidst, men ville det ikke være smartere at lave det i rækkefølgen RGB, Hvid, Gamma, CMY? Eller evt: Hvid, RGB, Hvid (igen), Gamma, CMY?