- This topic has 46 replies, 3 voices, and was last updated 6 years, 6 months ago by
.
-
Posts
-
If you don’t mind limiting yourself to a 100% output offset gamma curve with exponents 2.2, 2.35 and 2.4 (depending on choice in MPC-HC). I would suggest enabling 10-bit output and floating point processing in MPC-HC.
Can you explain this further? Isn’t the purpose of ICC support to map the source material to whatever my monitor profile is (D6500, BT.1886)? Is MPC-HC’s support improper?
Can you explain this further? Isn’t the purpose of ICC support to map the source material to whatever my monitor profile is (D6500, BT.1886)? Is MPC-HC’s support improper?
MPC-HC doesn’t offer BT.1886, so it’s simply a little more limited than using madVR in that regard.
MPC-HC doesn’t offer BT.1886, so it’s simply a little more limited than using madVR in that regard.
You mean it cannot detect BT.1886 source content? Or it cannot output to a BT.1886 display? I don’t understand how the output can be limited if it’s ICC compliant.
You mean it cannot detect BT.1886 source content? Or it cannot output to a BT.1886 display? I don’t understand how the output can be limited if it’s ICC compliant.
I’m not sure how to be more clear – MPC-HC offers gamma 2.2, 2.35 and 2.4. That’s it. It has nothing to do with being ICC compliant or not, and it has nothing to do with the tone response of the display.
Why does it need to alter the decoded pixels at all, beyond the YV12 to RGB conversion?
If you cannot answer that question, maybe reading an introduction to color management like The Color of Toast will help?
If you cannot answer that question, maybe reading an introduction to color management like The Color of Toast will help?
I get that, but I don’t understand why gamma needs to be chosen in the video player. If it just does colour transformation, won’t it retain the same gamma as the source?
I get that, but I don’t understand why gamma needs to be chosen in the video player.
I can only guess, but at some point the MPC-HC developers probably decided that they wanted a simple way to adjust decoding gamma for different viewing environments.
I can only guess, but at some point the MPC-HC developers probably decided that they wanted a simple way to adjust decoding gamma for different viewing environments.
Isn’t this achieved by simply loading a different ICC profile + VCGT?
Isn’t this achieved by simply loading a different ICC profile + VCGT?
No, why would you expect it to? A display profile is not normally supposed to alter or influence the source color (as long as the profile is accurate), but to reproduce it as accurately as possible.
No, why would you expect it to? A display profile is not normally supposed to alter or influence the source color (as long as the profile is accurate), but to reproduce it as accurately as possible
What would happen if you calibrated to a 2.4 gamma? Wouldn’t the same image get darker?
What would happen if you calibrated to a 2.4 gamma? Wouldn’t the same image get darker?
In a color managed application, no it wouldn’t. That is the exact reason for color management.
In a color managed application, no it wouldn’t. That is the exact reason for color management.
Why choose anything other than native gamma calibration then? Just to affect the unmanaged Windows desktop? Or to increase the usable bits by distributing them between ICC and GPU LUT? And this question seems invalid for 3D LUT.
Why choose anything other than native gamma calibration then? Just to affect the unmanaged Windows desktop?
Pretty much, yes. Another purpose calibration serves is to make the device more well behaved (pre-linearization), which can help the profiling (especially on laptops or cheaper TN panel displays where equal RGB natively often does not produce neutral, but has a blue push in the midtones).
