Calibrating Samsung TV?

[toke lahti]

I don’t know where my last comment disappereared.
But I did get PGen to work. I just assumed it didn’t need the cloud account, but it did.

ConnecTEDDD in AVS forums told, that PGen-HCFR combo is limited to 8-bit.

That is a non issue for calibrating a TV using its internal CMS, the N-point grayscale, WP and optionaly 6axis for gamut cliping to rec709 or whatever.

The whole idea for me was to calibrate my tv to be used with MBP in 10-bit HDR.
I guess this is not happening.

Do you want to use mpc as source for reading, rendering and sensing HDR content on the TV?
That is not using the TV as a TV. Or as a widegamut monitor.
That needs that TV behaves as expected for that input. It’s a full calibration in HDR. This means writing a custom LUT from rec2020 PQ (or similar) to actual panel characteristics. You’ll need to acces to propietary API for that TV.
Otherwise you may access to very simplified CMS to tweak HDR grayscale response and “expect” (because it will be beyond your control) that when you “move” greyscale in HDR colorspace 3d volume all the other points mapped from Rec2020 to actual panel response won’t be affected in a negative way because whatever LUT and tonemapping wrote on TVs memory.

Maybe I try again when ColourSpaceZRO is released to macOS.

That will have the same limitations as HCFR = measuring the TV. Read ist features: https://lightillusion.com/colourspace_zro.html
You’ll need a more expensive calman or LI licenses to do a “full calibration”, if that model is supported by X or Y version or each software.

——————-

On SDR be it rec709 or widegamut to be used as a display BY A COMPUTER, you calibrate white and greyscale to have certain color, and optionally to some expected gamma for non color managed enviroments. Then you profile display to capture how it behaves in an ICC file. Apps read ICC profile published by OS and reencode whatever content they what to show in display colorspace.

HDR is different in the way most computer OSes deal with it.  App or even OS sends Rec2020 PQ data (typically) and expects that TV itself  reencondes it to its native colorspace, internally. As I wrote abvove, unless to full acces to whatever LUT and tonemaping TV is using… you’re mostly limited to tweak a little CMS fr greyscale and nothing more, and expect that your tweak does not “deform” the mesh of whatever tonemapping manufactured did

My plan is still:
Calibrate the tv with RP4 + HCFR or PG_client. (Because I can’t do that with my mac.)
Then profile it with mac + DisplayCAL.

Is there something wrong with the plan?

• This reply was modified 8 months, 1 week ago by toke lahti.

[Vincent]

I don’t know where my last comment disappereared.
But I did get PGen to work. I just assumed it didn’t need the cloud account, but it did.

ConnecTEDDD in AVS forums told, that PGen-HCFR combo is limited to 8-bit.

That is a non issue for calibrating a TV using its internal CMS, the N-point grayscale, WP and optionaly 6axis for gamut cliping to rec709 or whatever.

The whole idea for me was to calibrate my tv to be used with MBP in 10-bit HDR.
I guess this is not happening.

Do you want to use mpc as source for reading, rendering and sensing HDR content on the TV?
That is not using the TV as a TV. Or as a widegamut monitor.
That needs that TV behaves as expected for that input. It’s a full calibration in HDR. This means writing a custom LUT from rec2020 PQ (or similar) to actual panel characteristics. You’ll need to acces to propietary API for that TV.
Otherwise you may access to very simplified CMS to tweak HDR grayscale response and “expect” (because it will be beyond your control) that when you “move” greyscale in HDR colorspace 3d volume all the other points mapped from Rec2020 to actual panel response won’t be affected in a negative way because whatever LUT and tonemapping wrote on TVs memory.

Maybe I try again when ColourSpaceZRO is released to macOS.

That will have the same limitations as HCFR = measuring the TV. Read ist features: https://lightillusion.com/colourspace_zro.html
You’ll need a more expensive calman or LI licenses to do a “full calibration”, if that model is supported by X or Y version or each software.

——————-

On SDR be it rec709 or widegamut to be used as a display BY A COMPUTER, you calibrate white and greyscale to have certain color, and optionally to some expected gamma for non color managed enviroments. Then you profile display to capture how it behaves in an ICC file. Apps read ICC profile published by OS and reencode whatever content they what to show in display colorspace.

HDR is different in the way most computer OSes deal with it.  App or even OS sends Rec2020 PQ data (typically) and expects that TV itself  reencondes it to its native colorspace, internally. As I wrote abvove, unless to full acces to whatever LUT and tonemaping TV is using… you’re mostly limited to tweak a little CMS fr greyscale and nothing more, and expect that your tweak does not “deform” the mesh of whatever tonemapping manufactured did

My plan is still:
Calibrate the tv with RP4 + HCFR or PG_client. (Because I can’t do that with my mac.)
Then profile it with mac + DisplayCAL.

Is there something wrong with the plan?

For SDR (including full native gamut) yes, you can even skip HCFR/pgen stuff and let your macbook GPU handle grey calibration. It should have dither.
IINA is a free color managed video player for macOS, very nice.

For HDR maybe not because you may not be able to profile it in HDR an create a compatible ICC profile for that task with DisplayCAL. Ask in github.

[toke lahti]

For SDR (including full native gamut) yes, you can even skip HCFR/pgen stuff and let your macbook GPU handle grey calibration. It should have dither.
IINA is a free color managed video player for macOS, very nice.

For HDR maybe not because you may not be able to profile it in HDR an create a compatible ICC profile for that task with DisplayCAL. Ask in github.

For about 20 years I waited that affordable displays have more than 8bit colors.
I have seen enough banding, although mostly on video side.

So, if my tv has an 10bit colors, I will use that mode from my computer.
And intend not to profile 2 bits away from colors.
I’d hope that maybe with calibrating, I only throw away 1 bit, so with profiling I can get really 9 bits out computer. Meaning 134M colors dipslayed accurately on my tv.

Profiling is always cutting away colors, you can’t never make more of them.

[DaniJ]

How does the greyscale look after measuring it? How does it look after adjusting it from the TVs menu?

There are limits at every corner. The TVs OSD only has so many adjustments one can make. Even if you do an extensive profiling to generate a 1D/3D LUT, you only measure a few thousand points at most. Still far from 8-bits 16M.

[Vincent]

For SDR (including full native gamut) yes, you can even skip HCFR/pgen stuff and let your macbook GPU handle grey calibration. It should have dither.
IINA is a free color managed video player for macOS, very nice.

For HDR maybe not because you may not be able to profile it in HDR an create a compatible ICC profile for that task with DisplayCAL. Ask in github.

For about 20 years I waited that affordable displays have more than 8bit colors.
I have seen enough banding, although mostly on video side.

So, if my tv has an 10bit colors, I will use that mode from my computer.
And intend not to profile 2 bits away from colors.I’d hope that maybe with calibrating, I only throw away 1 bit, so with profiling I can get really 9 bits out computer. Meaning 134M colors dipslayed accurately on my tv.

Profiling is always cutting away colors, you can’t never make more of them.

You have a lot of misconceptions regarding HDR. You can have 10bit on SDR as long as GPU can output it and monitor accepts it. That’s how I’m using my widegamut (AdobeRGB +P3) 10bit SDR monitor.

Also yor source of banding is not 8bit communication but the absence of dithering or color management rounding errors.

Also profiling does not cut colors because it’s just storing a description of display on a file.
Color managing a sRGB black to red 255 gradient to a widegamut display will cut something on 8bit since that 255 sRGB red will be something like “245, 12, 5” so you’ll have 245 actual steps if there is no dithering. But you can use 16bit images on a 10bit SDR output.

Anyway it seems you lack some of the basic concepts so my previous post still applies:
-for SDR (ARGB2101010 pixel format on mac GPU for 10bit vs RGB8888), just calibrate TV as you will do on a regular monitor. Of couse using n point greycale controsl in HCFR will lower the correction needed by grey, but it will be applied in TVs internal lut.
-for HDR maybe you won’t be able to generate a cmpatible HDR ICC profile.

• This reply was modified 8 months ago by Vincent.

[toke lahti]

You have a lot of misconceptions regarding HDR. You can have 10bit on SDR as long as GPU can output it and monitor accepts it. That’s how I’m using my widegamut (AdobeRGB +P3) 10bit SDR monitor.

I appreciate your input.
Even better when it’s shorter.
Btw, is there a way to make this writing box taller than 10 rows, so I could see, what I’m answering to? Well, maybe I’ll put my points between…

I do might have misconseptions about HDR, but I don’t know what they are.
Especially on this UE49KU6645.
I believe, that using HDR with this tv, I can get

1. More brightness
2. Because of that, better contrast ratio
3.  More color depth
4.  See better how my photos (or video) looks like with modern screens (very bright phone screens etc.) after next decade.

Do you know that these are false?
Documentation says, that tv accepts 10/12-bit only in HDR and in 4:2:0(!).

But now, that I’ve got Better Display app tp my mac, I can see, that it (at least) accepts 10bit colors in RGB 4:4:4 (with right cable to right output port).

I do not know what macbook does for the display signal, when you click HDR on in macOS Settings. Do you?
My guess is that with many apps there is “behind the scene” color science happening inside the macOS, so if one plans to use brighness levels that are closer to commonly HDR than traditional SDR (≤100nits), it’s safer to choose HDR setting.

It might be, that I could end as good endpoint with SDR, but why would you think that would be better than with HDR?

Also yor source of banding is not 8bit communication but the absence of dithering or color management rounding errors.

I still don’t believe that dithering is as good as real better color depth. Do you?
If you do, then of course one would choose 12-bit dithered picture to real (hardware) 10-bit display?
I surely don’t know how close “hi quality dithering” is these days to a real thing.
Back in the day 8bit dithering with 6bit screens was not good. But it might also be that those screens were bad also in any other way; low brighness, small gamut, etc.

Also profiling does not cut colors because it’s just storing a description of display on a file.
Color managing a sRGB black to red 255 gradient to a widegamut display will cut something on 8bit since that 255 sRGB red will be something like “245, 12, 5” so you’ll have 245 actual steps if there is no dithering. But you can use 16bit images on a 10bit SDR output.

In profiling, I might choose to use perceptual rendering intent.
Where, if the screen can’t show some colors, the profile will balance the gamut with cutting also opposite colors, right?
When we miss those colors that display can’t show and also those colors that the display can show.
And like you told, if keeping the white balance means cutting some colors not to be used, we miss also those colors.

And I still believe that tv’s internal LUT will have higher bit depth, so adjusting color there (called “calibration”) does not cut any colors that are sent from computer. Do you disagree? Or do you think those colors can be thrown away, because of dithering or something else?

Anyway it seems you lack some of the basic concepts so my previous post still applies:
-for SDR (ARGB2101010 pixel format on mac GPU for 10bit vs RGB8888), just calibrate TV as you will do on a regular monitor. Of couse using n point greycale controsl in HCFR will lower the correction needed by grey, but it will be applied in TVs internal lut.
-for HDR maybe you won’t be able to generate a cmpatible HDR ICC profile.

You still haven’t told why it would be better for me to use SDR.
Is it because with SDR I can make a good ICC profile, but with HDR I can’t?
And this is “maybe” with DisplayCAL? You suspect, but don’t know?

[toke lahti]

How does the greyscale look after measuring it? How does it look after adjusting it from the TVs menu?

There are limits at every corner. The TVs OSD only has so many adjustments one can make. Even if you do an extensive profiling to generate a 1D/3D LUT, you only measure a few thousand points at most. Still far from 8-bits 16M.

I do understand that I’m not doing 16M point calibration.
And I also believe that I can do just fine a calibration for 10 bit color use with 8bit patterns.

So, why I do want to do that calibration in exactly same “signal mode” that I will use with real use?
Because there can be lots of changes of that signal depending on mode. How do I even know what gamma macbook will send? The more profiling needs to alter the colors, more colors are thrown away. And that kinda removes the point of trying to use “consumer grade” display in as good quality as it’s possible.

And, actually, having that Better Display app now, changes quite a bit things. I do not have to speculate what macOS does to that signal and what it’s mode is.
Even Samsungs engineer settings didn’t tell all aspects. Or I couldn’t find them.

I can now emulate that macbook’s output presicely with RP4+PG_client/HCFR.

With this UE49KU6645, it might be better to calibrate it in SDR, because, then I can choose “movie mode”, which then allows 10-point white balancing. I’ve tested few times how 2-point, which is the only option in HDR mode.
It is too few points to do it accurately.
I also get quite a different results with PGen_client than from HCFR and I don’t know why, so I also don’t know which to trust more.
This might have something to do with HCFR’s ability to average i1D3’s measurements?

Calibrite Display Pro HL on Amazon  
Disclosure: As an Amazon Associate I earn from qualifying purchases.

[toke lahti]

You still haven’t told why it would be better for me to use SDR.

Quite frustrating also, that I can’t edit the posts afterwards.

But one important thing about profiling this UE49KU6645 might be, that in SDR I can use it’s 10-point white balancing.
I guess the only way to find out how using HDR or SDR in macbook affects the colors or brightness of the tv’s display, it to try both and see what happens.

[Vincent]

You have a lot of misconceptions regarding HDR. You can have 10bit on SDR as long as GPU can output it and monitor accepts it. That’s how I’m using my widegamut (AdobeRGB +P3) 10bit SDR monitor.

I appreciate your input.
Even better when it’s shorter.
Btw, is there a way to make this writing box taller than 10 rows, so I could see, what I’m answering to? Well, maybe I’ll put my points between…

I do might have misconseptions about HDR, but I don’t know what they are.
Especially on this UE49KU6645.
I believe, that using HDR with this tv, I can get

1. More brightness

in HDR and when feed a signal encoded in PQ that states that it should be showing such brightness… which is unlikely  for a TIFF unless you manually choose to rise SDR max level on OS settings.
But you can do the same on a common SDR display… because it is literally rising display brightness (350nit typical).

1. Because of that, better contrast ratio

That’s false, that’s related to panel.

1.  More color depth

It’s the same as in ARGB2101010 SDR

1.  See better how my photos (or video) looks like with modern screens (very bright phone screens etc.) after next decade.

If your photos are encoded in an “SDR” format they will look the same shown in an HDR display that can render properly such images

Do you know that these are false?
Documentation says, that tv accepts 10/12-bit only in HDR and in 4:2:0(!).

pretty useles for photo using it that way. Do you have a link for such TV specs?
It may be linked to low spec HDMI controler=> UHD@60 4:4:4 8bit or 4:2:0 10.
For any serious desktop work you should use 4:4:4 8 IF that your TV have such old and low spec HDMI controller.

But now, that I’ve got Better Display app tp my mac, I can see, that it (at least) accepts 10bit colors in RGB 4:4:4 (with right cable to right output port).

Better displays can configure virtual resolutions, beware. IDNK what kind of configuration you made.
Actually Better Displays is the way to get factional scalling on macOS due to its poor scalling capabilities, far behind to Windows in that subject. You choose a higher res that will be downscalled using GPU till you get your resired scalling equivalente to MS windows 125% or 150% scalling. macOS natively can do 100% (“size” of things like in 27″ QHD) or 200% (retina)

I do not know what macbook does for the display signal, when you click HDR on in macOS Settings. Do you?
My guess is that with many apps there is “behind the scene” color science happening inside the macOS, so if one plans to use brighness levels that are closer to commonly HDR than traditional SDR (≤100nits), it’s safer to choose HDR setting.

macOS needs to reencode SDR data in PQ HDR stream to render SDR desktop and your SDR AdobeRGB or ProPhotoRGB images, like I said above. Same for Win in HDR mode.

It expects display to accept that signal so at macOS level your display will be Rec2020 PQ regarding color management… unless a custom HDR ICC profile is made and OS supports it. Whatever display does in order to translate such signal to actual panel capabilities is a black box that you won’t be able to modify, exluding maybe HDR n point grayscale… unless you can write full HDRcalibration INSIDE, using Calman <vendor name>, Full version of Calman or full version of Light illusion equivalent.

Regarding SDR brightness it’s another misconception of yours. Computer display SDR has no preferred brightness.
People grade at 100nits for Rec709 SDR becase they are in a controled envirement… but that’s all. It has nothing to do about your actual brightness on computer display or photo editing. Or printing (160nit D50 for P3 appraisal.. or mayeb you want 90nit because your actual room)

It might be, that I could end as good endpoint with SDR, but why would you think that would be better than with HDR?

Because  an ICC profile will store actual primaries and actual gamma, while on HDR as explained above whole system expects display to behave like PQ rec2020 and… let TV deal with out of gamut : brightness, tone mapping… Maybe you can do some custom HDR ICC profile but AFAIK you won’t do it using only DisplayCAL

If you want to show HDR videos you should change OSD settinsg and let OS know that new situation if not auto detected.

Also yor source of banding is not 8bit communication but the absence of dithering or color management rounding errors.

I still don’t believe that dithering is as good as real better color depth. Do you?

You have not seen what an AMD card can do. Or DWMLUT before it broke in W11. It was akin to real HW calibration.

If you do, then of course one would choose 12-bit dithered picture to real (hardware) 10-bit display?

Another misconception of actual data pipeline.
Images are 8 or 16bit. Then they are reecoded from let’s say sRGB 16bit to display colorspace 16bit (described by display SDR ICC profile = color management, done).
They they need to be sent from app to desktop composition that’s where the dithering kicks in for Capture One or LR redarsless or what GPU do you have or in case of using Photoshop it draws an 10bit Open GL surface over desktop composition (maybe latter macOSes changed this, this is the way current 10bit is drawn in Windows for ARGB2101010 pixel format).
So at best your image is dithered to desktop composition bitdepth or drawn at 10bit in an Open GL surface over desktop composition.
Then from that OS desktop composition it is sent to GPU driver and from GPU driver it goes to whatever communication channel you have. Driver can do dither if comms are 8bit (like macintel macbooks with 8bit panel but full 10bit support from almost 10 y ago) or sent as is (10bit 4:4:4) or “blurry them” because channel cannot handle “individual pixels” at that bitdepth and frame rate (4:2:0)

So for showing an 16bit AdobeRGB image on a RGB 10bit SDR capable display, no doubt it’s better to use it 4:4:4 10bit than whatever 4:2:0 unless dpi is so high that “bluriness” doesnot matter at all. 49″ UHD have not a high dpi. It’s close to a 24″ FullHD.

I surely don’t know how close “hi quality dithering” is these days to a real thing.
Back in the day 8bit dithering with 6bit screens was not good. But it might also be that those screens were bad also in any other way; low brighness, small gamut, etc.

We are talking about dithering 16bit image to “real” 8bit (CaptureOne, LR, DWMLUT) or to dither 16bit VCGT gray calibration (from ICC profile) to actual 10 or 8bit comms (HDMI/DP or DVI).
We are not talking about low spec panel 8bit in  to 6bit out.

Also profiling does not cut colors because it’s just storing a description of display on a file.
Color managing a sRGB black to red 255 gradient to a widegamut display will cut something on 8bit since that 255 sRGB red will be something like “245, 12, 5” so you’ll have 245 actual steps if there is no dithering. But you can use 16bit images on a 10bit SDR output.

In profiling, I might choose to use perceptual rendering intent.
Where, if the screen can’t show some colors, the profile will balance the gamut with cutting also opposite colors, right?
When we miss those colors that display can’t show and also those colors that the display can show.
And like you told, if keeping the white balance means cutting some colors not to be used, we miss also those colors.

As explained above, system expects an HDR display to behave in a certain way. No color magament excluding SDR encoding (desktop, excel, Safari, Photoshop) into  HDR PQ stream.

You have no control over it, excluding that your TV allows some kind of HDR hardware calibration to maping correcting “RGB numbers” form rec202 PQ signal to “RGB numbers” in display internal HDR colorspace… and you’ll need a propietary paid app to to that, the more expensive ones as we discussed before. IDNK if it was you or other person here about the same,  afew weeks ago.

And I still believe that tv’s internal LUT will have higher bit depth, so adjusting color there (called “calibration”) does not cut any colors that are sent from computer. Do you disagree? Or do you think those colors can be thrown away, because of dithering or something else?

Whatever TV does. For example if an Eizo SDR panel at very low level accepts 10bit input at external interface level but its internal LUTs (doing things at en early stage than input to panel) use 16bit it will dither. They use 16 bit because luts are chained in a prelut-matrix-postlut to avoid rounding errors… but they will dither.

Regarding your TV at n-point greyscale calibration you won’t see (hence won’t correct) any errors in between. It’s a sampling problem.
If TV is well behaved then it’s enough. If it is not so well behaved a full VCGT grey calibration (in GPU) by ARgyllCMS on a GPU that supports dithered VCGT like AMD or (supposed to) Silicon GPU in Mx Appel chips will be better since ArgyllCMS can measure up to 96 points the extrapolate to 256 entry in VCGT. = errors will be measured, hence corrected

Measure and test. Use mid to large greyscale testchart and look for wild a* oscillations from pink to green… although TVs may have b* oscillations too.
If TV grey is very good then n-point in TV’s CMS is enough.

Anyway it seems you lack some of the basic concepts so my previous post still applies:
-for SDR (ARGB2101010 pixel format on mac GPU for 10bit vs RGB8888), just calibrate TV as you will do on a regular monitor. Of couse using n point greycale controsl in HCFR will lower the correction needed by grey, but it will be applied in TVs internal lut.
-for HDR maybe you won’t be able to generate a cmpatible HDR ICC profile.

You still haven’t told why it would be better for me to use SDR.

Now you have it

Is it because with SDR I can make a good ICC profile, but with HDR I can’t?

Explained too. On HDR display is expected to behave like the signal (with SDR content reencoded to HDR signal in the “SDR” zone of that signal, usually “user driven” the brightness level of such encoding by some OS settings) while on a regular SDR configuration display can be “whatever it s” and color management reencodes content on the fly for that particular display.
You have control for the latter (SDR), you do not have control about such transfomation of the first… unless TV has HW calibration for HDR with some expensive 3rd party apps with acces to API to upload such calibration to TV

And this is “maybe” with DisplayCAL? You suspect, but don’t know?

DisplayCAL:
-generates VCGT for grey… and only that
-applies it to display and the measure how display behaves. Such behavior is stored in an ICC profile but due all limitations on macOS color management engine (Adobe uses its own) you are limited to simplified matrix profiles (so no perceptual et cetera).
optionally it can compute LUT3D for a crystallized colorspace transformation from colorspace A (like Rec709) to colorspace B (like display SDR profile)
DIsplayCAL or ARgyllCMS do not use (and AFAIK won’t use) any propieraty LUT uploading API… so unless LG provides an app to do it … you won’t.

Eizo for example allows to upload precomputed LUT3D from a file, hence it can use DispayCAL LUT3ds. SOme older panasonic OLED allowed SDR LUT3D (rec709 to display profile) uploading by SD card…. so if LG does not allow such things on a free app, you won’t.

• This reply was modified 8 months ago by Vincent.
• This reply was modified 8 months ago by Vincent.

[Author]

Posts