- This topic has 13 replies, 3 voices, and was last updated 4 years ago by
.
-
Posts
-
I’m really not sure what to set this to in the Calibration tab. Windows is sRGB and non color managed programs that run on Windows are mastered to sRGB.
The problem is that sRGB 2.2 is designed for daylight surround, but I on the HDTV I’m mostly at dim or black surround which complies to 2.4.
For comparison I choose the Reshade preset and it defaults to “As measured”. So what’s going on? Shouldn’t I set this to Rec. 1886 2.4?
Finally I did a calibration for Reshade (as measured) and reused the icm for HDTV profile as well.
Still I’m interested in knowing if I should set this to Rec. 1886 2.4 for an HDTV in a dim/dark surround.
Thanks for response.
When on HDTV I mostly use madVR (color-managed, with 3dlut) and emulators (many color-managed through Reshade preset), also Firefox (color-managed).Since these programs are color-managed I included them as exceptions in Profile Loader, but there’s still a caveat, the 3dlut from the Reshade and madVR presets by default don’t include the gamma 1D LUT (Tone Curve defaults to As Measured) unless I explicitly set a Tone Curve.
Why is this, shouldn’t they default to Rec.1886 2.4 Tone Curve?
Why is this, shouldn’t they default to Rec.1886 2.4 Tone Curve?
No, when the assumption is that a 3D LUT is in use, creating a calibration for non-color-managed apps is basically a bit of a waste of time.
I see, unless I also want to make use of the ICM profile (for non color-managed applications) that the Reshade preset also generates. Thanks.
Re concept of surround, been reading the sRGB whitepaper (linked) in the help and considering in context of history of TV and Poynton’s open letter to industry which resulted in the creation of bt1886:
Does the idea of “daylight” surround occur in some spec? sRGB doc only mentions “dim” and “dark” surround which it took me a double take to realize that “dim” meant bright 🙂
I am trying to put pieces of puzzle together on migration of idea of gamma from TV to PC industry
PC industry accepted TVs (FCC) encoder under-correction (transmission encoder assuming CRT of nominal G2.5) and built it into the display, then Microsoft and HP sampled the field of PC monitors, discovered this assumption and put it into sRGB, reasoning a good compromise over a range of factors. The sRGB doc gets a bit hand-wavy on these reasons but it makes sense.
It works. PCs master the web against themselves while video content which has moved from mastering (dark surround) to PC (brighter dim surround) gets a shadow lightness bump that used to be in encoding for transmission. In essence the balance of correction was preserved from TV as content creation and distribution was decentralized.
The sRGB spec and its application in PC carries no features for viewing environment correction that I can find. Just looks backwards.
This last point seems a ripe area for refinement: should display calibration explicitly account for viewing environment?
I tried DisplayCal’s “ambient” setting and can’t see what it does. I need a display config that changes from day to night as my room gets a lot of daylight, which per sRGB is much brighter than a usual office. Simultaneous contrast wrecks display. Everyone says make room dark, but why can displays work in bright light? 😉
Finer point: Are there times when you want to hide the displays effective cal from the profile. I think Apple does this to a certain extent: they advertise a profile TRC as sRGB or P3 and roll their own cal to make contrast more pleasing as compared to a strictly colorimetric sRGB rendering. What Poynton refers to as rendering intent
Any thought on this subject, appreciated, including that I am totally wrong re sRGB assumptions as this topic has been very interesting and confusing to me.
sRGB doc only mentions “dim” and “dark” surround which it took me a double take to realize that “dim” meant bright
I’m pretty sure where the sRGB spec mentions “dim” or “dark” they actually meant that literally – this spec was created in the age of CRT monitors, which were very limited (in comparison to LCDs) with regards to peak luminance, so could really not be used well in bright environments without causing eye strain.
This last point seems a ripe area for refinement: should display calibration explicitly account for viewing environment?
In an ICC environment, you need to account for it in the profile (CIECAM02 gamut mapping options in DisplayCAL). The calibration viewing condition adjustment is only really ever useful for non-color-managed applications (and for this reason, I’ll eventually remove it).
Wanted to ask for some time since I’ve been getting bad results when using the tone curve setting, I guess this is expected. Could you give a glimpse to the verification report and see if this is reasonable or I should change something? It’s mainly off in very saturated values (due to a dip in gamma in the higher range), but grey balance is nice.
You mean that for verification I need to disable Simulation Profile? Link
Depends on what you want to check. Uncalibrated display response? Use the settings like you did. Calibrated response with profile (to check device drift and profile accuracy against itself)? Disable simulation profile. Want to see how well sRGB can be simulated using your profile? Enable simulation profile, disable “use simulation profile as display profile”.
