yCMS - Color Management System

[yesgrey]

Yes, it was barely noticeable but you could see it too because you corrected it.
Should I stop reporting the "barely noticeable" and "really small" errors?
Of course not. Any bug should be corrected. I was only giving an example about the correct calibration of the displays. My goal is always perfection, I never suggested (or will) to decrease the brightness to mask a bug.;)

I think yCMS and/or madVR with 3DLUT processing is not perfect yet.
And never will. :D
On a more serious tone... We're still working on improving them, and there is still much to improve, so of course it's natural that the results in some cases are not yet so good as they could.

Professional CRT monitors used for mastering content measure 2.35 gamma.
Yes, but some people working in the area state that the monitors are LUT calibrated to have BT.709 gamma curve characteristics... so, at least some of the studios might be using them.;)

EBU guidelines specify 2.35 gamma based on extensive testing and Barco monitors are set to 2.35 by default. (EBU/SMPTE compliant)
EBU guidelines also specify a different transfer function for SD broadcasts, but it seems that the one used is BT.601...

If you are only measuring an average of 2.35, there is a high chance that detail near black is being compromised, and that there are errors elsewhere. You have to measure 2.35 at every point on the curve for the image to be accurate. Averages just don't cut it.
Measuring the same value at every point is the same as using a pure power function. The average is a simplification used when comparing a BT.709 curve with a pure power curve.

Unfortunately, you did not bring anything new, because we still have several arguments voting for each side, so I still keep my opinion to try it and judge for ourselves. However, I admit that with a higher contrast ratio display the shadow detail loss might not be an issue with a pure power curve... I need to calibrate my CRT monitor using yCMS and see how it works...

[6233638]

Yes, but some people working in the area state that the monitors are LUT calibrated to have BT.709 gamma curve characteristics... so, at least some of the studios might be using them.;)I have never seen any commercial content that looks even close to good using the inverse BT.709 gamma curve. They must be mistaken. A lot of people working on the monitors do not the technical details on how the monitors work.

[yesgrey]

I have never seen any commercial content that looks even close to good using the inverse BT.709 gamma curve.
I don't agree. I'm using it and I'm having very good results with it. Recently I increased the gamma value to 2.35 instead of 2.222 and it looks slightly better, so I'm keeping it. However, as I stated before, I admit that this might be due to the poor contrast ratio of my projector (800:1), but I will try to find the time to test it with my CRT monitor to compare.

They must be mistaken. A lot of people working on the monitors do not the technical details on how the monitors work.
The person I'm referring does the two things: he calibrates the monitors with the LUTs and corrects the image.

It would be great if existed a definitive value and curve type, but unfortunately it does not, so we have to live with what we have, and, to be honest, even with all this "mess" with the gamma curve types and values, the results are really impressive.:)

[6233638]

I don't agree. I'm using it and I'm having very good results with it. Recently I increased the gamma value to 2.35 instead of 2.222 and it looks slightly better, so I'm keeping it. However, as I stated before, I admit that this might be due to the poor contrast ratio of my projector (800:1), but I will try to find the time to test it with my CRT monitor to compare.You know the BT.709 curve is around 1.96 power?

2.22 is the lowest I would ever use. 2.35 is best.
On an 800:1 projector you would have to use a low gamma though. Maybe 1.96 looks acceptable there.

[yesgrey]

You know the BT.709 curve is around 1.96 power?
Yes, and so what? You are talking only about numbers, like if it existed a magical or definitive number, when there is not. First, we need to know what curve type is used by the studios on their mastering displays, and different people refer different curve types. However, on the gamma value to use it seems there is some agreement, around 2.35, but as you perfectly referred on your question, the gamma issue is much more than the gamma value used.

2.22 is the lowest I would ever use. 2.35 is best.
If you use a pure power function with a gamma value of 2.35 to watch a movie that was mastered using a BT.709 with a gamma value of 2.222, I don't believe you would get a great result...

Summing up: I'm not saying that we should use the BT.709 curve. I'm saying that we still don't know which is the best, so it's wiser to try both and decide. If you prefer the pure power curve that's great for you, but making it a rule to everyone I don't agree.

[6233638]

If you use a pure power function with a gamma value of 2.35 to watch a movie that was mastered using a BT.709 with a gamma value of 2.222, I don't believe you would get a great result...

Summing up: I'm not saying that we should use the BT.709 curve. I'm saying that we still don't know which is the best, so it's wiser to try both and decide. If you prefer the pure power curve that's great for you, but making it a rule to everyone I don't agree.Films are mastered at 2.35. (2.4) Its what pro CRTs measure and what Pro LCDs are set to: http://www.barco.com/en/product/2146/specs

BT.709 is a camera transfer function to avoid shadow noise. 2.35 is what content is mastered at and should be viewed with in a dark room.

[madshi]

@6233638, we have contact to a person involved in mastering. He's saying that he's calibrating his displays to a BT.709 curve and that's he's checking the content he's encoding with 2.2 and 2.5 (BT.709), IIRC. However, he also says that when just watching content, he prefers a higher gamma value and that he's using 2.2 only so that he can see "everything" (so that his encodings are artifact free).

However, Poynton has recently measured some monitors used for mastering and measured them to be about ~2.35 pure gamma. He doesn't really say how many monitors/studios he's tested/measured, though.

The Calman help system recommends to use a pure power curve for batcaves and a BT.709 curve when there's ambient light.

So we have conflicting information. My personal opinion is that a pure gamma function is the "theoretically correct" transfer function to calibrate to for a batcave. However, the difference between a pure gamma curve and a BT.709 curve is not night and day and a BT.709 curve helps showing shadow detail better. So I can imagine that some people may prefer a BT.709 curve, depending on display, room conditions and also personal taste. Furthermore, since no standard out there really defines how monitors should be calibrated (which is something Poynton complains about a lot), we have to expect that different studios might be using differently calibrated monitors. E.g. I've been told Pixar uses 2.4 (probably pure power). Basically that means that the "best" gamma curve to calibrate the display to might even differ for different movies.

yCMS allows you to choose a pure power curve or a BT.709 curve, or even an intermediate curve, with any gamma "value" you want. So our recommendation (both by yesgrey and me) is that you try out what works best in your setup. I can't see anything wrong with that. Later, when I add more automated yCMS support to madVR, I plan to choose a 2.35 pure power curve as the default setting for a batcave. But still I'll allow BT.709 curves and other gamma values, too, of course.

[6233638]

EBU, ARIB and BBC have done extensive measuring of CRT monitors, all around 2.35.
When encoding you do have to adjust gamma to make sure it's good, but color/tone work is aimed at 2.35.

I agree there should be a defined standard, and in some cases 2.35 is not ideal. (brighter rooms)
In ideal conditions (dark room, high contrast display etc) the target is 2.35.

2.35 is not a hard rule (too many variables) but it is what you should target in ideal conditions for the most accurate picture.

[Fer]

It shows that Gamma_Curve is working almost as it should, only the >80 IRE values drift a little, but maybe that's due to you being using such a coarse set of measurements... could you try with 4 or 5 IRE sized steps above 80 IRE?

I have measured the 5 IRE sized steps display gamma. With the new configuration file the corrected yCMS gamma curve show a similar behaviour compared with the 10 IRE sized steps previous measurements:

Gamma_Curve 1.0 2.55
http://a.imageshack.us/img834/9387/gammatf1g2555step.th.jpg (http://img834.imageshack.us/i/gammatf1g2555step.jpg/)

Gamma_Curve 1.0 2.20
http://a.imageshack.us/img828/5904/gammatf1g2205step.th.jpg (http://img828.imageshack.us/i/gammatf1g2205step.jpg/)

[yesgrey]

I have measured the 5 IRE sized steps display gamma. With the new configuration file the corrected yCMS gamma curve show a similar behaviour compared with the 10 IRE sized steps previous measurements
OK, I will investigate to see if I can find the problem...

[janos666]

This is not "the truth" 'yet' (it doesn't even try to look like a very professional article but I think he know what he talks about) but looks interesting: http://www.lafcpug.org/phorum/read.php?1,250276
It looks like he think that Rec. 709 encoding gamma means to correct the linearly encoded sources before they show up on a CRT-like display. In short version:
- A CRT has non-linear correlation between voltage and luminance (and LCDs try to simulate the same).
- Look, the linearly encoded image looks too dark on the CRT-like screen.
- Apply the magical Rec.709 curve and it is fine now (on the CRT-like display).
He also said this:
- Ask your graphics guy directly, "Hey, what gamma space are you working in?
- If he says "Rec. 709," send him a fruit basket, 'cause you're dealing with somebody who gets it.

It makes sense for me now. I think the "graphics guy" should use a Rec.709 calibrated display when he edits the linearly encoded materials. So, the display will show him the linearly encoded sources as they will show up on the CRT-like screens after they applied the Rec. 709 encoding, between the editing and the broadcast.

A content mastering engineer should use a Rec.709 calibrated display when she/he edits the source material. But both she/he and us should watch it on a CRT-like calibrated display after she/he applied the Rec.709 encoding curve on the contents.

The engineer with the Rec. 709 calibrated display saw the linearly encoded materials during the editing work as we see it on a CRT-like display after he finished his job with the Rec.709 encoding.

So, we should NOT apply an invert-Rec709_encoding_curve. It was a correction between the linearly encoded source and the CRT-like display.

The remaining questions:
- Are these kind of "graphics guys" are as rarely available that you should send him a fruit basket?
- What is the ambient light condition in their workplace? It can be some kind of "Rec.709 environment" which simulates a "usual living room" where people will watch their TVs. (But it doesn't make sense because it changes randomly. So I guess they work on a dark room.)
- What the hell is the "perfect CRT(-like) display" what the Rec. 709 authors assumed? Pure-power gamma 2.2 or 2.35?

I think I will send an E-mail to this guy tomorrow.

[6233638]

- What the hell is the "perfect CRT(-like) display" what the Rec. 709 authors assumed? Pure-power gamma 2.2 or 2.35?2.35 power. Poynton, EBU, ARIB, BBC, Pixar, Barco all say its what CRTs measure.

[SantinoSan]

Total AVISYNTH newb here. I am trying to use yCMS with MPC-HC(x64) and cannot figure out how to get rgb3dlut to run. I installed the latest version of AVISYNTH and have downloaded the proper filters, but am lost once I get there. Is there a guide to setup? I have searched high and low to find something. Does the filter get called from ffdshow? Should it show up in the ffdshow menu while playing a movie or does it show up as a shader in MPC...just a bit cluless right now.

Also, some more general questions, I assume this works in conjunction with ffdshow, if so, can it also be used with Mediaportal's internal player? I can easily set up MPC as an external player in Mediaportal, so no big deal, but I like the eamlessness of using the internal player.

Any help would be greatly appreciated.

Thanks,
Santino

[yesgrey]

I am trying to use yCMS with MPC-HC(x64) and cannot figure out how to get rgb3dlut to run.
You can't. If you want to use MPC-HC(x64) you would need avisynth x64, ffdshow x64 and rgb3dlut x64. rgb3dlut is only x86, so it will not work.

If you decide for MPC-HC x86, you would get better performance from madVR, but if you really want/need to use rgb3dlut let me know and I will tell you how.

[SantinoSan]

Thanks for the reply.

I have both MPC x64 & 86 on my PC as I knew madVR is only x86. I will not be using madVR, however as my PC will not play 1080P smoothly without DVXA, at least it didn't with madVR running.

So if I try to set this up, I need a little help getting the rgb3dlut running. I did find a bit more info about using avisynth within ffdshow, but am still unclear how to call the filter and use the values from yCMS. How about using t3dlut...is this easier to use or more compatible?

Thanks,
Santino

[janos666]

Thanks for the reply.
I will not be using madVR, however as my PC will not play 1080P smoothly without DVXA, at least it didn't with madVR running.


Did you try to set bilinear resizer for all resizer settings? Did you try to use some of the "trade quality for performance" settings?
You can also try the CUDA accelerated CoreAVC with an nv card (and update your VGA drivers).

My laptop is week too. But the 0.2x madVR builds run faster than EVR+t3dlut. (Of course, 1080p would be problematic, but I think it will be impossible with t3dlut as well. -> Here comes the CUDA idea which I never tested.)


2.35 power. Poynton, EBU, ARIB, BBC, Pixar, Barco all say its what CRTs measure.

Yes, I read the EBU document. But gamma 2.35 looks impossible with a usual LCD. (May be a very good 10+ bit LCD panel with rewritable 12+ bit hardware LUTs. But hey... This is my Home, I won't make money with this display, so I won't pay the extra money for a professional display.)
May be I should reconsider the small FullHD Plasma display idea. (But I want a display with 16:10 aspect ratio. :( )
I considered the Panasonic G20. Here is an assumption about it's characteristics: It looks like it had a little "black crush like" behavior: http://prohardver.hu/dl/cnt/2010-05/59914/pic/pana_tv_bekalibralva_a2.jpg, so it may won't lose the shadow details when calibrated to 2.35

[SantinoSan]

My PC specs are as follows:
Athlon +4800 dual core
2 gig ram
ATI 4550 video card
Windows 7 Ultimate x64

Should this play 1080P OK without DXVA?

I have no clue, but I could try to figure it out.

[janos666]

My PC specs are as follows:
Athlon +4800 dual core
2 gig ram
ATI 4550 video card
Windows 7 Ultimate x64

Should this play 1080P OK without DXVA?

I have no clue, but I could try to figure it out.

Try the CoreAVC codec (find a way to try it before you purcashe it :cool:), they said it is fater than FFDshow. (But it was years ago, both of them was improved...)
I don't know the Athlons, but a Core2 Dou should play it with relatively low clocks. But a notebook CPU, well... it can be slower.

[SantinoSan]

I took a look at the cpu usage and I don't think that is where the problem is. It clocks in around 60% when decoding AVC while it hovers around 30% for DXVA decoding. I get low frame rates between 10 and 20 with MadVR. I think if I can figure out the frame problem, I can use the 3dlut to correct my PJs colors. Any tips on where to look to troubleshoot from here? Using EVR custom plays the movies back flawlessly.

The audio plays back fine while the video stutters. Not sure if that is helpful or not.

[yesgrey]

I get low frame rates between 10 and 20 with MadVR. I think if I can figure out the frame problem, I can use the 3dlut to correct my PJs colors. Any tips on where to look to troubleshoot from here?
I think your limitation might be the video card...

Try setting all resampling settings in madVR to "Nearest neighbor" and disable dithering. If it works fine, then start by changing the resampling to bilinear.

[SantinoSan]

The GPU usage was never even registering when using madVR as opposed to when DXVA was active the GPU was at about 30%. I tried changing all the scaling and dithering and it made no difference at all. I played back a 1080p mpeg2 stream and the CPU was around 35% but the results were still the same. When I start a movie, I get about 5 to 10 seconds of smooth video, then it just chokes. On the mpeg2 stream, the fps was right on 24, but the video was still jerky.

If I can get on of the 3dlut scripts to work in ffdshow, then I think maybe that is the way to go.

Thanks,
Santino

[yesgrey]

When I start a movie, I get about 5 to 10 seconds of smooth video, then it just chokes.
Yes, it seems the video card is your limiting factor for using madVR... Let's try with rgb3dlut then.

Install rgb3dlut:
For this method to work you must have Avisynth installed on your computer.
Download ddcc and copy the "ddcc.dll" file into the Avisynth plugins directory - rgb3dlut is part of the ddcc pack.

Configuration File for yCMS:
Create a configurationFile for yCMS. rgb3dlut only works with 8 bit input / 8 bit output 3DLUT files, so, it should be something like this:
Input_Format HD YCbCr 8
Output_Format HD RGB_PC 8

If you need video levels, just change RGB_PC to RGB_Video. For sources other than HD, change accordingly (look in the manual).
You can also add any other customization to the file, just don't forget to keep the input and output bitdepths as 8.

Setting ffdshow:
Install ffdshow with Avisynth support.
In ffdshow "video decoder configuration", go to the Avisynth tab, verify that the YV12 Input colorspace is check and write the following:
ConvertYV12ToYUY2()
rgb3dlut(lutfile="your.file.3dlut")
On ffdshow's Output tab check RGB32.
If you are not using ffdshow for decoding the video, you should go to ffdshow's "Codecs" tab and set "Raw video" to YV12.

[SantinoSan]

OK. A few more questions. The avisynth "tab" is only available in the ffdshow video decoder menu. I assume I have to use the ffdshow video decoder filter in MPC-HC for the avisynth script to be called. Is this correct so far? If so I think I can stop now as the CPU using ffdshow to decode the video is too choppy to use. I drop frames too often for my taste. Only using DXVA gives me results smooth enough for me to care about proper color calibration.

Please let me know if I'm off in the wrong direction here. Also, you did mention that if I was using a different decoder...how can I di this while still calling the avisynth script.

Thanks for your help so far...sorry so many newb questions,
Santino

[yesgrey]

I assume I have to use the ffdshow video decoder filter in MPC-HC for the avisynth script to be called. Is this correct so far?
Yes.

If so I think I can stop now as the CPU using ffdshow to decode the video is too choppy to use.
Are you using ffdshow with multi-threading? on ffdshow's Codecs tab select ffdshow-mt for H.264/AVC decoder.

If this doesn't work good enough your only option for getting some color correction is by using the pixel shader method I worked on some time ago... Another option would be to use CoreAVC, by since you have an ATI you cannot use the CUDA for hardware acceleration...

Also, you did mention that if I was using a different decoder...how can I di this while still calling the avisynth script.
I've told you. You need to activate Raw video support on ffdshow. By default is disabled. With it enabled ffdshow is called as a postprocessing filter.

[SantinoSan]

Yes, unfortunately, ffdshow mt is already selected as the h264 decoder. After a bit more testing, even VC-1 is not smooth enough for my liking without dxva.

So maybe I misunderstand, but if I enable Raw Video support, can I then use ffdshow as a post processing filter, after using a DXVA decoder, to call rgb3dlut?

Any other options besides upgrading my PC?

Thanks,
Santino

[janos666]

When I start a movie, I get about 5 to 10 seconds of smooth video, then it just chokes. On the mpeg2 stream, the fps was right on 24, but the video was still jerky.

It sounds familiar. I had the same problem lately!
I reinstalled every playback related softwares and the VGA driver. It works well again.

So, I suggest you to uninstall your VGA driver (with a proper cleanup) and install the latest WHQL set.
Uninstall every video players and A/V codecs. Install a fresh MPC-HC (http://www.xvidvideo.ru/media-player-classic-home-cinema-x86-x64/) (not the last one, that is buggy), a fresh FFDShow (http://sourceforge.net/projects/ffdshow-tryout/files/) and the latest madVR from the neighboring tread.
Make sure the FFDShow installer set ffmpeg-mt (multithreaded) but you shouldn't use any filters/plugins. Disable every Transform Filters in MPC-HC (but leave the Source Filters ticked).
You should be fine now. :rolleyes: (But you should start with bilinear resizer, ect.)

[yesgrey]

So maybe I misunderstand, but if I enable Raw Video support, can I then use ffdshow as a post processing filter, after using a DXVA decoder, to call rgb3dlut?
Yes, but it would work only with CoreAVC that uses CUDA. With DXVA decoders it won't work, but for using CUDA you would need a NVidia card...

Any other options besides upgrading my PC?
Unfortunately, I think that's your only option...
A more economic solution might be buying a new graphics card from NVidia. That way you might be able to use both madVR and hardware decoding...

[janos666]

A little update on the gamma topic.

Today, I calibrated my display with a Rec.709 curve (with the effectively 10 bit/color VGA LUT). I got a relatively error free 8 bit grayscale (there is no noticeable tinting, banding, etc.) with a low but temporally acceptable contrast ratio. (I played with the sRGB mode now. The Standard mode may give me much better calibrated contrast ratio with this curve but this time I wanted to avoid any 3DLUT corrections, including the wide->Rec709 gamut as well. May be I will check that tomorrow.)

The uncorrected images (madVR TV levels without 3DLUTs) looks very bad! I can see everything behind the shadows. But this includes the heavy noise as well (not an x264 issue, these are full Blu-Ray AVCHD materials)! And the screen looks like an ink-economical ink-jet print on a plain toilet paper. The colors are washed out and I can't feel the depth of the objects. It is close to the state when you send out TV levels to a display with PC levels (except that the full black is deeper).

Just for curiosity, I made a 3DLUT with the Output_Transfer_Function 6 command and it doesn't look too bad. Of course, it has noticeable quality degradation after the cross-corrections but it reminds me to the gamma_curve 0 2.35 state (it is darker than the uncorrected image with gamma 2.2 display settings). But there are no black swathes. They are very noisy dark shadows now with some remained details (this is what I expected last time -> but they could be darker without the cross-correction way and better display contrast ratio...).


So, to sum it up. I start to believe that we need to calibrate our displays to pure power gamma 2.35 (and editor use Rec709 calibrated displays to edit the linear materials before the Rec709 encoding) but I also think that something is wrong with your current gamma correction method (or my measures, but they look good :rolleyes:).

How do you work with the measurement data when the gamma_curve is also applied? I think you were not so lazy but: do you always start with an invert-Rec709-encode and apply this gamma_curve compensation later? It would explain my black swatches. (Too many cross-corrections with lower effective calibration quality. -> I think I will suggest you something later.)

[dansrfe]

A couple of questions:

a) How and what do I use to calibrate my display and find the optimum values to match the primaries and white point.

b) Should the display be calibrated to HD standard then have NTSC, PAL, and sRGB converted to HD standard after calibration has been done?

c) I understand Gamma_Curve, Gamut_Measurements however I do not understand what Greyscale_Measurements exactly is.

d) Does RGB_PC output RGB32 at PC levels or RGB24 at PC levels?

[yesgrey]

How and what do I use to calibrate my display and find the optimum values to match the primaries and white point.
First I need to know if you have a meter for measuring your display. You didn't say it.

Does RGB_PC output RGB32 at PC levels or RGB24 at PC levels?
That's not related with any yCMS setting. It's defined by the application that uses the 3DLUT files. Usually the applications output RGB32, but some of them (rgb3dlut/t3dlut) might output RGB24 if you tell them to.

[dansrfe]

I don't have a meter to measure my display but I would be willing to buy one. Cost is not an issue as long as it's a reasonable price. Something that gives the most accurate results as per you opinion. Also I have one more question. Since I will be calibrating the 3DLUT files to my display, should I change any display settings prior to calibrating and changing values in yCMS? Will that produce a better output or what is your opinion on the best method to approach calibrating yCMS and calibrating the display settings itself in terms of order and how much to tweak on each?

[yesgrey]

Something that gives the most accurate results as per you opinion.
Sorry, but I cannot help you on this. I don't have much experience with meters, so any advice I could give you would be based solely on opinions from other people. Considering this, it would be preferable if you search and read a little about it. You could take a look at the HCFR project, which supports several meters. There are also several payware software display measurement/calibration solutions that include a meter, so probably a solution like that would be preferable...

what is your opinion on the best method to approach calibrating yCMS and calibrating the display settings itself in terms of order and how much to tweak on each?
That's not an easy question. Furthermore, it also would depend on the display and the settings available on it for calibration.

The simplest approach would be:
(1) Set all display settings to its defaults.
(2) Set Brightness and Contrast accurately on display.
(3) Measure display.
(4) Use the measurements with yCMS for getting all 3DLUTs you would need for all your viewing options.

Another approach would be first calibrating the display with all the settings available on it and then use yCMS for correcting any flaws that could not be fixed by the display.

I use the simplest approach, but my projector doesn't has many settings for calibration...

[janos666]

@dansrfe
If you have a display with normal gamut coverage (sRGB/Rec709), you should pick up a cheap colorimeter, like the EyeOne Display LT (it is the same hardware as the i1d2, the difference exists only in the bundled software's features) or a Spider 3 Pro.
For a wide-gamut display (and if you want more accurate white balance and saturation measurements), you should choose a spectrophotometer, like the ColorMunki (design or photo but not a create, that one is an i1d2 colorimeter with white case).
And I recommend the ArgyllCMS software with the DispCalGUI interface. It is the best calibration software which I ever tried and this is the only software which let you collect a lot of custom measurement data (like inputs for yCMS) easily and automatically.

[dansrfe]

@janos666

I found this: ColorMunki (http://www.bhphotovideo.com/c/product/550833-REG/X_Rite_CMUNPH_ColorMunki_Photo_Color_Management.html#features) at B&H.
I have a Panasonic Plasma 3D 1080p and an LG WLED 1080p laptop screen which both seem well calibrated after a few minor tweaks I had made a while back but I still want to make sure I get the best color reproduction so I will give ColorMunki a try. What exactly do ICC profiles do or work with? I says that it makes profiles for the display, projector, and RGB/CMYK printer but as per my understanding doesn't the calibration device only attach to and measure the display? I was under the impression that the calibration software calibrates the display to how images are "supposed" to print on good printers by default. Also when doing these calibrations shouldn't I calibrate to "PC.709" since both the plasma and LED use PC levels. If I do calibrate to PC.709 then will I have to convert NTSC, PAL, and sRGB inputs in yCMS to HD standard? If the ICC profile with adjustments can already made by discalGUI then why is there a need for yCMS 3DLUT usage? How would I factor in the GPU driver contrast/gamma/brightness settings? Do I just keep them default?

[yesgrey]

What exactly do ICC profiles do or work with?
The concept is similar to the 3DLUT idea. The problem is that they are only used if the software applications explicitly use them, and there is no video player that uses them. Only some professional software for photo editing use them.
The 3DLUT has the advantage of a higher bit depth (considering the dithering).

Also when doing these calibrations shouldn't I calibrate to "PC.709" since both the plasma and LED use PC levels.
If you use a meter you must calibrate for your measured results, if you don't, so why would you buy one?;)

How would I factor in the GPU driver contrast/gamma/brightness settings? Do I just keep them default?
Like I said. Default, then set brightness and contrast for accurate black/white level, and then measure.

[janos666]

@janos666

I found this: ColorMunki (http://www.bhphotovideo.com/c/product/550833-REG/X_Rite_CMUNPH_ColorMunki_Photo_Color_Management.html#features) at B&H.
I have a Panasonic Plasma 3D 1080p and an LG WLED 1080p laptop screen which both seem well calibrated after a few minor tweaks I had made a while back but I still want to make sure I get the best color reproduction so I will give ColorMunki a try. What exactly do ICC profiles do or work with? I says that it makes profiles for the display, projector, and RGB/CMYK printer but as per my understanding doesn't the calibration device only attach to and measure the display? I was under the impression that the calibration software calibrates the display to how images are "supposed" to print on good printers by default. Also when doing these calibrations shouldn't I calibrate to "PC.709" since both the plasma and LED use PC levels. If I do calibrate to PC.709 then will I have to convert NTSC, PAL, and sRGB inputs in yCMS to HD standard? If the ICC profile with adjustments can already made by discalGUI then why is there a need for yCMS 3DLUT usage? How would I factor in the GPU driver contrast/gamma/brightness settings? Do I just keep them default?

A lot of questions. :rolleyes:

Colorimeters can run into serious troubles with LED back-light LCDs as well (as with WCG-CCFL back-lights). And usual colorimeters theoretically work with usual Plasma displays (until they don't offer wide color gamut) but you can find some forum topics where plasma users have troubles.
So, yes. A ColorMunki is the right choice for you (, I think).

An ICC file will contain a remapped VGA LUT which corrects the display gamma and white balance; the 100% R,G,B color coordinates (relatively to D50 white); a simple and small 3DLUT. The last two can be used by color managed softwares for gamut correction (with interpolations). And it contains the average gamma as well (for different type of source materials).
There is no any video renderer which uses ICC files. But this is not a problem, yCMS works better without it because ICC is simplified.

So, you can correct only the gamma and the white balance with your VGA LUT. The gamut emulation has to be done by softwares (or by the display hardware itself). Here comes the yCMS software.
And madVR offers 8 bit + dithering, so you may want to use 3DLUTs for gamma and white balance corrections instead of the simple 8 bit VGA LUT. (Until you have a DeepColor compatible display and VGA card where the effective VGA LUT precision is 10+ bit/color. - Then you have to test and decide...)

But I think you shouldn't use the gamma correction right now. (Of course, you can try if you wish.) I think it is not good enough yet. And the current yCMS version doesn't support full white balance correction either.
So, my best guess now is to calibrate your display with DispCalGUI (VGA LUT in an ICC file) and use yCMS for gamut emulation (if it is needed).

There is no PC.709. TV and PC levels doesn't matter here. More preciously, you should always output PC levels from a VGA card (anything else is only an internal cross-conversion), so you have to do the calibration with PC settings. MadVR and yCMS will take care about the TV->PC correction with limited range sources.

Yes, you have to use different 3DLUTs for the different source standards. But madVR can select the right one depending on the source resolution and your madVR GUI settings (SD or HD and TV or PC, but they are universal "slots" when you use 3DLUTs - they can be anything, and they will be selected by these setting...).

A calibration will grant you a corrected output. If you have a calibrated display and a calibrated printer (and you used the correct calibration targets for both of them), then they will match.


--------------------


I calibrated my display with a pure-power gamma 2.35 today (with the 10bit VGA LUT).
There are no any black swatches at all. The difference is easily noticeable but it is much milder than yCMS's gamma correction between 2.2 and 2.35

But I really can't decide between 2.2 and 2.35 :confused:

Yes, EBU says 2.35 (but is talks about dim surround!), and a lot of documents say that 2.2 is the ""officially"" (averaged/)assumed CRT (compatible) gamma (for CRT-like non-CRT display, at least).

The DVI standard talks about gamma 2.2 (for digital displays, as a suggestion - they also mentions that this is a serious mess which can't be standardized by the given document).

EIZO suggests 2.2 for their CG displays as a basis (until you don't have any specific idea).

A lot of people use this value. The Rec709 has the same exponent value (after the linear "noise-hider" segment).

The only sources of this gamma 2.35 are measures from professional CRTs but we are not absolutely sure about how do they use those displays. They can be used on different environment conditions and/or can be calibrated with display/VGA LUTs. (And this EBU document which talks about controlled dim surround assumes a D65 light source behind the display...)

My current guess is gamma 2.2 (but this can be affected by my past with gamma 2.2 displays...)

But I am really sure that we shouldn't do a full Rec709 inversion. :rolleyes:

Yes, it can look good with your projector and the current yCMS behavior. But I also think that the current yCMS behavior is really far from how it should handle this gamma correction thing.
I tried to do the same things with ArgyllCMS and yCMS and the first one always gave me reasonable results while yCMS produced strange things (even if it looked nice for the first time). And I could do verifications on ArgyllCMS's job, the gamma correction was nearly perfect with it, so I have to assume that your method is erroneous now. (But I can't do measures on H264 video patterns right now.)

[6233638]

Can you list a source for 2.2 gamma? I dont know of any spec that uses it.
sRGB monitors use the sRGB TRC which is close to 2.2 but not 2.2 so many desktop displays are calibrated to that/recommended it. sRGB has nothing to do with video though. CRT monitors often had an sRGB mode that changed their response to better match the sRGB TRC.

I would use 2.2 for desktop PC use/image editing/gaming, but 2.35 for video.

[janos666]

Can you list a source for 2.2 gamma? I dont know of any spec that uses it.
sRGB monitors use the sRGB TRC which is close to 2.2 but not 2.2 so many desktop displays are calibrated to that/recommended it. sRGB has nothing to do with video though. CRT monitors often had an sRGB mode that changed their response to better match the sRGB TRC.

I would use 2.2 for desktop PC use/image editing/gaming, but 2.35 for video.

EIZO FAQ (http://www.eizo.be/support/faq.html?cmd=search&cHash=4f1b10c1e1) - Type in "gamma", hit enter, click on the answer.
PhotoRGB, AdobeRGB, sRGB are based on a Gamma characteristic of 2,2.
Our recommendation for the Flexscan Monitors is Gamma = 2,2 and Whitepoint=6500
(We use decimal , instead of decimal . in Europe) sRGB displays are theoretically compatible with Rec709 materials. The Rec709 encoding curve uses the same exponent value after the noise-hider linear segment (1/0.45~2.2).

Ok, these are PC displays but this is the same story. PC was also born with analogue (monochrome) CRT displays. The old VGA cards didn't use LUT and new ones have linear LUT by default. Software based Color Management is not new but it isn't widely used today either. So, PC displays should also follow the legacy CRT compatibility.

DVI 1.0 Specification (http://www.ddwg.org/lib/dvi_10.pdf) - Page 15 / 2.2.7, end of the first paragraph. (This is a copy protected document, so I won't copy-paste the lines.)

A lot of documents talk about gamma 2.2. I think it is the most widely used nominal value. It can be a too big rounding but it doesn't matter when everybody use this. (If everybody else follow a false number then you should do the same and it won't be a real problem.)
Old and new professional CRTs may lay closer to gamma 2.35 but as we know, they can also calibrate their displays with LUTs (with various and rarely known targets).

Can you give me other source which mentions 2.35?
I found it only in the EBU document but it is clearly stated that they recommend dim surround. The original EBU document didn't specify these surround conditions but external sources talk about D65 light source behind the display and white walls: avsforum - D65 Video Bias Lighting thread (http://www.avsforum.com/avs-vb/showthread.php?t=1162578)

I don't have a D65 light source or white walls behind my display. May be I should but this is another question.


sRGB is very close to gamma 2.2. It has a small linear segment but it averages around the gamma 2.2 curve. This is not a big difference and it is a correction for brighter environment conditions. So, I think a pure-power gamma 2.2 instead of the real sRGB curve is theoretically perfect in dark rooms. (And professional PC displays are meant to be in dark rooms. So, that is why EIZO recommends pure-power 2.2)


I also showed you a graph where you could see that a plasma HDTV measures around gamma 2.2 in it's factory calibrated THX display mode.
Panasonic G20 in THX mode: uncalibrated measures (http://prohardver.hu/dl/cnt/2010-05/59914/pic/pana_tv_kalib_thx.jpg), calibration curves (http://prohardver.hu/dl/cnt/2010-05/59914/pic/pana_tv_bekalibralva_a2.jpg). So, I think they thought THX recommends gamma 2.2 (Ok, I agree, it is not a nice way to measure a HDTV. I would measure it in much different ways. They also used a colorimeter on a wide-gamut display, which is not correct in emulated gamut modes either.)

[6233638]

EIZO FAQ (http://www.eizo.be/support/faq.html?cmd=search&cHash=4f1b10c1e1) - Type in "gamma", hit enter, click on the answer.They're mistaken.
ProPhoto RGB uses 1.8 Gamma.
sRGB uses the sRGB curve.
Adobe RGB uses 2.2 gamma
Melissa RGB was created specifically because ProPhoto is 1.8 gamma and uses the ProPhoto primaries with sRGB TRC. Its what Adobe Lightroom uses.

In most cases 2.2 is close enough to use instead of the sRGB TRC, especially because most displays are not accurate enough for it.

All your sources are talking about PC displays. I have no argument there. PC displays should use 2.2 for general PC use and graphics work.


The THX specification requires a minimum of 2.2 gamma from the display. It does not state that 2.2 is ideal. Most displays use 2.2 because its hard to use higher than that without problems on low contrast flat panels.

EBU has several documents mentioning 2.35 gamma. Tech 3320/3321 and more.
ARIB TR-B28 has measurements from CRTs
Poynton has several articles stating gamma should be 2.35/2.4 (assume 2.4 to be rounded)
Barco specifies designs its monitors to be 2.35 from the factory.
Someone here mentioned pixar uses 2.4 with their films earlier.

Under ideal conditions, you want 2.35 gamma. It is the target you should be aiming for with video.

In non-ideal conditions, gamma is probably the first thing that you should compromise on. 2.35 will look too dark in a bright room for example.

[janos666]

All your sources are talking about PC displays. I have no argument there. PC displays should use 2.2 for general PC use and graphics work.

Yes, but PC was born with analogue CRTs as well as the TV, so PC has to keep the legacy CRT compatibility just as much as TV.

Most displays use 2.2 because its hard to use higher than that without problems on low contrast flat panels.

Contrast ratio is not everything when you use black offset. This is more like an LCD native TRC and not a contrast ratio limitation, I think.
And my previous example was a plasma display with high contrast ratio.


What is the assumed surrounding light condition for those displays? Dark "batcave" or dim D65 light source in a white room?

Under ideal conditions, you want 2.35 gamma. It is the target you should be aiming for with video.

I think I can believe that most of the film studios work with this number and the PC side was more indulgent.

[6233638]

Yes, but PC was born with analogue CRTs as well as the TV, so PC has to keep the legacy CRT compatibility just as much as TV.No, sRGB has been used on PCs since '96. sRGB is the standard and has a defined viewing TRC. (close to 2.2)

Contrast ratio is not everything when you use black offset. This is more like an LCD native TRC and not a contrast ratio limitation, I think.LCD native TRC is an S-curve gamma that needs correction to even get close to being correct.

[janos666]

No, sRGB has been used on PCs since '96. sRGB is the standard and has a defined viewing TRC. (close to 2.2)

Ok, but why sRGB curve averages around 2.2? I think they also tried to keep the compatibility with legacy CRTs (as much as they could without further harm). But ok, let's forget about it.

LCD native TRC is an S-curve gamma that needs correction to even get close to being correct.

I can't see the problem here. I said this is not a contrast ratio limitation but a native LCD TRC limitation. I wanted to imply that 2.2 is an easier target from that S-like curve. (Most of the cheaper LCDs would produce even flatter curves by default. And yes, you will pay in contrast ratio if you aim higher gamma values. So, yes, it is easier to sacrifice with higher native contrast ratio. But the source of this problem is the S curve, not the contrast ratio itself. It is not a real problem with black offset.)

[janos666]

Question:
Does v1.7 support separate R G B values for the Grayscale_Measurements command again?
I remember that you introduced this command with full white balance optimization but you reduced it's functionality to a simple gamma correction. (For debugging purposes, I think.)
There was no any note in the changelog about this, so I assumed that it is still unavailable.
I just noticed that it currently accepts three values. Does it use them to correct the white balance or does it make an averaged number of them?
Does it take care about the white balance? (If it does, I would test it.)

[yesgrey]

There was no any note in the changelog about this
v1.4 - 2010/06/25
- Re-added support of different measures for R,G,B on Grayscale_Measurements.

[yesgrey]

Does it use them to correct the white balance or does it make an averaged number of them?
To correct the white balance. What would be the use of an average number?...

[janos666]

v1.4 - 2010/06/25
- Re-added support of different measures for R,G,B on Grayscale_Measurements.


Sorry, I missed it. :(

But, how can I produce these values?
I have XYZ values from 256 IREs. How should I convert them into RGB values?
The XYZ values are absolute coordinates and the RGB values are relative coordinates. Are the produced values should be relative to D50, D65, or to the measured white? And it looks like it also depends on the working color space. So, which is the reference color space?
It looks like a complicated calculation (http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html), so I can't figure it out alone. (That is why I asked you earlier that you should accept XYZ sensor data. You know the specifics...)

I have no idea how HCRF works (but the reference white is D65 and the reference gamut is Rec709 by default - Does it use these references during the RGB conversion?) and what are your assumptions about the produced RGB values.

[yesgrey]

But, how can I produce these values?
I have XYZ values from 256 IREs...

That is why I asked you earlier that you should accept XYZ sensor data.
I've confirmed that HCFR also outputs XYZ and xyY values, so I will try to include support for both formats on next version.

[tschi]

Hi,
I made some tests with yCMS 1.7
Here my calibration result without yCMS :
http://a.imageshack.us/img291/9238/250810woycms.png
Using yCMS with default gamma curve :
http://a.imageshack.us/img228/8215/250810wycms.png
Using yCMS with Gamma_Curve 1.0 2.35 :
http://a.imageshack.us/img529/5996/250810wycmsgammacurve23.png
HD - PC ycms files :
http://tinypaste.com/6999c
My colorHCFR files :
http://www.multiupload.com/BEBH4HMSZL

IMHO, grayscale rvb level correction are very good at low level :)
But my Gamut is not so good when I use yCMS :confused:
The distance to CIExy position for green is the worst (0.021 vs 0.029) Red is quite very good (0.020 vs 0.006) and blue is intermediary (0.019 vs 0.023).
Is there any way to correct that ? :confused:
I tried to change Gamut_Measurements for green position without any good result (may be just instrument error level)
I guess it comes from my tv gamut (sharp ldc 37XD1E) but is it possible to make average between red correction / blue and green or it's doesn't make sense ?

[tschi]

I made some others tests and always the same result:(
but now I understand what is happening :)
yCMS try to adjust gamut to the reference using xy position but the reference are out of my tv gamut :
http://a.imageshack.us/img822/9329/gamut.png
So in my case, may be the best things would be to compute a target which minimize the distance from the reference instead of trying to adjust to xy reference postion.

[yesgrey]

So in my case, may be the best things would be to compute a target which minimize the distance from the reference instead of trying to adjust to xy reference postion.
Yes, that's the problem. Currently yCMS is not using the full gamut available on a display with situations similar to yours. I will try to find a solution for it...