.ti3 Parser / .3dlut Generator for madVR + .3dlut toolset

[nand chan]

Oh wow, I totally forgot to upload version 0.16. This was done ages ago.

Download link: http://www.mediafire.com/?d8wmeqlx7dd378y

Changelog:

Version 0.16:
! Color spaces are now aware of their gamma functions by default
~ ColorEnc() and ColorDec() renamed to XYZEnc() and XYZDec(). The new ColorEnc() and ColorDec() functions apply gamma
  encoding/decoding by default as well, for color spaces that support it
? Note: This does not apply to all color spaces, eg. ones which define no reference gamma curves, the only gamuts that
  automatically apply gamma en/decoding are:
  BT.709 (PPC 2.35), Apple RGB (PPC 1.8), sRGB/scRGB (sRGB curve), ROMM/ProPhotoRGB (ROMM curve),
  HDTV (709 curve), NTSC87/SMPTE "C" (PPC 2.2), PAL (PCC 2.8), madVR (PPC 2.2) and SECAM/EBU Tech 3213 (PCC 2.8)
+ New gamut: madVR, this gamut uses BT.709 primaries with a 2.2 PPC, to match with what madVR inputs to the .3dlut
~ GammaDec() and GammaEnc() changed to accept an ICurveProvider argument.
+ New functions sRGB() and PPC(double gamma) give you an sRGB or Pure Power Curve. So, for example, GammaEnc(PPC(2.2))
  would replace what was previously just GammaEnc(2.2), and GammaEnc(sRGB()) would replace sRGBGammaEncode()
+ New function L_(L_Mode standard) gives you an L* curve, L_Mode can either be Actual or Intent
- Removed sRGBGammaEncode() and sRGBGammaDecode()

Truth be told, I don't exactly know much about the black point compensation options in either LittleCMS or dispcalGUI. If you want to do some more research, maybe in the LittleCMS manual or mailing list, and maybe test some options, it would be a great improvement.

[6233638]

So, I think it just didn't like the ICM filename. Installed 0.16, renamed the LUT from the dispcalGUI generated one, and it seems to have worked. I'm betting it was the "cdm²" that was causing problems.

Still seems to be raising the black level considerably and introducing some discolouration near black. Will give it another try this weekend.

Looks good otherwise though, will need to verify with test patterns and see how it actually measures.

[nand chan]

Originally Posted by 6233638

Still seems to be raising the black level considerably and introducing some discolouration near black. Will give it another try this weekend.

That seems to be an effect done by LittleCMS, even with “black point compensation” disabled (it's disabled in 0.16. I tried enabling it, but it didn't seem to have any effect). I believe it's linked to the fact that the device doesn't have a perfect black level, so something that should be perfectly black in theory will get cut off to the minimum that the display supports.

What I tried doing to work around the issue, at the cost of accuracy near the blacks, is “warping” the curve near the bottom, bending it to fit within the monitor's envelope. This is what “LinkICCGUI” does internally, but it relies on yCMS's calculations, which doesn't currently support spectrophotometer readings.

I'll see if there's another way to get the desired effect, maybe by pre-scaling values to fit into the black level.

If you can work out the ratio of your monitor's black level to your monitor's white level (ie. its contrast), and pre-scale the XYZ values by that factor, it might have a desirable effect. This would be a simple command in LutScript: Scale(contrast, 1) where contrast is the ratio of black to white (a very small figure). This would be put in between IccSingle and ColorDec.

[6233638]

Originally Posted by nand chan

If you can work out the ratio of your monitor's black level to your monitor's white level (ie. its contrast), and pre-scale the XYZ values by that factor, it might have a desirable effect. This would be a simple command in LutScript: Scale(contrast, 1) where contrast is the ratio of black to white (a very small figure). This would be put in between IccSingle and ColorDec.

Contrast is effectively infinite, the backlight turns off with black, so I'm not really sure what should be done. (this is a local-dimming LED backlit screen)

[nand chan]

Originally Posted by 6233638

Contrast is effectively infinite, the backlight turns off with black, so I'm not really sure what should be done. (this is a local-dimming LED backlit screen)

You're calibrating a display with dynamic contrast enabled? Doesn't that completely screw up accuracy? Either way, it might just be an issue with your sensor at that point. Spectrophotometers are notoriously bad for very-low-light measurements, it's possible that this is what causes the high inaccuracies around black when using stock LittleCMS settings. Or maybe LittleCMS simply isn't equipped to work with such low light levels. Or maybe it's a curve inaccuracy somewhere along the line. Who knows? (Maybe it's even an issue with the source file, eg. being tagged incorrectly)

[6233638]

Originally Posted by nand chan

You're calibrating a display with dynamic contrast enabled? Doesn't that completely screw up accuracy?

It's not dynamic contrast, it's local dimming.

Dynamic contrast simply dims the whole screen with low APL images, and brightens it with high APL images.

LED local-dimming combines both the LC panel and backlight zones to greatly expand the dynamic range of the display. (improving black levels and shadow detail without changing the image)

Originally Posted by nand chan

Either way, it might just be an issue with your sensor at that point. Spectrophotometers are notoriously bad for very-low-light measurements, it's possible that this is what causes the high inaccuracies around black when using stock LittleCMS settings.

Spectros can have issues with low light, but I have no issues using CalMAN measuring the kind of levels that are showing big errors in the greyscale.

I didn't get a chance to try calibrating things again. I think what I'm going to do next time is use it as a contact meter (on the screen rather than on a tripod) which I would prefer not to do, and then disable backlight scanning during the calibration which increases the light output from the display significantly, without introducing any colour shifts and should help with readings at lower light levels.

[nand chan]

Originally Posted by 6233638

It's not dynamic contrast, it's local dimming.

Dynamic contrast simply dims the whole screen with low APL images, and brightens it with high APL images.

LED local-dimming combines both the LC panel and backlight zones to greatly expand the dynamic range of the display. (improving black levels and shadow detail without changing the image)

I was under the impression that “dynamic contrast” is an over-arching term for any sort of technology in which the static contrast ratio is improved by adjusting the backlight in any way.

Spectros can have issues with low light, but I have no issues using CalMAN measuring the kind of levels that are showing big errors in the greyscale.

I didn't get a chance to try calibrating things again. I think what I'm going to do next time is use it as a contact meter (on the screen rather than on a tripod) which I would prefer not to do, and then disable backlight scanning during the calibration which increases the light output from the display significantly, without introducing any colour shifts and should help with readings at lower light levels.

Well, if the measured black level is very low, then I don't see why black detail would be removed when using LittleCMS. Have you tried my suggestion regardless? How large is your measured black and white level?

[6233638]

Originally Posted by nand chan

I was under the impression that “dynamic contrast” is an over-arching term for any sort of technology in which the static contrast ratio is improved by adjusting the backlight in any way.

It's not the same thing really, though I can see why you might think that. Dynamic contrast is awful.

Originally Posted by nand chan

Well, if the measured black level is very low, then I don't see why black detail would be removed when using LittleCMS. Have you tried my suggestion regardless? How large is your measured black and white level?

Black detail is not being removed, but the black level is being raised. (dramatically lowering contrast)

You cannot divide by zero. Black level = 0, White level = 100.

[Wile-E-Coyote]

I have this weird issue when using 3dluts with madVR.

So I calibrated and profiled my monitor with dispcalGUI and created a 3dlut with linkICC. The profile is loaded system-wide after creation.

When I launch a video (using madVR as renderer), it all looks nice. However when I go into madVR settings to set the 3dlut file as calibration, the dark areas of the image are waaaaaay to dark. It's most obvious when using a THX Optimizer-like tool. It's like there's no dark grey anymore. It's either black or light grey. This happens both when the auto-calibrate box is checked or unchecked.

Anybody else had this before? Any idea what could be the issue?

[6233638]

Well, I liked what this seemed to be doing for colour and gamma, though it definitely needed improved somewhat, but I definitely seemed to be noticing a lot more banding, though I never got around to doing a proper test.

From the beginning of Pitch Black:

Original:


yCMS:


ArgyllCMS:



This is exactly the sort of problem you get when using too much data to create a LUT, as I warned about before.

Any ideas on what can be done to improve things?

[nand chan]

I find it nearly impossible to believe that ArgyllCMS will produce that result, what were the exact steps you took to get it?

Even with 2400 sample points I get nowhere near that amount of banding, I see practically no difference in quality to yCMS except for a few very minor tone differences (especially around the greens).

[Wile-E-Coyote]

I just got this error message after trying to create a 3dlut with LinkICC.



First time I ever had this message. Any ideas?

[6233638]

Originally Posted by nand chan

I find it nearly impossible to believe that ArgyllCMS will produce that result, what were the exact steps you took to get it?

Even with 2400 sample points I get nowhere near that amount of banding, I see practically no difference in quality to yCMS except for a few very minor tone differences (especially around the greens).

It's the same 396 patch LUT I made from my initial measurements, all I did was play the video.

[rurika]

Hi, nand chan
I can't generate 3dlut with LinkICC. It crashed when it generating 3dlut.



My system is Phenom II x6 1055T + Windows 7 x64.
It work fine when I used other PC to generate ( core2duo E6750 + Windows XP x86 or Phenom II x4 945 + Windows 7 x64 )

I send this program to my friend that has Phenom II x6 & it seem he had a problem like me.
So, I guess the LinkICC can't work with Phenom II x6.

Hope it will work with Phenom II x6.

[markanini]

nand chan, I followed you calibration guide I & II and I'm wondering now what would good for Flash video in Firefox or Chrome.

[nand chan]

Originally Posted by rurika

Hi, nand chan
I can't generate 3dlut with LinkICC. It crashed when it generating 3dlut.

My system is Phenom II x6 1055T + Windows 7 x64.
It work fine when I used other PC to generate ( core2duo E6750 + Windows XP x86 or Phenom II x4 945 + Windows 7 x64 )

I send this program to my friend that has Phenom II x6 & it seem he had a problem like me.
So, I guess the LinkICC can't work with Phenom II x6.

Hope it will work with Phenom II x6.

Probably an issue due to the number of cores, I'll look into it if I ever get the time. I assume you can just use your other PC for now.

[Wile-E-Coyote]

Originally Posted by Wile-E-Coyote

I just got this error message after trying to create a 3dlut with LinkICC.



First time I ever had this message. Any ideas?

Up. Anyone got an answer for me?

[BeNooL]

Originally Posted by Wile-E-Coyote

Up. Anyone got an answer for me?

I'd say you are doing too many measurements (ie too close to each other) and/or your meter is not precise enough.

Try lowering the number of measurements so that each patch is out of the error range of the meter or eventually edit the file and remove the line where the results are not in increasing order.

[IceB]

Nand, thank you for your work and the great tool.
I have used your previous calibration guide with the REC.709 suggestions.
During the weekend I have tried to recalibrate my LCD TV with the updated guide - gamma 2.4 from here : http://haruhichan.com/wpblog/?p=364 .
My rig is HTPC ( ATI 6450 ) -HDMI-> Yamaha RX-V2700 -HDMI-> LCD Philips 42PFL8404.
The calibration processed with DTP-94 (Monaco Optix XR) colorimeter with dispcalGUI + ArgyllCMS (Win7 32bit).
The problem is every time I have tried to calibrate my monitor with 2.4 gamma tone curve the picture is very dark.
As a result I can not see any details on the dark patterns both on pictures in windows and in MPC-HC with madvr.
Creating 3dlut calibration file for madvr improves the colors in the movies, but still very dark with no details on near black parts of the picture.
After several unfortunate tries I had to recalibrate all back to the REC.709 tone curve. As a result - the picture is great, the colors are bit less vivid comparing to the gamma 2.4, but all the near blacks are clear and well detailed with the created 3dlut calibration file in madvr and in windows as well.

Despite my countless calibration related readings, I can not understand why have you changed the guide from REC.709 to gamma 2.4 ? Would you please explain ?
What might be the reason for the explained issues with my calibration with 2.4 gamma tone curve ?
Am I doing something wrong or my TV is not compatible with the gamma 2.4 colors ?

[nand chan]

Originally Posted by IceB

Nand, thank you for your work and the great tool.
I have used your previous calibration guide with the REC.709 suggestions.
During the weekend I have tried to recalibrate my LCD TV with the updated guide - gamma 2.4 from here : http://haruhichan.com/wpblog/?p=364 .
My rig is HTPC ( ATI 6450 ) -HDMI-> Yamaha RX-V2700 -HDMI-> LCD Philips 42PFL8404.
The calibration processed with DTP-94 (Monaco Optix XR) colorimeter with dispcalGUI + ArgyllCMS (Win7 32bit).
The problem is every time I have tried to calibrate my monitor with 2.4 gamma tone curve the picture is very dark.
As a result I can not see any details on the dark patterns both on pictures in windows and in MPC-HC with madvr.
Creating 3dlut calibration file for madvr improves the colors in the movies, but still very dark with no details on near black parts of the picture.
After several unfortunate tries I had to recalibrate all back to the REC.709 tone curve. As a result - the picture is great, the colors are bit less vivid comparing to the gamma 2.4, but all the near blacks are clear and well detailed with the created 3dlut calibration file in madvr and in windows as well.

Despite my countless calibration related readings, I can not understand why have you changed the guide from REC.709 to gamma 2.4 ? Would you please explain ?
What might be the reason for the explained issues with my calibration with 2.4 gamma tone curve ?
Am I doing something wrong or my TV is not compatible with the gamma 2.4 colors ?

Rec709 is simply incorrect. The black levels you are seeing are unnaturally bright. It's supposed to be as dark as 2.4. If 2.4 is too dark you can try 2.2 or maybe 2.1 instead, but definitely don't use Rec709.

The reason you're experiencing the problem is probably because your TV doesn't have very good detail in the dark regions in the first place. I personally can see the difference between (0/0/0), (1/1/1) and (2/2/2) on my monitor.