- This topic has 4 replies, 2 voices, and was last updated 4 years, 10 months ago by
.
-
Posts
-
This is an actual help request…
Working with my old Dell sRGB CCFL IPS panels, I’m seeing divergence results for configs that I expect to produce the same results…
When I choose the sRGB preset then change gamma to custom 2.4, I get a calibration that looks like 2.4, and DCal Verify shows nominal perfect 2.4 up and down the line and measured tracking 2.4 well.
OTOH If I choose 1886 preset with gamma 2.4, Verify tells my that nominal is down below 2.0 until level 5 then climbs to 2.2 at about level 13 to hold steady at 2.2 for the rest of the way up, with measured tracking the same. The resultant profile cal looks like 2.2.
At risk of wasting your time, why would DCal produce solid 2.4 results for sRGB+2.4 but significantly mis-track 2.4 as about 2.0 / 2.1 under the 1886 preset?
I’m using the same display and instrument for both runs and the display should be within the limits of the instrument. The odd results are repeatable.
See attached the DCal data sets and Verify reports.
At risk of wasting your time, why would DCal produce solid 2.4 results for sRGB+2.4 but significantly mis-track 2.4 as about 2.0 / 2.1 under the 1886 preset?
By definition of Rec 1886. To give a short explanation 1886 tries to bend “gamma value vs input plot” earlier in low contrast displays (dark greys are lift).
Tip: avoid Rec.1886 unless you have contrast ratio close to VA-like panel or better.
I’m gonna keep trying to reconcile all these details and factors to home in on an explanation for my original Apple TRC quandary over in General while not getting stuck on it.
As we put the pieces of the puzzle together I can see my displays are truly sRGB devices, the Dell is excellent for this because it can reach just a tad farther in both gamut and contrast than pure sRGB, but it’s not good for more. 2012 Macbook Pro is slightly under sRGB.
I see how these lower contrast ratio (700:1) displays struggle with cal TRC higher than effective G2.2. In a fashion my setup is a simulacrum of the mastering condition that 1886 was intended to help a studio with a more capable setup cope with: i.e., a true sRGB display is a simulator of a 709 CRT with the brightness control a bit high. So someone dealing with my content on a better setup will want the power of 1886 to cope with me——Just an analogy and keeping in mind that 1886 was designed for a legacy of HDTV not my scenario.
OTOH for me, given my display’s limits, if I’m gonna do video, I want to think like 1886: I want a calibration with an offset and a power curve that avoids crushing blacks but trades this off a tad for a punchier apparent contrast than sRGB, while internally retaining a profile TRC that follows Rec.709 to be compatible and avoid passing my calibration clipping down the line. Downstream whomever gets my edit will just have to suffer my bias but its been controlled as much as possible.
This sounds like what Apple supplied profile does on my Macbook pro! Except it passes sRGB TRC (web) down the line. This is tricky to follow but on computer side we can assume the image data are normalized to a working space such as sRGB or Adobe or Pro Photo or whatev. The display is giving us a window on the working space. But for video side the data tends to be display referred normalized to some standard. The working space is the window itself normalized to a standard camera. Very confusing. Apple display recognizes you are encountering video with cal but goes the computer way and data are assumed to be sRGB referred. A hybrid.
Regarding tradeoffs of dispkay, puck, target and workflow:
It would be cool if DCal could warn me about the limits of my display both by helping me grok the issue and steering me towards a compromise for whatever workflow my target implies. There are alignments I will try where DCal should flash a yellow light and let me move on, or flash a red light and sound an alarm klaxon.
And there’s room for DCal to offer more tailoring of the psycho-visual aspects of alignment.
Apple chooses to keep silent because it doesn’t look good telling you what their product can’t do while their supplied alignment steers you as best they can. DCal is free to just say “that won’t work” or “here’s a fudge that can help with your display”
Another cool feature could be if DCal can warn about limits of puck, in terms of well known traits of specific devices, and maybe can device limits / failure can be inferred from measurements? I have no clear idea how this could be done but it would be awesome
It will make the app an even more amazing tool for learning about and using CMS.
A database of display capabilities with cross ref to suitability for specific standards would be valuable and these tools are in a unique position to make hay about this
In my travels across the web looking into topic of profile rendering intent (so to speak) this old AVSForum post on gamma looks like a valuable resources to understanding the topic, and what BT.1886 is about. The threat becomes very technically minded, it cant be appreciated without attending to some math, however the video that leads off the thread is for the layperson.
AVSForum Thread All ABout Gamma
https://www.avsforum.com/forum/138-avs-foruma-podcasts/1533867-all-about-gamma.htmlThe AVSForum diatribe looks at the concern first from the point of view of consumer grade TV systems alignment, then moves onto to an study of the math that makes BT.1886 work. See page 2 of the thread above for the more technical discussion.
For anyone who truly cares about the topic of BT.1886, reading Poynton’s 2011 open letter to the ITU is required reading (posted previously, titled “Perceptual uniformity, picture rendering, image state, and BT.709”).
But before that, Poynton wrote a seminal whitepaper, titled Rehabilitation of Gamma, which examines gamma from the perspective of programmers writing applications for Apple Mac (Quickdraw) and Silicon Graphics platform. Both computer contexts became inflection points in the adaption of high-fidelity graphics, device independent color management, and touchstones in the evolution of computerized color for television and cinema. This may be a challenging read for some, but it’s written as a survey reaching any audience who has an interest in the topic of history and future of CMS gamma.
https://poynton.ca/papers/IST_SPIE_9801/index.html
Imaging system gamma is a simple idea with a surprising degree of systems complexity, due to the history of television and computer graphics, and today the term is a harbor of partially formed conceptions about imaging systems tonal response and imaging standards. IMHO, the most overlooked aspect of the topic of gamma is conflict between understanding of the topic as an implicit versus overt component of electronic imaging standards — for example tuning of early television cameras to account for display viewing assumptions, and JPEG just assumed CRT-oriented non-linear / perceptual luminance coding in its origins — and gamma’s role as a rendering intent for specific capture and viewing conditions. As you read about the origin and evolution of gamma, I expect you will be struck by the degrees of confusion over both the purpose of gamma, and the meaning of the term, which ranges at its most precise from describing a very specific exponent in a tonal response curve (which sometimes is discontinuous / has two parts) to a generalized description of a system response (e.g., Mac, Windows, TV, etc), and onward to a tuning of a capture or display system for a specific purpose (e.g., viewing conditions a la BT.1886 or high dynamic range a la hybrid log gamma). It’s tricky to tease these concerns apart. The reason the Poynton papers are important is because they survey the history of the matter and provide a precise foundation of terminology.Basically, Back in the day (circa 1999) Poynton took it upon himself to help the computer industry understand the topic, and now computers are in everything, so here we are,
