Wide gamut betekent dat het kleurbereik significant verzadigdere primairen (rood, groen en blauw) heeft dan de sRGB kleurruimte. Soms wordt het kleurbereik van wide gamut monitoren ook wel aangeduid met Adobe RGB, maar dat is niet helemaal juist, om verschillende redenen. Eén daarvan is dat vrijwel alle wide gamut monitoren een meer verzadigde rode en blauwe primair hebben dan de Adobe RGB kleurruimte (die dezelfde rode en blauwe primairen heeft als sRGB).
Het grotere kleurbereik betekent dat een groter deel van het kleurvolume dat wij kunnen waarnemen door het scherm kan worden weergegeven. Het heeft echter geen invloed op het aantal kleuren dat een scherm kan weergeven, dat is namelijk alleen maar afhankelijk van de kleurdiepte.
Een monitor met wide gamut color space kan dus in principe meer variaties weergeven dan een standaardmonitor.
Nee, hetzelfde aantal variaties, tenzij de kleurdiepte ook hoger is. Bij dezelfde kleurdiepte liggen de variaties alleen verder uit elkaar (wat dus ook de oorzaak is van color banding).
Mits die uiteraard beschikbaar zijn in de bron.
Dat is niet eens noodzakelijk. Sterker nog, als je niet aan color management doet wordt het altijd met het grotere kleurbereik weergegeven. Je hebt dan dus alleen een foute kleurweergave, doordat alles sterk oververzadigd wordt weergegeven.
Dan lees ik echter verhalen dat als je standaardmateriaal (sRGB) bekijkt op een wide gamut monitor het allemaal veel te verzadigd wordt, omdat het feitelijk vertaald moet worden.
Klopt. Dat vertalen kan dus alleen als je color management workflow goed in elkaar zit, anders wordt het niet gedaan en dan gaan de RGB waarden van de bron ongewijzigd door naar het scherm.
Dit kan je dan tegen gaan door een profiel/kalibratie in je OS in te richten maar niet alle software kan daar goed mee om gaan. Is dit waar en nog steeds zo?
True.
Stel dat je alles goed ingesteld hebt en je naar tevredenheid kunt werken, hoe zit het dan met je workflow? Je werkt dan in feite in een 'bredere' kleurruimte dan anderen dus zal je spul aan het einde moeten exporteren als sRGB als ik het goed begrijp? Dat stel je dan in bij je LR export functie?
Als je in RAW schiet werk je in Lightroom eigenlijk altijd in een grotere kleurruimte. De werkruimte van Lightroom heet voor zover ik weet ook gewoon Lightroom RGB en is gebaseerd op
ProPhoto RGB. Deze kleurruimte gebruikt imaginaire groene en blauwe primairen en kan dus nooit volledig door een scherm worden weergegeven. Dit is gedaan zodat het kleurbereik van de bron niet wordt beperkt door de werkruimte van Lightroom.
Overigens is het volgens mij niet zo dat RAW helemaal geen kleurinformatie bevat en dat het profiel zomaar wordt toegewezen. Dat heb ik wel regelmatig gelezen, maar dat kan nooit kloppen en wel om drie redenen:
- Door de imaginaire groene en blauwe primairen is het onmogelijk om een apparaat te maken dat het volledige kleurvolume van die kleurruimte kan vastleggen of weergeven.
- Door het erg grote kleurbereik dat dan wordt aangenomen zouden vrijwel alle kleuren oververzadigd worden weergegeven. Sterk verzadigde groene en blauwe tinten zouden door de imaginaire primairen zelfs buiten het reële bereik vallen en dus ofwel clippen of weggegooid moeten worden.
- Het zou betekenen dat voor alle opname-apparaten hetzelfde kleurbereik wordt aangenomen. Het verschil in kleurbereik van opname-apparaten is lang niet zo groot als bij weergave-apparaten, maar er zijn nog steeds wel significante verschillen. Zeker sinds de komst van UHD, want fabrikanten proberen nu ook aan de opnamekant een zo groot mogelijk deel van de Rec. 2020 kleurruimte vast te leggen.
Wat blijft er dan nog over van de kleuren, is dat ineens anders of is het gewoon 'minder' maar wel correct omdat je alles juist afgesteld hebt?
Dat is dus het irritante, je werkt in Lightroom eigenlijk altijd met een subset van de kleuren die er zijn. Vrijwel elke camera kan wel kleuren opnemen die vrijwel geen enkel scherm kan weergeven. Die kleuren zijn er nog steeds als je aan het bewerken bent, alleen worden die niet helemaal correct weergegeven doordat je scherm er fysiek niet toe in staat is om ze correct weer te geven. Als je op een standard gamut scherm (kleurbereik ongeveer gelijk aan sRGB kleurruimte) werkt is dit in nog veel sterkere mate het geval.
De kleuren buiten het kleurbereik van je scherm zullen clippen naar de rand van het kleurbereik van je scherm. Maar er kan ook nog verschil zitten in de kleuren binnen het kleurbereik van je scherm. Bij gamut mapping zijn er namelijk ook methodes (rendering intents) waarbij kleuren nog net binnen het kleurbereik van het weergave-apparaat minder verzadigd worden weergegeven zodat er nog steeds een verschil is tussen kleuren die buiten het kleurbereik van het scherm vallen en kleuren die er nog net binnen vallen. Anders zouden die kleuren allemaal hetzelfde worden weergegeven, waardoor je door een gebrek aan kleurnuances (oftewel color banding) veel detail verliest in kleurovergangen met een klein kleurverschil.
En bij anderen ziet het er dan gewoon goed uit, maar wel 'gewoon' sRGB? Of kan het zijn dat het in je eigen bereik erg mooi is maar na export toch ineens heel anders?
Als jij exporteert als sRGB zou de foto er bij iedereen met een gekalibreerd scherm dat alle kleuren in de sRGB kleurruimte kan weergeven goed uit moeten zien. Ik vraag me alleen af of je dat in Lightroom ziet. Als je in Lightroom exporteert in sRGB zie je daarna in Lightroom volgens mij nog steeds de foto zonder de conversie naar sRGB, maar dat weet ik niet 100% zeker. Het lijkt me in ieder geval niet geheel onverstandig om de foto na exporteren nog even te bekijken in een ander color managed programma, bijvoorbeeld Photoshop.
Om te zorgen dat de export er uit ziet zoals je wilt, in plaats van de pre-export, moet je volgens mij soft proofen. Dat kan voor zover ik weet niet in Lightroom, maar wel in Photoshop.
Heeft het dan eigenlijk wel toegevoegde waarde om zelf veel kleuren te kunnen zien als je het uiteindelijk toch allemaal exporteert naar minder kleuren?
Dat hangt af van je gamut mapping methode en of je gaat soft proofen. Die kleuren hebben geeft extra vrijheid bij het bewerken. Je kan het vergelijken met HDR:
Als je een HDR sensor hebt en een SDR scherm krijg je standaard dynamic range compression. De foto zal er dan niet goed uit zien. Het dynamisch bereik van je beeldschermen of drukwerk blijft gelijk, dus als je een groter dynamisch bereik van de camera gaat mappen naar het dynamisch bereik van je beeldscherm of drukwerk dan wordt het beeld minder contrastrijk.
Wat eerst zwart was kan nu best donkergrijs zijn, doordat dat deel dan niet meer de donkerste vastgelegde waarde is. Aan de andere kant kan een deel dat eerst clipte naar wit nu donkerder zijn, bijvoorbeeld de lucht rond de zon. Al zat dat minder snel de indruk geven van een minder contrastrijk beeld.
Je kan dan vervolgens het dynamisch bereik van de sensor beperken, waardoor donkere tinten eerder clippen naar zwart en lichte tinten eerder naar wit. Je kan er echter ook voor kiezen om het te tone mappen zodat de HDR bron optimaal wordt weergegeven op een SDR weergave-apparaat. Het is dan niet meer echt HDR, want daarvoor moet de hele keten van begin tot eind HDR zijn, maar het is wel beter dan wanneer het vanaf het begin al was beperkt tot SDR.
Hetzelfde kan dus ook met kleur. Je kan het kleurbereik laten clippen zonder de kleuren die binnen het bereik vallen te wijzigen (vergelijkbaar met HDR beperken tot SDR), of je kan er bij de gamut mapping methode voor kiezen om kleuren die nog net binnen het bereik vallen iets minder verzadigd weer te geven. Kleuren binnen het bereik zullen dan iets onderverzadigd zijn, maar perceptueel zal het beter overeenkomen met hoe je het zelf in het echt zou zien (of op een scherm dat wel al die kleuren weer kan geven). Dat laatste is dus de variant voor kleur van HDR tone mappen naar SDR.
Van die 10-bit monitoren weet ik dat ook de aansturende hard- en software ermee om moet kunnen gaan. Maar in hoeverre geldt dat ook voor 'gewoon' wide gamut?
Om er volledig gebruik van te maken moet de keten van begin tot eind wide gamut ondersteunen. Vergelijkbaar met HDR en met 10-bit, maar het kan nog steeds toegevoegde waarde hebben om het alleen aan het begin van je workflow te hebben in plaats van helemaal niet, zoals ik hierboven heb uitgelegd.
Gonadan schreef op vrijdag 18 september 2015 @ 14:17:
Is het dan zo dat als je zo'n scherm kalibreert, via windows, via grafische kaart of hardwarematig in de monitor. De kleurweergave dus weer in orde is, ofwel niet oververzadigd? Dus ook voor applicaties die zelf geen weet hebben van die 'wide gamut' etc?
Die eerste twee zijn hetzelfde. Bij softwarematige kalibratie worden vrijwel alle aanpassingen gedaan door de videokaart op basis van de ICC profielen van de bron en het scherm. Als de bron geen ICC-profiel heeft wordt aangenomen dat het sRGB moet zijn.
Bij hardwarematige kalibratie maak je eigenlijk een virtuele monitor met een bepaald kleurbereik, witpunt en gammacurve. Stel ik kalibreer mijn scherm hardwarematig naar Adobe RGB, dan gaat vervolgens alles in de keten voor het scherm er van uit dat het een perfect Adobe RGB scherm is. Er is nog steeds wel een ICC-profiel, zodat content die niet Adobe RGB is kan worden gemapped naar Adobe RGB. Maar alle aanpassingen om van Adobe RGB naar het daadwerkelijke scherm te gaan worden dus in het scherm zelf gedaan op basis van de LUT.
Ik heb in juni hier al het één en ander
over geschreven in het artikel over de introductie van de Eizo ColorEdge CS270:
Waar de LUT voor gebruikt wordt is het omzetten van de kleuren zoals die door de videokaart worden uitgestuurd naar de kleuren zoals die op het scherm moeten worden weergegeven. In de LUT staat dus je kalibratie, maar in plaats van formules is het dus een kant en klare tabel. De reden hiervoor is heel simpel: een beeldscherm heeft niet de rekenkracht om voor elke pixel voor elk nieuw frame uit te rekenen wat de juiste waarde moet zijn.
Bij "softwarematige" kalibratie staat alle kalibratie-informatie in het ICC-profiel. Vervolgens bepaalt je videokaart aan de hand daarvan hoe de kleur van een pixel zoals dat van een programma naar de videokaart gaat moet worden omgezet voor het wordt doorgestuurd naar het scherm.
Bij hardwarematige kalibratie bevat het ICC-profiel niet de volledige kalibratie-informatie. De videokaart past dan alleen maar aan voor het ingestelde kleurbereik, witpunt en gamma van het scherm op basis van de het ICC-profiel van de content, wat veel simpelere correcties zijn. Die correctie gaat er van uit dat het scherm een perfect scherm is: als je hebt gecorrigeerd voor gamma, witpunt en kleurbereik wordt de kleur goed weergegeven. Alleen is geen enkel scherm een perfect scherm, want je hebt ook nog onregelmatige afwijkingen.
Als je een 3D kleurvolume zou opsplitsen in een 3D grid, dan zou bij een perfect scherm elk deeltje een kubus zijn met gelijke afmetingen. In de praktijk heb je echter grid distortion: het zijn geen perfecte kubussen meer en de afmetingen verschillen ook een beetje. Het deel van de correctie dat vervolgens in het scherm wordt gedaan op basis van die LUT is het rechttrekken van dat 3D grid, zodat elke kleur wordt weergegeven zoals bedoeld.
Doordat het scherm niet echt berekent wat het moet worden, maar opzoekt, heeft het nut om een LUT te hebben met een veel hogere bitdiepte dan de kleurdiepte van het paneel. De belangrijkste reden daarvoor is dat hardwarematige gekalibreerde schermen gamut mapping ondersteunen: door middel van de LUT het kleurbereik beperken, ongeacht de kleurinformatie van de content. Hierdoor verschuiven de fysieke RGB-combinaties van het paneel ten opzichte van de RGB-combinaties zoals die zouden moeten zijn voor het kleurbereik dat je weer wilt geven. Doordat er een nagenoeg oneindige hoeveelheid verschillende kleurbereiken ingestelde kunnen worden in de applicatie voor hardwarematige kalibratie heb je dan ook een heel erg grote LUT nodig om te zorgen dat je afrondingsfouten beperkt tot een minimum.
Het voordeel van gamut mapping is dat het voor alle content geldt. Het kleurbereik van veel wide gamut schermen is iets groter dan Adobe RGB. Zou ik het scherm niet kalibreren (en per definitie dan dus ook niet het kleurbereik aanpassen), dan wordt bij alle content zonder kleurprofiel de pixel door het scherm worden weergeven zoals deze door het programma werd opgegeven.
Stel nu echter dat ik het gamut heb gemapped naar Adobe RGB en dat het native kleurbereik van het paneel als volgt is:
Rx = 0,680
Ry = 0,310
Gx = 0,210
Gy = 0,700
Bx = 0,147
By = 0,054
(gamut van LG Display LM270WQ3-SLA1 paneel)
Als een programma dan doorgeeft aan de videokaart dat een bepaalde pixels de RGB-kleur [200;0;0] heeft, dan wordt er van uit gegaan dat dat Rx = 0,640 Ry = 0,330 is van Adobe RGB. Maar het kleurbereik van het scherm is groter dan Adobe RGB dus die [200;0;0] wordt dan met behulp van de LUT omgezet naar [200;55;28], zodat het ook echt als de rode primair van Adobe RGB wordt weergegeven en niet als de rode primair van het paneel zelf.
Maar als je nu een afbeelding opent in Photoshop die als kleurprofiel sRGB heeft toegewezen, dan kan het niet in één keer worden omgezet. De videokaart zet het dan eerst om van sRGB naar Adobe RGB, want die denkt dat het scherm een kleurbereik heeft gelijk aan Adobe RGB op basis van het ICC-profiel van de kalibratie. Vandaar dat ik eerder ook "het ingestelde..." er bij had gezet, want het gaat dus niet om de native eigenschappen van het scherm.
Laten we dan zeggen dat we de RGB-kleur [135;218;56] hebben in sRGB. Dan maakt de videokaart daar eerst [164;218;73] in Adobe RGB van en vervolgens wordt dat in het scherm op basis van de LUT omgezet naar [163;214;71] voor weergave door het paneel.
Zou je een LUT hebben die maar een bitdiepte heeft van 8 bits, gelijk aan het paneel, dan zou daar best wel eens iets anders uit kunnen komen, doordat het al is omgezet van sRGB naar Adobe RGB. Als je dan Adobe RGB niet heel uitgebreid in die LUT hebt staan krijg je twee keer afronden op hetzelfde aantal significante cijfers als het eindresultaat, want dan een significant verschil kan geven in het eindresultaat.Is het dan ook zo dat als je met RAW werkt, dus mogelijkheid tot bewerken in ruime kleuren, je hem gewoon als export naar sRGB kunt doen uit LR? Bijvoorbeeld via de Flickr plugin? En dat je dan dus niet de fletse kleuren hebt in een andere browser omdat je het zelf al correct geëxporteert hebt?
Dat zou inderdaad goed moeten gaan.
Deathchant schreef op vrijdag 18 september 2015 @ 14:31:
offtopic:
Ik zie niet waar hij het over me heeft...
Die U2713H ondersteunt hardwarematige calibratie via die X-Rite i1 display pro apparaat. D.w.z. dat het apparaat alles meet, het icc profiel maakt, inlaadt en ook direct alle settings die je normaal op je monitor zou instellen al vanzelf instelt in een lookup table. Althans zo heb ik het begrepen.
Normaal stel je eigenlijk alleen maar de witbalans voor wit (100% grijs, RGB [255;255;255]) en de helderheid in, de rest wordt vrijwel altijd via het ICC profiel gedaan. Bij hardwarematige kalibratie worden er veel meer aanpassingen dan dat in het scherm gedaan. Het ICC-profiel is er alleen nog maar om content met een ander kleurprofiel dan de perfecte virtuele monitor die je hebt gecreëerd te remappen naar het kleurbereik, witpunt en gammacurve daarvan.
Dus als het goed is, zou het wisselen van videokaart geen invloed mogen hebben...
Klopt, maar zou zelf dan toch opnieuw kalibreren.
...alhoewel wordt aangeraden je monitor naar gelang de tijd verstrijkt vaker opnieuw te kalibreren vanwege "inslijting"
Hangt er een beetje vanaf hoe professioneel je er mee bezig bent. Als het echt je werk is zou ik toch minimaal één keer per 200 branduren kalibreren (ongeveer één keer per maand dus bij standaard werkweek). Als het scherm nieuw is heb je ook meer last van drift dan als het scherm al wat ouder is. Als je scherm er al een aantal duizend branduren op heeft zitten kan je als hobbyist ook wel één keer per twee à drie maanden kalibreren.
Gonadan schreef op vrijdag 18 september 2015 @ 15:07:
Nou ja ik lees overal dat software er niet mee om kan gaan dus dat je dan alles in teletubbykleuren krijgt in bijvoorbeeld je browser. Dan zou hij alleen bruikbaar zijn voor de fotobewerking en verder wil je hem eigenlijk gewoon op sRGB hebben.
Toen ik vier maanden de Eizo ColorEdge CG277 kon gebruiken voor m'n review van dat scherm was dat inderdaad wat ik deed. Je kon toch met twee muiskliks van profiel wisselen, dus als ik niet bezig was met iets waar ik wide gamut voor wilde gebruiken activeerde ik het sRGB profiel dat ik gemaakt had en wist ik zeker dat het goed werd weergegeven.
Het zou ook goed moeten gaan in andere gevallen ware het niet dat Windows niet goed overweg kan met ICC v4. Ik weet niet meer uit m'n hoofd wat nou ook alweer de voordelen waren van v4 boven v2, maar zelf had ik destijds in ieder geval bewust gekozen voor v4, ten koste van een correcte weergave buiten goede color managed software zoals Lightroom en Photoshop.
Als je ICC v2 gebruikt zou het eigenlijk altijd goed moeten gaan, maar dat zou ik dan eigenlijk eens moeten testen.
begintmeta schreef op zondag 20 september 2015 @ 22:48:
Je hebt niet per se een Quadro (of Fire) kaart nodig toch? Alleen wel monitor, kaart en een driver die 30bits doen natuurlijk (o.a de Linux-nvidia driver doet als ik me niet vergis ook op gewone g-kaarten 30 bits). Ook HDMI kan overigens tot bepaalde resoluties ook met >24b-bits overweg.
Photoshop laat je volgens mij alleen maar 30 bit output activeren als een Quadro of FirePro videokaart gedetecteerd wordt.
300 cd/m² is wel heel erg helder. Ik werk zelf meestal tussen de 120 en 180 cd/m², voor films en series kijken (volledig verduisterde kamer) schroef ik de helderheid vaak zelfs terug naar 50 tot 80 cd/m².
Zonder rebooten had ik met m'n U2711 in combinatie met X-Rite i1Profiler software en i1Pro spectrofotometer dat je kalibratie op kalibratie kreeg, ondanks het eerst verwijderen van het profiel. Geen idee of dat een bug was in een oudere versie van de software, maar ik doe het nog steeds maar voor de zekerheid, is ook een kleine moeite.
[
Voor 13% gewijzigd door
Kid Jansen op 27-09-2015 14:24
]
:fill(white):strip_exif()/i/1310643085.jpeg?f=thumbmini)
:strip_exif()/u/106968/belkar2.gif?f=community)
:strip_icc():strip_exif()/u/93148/NaNthor_Ultimate_Avatar_Tweakers.jpg?f=community){kind=avatar}
:strip_icc():strip_exif()/u/162143/crop5b6d888e9cc79_cropped.jpeg?f=community)
:strip_icc():strip_exif()/u/1981/Image00001.jpg?f=community)
/u/168807/crop64be8029a8530_cropped.png?f=community)
