yCMS - Color Management System [Archive]

yesgrey

22nd May 2010, 22:33

How to use yCMS:
(1)Read the detailed instructions inside the Manual and create 3DLUT file(s) that fit your needs.
(2)Use your 3DLUT file(s) with madVR, t3dlut or rgb3dlut, the software options which support 3DLUT files. Below are instructions on how to use them.

How to use madVR v0.66+:
See instructions on this (http://forum.doom9.org/showpost.php?p=1510363&postcount=637) post.

How to use madVR up to v0.61:
madVR is a DirectShow video renderer created by madshi. If you don't know what madVR is or how to set it up and use it go here (http://forum.doom9.org/showthread.php?t=146228).

madVR supports four different 3DLUT files. Two for watching HD media (PC and video levels) and two for watching SD media (PC and video levels). The selection between HD and SD files is automatic, according to media resolution. For "height > 576" or "width > 1024" it uses the HD files, otherwise it uses the SD files. You can manually choose between PC and video levels in madVR's settings dialog.

You should create a 3DLUT file for each of the available options. To make madVR use them, just copy them into madVR's installation directory (where madVR.ax is contained) and name them properly. The file names expected by madVR are:
HD media with PC levels: "hd - pc.3dlut"
HD media with video levels: "hd - video.3dlut"
SD media with PC levels: "sd - pc.3dlut"
SD media with video levels: "sd - video.3dlut"

After creating, copying and renaming the 3DLUT files simply start your media player and check the "Use 3DLUT" checkbox in madVR's settings dialog.

note: madVR only supports Y'CbCr 8 bit input / R'G'B' 16 bit output 3DLUT files. The output is dithered to screen bit depth by madVR.

How to use t3dlut/rgb3dlut:
t3dlut/rgb3dlut are Avisynth plugins created by tritical. If you don't know what they are or how to set them up and use them go here (http://bengal.missouri.edu/~kes25c). rgb3dlut is included in ddcc.

You can use t3dlut/rgb3dlut for watching your media or for processing your video files using Avisynth. t3dlut supersedes rgb3dlut by allowing any combination of RGB and YCbCr input/output, while rgb3dlut only supports RGB output. rgb3dlut is faster because it has some assembly optimizations, so you will have to decide which would fit better your needs. Using t3dlut with a 3DLUT file should give you slightly more accurate colorspace conversions than using ColorMatrix.

Due to the high number of possible configurations no example is offered at this time. I will add examples when requested.

note: t3dlut supports 8 bit input / 8 or 16 bit output 3DLUT files, and all of the video formats combinations available in yCMS. When using 16 bit output 3DLUT files, the output is automatically dithered to 8 bit by t3dlut.

Example using rgb3dlut with ffdshow: Instructions here (http://forum.doom9.org/showthread.php?p=1426031#post1426031).

yesgrey

22nd May 2010, 22:34

Calibration example:
Here are the results after calibrating my projector (JVC M15) using yCMS and madVR.

I started by measuring my projector primaries and white point at 75 IRE. For that I ran a video with 75 IRE R,G,B color fields, unchecking the 3DLUT option in madVR and selecting PC levels (my projector only accepts this):
Red: x = 0.6662; y = 0.3280
Green: x = 0.2654; y = 0.6818
Blue: x = 0.1425; y = 0.0551
White: x = 0.3109; y = 0.3324

Then, I created a yCMS configuration file for it:
# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

# Gamut correction
Gamut_Measurements 0.6662 0.3280 0.2654 0.6818 0.1425 0.0551 0.3109 0.3324

Here are the results only with Gamut correction:
11197
In the picture, the HD color gamut (BT.709) is the black triangle, and my projector's color gamut is the white triangle.
After using gamut correction the results are slightly better. The green primary is nearer to the HD green primary, but the red and blue primaries were not corrected at all.

I then measured my display's grayscale response (gamma curve):
11196
As you can see, it's not very nice...:(

I tried again, but this time including gamma correction by using my display's grayscale response:
# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

# Gamut correction
Gamut_Measurements 0.6662 0.3280 0.2654 0.6818 0.1425 0.0551 0.3109 0.3324

# Gamma correction
Grayscale_Measurements
30.0 6.29
40.0 11.82
50.0 20.12
60.0 30.89
70.0 44.31
80.0 62.52
90.0 83.82
100.0 100.00

Here are the results with both Gamut and Gamma corrections:
11198
As you can see in the picture, all primaries are in the correct positions now, over the HD primaries.:cool:

Thunderbolt8

23rd May 2010, 02:10

will your version of the 3d lut be automatically included in madvr? if not, is there any reason why I should or shouldnt get it when I just want to watch blu-rays via my PC & hdmi connection to a tv? are there any advantages or disadvantages compared to when I don't use your version?

madshi

23rd May 2010, 09:03

Congrats to yesgrey for (finally :)) releasing yCMS!

will your version of the 3d lut be automatically included in madvr?
Our plan is that a future madVR version will no longer include cr3dlut/yCMS by default, but instead madVR will automatically download and "install" yCMS, when you ask madVR to use 3dlut files.

if not, is there any reason why I should or shouldnt get it when I just want to watch blu-rays via my PC & hdmi connection to a tv? are there any advantages or disadvantages compared to when I don't use your version?
If you use 3dlut files with madVR, then you should get rid of cr3dlut and use yCMS instead. That's very simple.

Now if you're asking whether you should or should not use 3dlut files, that's a more complicated question. Let me give you a list of advantages and disadvantages of using 3dlut files vs. not using them in madVR:

advantages:
(1) yCMS can make your display show a perfect gamma response
(2) yCMS can correct the gamut/primaries of your display (color management system)
(3) when watching SD content, yCMS can convert the SD gamut/primaries to HD
(4) madVR needs to do less math (faster performance?)

disadvantages:
(1) ever so slightly higher loading times
(2) higher memory usage on your GPU
(3) madVR needs to do more GPU memory accesses (slower performance?)

In order to use advantages (1) and (2), you will need to have a meter (e.g. Spyder3 or Chroma5 etc) and a calibration software (e.g. HCFR or Calman).

cyberbeing

23rd May 2010, 10:16

What exactly is yCMS doing when you input values for Grayscale_Measurements?

When I use it, it greatly brightens up the picture and reduces overall contrast considerably. Blacks turn gray. Whites get slightly crushed. It's like a light gray film gets placed over the video.

http://img218.imageshack.us/img218/6271/nolutpc.th.png (http://img218.imageshack.us/img218/6271/nolutpc.png)http://img97.imageshack.us/img97/2900/hdpc.th.png (http://img97.imageshack.us/img97/2900/hdpc.png)http://img80.imageshack.us/img80/7955/hdpcirew.th.png (http://img80.imageshack.us/img80/7955/hdpcirew.png)
From left to right.
| madVR TV->PC | yCMS LUT TV->PC | yCMS LUT with IRE TV->PC |
Funnily enough, yCMS LUT /w IRE 16-235 -> 0-255 makes what should be a 0 black, brighter than yCMS LUT 0-255 -> 0-255 (seen below)...

http://img297.imageshack.us/img297/2169/noluttv.th.png (http://img297.imageshack.us/img297/2169/noluttv.png)http://img245.imageshack.us/img245/7381/hdtv.th.png (http://img245.imageshack.us/img245/7381/hdtv.png)http://img375.imageshack.us/img375/705/hdtvire.th.png (http://img375.imageshack.us/img375/705/hdtvire.png)
From left to right.
| madVR PC->PC | yCMS LUT PC->PC | yCMS LUT with IRE PC->PC |

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

# Grayscale IRE Measurements
Grayscale_Measurements
10 0.486085 0.472363 0.497613
20 2.855507 2.751755 2.748106
30 7.040504 6.968139 7.044012
40 13.197106 13.020103 13.015621
50 21.422743 21.428576 21.564960
60 31.921806 31.852612 31.998531
70 45.422878 45.317829 45.406380
80 60.435123 60.174709 60.314659
90 78.802399 78.381996 78.620575
100 97.811592 98.124657 98.652870

# Display Gamut Measurements
Gamut_Measurements 0.626 0.343 0.294 0.607 0.149 0.078 0.3127 0.3290

The above is what I'm using with yCMS. How can I use the new IRE function and keep my Blacks, Black?

FoLLgoTT

23rd May 2010, 10:36

@yesgrey
Good work! :)

Would it be possible to input multiple gamut measurements? Right now we measure primaries/secondaries at 75% or 100%. Like calibrating greyscale there should be the possibility to input primary/secondary measurements for different IRE levels (e.g. in 10 IRE steps). I think this would higher the accuracy of calibration.

Another question: in which color space do you interpolate the colors?

FoLLgoTT

23rd May 2010, 10:45

Ah, another question: can luma (Y) of primaries/secondaries be corrected by yCMS? I can only see x and y in the manual. But a full gamut correction also includes Y.

pankov

23rd May 2010, 11:05

yesgrey,
I've just looked over the madVR thread and I can confirm that the selection of SD or HD luts is done not only based on the height but also on the width of the video - HD = width > 1024 or height > 576.
It will be nice if you correct the definition in your second post

janos666

23rd May 2010, 14:28

I have the same problem what cyberbeing described.

Here is my input file built with copy-pasteing HCFR 2.1 measurements:

# Source video format
Input_Format HD YCbCr 8

#3DLUT output format
Output_Format HD RGB_PC 16

# Gamut correction - measured native x;y coordinates
Gamut_Measurements 0.657073 0.329413 0.231911 0.690324 0.140940 0.090552 0.311880 0.329555

#Gamma correction - measured grayscale luminance Y;Z values
Grayscale_Measurements
10 1.469370 1.549970 1.633230
20 4.510128 4.779058 5.217576
30 9.946090 10.541579 11.273838
40 18.012747 18.977659 20.425848
50 28.926823 30.672146 32.918686
60 42.545696 44.938530 48.570366
70 60.392231 63.847328 69.020111
80 80.578819 85.209976 92.178696
90 105.731606 111.789406 121.205627
100 134.328751 141.941650 154.436478

(I know, it looks strange.)

The result is a brightened image with low contrast feeling.

I also tried to use the videoStandard preset (I calibrated my monitor with sRGB curve):
Output_Transfer_Function 0 0
Output_Transfer_Function 1 0
It is much better than it was with cr3dlut but it is still noisy.
I could not see it from normal viewing distance but I had the "something isn't right" feeling, so I lean closer to the display and it is clearly visible. (There is a lot of noise on dark areas.)

I made some screenshots with Output_Transfer_Function 0 0 enabled/disabled:
Sometimes I can see more geometry details with slightly less color accuracy: 01 (http://img12.tar.hu/janos666/img/76125895.png) - 02 (http://img12.tar.hu/janos666/img/76125896.png) ; 11 (http://img12.tar.hu/janos666/img/76125728.png) - 12 (http://img12.tar.hu/janos666/img/76125893.png)
But sometimes it causes some strange "sour cream" look: 21 (http://img12.tar.hu/janos666/img/76126042.png) - 22 (http://img12.tar.hu/janos666/img/76126043.png) ; 31 (http://img12.tar.hu/janos666/img/76128065.png) - 32 (http://img12.tar.hu/janos666/img/76128066.png)

I think it works well with SD sources but still useless with HD materials. The image is too bright and there is still too much quality loss. (I didn't noticed this with PAL DVDs but that was only a quick test, I do not watch them anymore...) After all, we may need that 10 bit output (and I need a new display then...).

cyberlolo

23rd May 2010, 19:53

I only have one question: why do you offer two different options for setting the chromaticity coordinates of the primaries and the white point? I mean, we can set it with the option:

Gamut_Measurements redX redY greenX greenY blueX blueY whiteX whiteY

and also, we can set it with:

Output_Primaries redX redY greenX greenY blueX blueY whiteX whiteY

What's the difference(s) between them?

Thanks for your great work. Now I can get rid of ffdshow's levels filter. Finally!!!

:thanks:

madshi

23rd May 2010, 21:01

I'll let yesgrey answer most of the questions, because he can do that much better than me, but I know the answer to some questions, at least.

It is much better than it was with cr3dlut but it is still noisy.
I could not see it from normal viewing distance but I had the "something isn't right" feeling, so I lean closer to the display and it is clearly visible. (There is a lot of noise on dark areas.)
Can you post a screenshot of a frame where you see so much noise in dark areas? Please also post the same frame without yCMS processing, so that we can compare. Thanks.

I only have one question: why do you offer two different options for setting the chromaticity coordinates of the primaries and the white point?
The commands serve different purposes. If you read the manual from top to bottom, the "mandatory" commands are explained first, then the "optional" commands, then the "calibration" commands. That's really all you should care about.

The remaining commands under the section "standards definition" are mainly meant to be used by people who want to convert a video from one standard/format to another. E.g. if you want to reencode video by upscaling SD to HD, you should also modify the primaries. The "Input_Primaries" should then be PAL or NTSC and the "Output_Primaries" should be HD. When reencoding video, you do NOT want to measure your display and use calibration commands. You want to define standard conversion parameters instead.

"Gamut_Measurements" is for display calibration during media playback. This command only supports measured coordinates.

"Output_Primaries" is for special purposes like e.g. reencoding video. This command mainly supports shortcuts to the well knowns standards (e.g. "0" for "HD"). But it also supports custom coordinates, in case a reencoding shall be done to a custom format, not directly supported by yCMS through a shortcut.

cyberlolo

23rd May 2010, 21:45

The commands serve different purposes. If you read the manual from top to bottom, the "mandatory" commands are explained first, then the "optional" commands, then the "calibration" commands. That's really all you should care about.

The remaining commands under the section "standards definition" are mainly meant to be used by people who want to convert a video from one standard/format to another. E.g. if you want to reencode video by upscaling SD to HD, you should also modify the primaries. The "Input_Primaries" should then be PAL or NTSC and the "Output_Primaries" should be HD. When reencoding video, you do NOT want to measure your display and use calibration commands. You want to define standard conversion parameters instead.

"Gamut_Measurements" is for display calibration during media playback. This command only supports measured coordinates.

"Output_Primaries" is for special purposes like e.g. reencoding video. This command mainly supports shortcuts to the well knowns standards (e.g. "0" for "HD"). But it also supports custom coordinates, in case a reencoding shall be done to a custom format, not directly supported by yCMS through a shortcut.

So, if I understood it correctly: for HD sources (input and output formats will be the same), I can use the "Gamut_Measurements" command to set the measured coordinates of my display. But for SD sources, if I want them to be reencoded to HD (which I do), it's better not using that command, and set input_format to NTSC/PAL and output_format to HD. Is this right?

cyberbeing

23rd May 2010, 22:05

#Gamma correction - measured grayscale luminance Y;Z values

According to the manual it should be | Red Luminance | Blue Luminance | Green Luminance | in the three IRE value columns. You shouldn't be putting X or Z values there unless I'm misunderstanding something.

Grayscale_Measurements
10 1.469370 1.549970 1.633230
From your example, 1.469370 should be Red Luminance, 1.549970 should be Green Luminance, and 1.633230 should be Blue Luminance. If you have a good display, all three should have near identical values with very little deviance.

Optionally you can also just list a single value (only using the first column) for overall Gray Luminance at a given IRE.

@yesgrey
Could the overly bright problem be because you aren't applying any sort of Black Point Compensation with yCMS?

I've also noticed yCMS only allows for 10 IRE values, but it would be nice if you could make it 11 (increments of 10 + zero) or even 21 (increments of 5 + zero), so you could have a value for 0 IRE to represent your Black Point.

yesgrey

23rd May 2010, 23:14

Congrats to yesgrey for (finally :)) releasing yCMS!
Thanks.:)

are there any advantages or disadvantages compared to when I don't use your version?

advantages:
(1) yCMS can make your display show a perfect gamma response
(2) yCMS can correct the gamut/primaries of your display (color management system)
(3) when watching SD content, yCMS can convert the SD gamut/primaries to HD
(4) madVR needs to do less math (faster performance?)

I would like to correct (2):
yCMS can overcome the incorrect gamut/primaries of your display and let you watch the colors as accurately as possible. If your display's gamut is wider than the source video gamut (if it contains entirely the source video gamut) all colors are shown accuratelly, otherwise the colors that lay outside the display's gamut would be clipped.

note: madshi answer was not wrong in a user's point of view, because it appears that the display's gamut/primaries are corrected by yCMS, but in reality they aren't. That could be done only within the display, and yCMS is external to it.

To (3) I would like to add:
(3) when watching SD content, yCMS can convert the SD gamut/primaries to HD, which should be done if you have a HD display.

janos666

23rd May 2010, 23:15

According to the manual it should be | Red Luminance | Blue Luminance | Green Luminance | in the three IRE value columns. You shouldn't be putting X or Z values there unless I'm misunderstanding something.

Yes, it was my mistake. :rolleyes: I wrote that note because I wasn't sure when I have tried to use this new software at the first time.
I already figured it out that I should use the RGB values from HCFR. And yes, they are nearly identical values and the 100% IRE is close to my calibration target luminance. :cool:

But the problem is still exist with the correct matrix. The image is too bright and it has low contrast...

And I would ask the same thing: I want to add 11 IREs...

Can you post a screenshot of a frame where you see so much noise in dark areas? Please also post the same frame without yCMS processing, so that we can compare. Thanks.

Yes. I will play more with the settings first to make sure it is not my fault (like poor movie quality, ect.) and I will make some screenshots.
But you can take a look at my actual screenshots above. They meant to represent the loss in color quality but you may see some strange on dark areas.
The main problem there that the overall image looks too bright and this brightening results in washed-out colors. (Ok, it is not a very serious mess -as it was with cr3dlut- but I can easily notice it on a S-PVA display...)

PS: I almost forgot to say thanks for your work. Aside from my continuous "problem reports" I appraise it. So, may be it isn't perfect but better than anything else which I can use now...

yesgrey

24th May 2010, 00:26

What exactly is yCMS doing when you input values for Grayscale_Measurements?
It removes the studio gamma encoding and then encodes using the inverse function of the display.

The above is what I'm using with yCMS. How can I use the new IRE function and keep my Blacks, Black?
I have the same problem what cyberbeing described.
Investigating...

Good work! :)
Would it be possible to input multiple gamut measurements?
Can luma (Y) of primaries/secondaries be corrected by yCMS?

Thanks.:)
Both are on the ToDo list.
Though, don't forget that in the second a perfect Y might run against a perfect xy, so it might ends up as an optional setting.

in which color space do you interpolate the colors?
Sorry, but i didn't understand your question. What did you mean with "interpolate colors"?

It will be nice if you correct the definition in your second post
Done. Thanks.

It is much better than it was with cr3dlut but it is still noisy.
After all, we may need that 10 bit output (and I need a new display then...).
Yes, I know it's not perfect yet, but I preferred to release yCMS now and keep working on it. It should improve in future versions. And no, we don't need the 10 bit output...

I only have one question: why do you offer two different options for setting the chromaticity coordinates of the primaries and the white point?

What's the difference(s) between them?

madshi answered it really well. I'll just add that the Gamut_Measurements command was created also having in mind the gamut correction for multiple saturations (not yet supported), and that would not fit in the Output_Primaries command.
With only one saturation allowed there is an overlapping between the two commands, but we decided to still introduce this command now because it's more user friendly than the Output_Primaries. A big part of the users would not need (or dare :D) to go past the Warning, so I must say that you are one of the braves...;)

So, if I understood it correctly: for HD sources (input and output formats will be the same), I can use the "Gamut_Measurements" command to set the measured coordinates of my display. But for SD sources, if I want them to be reencoded to HD (which I do), it's better not using that command, and set input_format to NTSC/PAL and output_format to HD. Is this right?
No.
The "Gamut_Measurements" command should always be used when the display's coordinates are measured, no matter what the source is. The source should be reflected only in the Input commands, and in none of the output commands. The commands relative to measures are all output commands, because you are measuring the output (display).

janos666

24th May 2010, 01:49

Can you post a screenshot of a frame where you see so much noise in dark areas.

I made some screenshots from different movies and different type of scenes to show all my concerns.
I made a 3dlut with these settings:
Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Output_Transfer_Function 0 0
And I used madVR with these settings:
[scaling settings]
luma upsampler=Spline64 luma downsampler=Spline64 chroma resampler=Spline64
[output settings]
video levels=0 use 3dlut=1
[trade quality for performance]
don't use dithering=0 use 10bit luma buffer=0 use 10bit chroma buffer=0 disable anti-tearing fix=0

I changed only this value through the CP:
use 3dlut=0

I take these from a re-encoded 1080p source (x264_L4.1 @ 7971 kbps) to represent how this brightening boost the perception of the noise: 01 (http://img12.tar.hu/janos666/img/76143352.png) - 02 (http://img12.tar.hu/janos666/img/76143353.png) ; 11 (http://img12.tar.hu/janos666/img/76143354.png) - 12 (http://img12.tar.hu/janos666/img/76143355.png)

I take these from a real Blu-Ray source (AVC_L4.1 @ 39.2 Mbps) to represent how this option kills the color detail: 21 (http://img12.tar.hu/janos666/img/76143634.png) - 22 (http://img12.tar.hu/janos666/img/76143635.png)

I take these from a re-encoded 1080p source (x264_L4.1 @ 8706 kbps) to show that image is sometimes too bright: 31 (http://img12.tar.hu/janos666/img/76143356.png) - 32 (http://img12.tar.hu/janos666/img/76143357.png)

And these comes from the Blu-Ray again to show them all (too bright scene with noisy dark spots and washed-out colors...): 41 (http://img12.tar.hu/janos666/img/76143497.png) - 42 (http://img12.tar.hu/janos666/img/76143498.png)

And here is the result of these new settings: 51 (http://img12.tar.hu/janos666/img/76144446.png) - 52 (http://img12.tar.hu/janos666/img/76144447.png)
Grayscale_Measurements
10 1.564805 1.551411 1.491997
20 4.668003 4.810841 4.791349
30 10.406371 10.604137 10.320132
40 19.016638 18.991844 18.722298
50 30.179890 30.871260 30.149662
60 44.580005 45.085168 44.541965
70 63.151944 64.109925 63.294323
80 84.184549 85.582548 84.539725
90 110.365791 112.272175 111.200465
100 140.120883 142.500616 141.767822
(The calibration targets were sRGB curve, ~140 cd/m^2 and D65 WP.)

madshi

24th May 2010, 07:44

So, if I understood it correctly: for HD sources (input and output formats will be the same), I can use the "Gamut_Measurements" command to set the measured coordinates of my display. But for SD sources, if I want them to be reencoded to HD (which I do), it's better not using that command, and set input_format to NTSC/PAL and output_format to HD. Is this right?
No, that's wrong. As I said in my previous comment, you should simply forget all commands in the "defining standards" section. They are for people who want to reencode (not play/watch) videos, e.g. Blu-Ray -> x264 MKV.

All commands you'll ever need for madVR and video playback are in the first 3 sections of the manual (mandatory, optional, calibration). Please simple *forget* the commands in the "defining standards" section.

Yes, I know it's not perfect yet, but I preferred to release yCMS now and keep working on it. It should improve in future versions. And no, we don't need the 10 bit output...
So you're aware of a noise problem in dark areas and there's hope for an improvement?

I made some screenshots from different movies and different type of scenes to show all my concerns.
I'm sorry, but I don't really understand which of your images shows what exactly. What I hoped to get was just 2 images of a movie frame where you see that "noise in dark areas", with the following settings:

(1) Full 3dlut processing (without Gamut_Measurements, though, since it doesn't seem to work properly yet).
(2) 3dlut turned off.

I expect to see the "noise in dark areas" in image (1), but not in image (2). Thanks!

FoLLgoTT

24th May 2010, 09:27

Though, don't forget that in the second a perfect Y might run against a perfect xy, so it might ends up as an optional setting.

I don't quite understand that. Luma (Y) should be independant from xy. Maybe I missed something?

Sorry, but i didn't understand your question. What did you mean with "interpolate colors"?

Maybe I'm wrong, but from my understanding of color management you have to correct all mixed colors if the primaries/secondaries get corrected. Here is an interesting paragraph from Lumagen's Radiance calibration guide (http://www.lumagen.com/docs/Tip0002_GamutCalibration.pdf):

Many displays and video processors claim to have primary color controls but, instead,
they really only have Color/Hue/Offset controls. Color/Hue/Offset controls should not be
used to try to correct the primary colors, because these controls operate in the wrong
color space. Other manufactures attempt to calibrate the primaries using HLS color
space. While this is an improvement over Color/Hue/Offsets, it is not as good as
correcting in the RGB color space.

Lumagen uses RGB color space for primary color correction. Lumagen believes that RGB
color space – the native color space for the primary and secondary colors – is the proper
color space to use when correcting primary and secondary colors. This is because it
allows the primary and secondary colors to be corrected, while maintaining the correct
interpolation of colors. The Radiance performs this calibration in linear RGB color space
to assure the best possible image quality. Figure 2 shows an example of corrected
primary and secondary colors.

So I'm wondering how yCMS interpolate the mixed colors when correcting gamut. :)

madshi

24th May 2010, 09:56

yCMS does its internal calcuations in linear light RGB, AFAIK, just like the Lumagen Radiance. However, yCMS calculates in 64bit floating point. I don't think the Radiance is that exact.

cyberlolo

24th May 2010, 11:32

madshi answered it really well. I'll just add that the Gamut_Measurements command was created also having in mind the gamut correction for multiple saturations (not yet supported), and that would not fit in the Output_Primaries command.
With only one saturation allowed there is an overlapping between the two commands, but we decided to still introduce this command now because it's more user friendly than the Output_Primaries. A big part of the users would not need (or dare :D) to go past the Warning, so I must say that you are one of the braves...;)
The "Gamut_Measurements" command should always be used when the display's coordinates are measured, no matter what the source is. The source should be reflected only in the Input commands, and in none of the output commands. The commands relative to measures are all output commands, because you are measuring the output (display).

The Output_Primaries command should be used only when a user cannot measure the display's primaries but he has an idea of what videoStandard his display might be. Then, he should use this command to set it accordingly.

Ok, I think I got it now. I won't use Output_Primaries at all, and will use Gamut_Measurements with both SD and HD sources. Thanks for explaining!

And hey, I'm one of the braves because I need to use that awesome Input/Output_Range to set my black and white points at 16 and 240, as I asked you some time ago. By the way, it works like a charm (no banding), so thank you again!!

No, that's wrong. As I said in my previous comment, you should simply forget all commands in the "defining standards" section. They are for people who want to reencode (not play/watch) videos, e.g. Blu-Ray -> x264 MKV.

All commands you'll ever need for madVR and video playback are in the first 3 sections of the manual (mandatory, optional, calibration). Please simple *forget* the commands in the "defining standards" section.

Thank you too for your help, madshi. But I think there's at least one command in the "Standards definition" section that it's really useful for watching/playing videos: that is the "Input/Output_Range", which allows to set black and white levels of the video data, defining the valid range (all video data outside of it is clipped). This command solves the problem that I posted in your madVR thread some time ago, as gives the users the chance to set top white level at any point between 235 and 254, without introducing banding (which ffdshow's levels filter does). So with this, anyone can decide if to discard all WTW info (white level @ 235), only a part of it (let's say setting white at 245), or if preserve all WTW up to 254. And to me, this is a really important feature. Don't you think?

cyberbeing

24th May 2010, 18:58

There appears to be a bug where if you don't use Input_Format & Output_Format and instead use the "Advanced settings" for everything, yCMS complains that there is no Compression_Method value. Since it is supposedly optional, it should be defaulting to 0 when no value is specified.

Also, could you please explain what Compression_Method does? Is it currently just a placeholder at this point?

Other than "0" what would be an example value? None are listed in the manual.

yesgrey

25th May 2010, 00:18

How can I use the new IRE function and keep my Blacks, Black?
I've found the bug. It will be corrected in next version.

So you're aware of a noise problem in dark areas and there's hope for an improvement?
Yes. I simply forgot to include it in the first post as "Known issues". I improved it compared to cr3dlut, but the definitive solution would take me a little more time...

I don't quite understand that. Luma (Y) should be independant from xy.
In a perfect display yes, but I think there isn't any in the market yet... I only will know for sure when I have it working. It might be possible to have it all correct.

Maybe I'm wrong, but from my understanding of color management you have to correct all mixed colors if the primaries/secondaries get corrected.
That's the idea: correct all colors. The primaries/secondaries are only the reference values.

So I'm wondering how yCMS interpolate the mixed colors when correcting gamut. :)
There is no interpolation involved in yCMS. All colors are corrected in linear RGB color space using 64 bit FP for each component. Then, it's applied gamma encoding and the result is converted into the output format bit depth selection.
The only interpolation involved is in madVR, which interpolates 3DLUT input/output using tri-linear interpolation for finding more accurate values for its 32 bit FP calculated values.

There appears to be a bug...
Thanks. It will be corrected in next version.

Also, could you please explain what Compression_Method does? Is it currently just a placeholder at this point?
Yes.
When we defined the 3DLUT file format specification we considered the possibility of compressing the files, due to its big size and high loading time, so this option is to be used when the 3DLUT files could be compressed.

madshi and I are currently working on adding compression to the 3DLUT files.

Blue_MiSfit

25th May 2010, 02:47

It seems to really take advantage of this, one must have good calibration equipment, correct?

~MiSfit

Mark_A_W

25th May 2010, 03:30

Get a HCFR Blue_misfit.

But I don't think it's ready yet. I don't think there is a clear path to go from measurements to the 3DLUTs yet.

yesgrey

27th May 2010, 01:27

yCMS v1.1 released

http://yesgrey.com/ycms.html

- Increased Grayscale_Measurements maximum to 11.
- Compression_Method was not being considered as optional.
- Fixed incorrect black point when Grayscale_Measurements ire 0 was not set.

cyberbeing

27th May 2010, 02:27

- Fixed incorrect black point when Grayscale_Measurements ire 0 was not set.

Well blacks are now black, but near black shadows are crushed into bright solid tones, which makes the problem orders of magnitude worse.

http://img710.imageshack.us/img710/9760/normall.pnghttp://img37.imageshack.us/img37/6268/irec.png
| Regular 3DLUT on LEFT | 3DLUT with IRE on RIGHT |

All of the below give horrible results. Try it with a dark scene and see for yourself.
# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

# Grayscale IRE Measurements
Grayscale_Measurements
10 0.486085 0.472363 0.497613
20 2.855507 2.751755 2.748106
30 7.040504 6.968139 7.044012
40 13.197106 13.020103 13.015621
50 21.422743 21.428576 21.564960
60 31.921806 31.852612 31.998531
70 45.422878 45.317829 45.406380
80 60.435123 60.174709 60.314659
90 78.802399 78.381996 78.620575
100 97.811592 98.124657 98.652870

# Display Gamut Measurements
Gamut_Measurements 0.626 0.343 0.294 0.607 0.149 0.078 0.3127 0.3290

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

# Grayscale IRE Measurements
Grayscale_Measurements
0 0.000000
10 0.486085 0.472363 0.497613
20 2.855507 2.751755 2.748106
30 7.040504 6.968139 7.044012
40 13.197106 13.020103 13.015621
50 21.422743 21.428576 21.564960
60 31.921806 31.852612 31.998531
70 45.422878 45.317829 45.406380
80 60.435123 60.174709 60.314659
90 78.802399 78.381996 78.620575
100 97.811592 98.124657 98.652870

# Display Gamut Measurements
Gamut_Measurements 0.626 0.343 0.294 0.607 0.149 0.078 0.3127 0.3290

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

# Grayscale IRE Measurements
Grayscale_Measurements
0 0.000000 0.000000 0.000000
10 0.486085 0.472363 0.497613
20 2.855507 2.751755 2.748106
30 7.040504 6.968139 7.044012
40 13.197106 13.020103 13.015621
50 21.422743 21.428576 21.564960
60 31.921806 31.852612 31.998531
70 45.422878 45.317829 45.406380
80 60.435123 60.174709 60.314659
90 78.802399 78.381996 78.620575
100 97.811592 98.124657 98.652870

# Display Gamut Measurements
Gamut_Measurements 0.626 0.343 0.294 0.607 0.149 0.078 0.3127 0.3290

http://img56.imageshack.us/img56/1585/gammaplot2.gif

Do you think you are running into a problem because the BT.709 curve (red line in the above image) crushes low luminance blacks. It appears yCMS may be adjusting those crushed (non-existant) BT.709 transfer curve blacks into actual visible colors when you shouldn't be.

Blue_MiSfit

27th May 2010, 06:26

I have a Pantone Huey Pro. It doesn't look like HCFR supports it, but we'll see...

kostik

27th May 2010, 21:08

I have the same issue that cyberbeing reported. The shadows turn into red with or withoust the 0 IRE:( evrything but this issue works well, hope it will be fixed soon.
Thanks for your work :)

yesgrey

27th May 2010, 22:57

I have the same issue that cyberbeing reported. The shadows turn into red with or withoust the 0 IRE:( evrything but this issue works well, hope it will be fixed soon.
Thanks for your work :)
I'm working on it...

BeNooL

28th May 2010, 07:57

What are the value measurement expected by yCMS for the Grayscale_Measurements option?

In the manual, the values given as example are quite large (more that 450 at 100IRE) while the one shown by cyberbeing are more in the 0 to 100 range (same for me).
So just wondering if the proper data is given for the computation of this correction?

yesgrey

28th May 2010, 12:52

What are the value measurement expected by yCMS for the Grayscale_Measurements option?
Like said in the manual: >= 0.0

In the manual, the values given as example are quite large (more that 450 at 100IRE) while the one shown by cyberbeing are more in the 0 to 100 range (same for me).
That was intentional to let people know they could use any values.
The units are not important, because internally all values are divided by the maximum value.

BeNooL

28th May 2010, 15:51

Okay so let me rephrase the question: in HCFR Colorimeter which of the grayscale measurement has to be copied over to yCMS config file?
X, Y, Z, R, G, B, x, y etc?

PS: thank you very much for your development effort on this project.

yesgrey

28th May 2010, 16:52

in HCFR Colorimeter which of the grayscale measurement has to be copied over to yCMS config file?
X, Y, Z, R, G, B, x, y etc?
I don't have HCFR installed, but I think it should be Y (Luminance)...

cyberbeing

28th May 2010, 17:02

I don't have HCFR installed, but I think it should be Y (Luminance)...

Y (Overall Luminance) if you are only inputting a single value.

R (Red Luminance), G (Green Luminance), B (Blue Luminance) if you are inputting multiple values.

Thunderbolt8

28th May 2010, 17:09

BeNooL

28th May 2010, 17:41

Thanks for the clarifications Yesgrey and cyberbeing.

Thunderbolt8, yes you have to regenerate the 3Dlut files with each new version of yCMS.

yesgrey

28th May 2010, 18:26

a question regarding 1.1 (and other upcoming versions): I only need those 4 3dlut files for madVR, 2xHD and 2xSD as described in your example. I created these files with 1.0, should I now recreate those files with v1.1 and all other upcoming versions?
If the new version does not correct any bugs shown in your current 3DLUT files there is no need to.
If you haven't used the Grayscale_Measurements you're should be ok, but I strongly advise to recreate the files whenever any bugs are fixed. It would be safer.
You can create a simple batch file that calls each of the input files and creates all the 4 files, which would take you only a few seconds. I don't think that's too much work... ;)

janos666

28th May 2010, 22:06

Nice progress. The Grayscale_Measurements command gives me better result than I had with the Output_Primaries command and it is nearly usable (for me) now.

But there is a huge bug with the out of gamut colors (I think) in this version. Take a look at the blue area on the upper left corner: off (http://img12.tar.hu/janos666/img/76364851.png) - on (http://img12.tar.hu/janos666/img/76364853.png)
I made these screenshots with enabled/disabled 3dlut which was built with these settings:
# Source video format
Input_Format HD YCbCr 8

#3DLUT output format
Output_Format HD RGB_PC 16

# Gamut correction - measured native x;y coordinates
Gamut_Measurements 0.657073 0.329413 0.231911 0.690324 0.140940 0.090552 0.311880 0.329555

I do not want to guess about the real problem (output bitrate, my perception, poor quality video source, poor quality display) but I think that gamma correction sometimes kills the shadow details. I can hear as shadows are screaming and dieing here: off (http://img12.tar.hu/janos666/img/76364850.png) - on (http://img12.tar.hu/janos666/img/76364852.png) (Sorry but I was a Lexx fan. :rolleyes:)
I used the lines above with these:
#Gamma correction - measured grayscale RGB luminances
Grayscale_Measurements
0 0.151752 0.146392 0.138733
10 1.564805 1.551411 1.491997
20 4.668003 4.810841 4.791349
30 10.406371 10.604137 10.320132
40 19.016638 18.991844 18.722298
50 30.179890 30.871260 30.149662
60 44.580005 45.085168 44.541965
70 63.151944 64.109925 63.294323
80 84.184549 85.582548 84.539725
90 110.365791 112.272175 111.200465
100 140.120883 142.500616 141.767822

cyberlolo

1st June 2010, 00:52

@yesgrey: I think I've found a bug too with the Input_Range parameter. Please take a look at this two images: With Input_Range (http://www.gandario.com/cal_img/Weeds_on.png) - Without Input_Range (http://www.gandario.com/cal_img/Weeds_off.png).

In the first one, you can clearly see the problem (I've added a white ellipse around it). In the second one, this problem is not there, but of course the levels are then wrong (they're 0-255 instead of 16-240).

I made both screenshots with enabled 3dlut, which was built with these settings. For the first image:

Input_Format NTSC YCbCr 8

Output_Format HD RGB_Video 16

Gamut_Measurements 0.6830 0.3170 0.3130 0.5810 0.1390 0.0500 0.2890 0.2800

Input_Range 16 240
Output_Range 0 255

For the second image, I used the same file, but removing the Input_Range parameter:

Input_Format NTSC YCbCr 8

Output_Format HD RGB_Video 16

Gamut_Measurements 0.6830 0.3170 0.3130 0.5810 0.1390 0.0500 0.2890 0.2800

Output_Range 0 255

Thanks in advance.

yesgrey

1st June 2010, 01:00

I think I've found a bug too with the Input_Range parameter.
Thanks for the report, it's the same bug. I'm currently working on it...

cyberlolo

1st June 2010, 01:05

Thanks for the report, it's the same bug. I'm currently working on it...

Ok then, I thought it could be a different one, as this seemed to be caused by a different parameter.

Thanks again for your work.

cyberlolo

1st June 2010, 17:32

yesgrey, here is more info in case it can help you: I had a surprise today when I tested again the same video, and the problem had disappeared. The only things I made are:
1) Suspend+wakeup PC.
2) Enable ffdshow's levels filter+disable 3dlut in madVR. After that, I switched back by disabling ffdshow's levels filter and re-enabling 3dlut (using the exact same file than before) in madVR, and then everything was Ok. The problem has gone by now.

Weird. Isn't it?

yesgrey

1st June 2010, 20:30

(using the exact same file than before)
Which 3DLUT file (with or without the Input_Range command)?

cyberlolo

1st June 2010, 20:54

Which 3DLUT file (with or without the Input_Range command)?

The one WITH the Input_Range command.

yesgrey

1st June 2010, 21:25

Yes, that's weird, though it doesn't help me...
I already know what the problem is, but I need to find time for correcting it...

janos666

6th June 2010, 12:56

I tried to add more low IREs to grayscale measurements to increase the shadow detail with gamma correction but I got an error that I should give the numbers in increaseing order. My IRE list was: 0, 1, 2, 3, 4, 10, 20, 30, 50, 70, 100. So, the real problem is that I should keep equal steps between values or I can not use too little steps.

Can you upload the v1.0 version for me? I can not enjoy any improvements/fixes but I have a bug which I didn't noticed with v1.0 (some - may be out-of-gamut - colors bands to black -> I don't know if this bug exists in v1.0 too but I didn't remember if I saw that)

Mark_A_W

6th June 2010, 13:10

Guys

How do I go from an HCFR measurement to a custom 3DLUT?

Can we do that yet?

Thanks

Mark

janos666

6th June 2010, 13:49

yesgrey

6th June 2010, 16:50

I got an error that I should give the numbers in increasing order. My IRE list was: 0, 1, 2, 3, 4, 10, 20, 30, 50, 70, 100. So, the real problem is that I should keep equal steps between values or I can not use too little steps.
There isn't such a limitation. The measures values should also be in increasing order, have you checked that? but that would not help you. I've already said that it's a bug. It's preferable to not use the Grayscale_Measurements command with the current version of yCMS. I'm working on it...

iSeries

6th June 2010, 17:29

Hi,

I'd like to have a go at creating a 3D LUT but to be honest after reading the 'manual' I am no more clued up than before. Is there a 'dummies' guide anywhere?

I have not calibrated my TV but someone on a well known AV forum posted profesional IRE calibration results. I've applied these through the 'Picture' menu of my TV (and improved colour 100%) but how can I apply these numbers to a 3D LUT?

Sorry for the newbie-ness :)

janos666

6th June 2010, 17:30

There isn't such a limitation. The measures values should also be in increasing order, have you checked that? but that would not help you. I've already said that it's a bug. It's preferable to not use the Grayscale_Measurements command with the current version of yCMS. I'm working on it...

No, there were 11 numbers in increasing order, like I wrote and I got that message.
May be there were some fluctuation in the RGB luminance values and (for example) R-2% was less than R-1%. (I checked the "Average many readings" but my display do not has internal LUT for gamma and software LUT won't give me perfect result through 8 bit link. - After you released this new yCMS and I started to examine dark gradiations I feel that I need a new display. :p)
I just recalibrated my display and noticed this "Near Black Scale" tab in HCFR, so I thoght it won't harm if I give it a try. It won't be a bad idea to increase the max IRE number to 14 either. (To add this near black scale too - as an experiment. It looks like PVA displays without internal LUT has strange gradiation near to black. I didn't noticed it with my S-PVA earlier but it is clearly noticeable with c-PVA panels and exists here too.)

But can you upload yCMS 1.0 or the latest cr3dlut version for me? I can't remember if I saw something like this in the past (only with simple gamut correction): 3DLUT OFF (http://img12.tar.hu/janos666/img/76795039.png) - ON (http://img12.tar.hu/janos666/img/76795040.png)
I didn't keep any old versions and I would watch movies until your next yCMS release. Thanks. :)

Hi,

I'd like to have a go at creating a 3D LUT but to be honest after reading the 'manual' I am no more clued up than before. Is there a 'dummies' guide anywhere?

I have not calibrated my TV but someone on a well known AV forum posted profesional IRE calibration results. I've applied these through the 'Picture' menu of my TV (and improved colour 100%) but how can I apply these numbers to a 3D LUT?

Sorry for the newbie-ness :)

First:
Using measures from others can result in better or worse state as well. If every display would be identical then they wouldn't be calibrated at home (and recalibratead about monthly period), they could be easily calibrated in the factory. (Some manufacturers do this for their displays one by one and you only have to fine tune it at home, if you want...)
But native primary colors should be close (with identical brightness and contrast settings), so you can use those coordinates to do a gamut correction (if necessary).
Second:
If your display has configurable internal CMS then you are very lucky and you do not need software CMS. I do not know the capabilities of your hardware and what settings did you applied exactly...
Third:
Here is a template. You should change the last 4x2 values (four substantional value would be enougt - I just copy-pasted them...) . These are the x;y CIE coordinates of Red, Green, Blue, White colors (in this order).
As yesgrey wrote it earlier too, you should not try to use IREs for gamma correction with current software versions.
Filename: HD - PC.txt

# Source video format
Input_Format HD YCbCr 8

#3DLUT output format
Output_Format HD RGB_PC 16

# Gamut correction - measured native x;y coordinates
Gamut_Measurements 0.655471 0.330898 0.232747 0.689508 0.140942 0.090273 0.311221 0.327337

iSeries

6th June 2010, 18:02

janos666

6th June 2010, 18:20

Thanks janos666 - yes I'm aware using someone elses calibration results will not be 100% perfect, but trust me, its miles better than it was (even Cinema mode was too blue - my TV is a LG 47LH5000).

I have a Spyder3 - can I use this to get the necessary measurements? If so, what software should I use?

Of course. It will be very easy if the display is connected to a PC through a digital cable and it won't be too hard if it is not.
Install this free software: Color HCFR (http://www.homecinema-fr.com/colorimetre/index_en.php).
Put some DLL files to it's folder from your bundled calibration software's folder if you asked to do it. (There will be a detailed notice later. Then start again from here...)
Start a new "View images" document, select your instrument from the list.
Set the output range of the image generator as your display requires it. (0-255 for PC monitors and sometimes for TVs which are connected to PC and normally 16-235 for TVs with any input source. You can figure it out with a quick test. Watch a black image. If it is black with 16-235 range then output setting is right.)
Do a complete measure set by clicking on the icon with many colored rings. Wait until it finished and save the document for later.
May be you have to cancel the first attempt and start it again if it would hang on showing a black image. I usually have to double click on the black image, wait, hit ESC, hit OK and start it a second time to do a correct measure set...

If you can't connect the display to a PC then you need the AVS HD 709 test patterns (http://www.avsforum.com/avs-vb/showthread.php?t=948496) and play it back on your player to manually measure the primaries (or grayscale, ect.) in free measure mode.
But yes, I could figure it out that you have a PC because yCMS can be used with PC softwares (like madVR video renderer) only.

You can select the Primaries and Secondaries tab, set the xyY format and copy-past the R,G,B,W columns to a text file, clear the Y value and sort it.
Or you can choose the Grayscale tab and the RGB value format to get color luminance values for IREs.

Another thing: If you watch movies from your PC than you can use the calibration software to correct your gamma curve. The problem is that I do not know any free/bundle software which can work with a real Rec709 tonal response curve. But it won't be a problem if you target a gamma function like x^2.2. (I am not sure yet if in the real life, most HDTVs really use the Rec709 inverse transfer function or they have a simple gamma curve like x^2.2)

Mark_A_W

7th June 2010, 02:35

Do a measurement set with HCFR (primary colors and white will be enough for now but grayscale could be useful later, so choose the icon with the most rings...) and use copy-paste (CTRL+C and CTRL+V keys on your keyboard) the xyY values to a text file, delete the Y values and sort the xy values (in R G B W order) to a row and copy-paste it after the Gamut_Measurements command in your yCMS settings file.
You can do the same with grayscale RGB values but I do not think it is useful with current softwares.

Of course. It will be very easy if the display is connected to a PC through a digital cable and it won't be too hard if it is not.
Install this free software: Color HCFR (http://www.homecinema-fr.com/colorimetre/index_en.php).
Put some DLL files to it's folder from your bundled calibration software's folder if you asked to do it. (There will be a detailed notice later. Then start again from here...)
Start a new "View images" document, select your instrument from the list.
Set the output range of the image generator as your display requires it. (0-255 for PC monitors and sometimes for TVs which are connected to PC and normally 16-235 for TVs with any input source. You can figure it out with a quick test. Watch a black image. If it is black with 16-235 range then output setting is right.)
Do a complete measure set by clicking on the icon with many colored rings. Wait until it finished and save the document for later.
May be you have to cancel the first attempt and start it again if it would hang on showing a black image. I usually have to double click on the black image, wait, hit ESC, hit OK and start it a second time to do a correct measure set...

If you can't connect the display to a PC then you need the AVS HD 709 test patterns (http://www.avsforum.com/avs-vb/showthread.php?t=948496) and play it back on your player to manually measure the primaries (or grayscale, ect.) in free measure mode.
But yes, I could figure it out that you have a PC because yCMS can be used with PC softwares (like madVR video renderer) only.

You can select the Primaries and Secondaries tab, set the xyY format and copy-past the R,G,B,W columns to a text file, clear the Y value and sort it.
Or you can choose the Grayscale tab and the RGB value format to get color luminance values for IREs.

Another thing: If you watch movies from your PC than you can use the calibration software to correct your gamma curve. The problem is that I do not know any free/bundle software which can work with a real Rec709 tonal response curve. But it won't be a problem if you target a gamma function like x^2.2. (I am not sure yet if in the real life, most HDTVs really use the Rec709 inverse transfer function or they have a simple gamma curve like x^2.2)

Janos, it seems to me from the first post that you are talking about doing Gamut cropping - as you are measuring primaries only, not greyscale.

But from the second post you kinda are talking about a custom gamma curve, which would need a greyscale measurement.

And we would need a target curve input somewhere.

What if I don't want the end result to be 2.2? What if I want, say, 2.5? Or a non-standard result?

It still seems to me that something is missing between the raw measurements and yCMS.

But we are getting somewhere :)

cyberbeing

7th June 2010, 04:21

But there is a huge bug with the out of gamut colors (I think) in this version. Take a look at the blue area on the upper left corner: off (http://img12.tar.hu/janos666/img/76364851.png) - on (http://img12.tar.hu/janos666/img/76364853.png)

I've run into this problem as well with a couple different videos. The yCMS created LUT creates black blocks within portions of certain video sequences (repeatable). Until some of these bugs get fixed, I've rolled back to using cr3dlut which at least was 'stable' (yet no longer available on your website). Hint: It may be nice if you continued to make cr3dlut available until you can consider yCMS as being 'stable', without any significant bugs.

iSeries

7th June 2010, 09:49

@ janos666 - this isn't going to be as simple as I'd hoped! I've copied spyder3.dll to the install directory as it asked but when I try to start the measurements the software is saying 'Spyder3.dll returned an error during initialisation', and then 'Error during sensor initialisation'. Any ideas?

yesgrey

7th June 2010, 09:50

What if I don't want the end result to be 2.2? What if I want, say, 2.5? Or a non-standard result?
That's the next thing I will take care after solving the current issue with Grayscale_Measurements. It's a subject that will need some discussion, so we'll get back to it after I fix the Grayscale_Measurements... Don't forget yCMS is still a new-born... ;)

I've run into this problem as well with a couple different videos. The yCMS created LUT creates black blocks within portions of certain video sequences (repeatable).
I thought the problem only affected the Grayscale_Measurements command, but I've also fixed a bug that might affect the image even when it's not used.
Can you upload a small video sample? If that fixed bug solves the problem I will soon release a new yCMS version.

cyberbeing

7th June 2010, 10:37

Here you go (blocking appears in the blue haze around the 4 second mark):
http://www.mediafire.com/?mdmvmnyzqom

The other time it occurred it was in a blue area as well, but I forgot what video showed it. The image janos666 posted also had blocking in a blue area, so maybe it only effects blue? Or possibly any significantly out of gamut colors for any primary?

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

# Display Gamut Measurements
Gamut_Measurements 0.626 0.343 0.294 0.607 0.149 0.078 0.3127 0.3290

janos666

7th June 2010, 11:52

@cyberbeing
I can notice it with blue colors only but this is the only primary color where the native point does not reach the Rec709 reference point, and it is out of the reference rectangle. I posted my gamut measures in #53
Here is an other blue sample: NLC logo (http://www.tar.hu/janos666/Sample.blueblank.mkv) (<- Right click, save as).
I can see some strange things with red colors as well but I can reproduce them with one movie only (Cargo), so it can be some encoding/decoding bug. There are some strange things with red scenes but they looks strange without 3DLUT processing as well. So I think that gamut conversion makes it more strange only. (Closed area, intense red light, red faces...)

@Mark_A_W
Yes. As yesgrey wrote it, we should do gamut correction only with current versions. But I suggested for him to measure the grascale as well if he already placed the instrument on his display because it can be useful in the (near?) future.
The other thing what I suggested that he can use PC softwares for gamma correction through VGA LUT. Some calibration softwares will let you define custom x^y gamma curves or sRGB curve, and a few (expensive) one will let you choose Rec709 or even allow you to define a custom math definition for any complex curves. The result won't be too close to perfect if you do not have 10+ bit output from your VGA but it will be close enough when you want a curve which is close to the native characteristics.

But this is a very complicated story. I was not able to figure it out yet that I should use sRGB or x^2.2 curve for a general purpose home PC. There are some arguments on both sides but I think that there is no one correct answer here. It is more like a recommendation. I used sRGB curve in the last few months but I calibrated my display with x^2.2 same days ago.
And the only software which can do Re709 calibration (as I know) is CalMan. That is more expensive than my EyeOne itself. And I do not want to manually load the VGA LUTs every time I watch movies.

So, my display will be calibrated to sRGB or x^2.2 (with VGA LUT) and I will convert the Rec709 sources with yCMS to match with this characteristic.

@iSeries
Sorry. I feel this is off-topic here, and I am not so familiar with Spyders. May be they can help: Color HCFR Calibration Discussion @ AVS Forum (http://www.avsforum.com/avs-vb/showthread.php?t=786966). But it will be some incompatibility with your DLL or device driver version.

yesgrey

7th June 2010, 12:59

yCMS v1.2 released

http://yesgrey.com/ycms.html

- Fixed corruption of blue and red at very low levels.

This is a new version only for fixing the corruption of blue and red at very low levels, noted by several users.

It's still recommended to not use the Grayscale_Measurements command until I fix what's wrong with it.

yesgrey

7th June 2010, 13:03

so maybe it only effects blue?
I can see some strange things with with red colors as well
You were both correct. The bug affected both blue and red at very low levels.

Let me know how it works with v1.2.

Thanks for reporting the problem.

cyberbeing

7th June 2010, 13:33

yCMS 1.2 fixes the sample I posted.

Is there a reason why you removed the Out_Of_Gamut_Clipping option which was in cr3dlut? Previously I always used the Simple method (if >1.0 -> 1.0; if <0.0 -> 0.0), which I assume is similar to Relative Colorimetric. Same goes for the Chromatic_Adaptation parameter.

Another thing which would be nice is if yCMS automatically outputted LUTs with the .3dlut extension, unless a different extension is specified.

janos666

7th June 2010, 13:34

The bug affected both blue and red at very low levels.
Let me know how it works with v1.2.

Yes, it is much better now. But still not perfect. Play my sample file and look at the lower right corner. There is some black blocks there with 3LUT processing.
But I think it won't be noticeable in actual movie scenes.

@cyberbeing - I was not able to see any real differences in actual movie scenes between those clipping modes. But I used the simple method.

yesgrey

7th June 2010, 14:09

Is there a reason why you removed the Out_Of_Gamut_Clipping option
Currently that option is not needed in yCMS.

Play my sample file
I can't download it. I only get a 1kB file.

janos666

7th June 2010, 14:32

@yesgrey - Try this link (http://rapidshare.com/files/396288093/Blueblanksample.mkv.html).

yesgrey

7th June 2010, 15:46

Try this link.
I got it, but I also need your configuration file for creating the 3DLUT.

janos666

7th June 2010, 15:50

I got it, but I also need your configuration file for creating the 3DLUT.
Last code area. (http://forum.doom9.org/showpost.php?p=1405988&postcount=53)

It's still recommended to not use the Grayscale_Measurements command until I fix what's wrong with it.
Will it affect the output_primaries command? I prefer to use that one as I use the VGA LUT to get gamma 2.2

cyberbeing

8th June 2010, 03:32

Is there a reason why you removed the Out_Of_Gamut_Clipping option which was in cr3dlut?Currently that option is not needed in yCMS.

Can you explain why you believe it is no longer needed? Doing color correction with a Perceptual rendering intent isn't automatically best for everything you know.

yesgrey

8th June 2010, 12:21

Doing color correction with a Perceptual rendering intent isn't automatically best for everything you know.
Using simple clipping isn't automatically best for everything you know, also. So, it has to be some kind of a mixed method, which yCMS is doing, hence the not inclusion of such an option.

cyberbeing

8th June 2010, 20:55

Using simple clipping isn't automatically best for everything you know, also.
'Simple clipping' taken literally would actually be Absolute Colorimetric, which you absolutely should not be doing. If by 'simple clipping' you actually mean Relative Colorimetric, then you are correct, which is why you would optimally need two different LUTs. One Perceptual and one Relative Colorimetric, depending on the content. At least that is how it is in the photography ICC color profile world.

So, it has to be some kind of a mixed method, which yCMS is doing, hence the not inclusion of such an option.
If you are compressing the gamut to preserve out-of-gamut gradients (which may not even matter), you are using a Perceptual method. This results in tone/hue color shifts of all colors which originally fell within the destination color space. This is usually the preferred method if your source has a lot of detail which falls out-of-gamut. If there is just one stray color which is way out-of-gamut, Perceptual can really mess up all your colors.

If you are not compressing the gamut and instead mapping out-of-gamut colors to the closest color in your destination color space, you are using Relative colorimetric. The goal of this method is to keep the original colors which were in-gamut in your destination color space unchanged. This is usually the preferred method if your source detail is mostly in-gamut. The goal is to preserve original colors whenever possible, which is not possible using a Perceptual method.

I don't really see how a mixed method is possible without two different LUTs or intervention of the video renderer. If you would explain what your mixed method was doing, that might help.

If a color is out-of-gamut, does yCMS do?

If if a particular color exists in both source and destination color space, what does yCMS do?

yesgrey

8th June 2010, 22:08

If a color is out-of-gamut, does yCMS do?
yCMS is not compressing the color gamut. All colors that lay in the destination gamut are untouched, it only changes the colors that lay outside the color gamut. yCMS can use a mixed method because it calculates all possible color combinations, and changes only the problematic ones.

racerxnet

9th June 2010, 04:07

I was wondering if a lut file could be created from the information from the panel manufacture. I copied the info and if someone could help I would appreciate it. CHI MEI LCD PANEL

Color Chromaticity

Red R x 0.632 -
R y 0.324 –

Green G x 0.273 -
G y 0.591 –

Blue B x 0.144 -
B y 0.068 –

White W x 0.280 -
W y 0.285

Color Gamut Min 68 Max 72

Thanks,

MAK

yesgrey

9th June 2010, 08:11

I was wondering if a lut file could be created from the information from the panel manufacture.
Add this line to your configurationFile:
Gamut_Measurements 0.632 0.324 0.273 0.591 0.144 0.068 0.280 0.285

Though, don't forget that the ideal situation would be measuring the primaries, because those indicated in the panel might not be accurate enough. However, it might give you a more accurate image than not using any correction at all.

Let us know how it worked.

cyberbeing

9th June 2010, 09:25

yCMS is not compressing the color gamut. All colors that lay in the destination gamut are untouched, it only changes the colors that lay outside the color gamut. yCMS can use a mixed method because it calculates all possible color combinations, and changes only the problematic ones.

So what type of 'changes' are being made to out-of-gamut colors?

You can:
A) Clip them (remove completely)
B) Move all out-of-gamut colors to the closet reproducible tone with no way to distinguish the out-of-gamut tones from your in-gamut tones. (multiple colors on the edge of the destination gamut represented as a single color)
C) Move all out-of-gamut colors to the destination gamut in a way so they are distinguishable from each other and produce smooth gradients (compress the gamut).
D) ????

flanger216

9th June 2010, 21:23

I'm still trying to stay afloat in all this colorimetry theory, but I'm hitting a conceptual dead-end:

I was under the impression that chromaticity primaries were an 'immutable' property of your display --- that is, you can tweak color and hue and gain settings as much as you like, but only a true CMS could actually alter the xy coordinates of your display's primaries. However, when I plot my TV's primaries to the CIE chart in HCFR, and then mess with the display settings, it quite clearly affects the shape and accuracy of the triangle on the CIE chart. In other words, my tweaks are affecting the chromaticity primaries, as reported in HCFR. Hue, color, gain, bias and temperature all affect the readings --- some quite severely.

My best attempt at wrapping my brain around this is the following: there are two sets of primaries --- let's call them the 'native' primaries and the 'gamut' primaries --- and the former refers to the full color gamut of which your display is capable, and the latter refers to the color gamut that ultimately results from your display settings (color temp, bias, gain, hue, etc.). HCFR intrinsically can only measure the 'gamut' primaries, because it must take its readings at the end of the display-chain, after the TV has performed its own post-processing.

Is this remotely accurate? Or am I still hopelessly confused? Most importantly, when and how should one measure the primaries for use in yCMS? As an extreme example, if I turn the 'color' control all the way down, the TV renders a black-and-white image, and HCFR would 'measure' the primaries as forming a curved line instead of a triangle at all. But this isn't really true, right? Turning the color saturation all the way down doesn't actually shift the color primaries into a linear curve... I imagine it merely distorts the measurements, not the 'true' chromaticity values of the display. So... for the purposes of using yCMS, should I measure the primaries at factory defaults, or after display calibration? Or am I doing this wrong? Is there some other method to calculate 'native' primaries?

Again, apologies... I'm usually semi-successful at figuring this stuff out, but colorimetry and CMSes are boiling my brains :eek:

cyberlolo

9th June 2010, 21:29

yesgrey

9th June 2010, 22:38

So what type of 'changes' are being made to out-of-gamut colors?
Not A), not B), not exactly C). So I would say it's D)...

So... for the purposes of using yCMS, should I measure the primaries at factory defaults, or after display calibration?
I don't have yet the definitive answer for that. Furthermore, it might be the case that it will depend on the display type.
The main goal is the user setting the brightness and the contrast and let yCMS calibrate all the rest, but yCMS it's still a bit far from that...

After I correct the current problems with the Grayscale_Measurements command, I will post some simple instructions, but now, I need to keep my focus on yCMS.;)

cyberbeing

9th June 2010, 23:01

Not A), not B), not exactly C). So I would say it's D)...

So in other words you don't want to share what you are doing...

naomatrix

9th June 2010, 23:39

I have an LCD monitor is calibrated program Atrise Lutcurve and I watch movies through MPC-HC + madVR. Look it very good. I also tried to use parameters color gamut of my display, that I have received from computer program - Monitor Asset Maneger via EDID, my tinctures such

# Parameters by Monitor Asset Maneger
# Default color space ...... Non-sRGB
# Display gamma ............ 2.20
# Red chromaticity ......... Rx 0,640 - Ry 0,334
# Green chromaticity ....... Gx 0,285 - Gy 0,599
# Blue chromaticity ........ Bx 0,153 - By 0,076
# White point (default ).... Wx 0,313 - Wy 0,328

I ordered a template string

Gamut_Measurements 0.640 0.334 0.285 0.599 0.153 0.076 0.313 0.328

and made the files 3DLUt, but I do not see any difference between the image without gamut correction and with correction. Where should I look at and whether there is some objective method of comparing images. Is it possible to make in yCMS use of parameters gamut through EDID automatically.
Sorry for my english I'm from Ukraine

yesgrey

10th June 2010, 11:31

So in other words you don't want to share what you are doing...
Please don't take it personally, but until yCMS be more stable and less bug affected I prefer to not discuss publicly some aspects of it. I consider it solely as some kind of protection...;)
Furthermore, I haven't yet implemented some of my ideas. The current clipping is only slightly better than the other two available modes...

yesgrey

10th June 2010, 11:56

but I do not see any difference between the image without gamut correction and with correction.
The differences are more evident when the display gamut differs more from the source one, especially when it's wider, which isn't your case. In your case, the coordinates are so similar to the HD ones that you might not be able to detect any differences with real world images, probably only with some test patterns, where you could compare the primaries colors.
If you don't have any test patterns, go here (http://www.avsforum.com/avs-vb/showthread.php?t=948496) and get them on the first post. Play the 100% color video and you should be able to detect some differences.

Is it possible to make in yCMS use of parameters gamut through EDID automatically.
I don't know if that will ever be added, because the reliability of that info might not be very high...

janos666

10th June 2010, 18:31

Most importantly, when and how should one measure the primaries for use in yCMS?

There are three important components in your display:
- CCFL or LED back-light which has it's own color spectrum and it's own color temperature (and max/min luminance).
- LCD TFT panel with it's R, G, B pixels (made with color filters)
- (digital) driver/controller panel(s).

They are intended to match with various design parameters which can be a standard (like Rec709, sRGB, ect...) or any custom design. But they will be slightly unique (one by one) and they will change in time uniquely. (This is the reason why you need a colorimeter. You shouldn't think those instruments are perfect, but they are usually more than enough.)

The combination of the back-light and the TFT panel will determine the native characteristics of your display.
You have different options to push your display closer to the desired standard characteristics:
- It can be done with the internal electronic controllers, fully or partially.
- You can use software calibration, like VGA LUT or yCMS, ect.
- They can be used together.

Your possibilities will be limited by the supported hardware calibration features. Some professional displays will allow you to upload your 3D LUTs (made by an automated software) and make a complete hardware calibration. Some display will let you change a few things only (nothing like 2D LUT or IRE list for gamma or sliders for huye and saturation, but luminance and contrast only...)

There is no universal rule here but the general suggestion that you should change any possible setup in your hardware settings first and fine-tune it with software calibration. (Of course, you should omit any hardware features if you find them defective. And this applies to software bugs as well.)

And the basic idea behind this calibration:
- You have ** output characteristics but you want ## like ones. - You know the desired ## and you can measure the representative values of the ** state.
- You can make a matrix with math functions or pre-calculated tables of any possible values to manipulate your input signal to get ## through your ** output distortion.

Of course, the number of the lost color tones will be (nonlinearly) scaled by the distance between your display's native characteristics and the desired standard.
But this is another hardware factor. We usually have 8 bit/color materials and some displays will support higher bit depth. For example it will process the 10 bit input signal with 12 bit accuracy for 10 bit visualization, so there can be some room for image manipulation without losing details. But the other side is when you have 8 bit input with 8 bit processing and 6+2 bit visualization (like 6 bit TN or c-PVA panels with dithering) and you are far from the standard.

yCMS creates 16 bit 3DLUTs but MadVR will convert it back to 8 bit with dithering (I do not know but may be fake 10 bit quality is a good estimation - but there will be some dithering noise as a side effect...). But this number can be increased in the future with deepcolor support.

So, this is a deep hole, filled by eternal questions, desinformations, and a lot of shit. But the achievable result is much better than it was without calibration.

And to answer to your question (if you didn't figured it out already): You should use the measures which you make after the hardware or VGA LUT calibration. (Because that is your current display characteristic.)

You can see hexagonal CIE diagrams when you measure the primaries and secondaries after you manipulated the primaries only. This is not a standard behavior for HDTVs or consumer PC monitors. May be this function can be used for better CMYK simulation (which is used by printers).

cyberlolo

11th June 2010, 10:58

But how are the chromaticity primaries (Rx Ry Gx Gy Bx By Wx Wy) measured? Yesterday, an ISF certified calibrator came home to calibrate my KRP-500A, and he didn't know how to get those values.

He used his calibration equipment, and he saw that in Pure mode, using Bumtious' settings, my set was already perfectly calibrated. He only had to tweak the color temperature to reach 6500K, but nothing else. And then, I showed him the yCMS manual and asked him to give me the chromaticity coordinates of my TV so I can enter them to create a custom 3dlut, but he didn't know how to get those values.

Any help here, please?

Mark_A_W

11th June 2010, 11:18

Measure Primaries with HCFR and export values to a spreadsheet. Is this what you want?

Measure Red Green Blue Yellow Cyan Magenta
X 14.10174 9.465929 4.771986 22.703403 14.206526 18.559078
Y 7.40095 20.656126 2.066542 27.544523 22.373522 9.33258
Z 0.631434 5.138814 25.99736 5.800269 31.580687 26.514742
R 34.007427 -3.639539 -0.67371 28.340027 -4.099868 32.5783
G 0.242164 29.789465 0.331876 29.909027 29.515242 0.621179
B -0.05774 1.744957 27.324909 1.775425 29.609224 27.156624
Rc 7359 1014 280 7929 1312 7477
Gc 911 6691 943 7526 7520 1842
Bc 317 2897 5284 3202 8234 5577

My friend is an ISF Calibrator, he went to the US to do the course. He only did it because he needed it as a "qualification" as a professional calibrator.

He said the course is a complete joke. It's like calibration for 5 year olds. So being an "ISF Calibrator" as such is almost meaningless, it bears no reference to their actual competence.

cyberlolo

11th June 2010, 11:54

Not exactly. What I want is something like this (values are not mine) for my display:

# Red chromaticity ......... Rx 0,640 - Ry 0,334
# Green chromaticity ....... Gx 0,285 - Gy 0,599
# Blue chromaticity ........ Bx 0,153 - By 0,076
# White point (default ).... Wx 0,313 - Wy 0,328

So with that info I can create a 3dlut with this line:

Gamut_Measurements 0.640 0.334 0.285 0.599 0.153 0.076 0.313 0.328

So my question is: how can I get this values that belong to my display?

Mark_A_W

11th June 2010, 12:14

Is this closer? I just picked xyY instead of RGB. (Sorry the columns get all mixed up).

Measure Red Green Blue Yellow Cyan Magenta White
x 0.637104 0.268454 0.145328 0.405069 0.208427 0.341119 0.316547
y 0.334368 0.585809 0.062935 0.491444 0.328246 0.171535 0.330533
Y 7.40095 20.656125 2.066542 27.544523 22.373521 9.33258 29.550847
delta E 9.6 15.6 5.3 8.7 11.6 17.1
delta xy 0.50% 3.50% 0.60% 2.00% 1.60% 0.027
delta luma 17.80% -2.30% -3.10% 0.50% -3.80% 10.90%

cyberlolo

11th June 2010, 12:26

Yes, Mark, I think you got it! With that info, your values are:

# Red chromaticity ......... Rx 0.637 - Ry 0,334
# Green chromaticity ....... Gx 0.268 - Gy 0.585
# Blue chromaticity ........ Bx 0.145 - By 0.062
# White point (default ).... Wx 0.316 - Wy 0.330

And now, can you PLEASE explain me how have you done it?

Mark_A_W

11th June 2010, 12:35

With my DIY HCFR probe, and the HCFR software.

There are cheap probes you can buy instead of build....probably cheaper than your ISF calibration..

http://www.homecinema-fr.com/colorimetre/index_en.php

I think I just answered half of my questions to Yesgrey myself (the other part being "how to get a custom gamma curve").

Mark_A_W

11th June 2010, 12:37

Oh, and these aren't my "real" measurements. These numbers come from some quick and dirty measurements on my 24" Sony CRT monitor, not my projector.

But I know how now :)

Just need to break out the tripod and measure the projector again (it's been a while).

Actually, my colour filtered CRT projector is very close to Rec 709. The reds a bit more saturated, but I kinda like that. I will try the Gamut cropping with the 3DLUT, but I will need a new videocard, the 2600XT stutters on bluray with the 3DLUT enabled.

cyberlolo

11th June 2010, 12:47

Cheers Mark, you've been of great help to me. I think I'll call the calibrator to see if he can come home again to use his probe with HCFR and get the values. Thank you!

Mark_A_W

11th June 2010, 12:50

If he saved the measurements, then he already has the values. He just has to find the values in xyY format, like I did.

yesgrey

11th June 2010, 13:04

Not exactly. What I want is something like this (values are not mine) for my display:
# Red chromaticity ......... Rx 0,640 - Ry 0,334
# Green chromaticity ....... Gx 0,285 - Gy 0,599
# Blue chromaticity ........ Bx 0,153 - By 0,076
# White point (default ).... Wx 0,313 - Wy 0,328

You're right, the manual is not clear enough. I will add that the coordinates must be in xyY format. Sorry for the trouble.

(the other part being "how to get a custom gamma curve").
What do you mean with that?
(1) How to measure your display's gamma curve or
(2) How to use yCMS to let you create your favorite gamma curve

Mark_A_W

11th June 2010, 13:17

"(2) How to use yCMS to let you create your favorite gamma curve "

There is an application on AVSforum called Video Equalizer.

http://www.avsforum.com/avs-vb/showthread.php?t=1042160
http://archive2.avsforum.com/avs-vb/showthread.php?t=777353

You can drag the curves around to create a custom gamma curve. All together, or one colour at a time.

It's used to create a custom gamma curve, but you have to run it each time you boot to load the custom gamma curve (a big limitation).

If this kind of interface, combined with the ability to call series of standard gamma curves (say 2.2, 2.3, etc), was combined with a colourimeter greyscale measurement, and yCMS, then we'd have a closed-loop custom gamma curve solution.

Combine this with the gamut correction, and it's perfect (isn't it?). You get a correct gamut and your desired gamma curve (standard or custom).

Mark

yesgrey

11th June 2010, 13:33

"(2) How to use yCMS to let you create your favorite gamma curve "
That's on my todo list too. ;)

To be honest, with the Grayscale_Measurements command it's already possible to do it, but it's not very user friendly... I already have some ideas on how to do it in a more friendly way, but we'll discuss it after I release the next yCMS version.

Mark_A_W

11th June 2010, 13:36

VideoEqualizer looks like this:

http://dl.dropbox.com/u/1372034/VideoEqualizer.jpg

And it kinda does "standard" gamma curves (LH lower sliders), but the numbers use the PC style numbers (which are backwards), not the "video" way of describing gamma.

janos666

11th June 2010, 19:09

But how are the chromaticity primaries (Rx Ry Gx Gy Bx By Wx Wy) measured? Yesterday, an ISF certified calibrator came home to calibrate my KRP-500A, and he didn't know how to get those values.

LOL. If that happened as I imagine, I would say: "Stop! Do not touch anything! Leave my house now, please." :p

ISF means nothing in my country. We just use the instruments. There are some barbarians who want to sell their half job for big price but others have EyeOne or ColorMunky and they know what they are doing and their price is good. (I bought an own colorimeter because I would like to test different settings. And I could do a favor for friends, as they did other favors for me in exchange, so it was not an expensive instrument at all.)

flanger216

12th June 2010, 01:19

My experiences with ISF 'technicians' have also been subpar at best. Not as bad as the yokels at the cable company, mind you --- I once had some cable tech, standing in my apartment, staring at a huge purple 60hz hum-bar wobbling down my TV, and he actually argued that the problem was caused by my speakers. He was, of course, referring to the magnetically shielded speakers that were sitting five feet from my LCD screen. I could only stare at him gape-jawed and politely observe that I'm pretty sure magnetic distortion looks nothing like that, that I'm pretty sure there are no magnetic fields in an LCD screen that could become improperly biased, and that I'm pretty sure it's just a ground loop caused by the oxidized bird's nest of coax cabling installed haphazardly on the roof of the apartment building. He stared at me like I was speaking Chinese. I swear to god, the cable guy didn't know what a freaking ground loop is.

So yeah, teaching yourself is the way to go :)

And thanks for the write-up on colorimetry, janos666... extremely helpful stuff!

P.S. I almost forgot the capper to the story: eventually I got so fed up that I went out and bought a big roll of coax cable, went up to the roof in the middle of the night, ripped out the cable company's mess and just reinstalled the whole stupid thing myself --- and I actually bothered to loop the cabling properly and (gasp!) put it in an enclosure so it wouldn't get rained on. Finally, no more ground loop. A few days later I overheard a few neighbors wondering if the cable company had done something to make their TVs look better :rolleyes:

sepheas

13th June 2010, 10:16

hello,

I would like to have more information about the custom gamma curve. In fact, I really don't understand the values : lv av pv threshold ?

The only thing I understood is pv= 1/gamma.

Is there a way to create a custom gamma curve with something like videoequalizer and then save it with the values ( lv/av/ap/threshold)

I mean, to adjust it graphically and then catch the values to paste into ycms.

sorry for my english, if there's errors

yesgrey

13th June 2010, 11:50

I really don't understand the values : lv av pv threshold ?
Those values are the coefficients of the transfer function (aka gamma curve) used.

Is there a way to create a custom gamma curve with something like videoequalizer and then save it with the values ( lv/av/ap/threshold)

I mean, to adjust it graphically and then catch the values to paste into ycms.
Those values only can be used if the custom gamma curve is representable by a power function, which does not seem to be what you want.

I'm considering adding some functionality in that area to yCMS, but I don't know when...

j5627429

18th June 2010, 16:48

Hi yesgrey,

First of all, I would like to thank you and madshi for your all of your great contributions to the HTPC world.

I've been trying for a while now with cr3dlut and now with yCMS, and I still can't figure out a way to get my primaries spot on with REC709.

I'm using a colormunki spectrophotometer to measure, which should be fairly accurate.

Setup:
ATI 5770 set to output RGB 4:4:4
FFdshow Video Decoder set to 0-255
madVR set to 0-255
Projector set to RGB limited, 6500K, 2.2 gamma)

I used this code with your latest yCMS release:

Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Gamut_Measurements 0.671 0.329 0.293 0.692 0.142 0.048 0.306 0.336

After applying the resulting 3dlut in madVR, my measured primaries are:
0.657 0.333, 0.286 0.609, 0.145 0.53

Which are much better than before but still not dead-on. I actually seem to recall getting a little bit more accuracy with the pixel shader method in EVR.

I have attached images of my before and after primaries.

Is there something that I'm not doing right or anything else that I can try?

Thanks in advance for your help!

kostik

18th June 2010, 17:15

yesgrey any progress about fixing the bugs with Grayscale_Measurements?
Thanks!

yesgrey

18th June 2010, 17:29

yesgrey any progress about fixing the bugs with Grayscale_Measurements?
Yes, they're fixed. I'm just cleaning up the code and making a few more tests before releasing the new version.

I still can't figure out a way to get my primaries spot on with REC709.
After fixing the problem above I've realized that if your display gamma curve is flawed you would only be able to get accurate gamut correction if you also perform gamma correction.

With the release of the new version I will also post some pictures showing this with my projector, which has a flawed gamma curve...

janos666

18th June 2010, 18:05

Yes, they're fixed.

Does it effect the Output_Transfer_Function command? I want to use that one because my gamma curve is already corrected through VGA LUT (gamma 2.2 for general PC usage...)

yesgrey

18th June 2010, 19:17

Does it effect the Output_Transfer_Function command?
Yes, but much less.

BeNooL

19th June 2010, 09:11

Setup:
ATI 5770 set to output RGB 4:4:4
FFdshow Video Decoder set to 0-255
madVR set to 0-255
Projector set to RGB limited, 6500K, 2.2 gamma)

Why set 0-255 (full range) everywhere but in the end set your projector to 16-235 (or limited) ?

j5627429

19th June 2010, 16:12

With the release of the new version I will also post some pictures showing this with my projector, which has a flawed gamma curve...

Great! Looking forward to it.

Why set 0-255 (full range) everywhere but in the end set your projector to 16-235 (or limited) ?

Should I be doing something different? I get really grey blacks If i set the projector to Expanded.

Honestly I'm not sure what the best way to set it up is. I don't mind if the PC desktop and games are innacurate. I just want to maximize the setup for optimum bluray playback. Should I set video card output to YCbCr 444 instead? Will MadVR and yCMS even work with that? Thanks for your help.

cyberlolo

19th June 2010, 16:56

Should I be doing something different? I get really grey blacks If i set the projector to Expanded.

Honestly I'm not sure what the best way to set it up is. I don't mind if the PC desktop and games are innacurate. I just want to maximize the setup for optimum bluray playback. Should I set video card output to YCbCr 444 instead? Will MadVR and yCMS even work with that? Thanks for your help.

May anybody correct me if I'm wrong, but my advice is to set madVR to TV Levels (unmolested), then set the projector to RGB Full, and finally create a 3dlut file adding this lines in yCMS for using it with madVR:

Input_Range 16 240
Output_Range 0 255

By the way, if you're using madVR, you'll need to output RGB. Always.

j5627429

19th June 2010, 20:05

May anybody correct me if I'm wrong, but my advice is to set madVR to TV Levels (unmolested), then set the projector to RGB Full, and finally create a 3dlut file adding this lines in yCMS for using it with madVR:

Input_Range 16 240
Output_Range 0 255

By the way, if you're using madVR, you'll need to output RGB. Always.

Okay I switched MadVR to TV levels and created an HD - Video.3dlut file with:
Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Input_Range 16 240
Output_Range 0 255

This still gives me proper blacks only if I keep the projector in "Limited" mode. Expanded washes everything out.

Do I have to change the video card output to "RGB limited" also? And what about the video decoder? Should stay on 0-255 input , 0-255 output within the video decoder?

Thanks

cyberlolo

19th June 2010, 20:32

Okay I switched MadVR to TV levels and created an HD - Video.3dlut file with:
Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Input_Range 16 240
Output_Range 0 255

This still gives me proper blacks only if I keep the projector in "Limited" mode. Expanded washes everything out.

Do I have to change the video card output to "RGB limited" also? And what about the video decoder? Should stay on 0-255 input , 0-255 output within the video decoder?

Thanks

Nope, you have to set the video card and the projector to Full RGB both. I think it's not working because you have to use this line:

Output_Format HD RGB_Video 16

instead of:

Output_Format HD RGB_PC 16

If it still doesn't work, please check the following:
1) Have you enabled the "use 3dlut" check box in the madVR settings dialog?
2) Is the created 3dlut file located in the madVR folder?
3) If you've only created a "HD - Video.3dlut" file, are you testing with a HD source video?
4) If you're using CoreAVC, do you have the Input and Output Levels set at Auto-detect?

yesgrey

19th June 2010, 23:18

This still gives me proper blacks only if I keep the projector in "Limited" mode. Expanded washes everything out.
Can you give us more info about your projector modes? Without knowing what exactly the "Limited" mode is I cannot help you...

And what about the video decoder? Should stay on 0-255 input , 0-255 output within the video decoder?
Don't worry with the video decoder. Those settings are used only when it outputs RGB, but when you use madVR the decoder outputs YV12, so you don't need to worry with those settings.

janos666

19th June 2010, 23:38

cyberlolo

20th June 2010, 01:04

j5627429

I think you should use RGB_PC output settings with full RGB range hardware setup or RGB_Video output settings with limited RGB range hardware setup.
"Expanded" mode sounds like it converts limited range to full range. So it should be used with RGB_Video output settings, but you shouldn't do that. (But this is only a guess.)
You shouldn't use the Output_Range command. It is already configured by the Output_Format command. (And you can mess your settings with duplications when you forget that they are duplicated and you try to edit only the first one...)

Maybe, but then he would not be able to keep some space over 235 for some excursions. That's why I recommended him a peak white value of 240, and that's only possible using RGB_Video instead of RGB_PC (which cuts any value over 235), and then using the Input&Output_Range commands.

j5627429

20th June 2010, 10:25

Nope, you have to set the video card and the projector to Full RGB both. I think it's not working because you have to use this line:

Output_Format HD RGB_Video 16

instead of:

Output_Format HD RGB_PC 16

If it still doesn't work, please check the following:
1) Have you enabled the "use 3dlut" check box in the madVR settings dialog?
2) Is the created 3dlut file located in the madVR folder?
3) If you've only created a "HD - Video.3dlut" file, are you testing with a HD source video?
4) If you're using CoreAVC, do you have the Input and Output Levels set at Auto-detect?

Okay I tried recreating the file with:
Output_Format HD RGB_Video 16
Input_Range 16 240
Output_Range 0 255
..and the blacks got even lighter.

1) yes
2) yes
3) yes
4) i was set to 0-255 0-255 in CoreAVC. However yesgrey just said that this doesn't matter.

Can you give us more info about your projector modes? Without knowing what exactly the "Limited" mode is I cannot help you...

I went back and verified it and the projector actually has three options: Standard, Expanded and Auto. Auto seems to have the same effect as "Standard" (it doesnt actually say "limited", sorry). This under the "HDMI settings". The projector is a JVC RS15. I'm using the standard cinema mode (cinema2) with 6500K color and 2.2 gamma selected, and all brightness and contrast and color sliders are set at the default middle position.

Don't worry with the video decoder. Those settings are used only when it outputs RGB, but when you use madVR the decoder outputs YV12, so you don't need to worry with those settings.
Good to know. Thanks!

janos666, That makes a lot of sense. Maybe I misunderstood what the projector is doing with the Standard and Enhanced setting. Here is what the manual says:
HDMI Input Level - Configures the input level setting of the HDMI input terminal.
Standard: For normal circumstances, select this setting.
Enhanced: Select this setting when the black-and-white of the projected image is unclear when RGB video signals are input from DVI devices.

I'll test the different configurations some more. It seems like setting madvr to video levels and using the Output Range command together with Output Format HD RGB_PC 16 to create the HD - Video.3dlut file looks exactly the same as keeping madvr at PC levels and not using the Output Range command (and naming the file HD - PC.3dlut of course)

yesgrey

20th June 2010, 12:21

The projector is a JVC RS15.

Here is what the manual says:
Standard: For normal circumstances, select this setting.
Enhanced: Select this setting when the black-and-white of the projected image is unclear when RGB video signals are input from DVI devices.

What manual is that? I've just downloaded the manual from JVC's site (http://www.service.jvcpro.eu/public/document.cfm?prog=InstrBook.cfm&Model=DLA-RS15) and look at what it says:
Standard: Select this when the dynamic range of the input images is 16-235.
Enhanced: Select this when the dynamic range of the input images is 0-255.

With this in consideration, you should use Standard when using RGB_Video output in yCMS, or you should use Enhanced when using RGB_PC output in yCMS - this is my recommended working mode.
If you are getting grey blacks with RGB_PC and Enhanced then it might be your graphics card drivers that are messing things up... I think I've read somewhere that sometimes they output video levels. Check that.

j5627429

20th June 2010, 13:53

What manual is that? I've just downloaded the manual from JVC's site (http://www.service.jvcpro.eu/public/document.cfm?prog=InstrBook.cfm&Model=DLA-RS15) and look at what it says:

With this in consideration, you should use Standard when using RGB_Video output in yCMS, or you should use Enhanced when using RGB_PC output in yCMS - this is my recommended working mode.
If you are getting grey blacks with RGB_PC and Enhanced then it might be your graphics card drivers that are messing things up... I think I've read somewhere that sometimes they output video levels. Check that.

That was from my old jvc rs2 manual because I couldn't find my rs15 manual. the function seems to operate in the same way, though I have to say the rs15 wording is much more clear.

Thanks for the help. I'm going to try different ati driver versions to see if I can get it to output pc levels.

yesgrey

20th June 2010, 14:51

I'm going to try different ati driver versions to see if I can get it to output pc levels.
Isn't there any driver setting for just that? or any registry key?

j5627429

20th June 2010, 19:22

Isn't there any driver setting for just that? or any registry key?

There is a setting in the "Video" section of the ATI driver panel that can be enabled and set to full or limited. However, I have tested it and it seems to have not effect whatsoever on either the desktop or the video.

Over at the AVSforum, it seems to be a known issue for some users of ati 5xxx cards, according to Andy o's thread (http://www.avsforum.com/avs-vb/showthread.php?t=1224697&highlight=rgb+full).

- Pixel Format RGB Full in some systems is broken, it seems to output desktop colors at the same levels as Limited. For some others (like me) this doesn't happen and RGB Full and Limited work as expected (Full outputs 0-255 and Limited 16-235). We don't know yet if the display affects the cards' output, but we're trying to test that.

I just tried plugging the projector straight into the video card, but the result is the same. The video card's Pixel Format setting of RGB 444 Full is using Limited levels.

yesgrey

20th June 2010, 21:34

I just tried plugging the projector straight into the video card, but the result is the same. The video card's Pixel Format setting of RGB 444 Full is using Limited levels.
It might not be exactly an issue...

Try this: instead of madVR use VMR9 or EVR, whether you are using XP or Vista/W7, and play a video without converting it to RGB. Let the renderer perform the conversion. Perhaps that setting only affects the conversion from YV12 -> RGB within the Microsoft renderers...
However, it should output always full RGB when feed with RGB, but let's consider that later...

Edit: It also might be a "smart" setting that detects you're using HDMI and then forces video levels... Have you tried connecting your projector with a DVI cable?

j5627429

21st June 2010, 16:24

It might not be exactly an issue...

Try this: instead of madVR use VMR9 or EVR, whether you are using XP or Vista/W7, and play a video without converting it to RGB. Let the renderer perform the conversion. Perhaps that setting only affects the conversion from YV12 -> RGB within the Microsoft renderers...
However, it should output always full RGB when feed with RGB, but let's consider that later...

Edit: It also might be a "smart" setting that detects you're using HDMI and then forces video levels... Have you tried connecting your projector with a DVI cable?

I haven't tried your first suggestion yet, but i did try using a DVI>HDMI adapter and sure enough, it is outputting PC levels. I had to change the HDMI setting of the projector to Expanded and everything looks normal.

I retook my red green and blue measurements with madVR set to 0-255 and 3dlut off, it looks like my x and y uncalibrated primary coordinates are no different than when my video card output was using video levels, so i guess my gamut correction problems are gamma related (as you mentioned earlier) and not related to the incorrect levels.

yesgrey

23rd June 2010, 10:26

yCMS v1.3 released

http://yesgrey.com/ycms.html

- The extension ".3dlut" is automatically added when missing.
- Video data below black and above white is not clipped anymore.
- Fixed RGB_Video setting. It was not working as it should.
- Removed parameter "mode" from Input/Output_Transfer_Function commands.
- Fixed Grayscale_Measurements command.
- Grayscale_Measurements command no longer supports measures for R,G,B.

Here it is.:)

The Grayscale_Measurements command should work fine now, but I recommend to be careful when using any measurements below 30 IRE. Some meters have lower accuracy at these levels, which might not give you good results...

All the reported cases with samples are working fine now, but I would like you to confirm that. If you could also post some images it would be even better.;)

I've removed temporarily the possibility of using measures for all color channels (R,G,B). I will add it again later.

When using the colorSpace setting RGB_Video yCMS was not working as it should. I would like users that have displays which support both video and PC levels to try both and verify if the image is exactly the same.

I will now prepare an example case...

Mark_A_W

23rd June 2010, 10:54

Please, we need a tutorial on the Greyscale Measurements function!!

yesgrey

23rd June 2010, 11:20

Please, we need a tutorial on the Greyscale Measurements function!!
I've just added my projector's calibration results on the third (http://forum.doom9.org/showpost.php?p=1402014&postcount=3) post (be a little patient because the pictures are waiting approval).

I will try to add later a more detailed explanation.

kostik

23rd June 2010, 12:09

So what measurments I need to put in Greyscale Measurements?
here is a picture with my Measurements from HCFR:

janos666

23rd June 2010, 21:59

I can see a firework with these settings (random pixels with full luminance primary colors):

# Source video format
Input_Format HD YCbCr 8

#3DLUT output format
Output_Format HD RGB_PC 16

Grayscale_Measurements
0 0.280090
10 1.301639
20 4.721668
30 11.083349
40 20.292418
50 33.596230
60 49.406956
70 70.420677
80 93.451164
90 122.102531
100 153.203751

# Gamut correction - measured native x;y coordinates
Gamut_Measurements 0.681838 0.306449 0.223260 0.699915 0.145035 0.063559 0.315212 0.329198

And this version doesn't want to create any LUT file with this command. (I copy-pasted it from the manual...)
Output_Transfer_Function 0 1.0 0.0 0.45 0.0

These are different numbers than I used to post earlier. This is not a mistake, I have a new display... :cool:

sepheas

23rd June 2010, 22:36

I've got a problem. When I want to créate a 3dlut file. Windows report me an error with the color management system. the service stopped.

Why ?

edit : yep it's the same thing. There's a problem with "output_transfert_function"

janos666

23rd June 2010, 22:59

I saw that error with v1.2 on a Vista x64 machine without the output_transfert_function command. I couldn't find any solution (run as admin, both x86 and x64 versions, ect...).
I didn't receive any error (Win7_x64) but it simply refused to create the file with that command.

yesgrey

24th June 2010, 00:52

I can see a firework with these settings (random pixels with full luminance primary colors):
Try without the measurements below 30 IRE. ;)

And this version doesn't want to create any LUT file with this command. (I copy-pasted it from the manual...)
Output_Transfer_Function 0 1.0 0.0 0.45 0.0
yep it's the same thing. There's a problem with "output_transfert_function"
Try without the first number after the command name.

Edit: I've confirmed that there is a bug in yCMS, because it shouldn't crash, but if you use the expected parameters it will work fine. I will correct this for not crashing when the wrong parameters are used, but only for next version.

yesgrey

24th June 2010, 01:03

Another thing. I've noticed some people use greyscale, while others use grayscale. I think both can be used, but I've named the command after the last one. I'm not English native, so I don't know which would be more accurate...

Can anyone enlighten me?

flanger216

24th June 2010, 03:13

Both are perfectly fine. One is more native to the UK, the other an American 'mutation,' but both are correct.

Mark_A_W

24th June 2010, 03:34

Yesgrey

Is it possible to add more data points? Like hundreds of them (obviously not manually)?

And can it be done separately for R, G and B? That's very important, to me at least.

Thanks

Mark

madshi

24th June 2010, 07:01

Hint: try without the measurements below 30 IRE. ;)
FWIW:

Yes, but even if the meter is giving bad results for < 30 IRE, that doesn't explain the "firework" janos666 is getting. Bad measurements below 30 IRE would explain problems like bad shadow detail or increased visibility or noise or things like that. But the "firework" points to a clear bug in yCMS.

yesgrey

24th June 2010, 11:31

Both are perfectly fine. One is more native to the UK, the other an American 'mutation,' but both are correct.
Thanks for the clarification. I will keep the current name then.

And can it be done separately for R, G and B?
Yes it can. I only disabled the separated measures to not further delay the release of the new version.

Bad measurements below 30 IRE would explain problems like bad shadow detail or increased visibility or noise or things like that. But the "firework" points to a clear bug in yCMS.
Yes, I will check that. I don't have yCMS immune to bad measures, yet.

yesgrey

24th June 2010, 11:41

And this version doesn't want to create any LUT file with this command. (I copy-pasted it from the manual...)
Output_Transfer_Function 0 1.0 0.0 0.45 0.0

Sorry, I missed that you have copy pasted it from the manual. :o
It's a typo in the manual. Remove the first 0 and it will run fine.

kostik

24th June 2010, 11:57

So what measurments I need to put in Greyscale Measurements?
can someone help me with this? I uploaded a pic of hscfr with my measurments some posts above.
thanks!

madshi

24th June 2010, 12:13

Yes, I will check that. I don't have yCMS immune to bad measures, yet.
Is there a way to detect bad measures with our eyes? I mean janos666's measurements look reasonable to me. How can we see if they're bad or not? JFMI...

yesgrey

24th June 2010, 17:19

So what measurments I need to put in Greyscale Measurements?
Only now the picture was displayed...

With the current version not accepting the grayscale for each color channel, you should change from RGB to xyY in the selection group you've pointed, and use the values of Y. Use values from 30 to 100 IRE.

kostik

24th June 2010, 17:22

Only now the picture was displayed...

With the current version not accepting the grayscale for each color channel, you should change from RGB to xyY in the selection group you've pointed, and use the values of Y. Use values from 30 to 100 IRE.

great thanks!

flanger216

24th June 2010, 17:29

I'm also a little surprised about the warning for low-IRE measurements. I have found that my Spyder 3 Pro does give wildly inconsistent results at low-IREs in HCFR, but that's at default settings: I've also found that if you set the read-time from 3000ms to something more like 9000ms, it gives me dead-on consistency out to three decimal places, pretty much every time. I realize consistency doesn't necessarily correlate to accuracy, but the low-IRE readings correspond to what I'm seeing with my eyes, make sense in terms of colorimetrical theory and, most importantly, I'm using my 10-30IRE measurements in yCMS right now and not seeing any problems. So what's the issue?

yesgrey

24th June 2010, 17:45

I'm also a little surprised about the warning for low-IRE measurements.
Ok, you're right, I was too cautious with my warning. I've rephrased it:
I recommend to be careful when using any measurements below 30 IRE. Some meters have lower accuracy at these levels, which might not give you good results...
I hope it's better now.;)

And it's good to know that you're having good results even with low IREs.:)

flanger216

24th June 2010, 18:41

Ok, you're right, I was too cautious with my warning. I've rephrased it:

I hope it's better now.;)

And it's good to know that you're having good results even with low IREs.:)

Ah, gotcha. I thought there was some inherent, theoretical reason that I wasn't understanding. But now it looks like, if it works, then use it!

BTW, it's looking freaking fantastic, yesgrey. I've never gotten this sort of performance out of my display before.

yesgrey

24th June 2010, 19:11

But now it looks like, if it works, then use it!
Yes, that's it.

BTW, it's looking freaking fantastic, yesgrey. I've never gotten this sort of performance out of my display before.
It's good to know that, and this is just the beginning... :)

yesgrey

24th June 2010, 19:17

Is there a way to detect bad measures with our eyes? I mean janos666's measurements look reasonable to me. How can we see if they're bad or not? JFMI...
The only way would be tracing the curve and looking at it to find any oddity, and even with that it might not be so simple...

janos666

24th June 2010, 22:55

This image shows the gamut coverage with native gmaut + yCMS 1.3 and U2410 in sRGB mode: HCFR - CIE charts (http://img12.tar.hu/janos666/img/77699490.png)
This display wins in the degree of the total uncovered + oversaturated areas. I think that blue would be oversaturated as well but my display can't show that color...
But I think I would choose the small oversaturation instead of the smaller oversaturations with an unnecessary clipping from the coverable gamut.

And here is a screenshot with the "firework" (I saw a different scene with more random colors when I gave it that name :p): click (http://img12.tar.hu/janos666/img/77701281.png)
I made it with this screenshot with the following settings:

# Source video format
Input_Format HD YCbCr 8

#3DLUT output format
Output_Format HD RGB_PC 16

Grayscale_Measurements
0 0.212637
10 1.141124
20 4.312172
30 10.302929
40 18.898254
50 31.034897
60 45.865826
70 64.588158
80 86.119484
90 112.591156
100 141.689590

# Gamut correction - measured native x;y coordinates
Gamut_Measurements 0.690234 0.299633 0.222931 0.703515 0.144627 0.062981 0.313639 0.330513

These are new measurements with different hardware settings. (I hate my new display. It was so cool when I tested my friend's one but I hate this one. I had to calibrate it from the factory menu to get a usable state. There was a serious mess in there... But my old and cheaper display looks better than this relatively expensive shit...)
I used HCFR 2.1 with an EyeOne and I set it to "Average many reads on dark measurements" mode. The display is calibrated to gamma 2.2 with the VGA LUT. (And it was in the native gamut.) But this is a crippled display anyway, so these measures can be wrong and my real gamma curve could be very strange. My LUT curves are strange...

I tried to use the Output_Transfer_Function 1.0 0.0 0.45 0.0 again but I don't think it is correct with v1.3 (as it never was...) or I don't think I would do a proper gamma correction. :p

yesgrey

25th June 2010, 20:00

yCMS v1.4 released

http://yesgrey.com/ycms.html

- Fixed "firework" bug on Grayscale_Measurements.
- Re-added support of different measures for R,G,B on Grayscale_Measurements.
- Increased maximum number of measurements on Grayscale_Measurements to 256.
- Fixed bug on Input/Output_Transfer_Function.

madshi

25th June 2010, 20:28

Very cool - congrats on the new version!

janos666

26th June 2010, 13:13

Yes, firework is gone. And you were right about the "wrong measures".
This Dell U2410 display is really sick. The standar mode has a gamma curve which lies around the gamma 1.8 curve and I tried to calibrate it with gamma 2.2 curve (by VGA LUT). The white balance is acceptable in the middle range but it is a complete mess near to black and white. (Other presets has their own sicknesses but I don't want to write too much about it in this topic...)
So, my measures were good readings but my display was a mess. I won't keep this industrial trash. :devil:

yesgrey

26th June 2010, 14:08

The white balance is acceptable in the middle range but it is a complete mess near to black and white.
Why don't you try correcting your gamma curve with yCMS? Now, with 256 measures at a maximum, you could fit your data to your display... and don't worry, because you won't need 256 measures for a good result.;)

janos666

26th June 2010, 15:54

Yes, I will try to do a Rec709->sRGB gamma correction. I will start with the transfer function command first and I will try to measure and add the 10..50..90, 0..5 and 95..100 grayscale.
But it won't make this display better for general PC usage (video games, photo viewing/editing, ect...).
The only usable state is the sRGB preset with sRGB calibration. This preset already does an sRGB gamut correction (in worse quality than your software does).

janos666

28th June 2010, 15:51

I think there is another bug with the Output_Transfer_Function 1.0 0.0 0.45 0.0 command. It produces the same thing with dark shades as older versions did with red and blue colors (without gamma correction): hint (http://forum.doom9.org/showpost.php?p=1412406&postcount=3451)
But I am not sure about that with my sick display.

Screenshots: original (http://img12.tar.hu/janos666/img/78096055.png) - gamma corrected (http://img12.tar.hu/janos666/img/78096054.png)
My input commands (the only difference was that the transfer function command was used of not...):

# Source video format
Input_Format HD YCbCr 8

#3DLUT output format
Output_Format HD RGB_PC 16

#Gamma correction - Measured Grayscale Y values
Output_Transfer_Function 1.0 0.0 0.45 0.0

# Gamut correction - measured native x;y coordinates
Gamut_Measurements 0.656699 0.331398 0.319551 0.607242 0.152108 0.077788 0.345703 0.358539

yesgrey

28th June 2010, 22:21

I think there is another bug with the Output_Transfer_Function 1.0 0.0 0.45 0.0 command.
Ok, I will take a look...

Thanks for reporting.

tschi

1st July 2010, 23:03

Hi Yesgrey

First, Thank you for yCMS.:)

I tried to use v1.4 using madVR 0.21
When I am using yCMS, I have a perfect gamut coordinate (sorry for the vocabulary I am a noob in calibration and in English)
but my gamma is decrease from 2.15 to 2

I had made some screenshots of calibration result :

Using madVR 0.21 and PC Level no 3dlut, yCMS 1.4
mpc hc last built, ATI 5770 with FULL RGB Output, X-RITE Display 2

gamma :
http://img5.imageshack.us/img5/8812/gamawoycms.png

gamut:
http://img198.imageshack.us/img198/5751/triangervbavantcorrecti.png

RVB grayscale
http://img694.imageshack.us/img694/8650/rvbavantycms.png

Using madVR 0.21 and PC Level with 3dlut, yCMS .14
mpc hc last built, ATI 5770 with FULL RGB Output, X-RITE Display 2
My HD - PC.txt files :
http://pastebin.com/6UcrWEsF

create with this coordinates
http://img145.imageshack.us/img145/2739/coordinate.png and
http://img21.imageshack.us/img21/3060/rvbgrayscalecoordinate.png

Gamma with yCMs is decrease
http://img227.imageshack.us/img227/1450/gammaycmsperdu.png

Gamut is quite good (in my understanding)
http://img18.imageshack.us/img18/2163/triangleycms.png

rvb grayscale
http://img130.imageshack.us/img130/6887/rvbgrisycms.png

Do I made something wrong ? Or can I increase my gamma using any parameter ?

Thank you for help :thanks:

cyberbeing

2nd July 2010, 01:44

I have the same gamma 'problem' as Tschi, but even worse.

yCMS 1.4 using Grayscale_Measurements is converting my sRGB (2.20 gamma) calibrated monitor to BT.709 with an avg target gamma of 1.89. Using a gamma of 1.89 kills contrast and would only be useful under very bright viewing conditions.

Since BT.709 doesn't have a native target gamma, you really should be targeting a gamma of 2.2 or possibly even 2.4 by default. Having a user configurable BT.709/BT.601 avg target gamma between 1.8 and 2.8 is also something very needed. That should cover the majority of the needed gammas for bright to dark viewing conditions.

The ArgyllCMS manual explains this situation a bit.
-g gamma Set the target response curve gamma. This is normally an exponential curve (output = input ^gamma), and defaults to 2.4 on MSWindows and Macintosh OS X 10.6 or latter and Linux/Unix (which is typical of a CRT type displays real response), and 1.8 on a Macintosh (prior to OS X 10.6). Four pre-defined curves can be used as well: the sRGB colorspace response curve, which is an exponent curve with a straight segment at the dark end and an overall response of approximately gamma 2.2 (-gs), the L* curve, which is the response of the CIE L*a*b* perceptual colorspace (-gl). the REC 709 video standard response curve (-g709) and the SMPTE 240M video standard response curve (-g240)

Note that a real display can't reproduce any of these ideal curves, since it will have a non-zero black point, whereas all the ideal curves assume zero light at zero input. In the case of a gamma curve target, dispcal uses an actual technical power curve shape that aims for the same relative output at 50% input as the ideal gamma power curve. To allow for the non-zero black level of a real display, by default dispcal will offset the target curve values so that zero input gives the actual black level of the display (output offset). This ensures that the target curve better corresponds to the typical natural behavior of displays, but it may not be the most visually even progression from display minimum, but this behavior can be changed using the -f option (see below).

Also note that many color spaces are encoded with, and labelled as having a gamma of approximately 2.2 (ie. sRGB, REC 709, SMPTE 240M, Macintosh OS X 10.6), but are actually intended to be displayed on a display with a typical CRT gamma of 2.4 viewed in a darkened environment. This is because this 2.2 gamma is a source gamma encoding in bright viewing conditions such as a television studio, while typical display viewing conditions are quite dark by comparison, and a contrast expansion of (approx.) gamma 1.1 is desirable to make the images look as intended. So if you are displaying images encoded to the sRGB standard, or displaying video through the calibration, just setting the gamma curve to sRGB or REC 709 (respectively) is probably not what you want! What you probably want to do, is to set the gamma curve to about gamma 2.4, so that the contrast range is expanded appropriately, or alternatively use sRGB or REC 709 or a gamm of 2.2 but also use the -a parameter to specify the actual ambient viewing conditions, so that dispcal can make an appropriate contrast enhancement. If your instrument is capable of measuring ambient light levels, then you can do so during the interactive display control adjustment. See <http://www.color.org/sRGB.xalter> for details of how sRGB is intended to be used.

-a ambient: As explained for the -g parameter, often colors are encoded in a situation with viewing conditions that are quite different to the viewing conditions of a typical display, with the expectation that this difference in viewing conditions will be allowed for in the way the display is calibrated. The -a option is a way of doing this. By default dispcal will not make any allowances for viewing conditions, but will calibrate to the specified response curve, but if the -a option is used, or the ambient level is measured during the interactive display controls portion of the calibration, an appropriate viewing conditions adjustment will be performed. For a gamma value or sRGB, the original viewing conditions will be assumed to be that of the sRGB standard viewing conditions, while for REC 709 and SMPTE 240M they will be assumed to be television studio viewing conditions. By specifying or measuring the ambient lighting for your display, a viewing conditions adjustment based on the CIECAM02 color appearance model will be made for the brightness of your display and the contrast it makes with your ambient light levels.
In addition to having a user selectable avg target gamma, it seems that adding optional CIECAM02 (http://en.wikipedia.org/wiki/CIECAM02) Average, Dim, Dark viewing conditions to LUT creation may not be a bad idea either. You may what to even want to consider using CIECAM02 CAT02 for your chromatic adaptions if you are not already, as it is the most modern method.

janos666

2nd July 2010, 01:46

Do I made something wrong ? Or can I increase my gamma using any parameter ?

These parameters are correlated. You can use the grayscale_measurements (may be now) or the output_transfer_function (when it will be fixed) commands to correct your gamma curve as well.

I don't have acceptable results with any of them but it can be my personal problem, and yesgrey is still working on this software.
(I will replace my display with a warranty-replacement and I will also replace my colorimeter with a spectrophotometer next week. So, there is some trouble here, yet.)

cyberbeing

2nd July 2010, 01:55

Bug (same as prior versions)

Grayscale_Measurements
0 0.008
10 0.370 0.451 0.480
20 3.082 2.952 2.902
30 6.441 6.422 6.354
40 11.669 11.677 11.591
50 18.739 18.606 18.615
60 27.551 27.148 27.093
70 38.179 38.272 38.055
80 51.758 52.215 51.828
90 68.327 68.625 67.421
100 85.468 85.004 86.309
&
Grayscale_Measurements
0 0.008 0.008 0.008
10 0.370 0.451 0.480
20 3.082 2.952 2.902
30 6.441 6.422 6.354
40 11.669 11.677 11.591
50 18.739 18.606 18.615
60 27.551 27.148 27.093
70 38.179 38.272 38.055
80 51.758 52.215 51.828
90 68.327 68.625 67.421
100 85.468 85.004 86.309Messed up dark colors. (http://img714.imageshack.us/img714/6935/incorrect.png)
_____
Grayscale_Measurements
10 0.370 0.451 0.480
20 3.082 2.952 2.902
30 6.441 6.422 6.354
40 11.669 11.677 11.591
50 18.739 18.606 18.615
60 27.551 27.148 27.093
70 38.179 38.272 38.055
80 51.758 52.215 51.828
90 68.327 68.625 67.421
100 85.468 85.004 86.309
Somewhat correct looking dark colors. (http://img257.imageshack.us/img257/3921/correctyetbright.png)

yesgrey

2nd July 2010, 12:51

my gamma is decrease from 2.15 to 2
Please tell me how do you measure your gamma with and without yCMS correction.

yesgrey

2nd July 2010, 12:52

You may what to even want to consider using CIECAM02 CAT02 for your chromatic adaptions if you are not already, as it is the most modern method.
Thanks for the info. :)

yesgrey

2nd July 2010, 12:57

Bug (same as prior versions)
If you want to use low IRE measures with yCMS you should use more measures. 10 ire steps are too large, try with 2 ire steps below 30 IRE.

cyberbeing

2nd July 2010, 16:01

Please tell me how do you measure your gamma with and without yCMS correction.

I know how I measured my gamma decrease.

First I downloaded the BT.709 testpatterns from here: http://www.avsforum.com/avs-vb/showthread.php?t=948496

I loaded up ColorHCFR in DVD Manual mode.
I opened up the '10% Grayscale.mp4' from the BT.709 testpatterns.
I ran the 0-100 IRE (steps of 10) Grayscale test with and without my 3DLUT enabled in madVR.

ColorHCFR calculates the gamma when the Grayscale test is finished.

yCMS with grayscale_measurements also seems to make my DeltaE values much worse.

http://img52.imageshack.us/img52/430/beforeafterycms.th.png (http://img52.imageshack.us/img52/430/beforeafterycms.png)

If you want to use low IRE measures with yCMS you should use more measures. 10 ire steps are too large, try with 2 ire steps below 30 IRE.
I did steps of 1 ire from 1 to 30 IRE and that did seem to help, but I have to pretty much guesstimate IRE 1-5 values since the Eye One Pro can't reliably measure luminance below 0.01 cdm2. Yet my avg gamma still ended up being 1.9 which is way too bright. Why is it even ending up at a gamma of 1.9 anyways?

Note: For various reasons, the below setting should not be directly compared to my previous ones (different max luminance, didn't make a new calibration beforehand). Real measurements, but only meant for a quick test.
# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

Grayscale_Measurements
0 0.000
1 0.001
2 0.002
3 0.004
4 0.008
5 0.010
6 0.069
7 0.127
8 0.234
9 0.296
10 0.527 0.495 0.578
11 0.904 0.818 0.877
12 1.129 1.007 1.118
13 1.632 1.390 1.517
14 2.066 1.694 1.854
15 2.381 2.062 2.216
16 2.669 2.315 2.445
17 3.093 2.661 2.834
18 3.414 2.952 3.109
19 3.770 3.234 3.394
20 4.076 3.489 3.655
21 4.417 3.815 4.163
22 4.728 4.290 4.490
23 5.215 4.654 4.848
24 5.633 5.033 5.414
25 6.074 5.458 5.816
26 6.688 5.963 6.227
27 6.926 6.407 6.629
28 7.553 7.043 7.299
29 8.155 7.351 7.792
30 8.594 7.995 8.295
40 15.617 15.227 15.675
50 24.700 23.439 24.055
65 44.360 43.390 44.042
71 54.803 52.638 53.461
75 60.259 57.928 58.859
78 65.379 63.618 64.636
81 71.284 69.470 70.711
84 77.764 75.635 76.382
87 84.498 82.118 82.993
90 91.691 88.897 91.127
93 99.373 95.965 97.509
96 105.940 103.375 105.167
100 112.784 110.141 112.136

# Display Gamut Measurements
Gamut_Measurements 0.626 0.343 0.295 0.606 0.149 0.079 0.314 0.328

Hopefully you do plan to add a way to scale the BT.709/BT.601 gamma curves...

Anybody willing to code something to parse exported HCFR GrayScaleSheet.csv measurements into the correct grayscale_measurments format for yCMS? Manually entering all those values one by one is very time consuming.

janos666

2nd July 2010, 19:43

Anybody willing to code something to parse exported HCFR GrayScaleSheet.csv measurements into the correct grayscale_measurments format for yCMS? Manually entering all those values one by one is very time consuming.

I already wanted to ask it. I can measure the whole 8 bit grayscale if that would be automatic.
I can leave the PC alone... or not... A spectrophotometer needs black level calibration in every 3-10 minutes.

But I think that a proper output_transfer_function feature would be the best way for PC attached devices because we can use the VGA LUT to correct the white balance and the gamma curve together with automated softwares. And it has to be done for general PC usage anyway. A new grayscale measurement after a display calibration is only one more error factor.

tschi

2nd July 2010, 22:07

Please tell me how do you measure your gamma with and without yCMS correction.
I use colorHCFR with 1080p files from Homecinema-fr http://www.homecinema-fr.com/forum/viewtopic.php?f=1196&t=29912662
and I read grayscale with mpchc / ffdshow video no filter only decoder and madVR
First time madVR has 3dlut off -> I read files and take gamma with colorhcfr
2nd time madVR with 3dlut on -> I read files and take gamma with colorhcfr
The only change is madVR 3dlut off / on
Tonight I calibrated my gamma to 2.35
http://img697.imageshack.us/img697/3801/woycms0702.png
and after with yCMS :
http://img408.imageshack.us/img408/5507/ycms0702.png
my gamma is decrease to 1.94, a bit less than before

tschi

2nd July 2010, 22:26

These parameters are correlated. You can use the grayscale_measurements (may be now) or the output_transfer_function (when it will be fixed) commands to correct your gamma curve as well.

I don't have acceptable results with any of them but it can be my personal problem, and yesgrey is still working on this software.
(I will replace my display with a warranty-replacement and I will also replace my colorimeter with a spectrophotometer next week. So, there is some trouble here, yet.)

Thank for the info

Mark_A_W

2nd July 2010, 23:32

I know this is not the answer, but can you workaround the gamma issue by tweaking the desktop gamma after tweaking the 3DLut?

(And I have a better video card now, so I will start playing with yCMS too, but I'm just a hack compared to some of you guys. Before I got stutters with the 3DLut enabled.)

yesgrey

3rd July 2010, 00:51

I ran the 0-100 IRE (steps of 10) Grayscale test with and without my 3DLUT enabled in madVR.
I use colorHCFR with 1080p files from Homecinema-fr
Thanks. Exactly how I supposed.

Would it be possible for you to send me your HCFR before and after results files? That way I could install HCFR and analyze with more detail your results... Furthermore, Could you also measure the gamma curve with yCMS using the Grayscale_Measurements, but without the Gamut_Measurements?

I did steps of 1 ire from 1 to 30 IRE and that did seem to help, but I have to pretty much guesstimate IRE 1-5 values since the Eye One Pro can't reliably measure luminance below 0.01 cdm2.
Have you tried not setting below 10 ire and let yCMS calculate the values for you?

You could also try putting your meter closer to your projector for those measurements and take a reading for one common ire value at both distances, and then scale the values accordingly.

Hopefully you do plan to add a way to scale the BT.709/BT.601 gamma curves...
Yes, that's planned.

yesgrey

3rd July 2010, 09:04

But I think that a proper output_transfer_function feature would be the best way for PC attached devices because we can use the VGA LUT to correct the white balance and the gamma curve together with automated softwares.
It would not be the best, because the gamut correction would be less accurate. Have you seen my example?
Furthermore, it would not be used the madVR capability of dithering the output from 16 bit to 8 bit, which could add some banding...

Until we have higher bit depths at desktop (which I don't believe it would happen soon) there is no better option than using madVR. Yes, I know that madVR does not fulfill all needs, but who knows, maybe one day the software houses (game developers) decide to support 3DLUT files and also dither from 16 bit to 8 bit... :D

janos666

3rd July 2010, 10:50

It would not be the best, because the gamut correction would be less accurate. Have you seen my example?
Furthermore, it would not be used the madVR capability of dithering the output from 16 bit to 8 bit, which could add some banding...

Until we have higher bit depths at desktop (which I don't believe it would happen soon) there is no better option than using madVR. Yes, I know that madVR does not fulfill all needs, but who knows, maybe one day the software houses (game developers) decide to support 3DLUT files and also dither from 16 bit to 8 bit... :D

- Most of the VGAs have 16 bit LUT which can output 10+ bit/color for displays (mine has a 8+2bit panel as well).
- I have to calibrate my display to D65 and gamma 2.2 (via VGA LUT) for general PC usage anyway.
- This display is able to do internal sRGB gamut conversion. (I wasn't able to test it's quality because I need a new instrument. So, may be it is inferior.)

So, the only thing I really need is a rec709->gamma2.2 gamma correction.

But I don't get the whole idea.
- A proper CMS should handle the gamut and the gamma together. I mean, gamut clipping can mess with the average gamma but that should be compensated or corrected as well (where the targets can be new values or the same input values before the side effects of the other corrections).

Why is it different when I want to define the target gamma with a theoretically perfect curve?
- My display will be as close to the theoretical characteristic as it can be. (Calibrated through the VGA LUT). Everything is already done which can be achieved by softwares (in this area).
- Instruments are not perfect. Interpolation is not perfect. A new measure set after the VGA-LUT calibration and a new interpolation from the values will have errors as well as everything in the past.
- Gray-scale measurements will produce an interpolated curve with more errors. The output_transfer_function will use the exact curve (which is theoretically achieved already).

No, I am not sure about my words. This is only my theory. :rolleyes:

janos666

3rd July 2010, 11:14

I have an idea for PC Games. We can use a lot existing softwares with their existing features. It will require a little new software only to do some tricks.
- Players which have support for madVR can play streamed videos. (And we can play with the buffer length. It will be a "local broadcast" and we don't need too much lag.)
- We can capture and save all of the rendered frames and we don't need to encode them. We need to store the last few uncompressed frames only (less is better).
- The captured, uncompressed video frames can be rendered by madRV (also with short buffer length).

We need only one new software which captures the rendered frames and send it to the player.
And the trick is that a modern VGA can use two or more displays. We need to force the game to be rendered on a fake virtual display (in full-screen mode) and we can watch the color corrected frames on a full-screen video player (while the cursor -mouse and keyboard- is operating on the virtual display - until you quit from the game, and the streaming software...).
(We can use a modified DVI->Dsub adapter to get a virtually existing display under Vista/Win7.)

Who wants to be the coder? :script::):)

nevcairiel

3rd July 2010, 12:07

janos666

3rd July 2010, 19:50

I have a U2410 as well, and while i agree that the "Standard" mode is pretty much unusable, the sRGB and Adobe RGB work pretty well. Combined with some minor adjustments through yCMS, i get really good output colors. :)

///OFF TOPIC
This is my third U2410 (in the last ~10 days) and I am waiting for my fourth. :devil:
- The first one had very low contrast ratio (~500:1) and the near-black gray-scale was equally black. The RGB Level graph was a joke.
- The second one had some regular sub-pixel errors and there was a strange panel error (I could see a lot of little dots on the 0% black test image, like the sky with the stars). But it had an acceptable contrast ratio (~700:1) and RGB Level graph.
- The third one had a contamination between the plastic layers. It has a very good contrast ratio (~800:1) and the RGB Graph is very nice as well (the contrast ratio is still ~800:1 after the calibration). But it has the worst gray-scale which I ever saw on U2410 displays. Near-black shades are equally black and there is some nonlinearity on the middle IREs as well. (And this is the latest A02 Revision, the last two was A01. So, they tried their best...)

The worst thing about the third one: I heard that the contamination may fall if I knock it with my nail. I couldn't believe it but the little bastard felt when I let my friend to play a wiZzzard. It is very near to a corner now and it is hardly noticeable. I need to take a closer look to find it. I think I would never find it if I don't know about it earlier. What if they won't give me a fourth one without asking me to show the error? The contamination was a clear warranty problem but the strange gray-scale is not.
And I already called them! They never asked me to show the problem but this will be the fourth replacement in two weeks. They should be suspicious! And I won't be able to show the big contamination...

The standard and the Custom mode is useless. But should I use the emulated modes only? I could buy a real sRGB (or AdobeRGB) display instead. It would be better than any emulation.

And an additional problem: I had to realize that I can't use my EyeOne colorimeter for this display. So, I ordered a ColorMunki Design spectrophotometer. (Which should be here by now but there is an undetermined delay because the seller has some problems with his PayPal account...)

At the end, I lost ~10 days from my life, I spend relatively big money and I still don't have a proper display. It is equal or worse than my old S-PVA display which was significantly cheaper two years ago.

And I still don't know what would happen with this shit.

Was it a good deal for me? :p

tschi

3rd July 2010, 23:29

Thanks. Exactly how I supposed.

Would it be possible for you to send me your HCFR before and after results files? That way I could install HCFR and analyze with more detail your results... Furthermore, Could you also measure the gamma curve with yCMS using the Grayscale_Measurements, but without the Gamut_Measurements?

I made several tests and zip colorHCFR results :
http://www.mediafire.com/?mjyui5nmmiz
I hope You will understand with name files.

First I calibrate the display with gamma 2.16
- without ycms gamma : 2.16
- with ycms only grayscale gamma : 1.96
- with ycms grayscale + gamut : 1.97

Second I calibrate the display with gamma = 2.45
and I use grayscale mesures of gamma 2.16
- without ycms gamma : 2.45
- with ycms grasycale 2.16 + gamma = 2.23
so that's a workaround and it could be adjut I guess :cool:

Anyway, I hasn't got the so perfect gamut correction than be before (even with gamma 2.16) May be just my X-Rite Display2 is not so accurate) :confused:

I had also a issue : I had some wrong ascii caracteres in my HD - PC.txt files I didn't see it when I compile the 3dlut. After that I wasn't able to read red pattern files.

Thanks for your work :)

j5627429

4th July 2010, 16:00

I thought I was having problems with dark colors too -- when I enabled 3dlut dark colors just disappeared.
Then I realized it was clipping because of double Video>PC levels expansion. I changed CoreAVC to output 16-235 and the clipping disappeared when i enabled 3dlut.

Sorry to bring this back up, but can someone please confirm for me that when using MadVR to play bluray content, the video decoder should always be set to 16-235 input and 16-235 output, regardless of what type of display you are using? (i.e. all levels adjustment should be done with MadVR and yCMS)

yesgrey

4th July 2010, 18:50

can someone please confirm for me that when using MadVR to play bluray content, the video decoder should always be set to 16-235 input and 16-235 output, regardless of what type of display you are using? (i.e. all levels adjustment should be done with MadVR and yCMS)
What's important is to set both input and output to the same. Whether both as 16-235 or both as 0-255, doesn't matter.

Sorry for having misled you before, but within ffdshow we have set it to make the input/output settings affecting the levels only when converting from YCbCr->RGB. I didn't know that other decoders changed levels even with YCbCr output. I've tested it and you're right, they affect them, so everyone should be cautious when setting the input/output levels on the decoders.

madshi

4th July 2010, 19:11

Sorry to bring this back up, but can someone please confirm for me that when using MadVR to play bluray content, the video decoder should always be set to 16-235 input and 16-235 output, regardless of what type of display you are using? (i.e. all levels adjustment should be done with MadVR and yCMS)
You should set up all decoders so that they do as little processing as possible. That allows madVR to do all the dirty work. You see, the software decoders are usually using 8bit math to do their processing. madVR does the math via GPU shaders in full bitdepth (depending on GPU, 32bit or more) floating point math. So you want to make sure that the decoders don't do *anything* but decode. Decode they do well. Everything else they suck in. That's why it's important to output YV12 and to avoid letting the decoder do any processing, which includes conversions between PC <-> video levels.

j5627429

5th July 2010, 07:00

Thanks madshi and yesgrey for your responses.

Within the CoreAVC decoder properties, I only have YV12 checkmarked and nothing else. However, CoreAVC's output level control does in fact adjust the levels that it feeds to MadVR. Does this mean that even if i select 16-235 input & 16-235 output within CoreAVC, the decoder is still doing some type of processing on the image? I want to make sure I'm getting the full benefit of MadVR, so I think I'm going to switch to FFDshow's untouched YV12 just to be on the safe side.

madshi

5th July 2010, 07:18

CoreAVC should be untouched, as long as you set input and output levels to the same value.

j5627429

5th July 2010, 08:48

Great! Thanks for the confirmation.

Now that I'm 100% clear about the decoder levels, I would really appreciate a little bit of newbie help with MadVR and yCMS levels settings, because I'm still not sure how they interact with eachother.

Given this configuration:

-ATI 5770 video card is set to output RGB Limited through HDMI
-Projector is set to accept RGB Limited input
-CoreAVC set to 16-235 in / 16-235 out
-Projector brightness/contrast sliders are at 0

1) When I select MadVR PC levels (no 3dlut) -- the test pattern levels bars flash to 15, and 16&below look very black, just like the desktop.
2) When I select MadVR Video levels (no 3dlut) -- the test pattern levels bars flash all the way down to 1, and the base color 0 is still black like the desktop.
3) When I select MadVR Video levels and enable 3dlut (created with yCMS1.4 Output_Format HD RGB_Video 16) -- the levels bars flash to 15, but 16 and below appear grey.

Is this correct behavior for an RGB Limited setup?
I can fix the situation in #2 and #3 by adjusting my projector's brightness to -6 and contrast to +14, but am not sure if that is the correct method. The desktop levels will become incorrect when I adjust these sliders.

I'm trying to understand what is happening, so please correct me if I am wrong:
My guess is that the video card is taking everything, including the desktop and video, and converting it to limited levels. Since the desktop is designed for PC levels, the output looks correct. That must be the same reason that setting MadVR to PC Levels looks correct.

If MadVR is set to Video levels, the 16-235 YV12 input remains untouched, but unfortunately must undergo 0-255>16-235 conversion by the video card. (BTW, the ATI Catalyst Control Center has a video dynamic range selector, but it has absolutely no effect on the image whatsoever :( )

So if my above guess is right, which option will give the bestt result (least amount of processing)?
A) Choose PC levels in MadVR and leave Projector brightness/contrast controls at 0
B) Choose Video levels in MadVR and leave Projector at 0 but use yCMS Output_Format+input/output range to expand to PC levels
C) Choose Video levels in MadVR and adjust projector brightness/contrast controls?

P.S. I do not care how the desktop looks, I only want the best possible image quality.

yesgrey

8th July 2010, 13:14

yCMS v1.5 released

http://yesgrey.com/ycms.html

- Fixed low level bug when using Output_Transfer_Function.

yesgrey

9th July 2010, 00:32

I've investigated the reported gamma issues and here are my conclusions.

In first place I want to clarify what is gamma. People usually refer the transfer functions as "gamma curves", but that's not exactly correct. Gamma is the name given to a value on the exponent of the power function contained in a transfer function, and not the transfer function by itself.

Having said this, it would be easier to understand that different transfer functions can have the same gamma, but that would not make them equal.

Let's look at an image to understand this a little better:
11229
As it can be seen in the image, the BT.709 transfer function (the blue one) is very different from a pure power curve with the same gamma value (the green one), which is 2.222 (1/0.45).

There are two more curves in the image. The red one is a pure power curve with a gamma of 2.0, and the magenta one has a gamma of 1.92. The red curve is a good approximation of the bt.709 curve for the > 75 IRE region, while the magenta curve is a good approximation for the 40-45 IRE region.

What the HCFR gamma graphs posted by some are showing seems to be the gamma value of pure power functions that fit the display transfer function at each IRE level, hence why the value increases while the IRE values increase, exactly like the example above.

When yCMS compensates for the display transfer function (aka "gamma curve") using the command Grayscale_Measurements, the resulting transfer function would be the Input transfer function, which for HD is the BT.709 one. So, what the HCFR graphs are showing is the approximation of the BT.709 transfer function by several different pure power curves.

To verify the accuracy of the BT.709 curve in HCFR, the graph type should be changed. Go to Advanced -> Preferences -> References -> Gamma Calculation, and select "Camera gamma (standard offset)". That will show the differences from the selected standard "gamma curve". Then you could see that yCMS is not decreasing the gamma, but simply keeping it as it should be: the BT.709 "gamma curve".

Of course the ambient lighting conditions affect the viewing, and the image should be compensated accordingly, but that would be another feature of yCMS, to be added in a future version...

cyberbeing

9th July 2010, 01:23

To verify the accuracy of the BT.709 curve in HCFR, the graph type should be changed. Go to Advanced -> Preferences -> References -> Gamma Calculation, and select "Camera gamma (standard offset)". That will show the differences from the selected standard "gamma curve". Then you could see that yCMS is not decreasing the gamma, but simply keeping it as it should be: the BT.709 "gamma curve".

"Keeping it as it should be" only applies if you were originally calibrating with "Camera gamma (standard offset)" in the first place. If you assume people are calibrating with anything other than "Display Gamma" you'll be wrong 99.99% of the time, since every professional software out there for calibrating your video/hardware lut and creating ICC profiles on computers uses "Display Gamma". Using "Display Gamma" is just the standard way to measure gamma when doing color management in the computer world. When I studio is mastering video, they would usually be using a bt.709 curve with a "Display Gamma" of somewhere between 2.2 and 2.6. What yCMS is doing with bt.709 curve with a "Display Gamma" of 1.9 is useless. Once again remember that bt.709 DOES NOT have a standard gamma, you need to scale the it to your desired gamma, which currently yCMS is not doing.

yCMS is indeed decreasing gamma rather significantly. Using those settings in HCFR, yCMS decreases the gamma from 2.6 camera gamma (2.2 display gamma) to 2.2 camera gamma (1.9 display gamma). That fact doesn't change at all.

Before is calibrated to a display gamma of 2.2, After is yCMS.
The below is showing gamma values in "Camera Gamma (standard offset)" instead of "Display Gamma".
http://img153.imageshack.us/img153/5315/cameragamma.png
Exact same .chc files as the ones from the post here:
http://forum.doom9.org/showpost.php?p=1413850&postcount=160
You can easily see how much yCMS brightens up everything from 10 to 80 IRE.

You may want to considering asking Graeme Gill for help with how to calculate BT.709 gamma on the ArgyllCMS mailing list:
http://www.argyllcms.com/mailinglist.html

What you currently appear to be doing is just applying the BT.709 transfer curve directly, which really isn't what you should be doing.
http://img682.imageshack.us/img682/1585/gammaplot2.gif
Green line is 2.2 display gamma power curve.
Blue line is 1.8 display gamma power curve.
Red line is BT.709 display gamma transfer function. (~1.9-2.0)

It really comes down to, that when you brighten up an encoded video so much, a lot of luminance and color information is lost, has already been lost in the encoded video, or never existed in the first place. Take x264 for example. It is designed to take away bits from dark areas below a certain visual threshold in order to save bitrate. When yCMS brightens up these dark areas, they potentially become a blocky/noisy mess on x264 encoded videos (which don't have insane bitrate), since x264 was never coded to always make such areas look pixel-perfect when bitrate restrained. This come back to why display calibration should always be used for making significant changes. Modification of the source video or image with color management should only be minor tweaks to compensate for the failings of your display calibration.

yesgrey

10th July 2010, 13:32

3) When I select MadVR Video levels and enable 3dlut (created with yCMS1.4 Output_Format HD RGB_Video 16) -- the levels bars flash to 15, but 16 and below appear grey.

Is this correct behavior for an RGB Limited setup?
No. That's a bug in yCMS, it shouldn't be clipping the BTB and WTW data. I will fix it.

yesgrey

10th July 2010, 14:25

Once again remember that bt.709 DOES NOT have a standard gamma, you need to scale the it to your desired gamma
That's not true, BT.709 DOES define a standard gamma. Even though for several practical reasons the final result is not exactly a BT.709 gamma curve, it should be considered as that.
When yCMS brightens up these dark areas, they potentially become a blocky/noisy mess on x264 encoded videos (which don't have insane bitrate), since x264 was never coded to always make such areas look pixel-perfect when bitrate restrained.
Yes, I know that, but original sources with high bitrates shouldn't have these problems.

What's really important in gamma is to keep the correct relations between all levels in the video images, and not targeting a specific value. If we would really want to do it right we probably would need different gamma curves for every film.

yCMS default behavior should be the current one, and it would keep like that, "turning" the display into the theoretical display defined by each standard. However, I do know that this is not the best solution for every situation, hence the future addition of gamma scaling to compensate for different ambient light conditions. Just wait a little more while I finish it...;)

janos666

10th July 2010, 22:39

The output_transfer_function feature is very close to an usable state now. May be it will be perfect with 10 bit/color output mode in the future. :)
But there is a new-old general bug in v1.5: it gives me black blocks instead of dark blue shades. (And the gamma correction makes them more visible.)
I made three sample pictures: MadVR alone (http://img12.tar.hu/janos666/img/80623844.png) ;;;;; simple 3DLUT (http://img12.tar.hu/janos666/img/80623845.png) ;;;;; 3DLUT with Rec709->gamma2.2 correction (http://img12.tar.hu/janos666/img/80624095.png)
My input commands was very simple (with or without the last line...):
Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Output_Transfer_Function 1.0 0.0 0.45 0.0

I can't reproduce it with the blue New Line Cinema intro which I uploaded for you earlier. Let me know if you need a new sample from this movie (but it would be harder to cut it out and more "dangerous" to post publicly...).

yesgrey

10th July 2010, 23:42

Let me know if you need a new sample from this movie (but it would be harder to cut it out and more "dangerous" to post publicly...).
Yes, please. Send me a PM with the link.

janos666

11th July 2010, 19:29

Here is the sample: http://rapidshare.com/files/406387971/BlueSample2.mkv.html (This came from another source material which is easily editable, but is can show the error as well.)

madshi

14th July 2010, 09:13

That's not true, BT.709 DOES define a standard gamma.
BT.709 does not define *viewing* gamma. Both Mr.D and ChrisWiggles clearly say so in this thread:

http://www.avsforum.com/avs-vb/showthread.php?p=17005032

Just read the first page, that's enough. See also here:

http://www.poynton.com/notes/PU-PR-IS/index.html

Current HD video standards, including BT.709 and its various descendants such as SMPTE 274M, specify the camera’s reference encoding – the opto-electronic conversion function (OECF). However, surprisingly, the electro-optical conversion function (EOCF, or “gamma”) of studio reference displays has never been adequately standardized.

It seems that most experts agree on that viewing gamma should be somewhere around 2.2 to 2.4, depending on taste and light conditions. E.g. Tom Huffman recommends "2.2-2.35". Mr.D prefers "something a bit higher than 2.2". EBU suggests 1.2 system gamma (1.96 * 1.25 = 2.35). Currently yCMS seems to produce 2.0.

yesgrey

14th July 2010, 12:59

BT.709 does not define *viewing* gamma. Both Mr.D and ChrisWiggles clearly say so in this thread
Theoretically there is only one gamma, so BT.709 does define both encoding and viewing gamma.

Having said this, I do realize we don't live in a theoretical world, but in a real world, hence the difficulty of stating which would be the standard "viewing" gamma, and then I accept and agree with Mr.D argumentation.

That's a very interesting thread, and Mr.D posts support what yCMS is currently doing. It considers as the reference point the source standard gamma (BT.709 curve with a 2.2 gamma for HD).:)

Currently yCMS seems to produce 2.0.
No. yCMS is producing a BT.709 curve with a gamma of 2.222 (1/0.45). The 2.0 value that people insist to point is not from a BT.709 transfer function, but from a pure power curve function, and Mr.D stated clearly that we should aim for a BT.709 curve with a gamma of 2.2. This confusion was created because people insist in comparing gamma values, when they can only be compared when using the same type of function, which is not the case. I hoped that my post with the image comparing the different curve types would be enough to help clarifying all this, but it seems it wasn't...

yesgrey

14th July 2010, 13:13

I made several tests and zip colorHCFR results
To verify the accuracy of the BT.709 curve in HCFR, the graph type should be changed. Go to Advanced -> Preferences -> References -> Gamma Calculation, and select "Camera gamma (standard offset)". That will show the differences from the selected standard "gamma curve". Then you could see that yCMS is not decreasing the gamma, but simply keeping it as it should be: the BT.709 "gamma curve".
Using tschi HCFR results posted above, here is the gamma response after yCMS gamma correction when using the correct option in HCFR:
11260
You can see that the final response is very close to BT.709 with a gamma of 2.222. Only at < 30 IRE the gamma deviates more, but that might be due to lower meter accuracy at low levels, or due to the bugs recently reported by j5627429 and janos666, which should be corrected for the next yCMS version...

tschi

14th July 2010, 14:02

:thanks: for the 1.5 version and the informations
Obviously using standard offset parameter colorHCFR reports 2.22 gamma :rolleyes:
Anyway, it would be great to be able to switch between severals 3dlut files using a keyboard shortcut in madVR.
In order to choose between different gamma response according to ligthing conditions

madshi

14th July 2010, 14:26

BT.709 does define both encoding and viewing gamma.
You are alone with this point of view. All the experts seem to say otherwise, as far as I can see.

I accept and agree with Mr.D argumentation.
You do? Mr.D clearly says that BT.709 does not define viewing gamma.

Mr.D posts support what yCMS is currently doing. It considers as the reference point the source standard gamma (BT.709 curve with a 2.2 gamma for HD).:)
No, actually Mr.D is extremely reluctant to be pinned to any specific number. He suggests to start with 2.2, but to try higher than that. He also says that he himself watches the content he encodes at 2.2 and 2.5.

No. yCMS is producing a BT.709 curve with a gamma of 2.222 (1/0.45). The 2.0 value that people insist to point is not from a BT.709 transfer function, but from a pure power curve function
And that's exactly my main problem right now. When people are talking about a single gamma number like 2.2 or 2.35, do they mean a Rec709 gamma transfer function or a pure power transfer function? I'm not so sure about that, and because of that I'm not sure if what yCMS does is correct or not.

Mr.D stated clearly that we should aim for a BT.709 curve
Where does he say that?

madshi

14th July 2010, 14:32

@yesgrey, check out this post including the images:

http://www.avsforum.com/avs-vb/showthread.php?p=17000844#post17000844

It seems that both EBU and Poynton suggest to apply a 1.2 (or 1.25) factor to the Rec709 curve for viewing.

I suspect that most people are talking about pure power curves when they mention simple gamma values like e.g. 2.2. If that is true, calibration experts seem to usually go for a pure power curve in the range around 2.2 - 2.4. Which is a lot darker than what yCMS currently produces.

yesgrey

14th July 2010, 16:16

You are alone with this point of view. All the experts seem to say otherwise, as far as I can see.
You shouldn't quote only part of what I've said... ;)
The standard is simply a mathematical formula, and that's why I've said that theoretically the bt.709 standard does define a viewing gamma. Theoretically you would have exactly the same viewing conditions as while encoding, hence my statement. I'm sure that all experts would agree with me on that.
You do? Mr.D clearly says that BT.709 does not define viewing gamma.
Yes. The real world is not the theoretical world. The viewing conditions are different from the encoding conditions (equipment, ambient lighting, different persons, etc...). So, the correct statement would be something like:"BT.709 does not define viewing gamma for viewing conditions other than the encoding conditions."

No, actually Mr.D is extremely reluctant to be pinned to any specific number. He suggests to start with 2.2
Yes, like I've said, the reference (or the starting point if you prefer) should be the BT.709 with a gamma of 2.2. Then, the possibility of changing gamma should be available to fine tune for the viewing conditions. This would be added in a future version. I'm still trying to get a stable version without nasty bugs.

And that's exactly my main problem right now. When people are talking about a single gamma number like 2.2 or 2.35, do they mean a Rec709 gamma transfer function or a pure power transfer function?
The main problem is that I think some people doesn't even know the difference between a pure power curve and a bt.709 like transfer function. They just read the gamma values and use them, no matter what type of transfer function is being used...

The only thing I can do is to keep explaining it and showing examples in hope that people start to realize that all this "gamma" talk can't be resumed to a simple number.

Where does he say that?
Here is a quote from this (http://www.avsforum.com/avs-vb/showpost.php?p=17003929&postcount=20) post.
My point for us home cinema fans:
Aim for Rec.709 . See what if you prefer it a bit higher than 2.2 on your kit.
Then get on with watching something on it.

yesgrey

14th July 2010, 16:19

If that is true, calibration experts seem to usually go for a pure power curve in the range around 2.2 - 2.4. Which is a lot darker than what yCMS currently produces.
It all depends on the viewing conditions.

Me, for example. I'm having great results with yCMS as it is now. Previously I always felt the images were too dark. Now I have a pretty balanced image.

Yesterday I've saw "Bridge to Therabithia, and the image looked great! Not too dark and not losing any details. It simply looked natural, but this only means that for my viewing conditions the BT.709 with a 2.222 gamma is a good solution.:cool: For others it might be different...

madshi

14th July 2010, 16:29

http://www.avsforum.com/avs-vb/showpost.php?p=18903891&postcount=66

The fact is that there is no precise official standard for gamma. Charles Poynton has been carping about this for some time. In absence of an exact specification, the best the user can do is at least to ensure that it is not wrong. Below 2.2 is wrong. Some users prefer to go a little higher, though I wouldn't recommend going over 2.35 because I think you lose too much shadow detail.

There is considerable evidence that about 2.35 would be ideal, but there is also considerable evidence that many studios use 2.2 (or 2.22) when mastering Blu-ray content.
@Tom, when mentioning gamma values like e.g. 2.2 and 2.35, are you talking about a pure power curve? Or are you talking about a BT.709 like curve with a linear segment? Thanks...
Pure power. The linear segments you refer to cover an extremely small portion of the output spectrum.
So TomHuffman is explicitly saying that anything lower than a pure power curve 2.2 gamma is wrong... :p

madshi

14th July 2010, 18:28

Is it the norm that calibrators are calibrating displays to a pure power gamma response? If so, why do they choose a pure power curve over a BT.709 curve?
Because a reading at 10% stim--the lowest I ever calibrate to--is typically well above the level where the linear segment kicks in.
@yesgrey, so would you reconsider, now that we know that calibrators usually seem to calibrate to a pure power curve in the range of [2.2 .. 2.35]?

tritical

14th July 2010, 22:40

yesgrey

15th July 2010, 00:17

So TomHuffman is explicitly saying that anything lower than a pure power curve 2.2 gamma is wrong... :p
In terms of pure power curves he might be right, but I still prefer to use a BT.709 curve with a 2.2 gamma as Mr.D says.

Furthermore, saying that the difference between a pure power curve and the bt.709 curve is only the linear segment is showing very little knowledge about the subject... I also thought that once, before I decided to draw both curves and compare them.;)
It's much more than that, because the curve has an offset, necessary to guaranty same value and same slope in the transition point. Please look at the image I posted above. The difference is significant!

@yesgrey, so would you reconsider, now that we know that calibrators usually seem to calibrate to a pure power curve in the range of [2.2 .. 2.35]?
No. yCMS default working mode will be like it is now, it will give the inverse of the source transfer function curve (BT.709 for HD and DVD). However, I'm considering creating a new command that besides changing the gamma value might also allow changing the output curve to a pure power function, so users could be able to set their displays to whatever they want, even if that is plain wrong...

Another thing. The fact that the image looks less dark is not necessarily wrong. Of course you would get a different image when using yCMS than when not using it, because usually the displays are set to a pure power curve and yCMS sets them to a BT.709 curve, but that could simply means that you were not getting an accurate image before...
In my case I know I wasn't getting it right, because I do prefer my new image.:)

madshi

15th July 2010, 07:43

As yesgrey's graph shows, it isn't the linear segment that causes the major differences between BT.709 transfer function with exponent T and a pure power curve with exponent T. Although I would guess Tom is talking about pure power curves when he states 2.2, 2.35 etc... his answers make it seem like the only difference is the linear segment.
True. I'm not sure if he thought his answer through. But in any case he clearly said that he calibrates to a pure power curve of 2.2 - 2.35, which is a lot darker than what yCMS currently does.

In terms of pure power curves he might be right, but I still prefer to use a BT.709 curve with a 2.2 gamma as Mr.D says.
I'm not convinced that you interpret his posts correctly. For once, you interpret him to say that 2.2 is the standard and that everything else is tweaking. While actually he says that he personally checks with 2.2 and 2.5 and that BT.709 does *not* define the viewing gamma. Also I'm not convinced that he's really calibrating to a BT.709 curve. We've asked him several questions in the past, and he replied to both you and me in separate threads that in his experience it's a useful shortcut to forget about the linear segment.

Furthermore, saying that the difference between a pure power curve and the bt.709 curve is only the linear segment is showing very little knowledge about the subject... I also thought that once, before I decided to draw both curves and compare them.;)
It's much more than that, because the curve has an offset, necessary to guaranty same value and same slope in the transition point. Please look at the image I posted above. The difference is significant!
Yes, I agree. But you cannot deny that it seems that most calibrators do calibrate to a pure power curve of 2.2 - 2.35, and that this is a lot darker than what yCMS is currently doing.

No. yCMS default working mode will be like it is now, it will give the inverse of the source transfer function curve (BT.709 for HD and DVD). However, I'm considering creating a new command that besides changing the gamma value might also allow changing the output curve to a pure power function, so users could be able to set their displays to whatever they want, even if that is plain wrong...
And I think your position of what is wrong, is wrong.

What is your opinion of the EBU's and Charles Poynton's recommendation to use a system gamma of 1.2 or 1.25 (so you would have to multiply your gamma value with 1.2)? You seem to be totally ignoring that. Do you think the EBU and Charles Poynton got it wrong?

Another thing you're totally ignoring is that (as I told you in the past) Calman's help system explains that displays should be calibrated to a pure power curve, when there's total light control (no ambient light), and that a BT.709 might be preferable if there's ambient light.

I'm not against giving some flexibility to yCMS, but please don't ask me to make it default to "flawed mode"...;)
I think you need to check your definition of "flawed mode" because I believe you got that wrong. Sorry. You seem to think that there's only one correct viewing gamma curve/value and that yCMS has currently nailed it. But in fact *ALL* the experts seem to agree on that BT.709 does not define the viewing gamma (nor any other current standard). And most professionals seem to calibrate to a pure power curve (at least that's my impression) and to a darker image than what yCMS currently uses. Are you saying that so many of the professionals are wrong, Calman's help system doesn't know what it's talking about, and only you got it right?

madshi

15th July 2010, 10:48

http://tech.ebu.ch/docs/tech/tech3321.pdf

It has been found that the end-to-end or “system” gamma for images captured in nominal daylight conditions, adapted for the dim-surround consumer viewing environment is approximately 1.2, i.e. definitely not linear.

The system gamma can be expressed as:

System gamma = camera encoding gamma (OETF) x display gamma (EOTF)

It has been found from measurement techniques, progressively refined over several decades, that a correctly designed CRT display has an EOTF gamma of approximately 2.35 [5]. This is part of the “immovable legacy effect” of the CRT.

Therefore our system gamma equation is rewritten as

System gamma = 1.2 = OETF gamma x 2.35

http://www.poynton.com/notes/PU-PR-IS/Poynton-PU-PR-IS.pdf

Since the earliest days of television, the display power exponent for studio video has been about 2.4, and this value remains representative of today’s studio displays – even those using non-CRT technology.

[...]

The EOCF of today’s studio displays closely approximates a 2.4-power function. The BT.709 reference OECF is essentially a 0.5-power function. Consequently, the end-to-end exponent implicit in BT.709 origination is 0.5 times 2.4, or 1.2. The perceptual significance of an end-to-end power of 1.2 is described in classic publications such as those from Bartleson and Breneman, Hunt, and DeMarsh that are cited in my survey paper.

[...]

BT.709 proposals

EOCF of a studio reference display should be standardized based upon a 2.35-power function. (Other values such as 2.36 and 2.4 have been proposed; any value between 2.35 and 2.4 would serve.)
Seems to me that both EBU and Charles Poynton are aiming for a system end-to-end gamma of 1.2. Which, as far as I understand, would be a 2.35 pure power curve. Or a 2.67 BT.709 curve.

janos666

15th July 2010, 22:46

These are my thoughts (if I am thinking as a "general" engineer):
If a standard has an exact math function which defines the encoding transfer function but the standard says nothing about the decoding, then:
- It is obvious that we have to use the inverse function for decoding. (I think that any engineer who doesn't know anything about displays but she/he used any kind of standards for her/his jobs will say the same, as a general rule and first opinion.)
- But we can't blame anybody if she/he would use any custom function for the decoding. (If there is no rule, you can do anything what you want...)
(But I never read the full Rec709 document. I only heard that it doesn't contain any rules about it.)

And here is my concern (and you should know something about displays to think about it as a second opinion - and this is the point where you will stop to feel that you know something about this topic...):
- The makers of the Rec709 standard could assume that everybody will follow the old "rule of thumb" that any customer displays will be calibrated to gamma 2.2 (the simple power function with two substantial value (Where "calibrated" means that it is either properly calibrated by the user/factory/ect. or it was supposed to be calibrated... Or it is a mess but it won't matter then because we design for reasonable conditions.)), or any chosen gamma value (for the simple power function) to honor the environment view conditions.
In this case, they could design the encoding transfer function with internal corrections for this situation.
Example:
Reality ---> RAW Camera data (with native errors in the technology) ---> Encoding with the exact Rec709 curve (with corrections for the native errors) ---> Decoding with a simple power function (usually gamma ~2.2) ---> The best achievable result.
And we make a mistake with a fully inverse decoding:
Reality ---> RAW Camera Data (with native errors in the technology) ---> Encoding with the exact Rec709 curve (with corrections for the native errors) ---> Decoding with the inverse Rec709 curve ---> Very erroneous result (we bring back the native errors with additional rounding errors).

But these corrections can contain a compensation for the assumed view conditions as well.
I think that most of the yCMS users have control over the view conditions (more or less). Of course, it is not as perfect as a professional workplace but it is much closer to that than most people has. (But they won't use these softwares. They are very far from that.)

In this case we should "bypass" these corrections (even with rounding errors). I think we agree that we should watch movies in a dark room. It gives you "cinema like feeling". You will see the display only and you can forget about your room (forget about the real world and live in the movie world). But we don't need the "usual TV watching environment corrections" for this.

If the Rec709 transfer function contains both of these example corrections then we are lost and we can't get the desired result without their help (the makers of the standard who won't help us in this way).

After this second thoughts I would consult with the chamber or the makers of the standard. Or I would throw out the full document and use my own knowledge and my own simulations, tests, experiences to find a solution. (It would depend on the operative laws and the size and importance of the given project.) In the EU you can throw out any standards (like the Euro Code) when you feel them useless (until some additional country specific law or your actual contract says something else about it). -> I say it for you, yesgrey!
So, I want the best result for my movies and I think we should try to achieve it with the following of the standards at the first place. But we have to think about the possibility that we should fully ignore them (as they never existed)! And we should start to do some experiments. (But hey, there is a lot of forums with user opinions and there is some people here who can test some variations...)

But I agree. You should fix every general bugs and make a proper version for the exact standard first. We should test and criticize the standard results after that happened.

--- My experience with yCMS 1.5 (expect the general bug) and the output_transfer_function command that the truth will be somewhere between the corrected and the uncorrected state but the path is right.
But I am not sure yet:
- I am still fighting with my latest U2410 (fourth replacement, and I think it is a perfect U2410 but it is a mess by design :D).
- I watched tons of movies with uncorrected gamma. How can't I feel it strange at the first time with the correction? (And I didn't try to watch a complete movie because here is the bug yet.)

PS. If we already speak about it. I used to say "transfer function" or "Rec709 curve", ect, when I talk about a complex math function and I used to write "gamma curve" or "gamma 2.2" when I talk about a simple power function. Is it theoretically right? (Did you understand it in my old forum posts here?)

(Sorry if I used strange words instead of the correct terms. I knew that I should learn math in english and finish that damn "English for engineers" half-year subject. :D)

madshi

16th July 2010, 09:16

janos666

16th July 2010, 14:04

These arguments make me believe that the correct way to watch BT.601 and BT.709 content is to simulate the behaviour of the technology BT.601/709 were designed for.

This sounds very reasonable for me.
But on the other side, this linear segment can be expounded many ways:
- A correction was required for CRTs with their native characteristics. But it is useless with a theoretically perfect power function.
There could be a strange segment on the native CRT curve. They had to assume that consumers will use uncalibrated CRTs. (There was no any digital signal processing in the consumer level CRT TVs in the past. So, the correction was used on the encoding side).
- Old sensors could produce more noise on dark areas. And new digital medias can use post-process effects to reduce this noise.
- The combination of these things together.

Here comes the testing...

I tried to do some graphical iterations to find some values for the output_transfer_function command. I think that I should use 7.5 0.099 0.373 0.018 for my LCD display (which was calibrated to gamma 2.2 - the simple power function).
But I am not sure about the result. May be I should try to skip the correction on the linear segment or I chose a bad slope value.

yesgrey

17th July 2010, 14:21

True. I'm not sure if he thought his answer through. But in any case he clearly said that he calibrates to a pure power curve of 2.2 - 2.35, which is a lot darker than what yCMS currently does.
A lot darker is not the same as more real or more natural looking.

I'm not saying that current yCMS output is how it should look like, because I agree that there isn't no fit all solution, but some differences are expected. My question is: do you feel the image to look unnatural?

We've asked him several questions in the past, and he replied to both you and me in separate threads that in his experience it's a useful shortcut to forget about the linear segment.
Yes, but only for simplicity (faster processing) and in case we didn't want to adapt the coefficients on the transition point.

What is your opinion of the EBU's and Charles Poynton's recommendation to use a system gamma of 1.2 or 1.25 (so you would have to multiply your gamma value with 1.2)? You seem to be totally ignoring that. Do you think the EBU and Charles Poynton got it wrong?
No, but remember that we don't watch in our displays the image directly captured by the cameras. We watch those images previously graded to video by studios. It's there, in the studios, where the 1.2 relation should be applied. So, if we had in our homes the exact studio conditions all we would need would be the same transfer function used in their monitors, hence the bt.709 with a 2.2 gamma. However, since our viewing conditions would be different from studios, another 1.0-1.2 factor needs to be used, depending on the conditions each user has. So, in the end, the final factor between the image we are watching and the original images captured by the camera might be something between 1.2-1.44.

I think you need to check your definition of "flawed mode" because I believe you got that wrong. Sorry. You seem to think that there's only one correct viewing gamma curve/value and that yCMS has currently nailed it.
Sorry, that expression was supposed to be funny but I realize now it wasn't (I've edited it). I prefer to have yCMS base working mode to be the mathematical accurate one, and for that there is only one: using the exact formulas of the standard. Having said this, I do realize that the real world viewing is much more than just some mathematical expressions, hence why I always considered the possibility of changing gamma. All this discussion has been good because now I realize that it might be preferable, in some situations, to have a pure power function as the display output, so I will also consider that in the future command settings.

Are you saying that so many of the professionals are wrong, Calman's help system doesn't know what it's talking about, and only you got it right?
Of course not.

These are my thoughts (if I am thinking as a "general" engineer):
If a standard has an exact math function which defines the encoding transfer function but the standard says nothing about the decoding, then:
- It is obvious that we have to use the inverse function for decoding. (I think that any engineer who doesn't know anything about displays but she/he used any kind of standards for her/his jobs will say the same, as a general rule and first opinion.)
That's what I thought too.

What I'm trying to say, and it seems people still didn't get it, is that current yCMS mode (that I call reference mode) is not the ULTIMATE/BEST/MIRACULOUS/FIT ALL solution, but simply the theoretical mode. It might be the best solution for some situations, but I know it's only that.

In the EU you can throw out any standards (like the Euro Code) when you feel them useless (until some additional country specific law or your actual contract says something else about it).
Yes, I know, and yCMS would allow users to break the "rules" and make their own decisions. yCMS is not meant to be a strict standards follower, but it has to have that always in his core base, or else it would start to be considered as some kind of "snake oil" solution.

I watched tons of movies with uncorrected gamma. How can't I feel it strange at the first time with the correction? (And I didn't try to watch a complete movie because here is the bug yet.)
Yes, it's natural, but only for curiosity I would like to ear what people feel while watching to the current mode, and no one but me have posted about it, and I can't be considered as an independent and trustful reviewer...:D

I used to say "transfer function" or "Rec709 curve", ect, when I talk about a complex math function and I used to write "gamma curve" or "gamma 2.2" when I talk about a simple power function. Is it theoretically right?
No. Theoretically it's not right because both type of curves include the "gamma" value. Gamma is the designation of the exponent value used in the power function, and both functions have a power function in it.

In pure mathematical terms we can consider that both the BT.709 and the pure power function belong to the same class, with the pure power curve being the case when no offset is used in the formula (you can look at the general formula inside yCMS manual).

The key argument for me is that the linear segment in the BT.709 transfer function has a very specific purpose. And if we use the direct inverse of the BT.709 transfer function for decoding, we are invalidating the very purpose of the linear segment.
Agreed, but we don't know if that would be bad... Soon we will know.;)

janos666

22nd July 2010, 12:45

What do you think about a support for the XYZ format type of input values to use it for every type of corrections (gamut and gamma together)?
My new sensor (ColorMunki) isn't supported by HCFR or too much third-party softwares. But I can use ArgyIICMS which provides me measurements in this format:

SAMPLE_ID RGB_R RGB_G RGB_B XYZ_X XYZ_Y XYZ_Z
...
69 0.00000 50.0000 0.00000 7.87530 15.5280 2.29060
70 12.5000 62.5000 12.5000 13.5690 25.6430 5.72250
71 0.00000 50.0000 25.0000 8.87860 16.0140 7.25910
72 12.5000 62.5000 37.5000 15.4420 26.4640 15.2890
73 0.00000 50.0000 50.0000 12.0260 17.4260 23.3070
...

So, I would be able to copy-paste the full measurement data from the *.ti3 files. I have 238 measures right now but I can use more or less and I can define user points too. It has some redundant values at the beginning, because it takes 4 measures on the 100% white. (It is an instrument agreement test, I guess.) But every other measures was taken on various shades. Of course, it includes 0% black and 100% white points.)
But my old EyeOne provided sensor data in this XYZ format too. So, it requires a conversion to get xyY format for yCMS. This conversion should be done by your software to ensure the quality and to make the life of the users easier. :)

Yes, may be I can do an excel document to convert these values into copy-paste and yCMS friendly format. But read my arguments above. :cool:

yesgrey

22nd July 2010, 13:15

What do you think about a support for the XYZ format type of input values to use it for every type of corrections (gamut and gamma together)?
OK, added to my todo list.

yesgrey

25th July 2010, 16:54

yCMS v1.6 released

http://yesgrey.com/ycms.html

- Fixed bug that caused corruption of blue at very low levels.
- Fixed bug that caused clipping of BTB and WTW video data with RGB_Video.

yesgrey

25th July 2010, 17:02

What do you think about a support for the XYZ format type of input values to use it for every type of corrections (gamut and gamma together)?
This would be done at a later stage, when yCMS would start to receive xyY data for both gamut and gamma correction. For now, if you want to, you can use part of your XYZ data into the Grayscale_Measurements command. The "Y" values in "XYZ" and in "xyY" are exactly the same, so use only the "Y" values from XYZ and copy them into the Grayscale_Measurements command - yCMS will use the same values for all color channels, but the error should not be significant.;)

janos666

26th July 2010, 13:14

The new version is good. I couldn't find any bugs (yet).

But I think I won't use it: We aren't sure about the theoretically perfect gamma handling and my subjective before/after tests won't let me decide squarely (sometimes I want to choose the corrected but other times I would prefer the uncorrected). So, I think I simply choose the uncorrected state because it let the display to show all the available shades. (And I think it is theoretically acceptable to watch Rec709 content on a display with pure power gamma 2.2 tonal response.) I think that my eyes adapts to an offset gamma easier than I can forget about the lost shades (or dithering noise, ect...).

And there is a little weird thing here: It was said earlier that the assumed end-user characteristic is a pure-power gamma 2.35. Well, I watch it on a display with pure-power gamma 2.2, so the image should be brightened up a bit. But I think it is either perfect or a little darker than it should be (but never brighter!). The full inversion with the Rec709 power function would brighten it up too much.
So, may be the correct state is between them. I think one of them would be correct:
1: A full Rec709 inversion and a correction between 2.35 and 2.20 pure-power gamma functions. (Inversion and "darkening".)
2: Inversion with a scaled ("darkened") Rec709 function (with the assumption that Rec709 meant to be shown on displays with gamma 2.35)
How can I figure out the correct output_transfer_function values for the second one? I would scale the full function with the slope as well. (The linear-exponential point would remain the 0.018 input value but anything else would be scaled...)

yesgrey

27th July 2010, 00:09

The new version is good. I couldn't find any bugs (yet).
Good. :)
How can I figure out the correct output_transfer_function values for the second one? I would scale the full function with the slope as well. (The linear-exponential point would remain the 0.018 input value but anything else would be scaled...)
I wouldn't advise going that route, it's not worth it. I'm already working on a new command for specifying the gamma curve desired, so it would be preferable to just wait a little more for it...;)

j5627429

30th July 2010, 15:30

My new sensor (ColorMunki) isn't supported by HCFR or too much third-party softwares. But I can use ArgyIICMS which provides me measurements in this format:

Argyllcms gives you Yxy values too.

I use "spotread -e -x" and it gives me something like this:

Result is XYZ: 14.345926 15.519101 15.986478, Yxy: 15.519101 0.312878 0.338464

I like that it gives you a lot of sigificant digits, but I now use NEC SpectraView instead. Only three decimal places but MUCH faster and easier to use than argyllcms command line.

Still, both of these are far inferior to the $200 version of Calman that supports Colormunki if you're actually going to perform a full calibration on your display. But since my projector's controls dont allow me to do that... it's yCMS to the rescue!! Thanks yesgrey :D

yesgrey

30th July 2010, 17:23

Argyllcms gives you Yxy values too.
It's good to know. So, for now, I will keep yCMS only with Yxy support, this way I will avoid to add another setting.

janos666

30th July 2010, 18:13

Argyllcms gives you Yxy values too.

I use "spotread -e -x" and it gives me something like this:

I think that "spotread" was developed for printer calibration (to measure the printed test spots). :cool:

To be specific, I used the DispcalGUI software. I think it uses the "dispcal" function for display calibration (through the VGA LUT) and the "dispread" function to get some measurement data for the display profiling function.
I want to use the post-calibration measurements (made by dispread) because I want to keep the calibration LUT loaded for 24/7. (And I posted the data format above.)

But I am limited to the sRGB mode on this display right now. (Nobody should consider to buy a U2410 for general purpose PC usage!) If I would be able to use a native mode (Which simply doesn't exist on this display: Every mode is factory calibrated but they screw up every mode expect the sRGB and that one is not perfect either...) then I want to use yCMS with these dispread measures to get a perfect gamut and gamma correction for movies. :) (And I would use the sRGB mode for PC games only. This was my plan, but...)

I think we would be able to create a little bat file for ArgyllCMS and yCMS to produce a 3DLUT as the final output. (Some kind of automatic calibration, like the ICC files for CMS supported PC softwares...)

I like that it gives you a lot of sigificant digits, but I now use NEC SpectraView instead. Only three decimal places but MUCH faster and easier to use than argyllcms command line.

You should check your instrument's precision on you display. I think that three substantial digits are enough.

Still, both of these are far inferior to the $200 version of Calman that supports Colormunki if you're actually going to perform a full calibration on your display.

I don't think so. As I know it won't make any calibration LUT. It let you configure your hardware with instrument support and it is aided by a cool GUI but nothing is automated.
It was developed for high-end HDTVs and projectors with internal hardware CMS features. ArgyllCMS is much better for any PC attached displays (until you have some high-end display with rewritable hardware (3D)LUTs or other kind of internal hardware CMS...)

But since my projector's controls dont allow me to do that... it's yCMS to the rescue!! Thanks yesgrey :D

I agree. yCMS is very good for software CMS. But software CMS can't compete with a good hardware CMS. (At least until we get DeepColor support for madVR. :))
For example, this U2410 produces better gamut emulation than yCMS and it would be a "perfect" display with rewritable internal LUTs (which are exist but I can't access them...).

I think I will be mad enough to buy an expensive EIZO (with rewritable internal 3DLUTs) when they sell some models with H-IPS panels. (Because this is the best LCD panel technology I ever saw --on quality/price side and may be generally too-- but current displays lack of software support for proper calibration...) I think they should make a Foris II with a H-IPS panel. I would consider to buy one of them! :cool:
(Until then... I will search for some hackers to access these LUTs in the U2410. Haha, nice dream... :devil:)

j5627429

30th July 2010, 19:17

I think that "spotread" was developed for printer calibration (to measure the printed test spots). :cool:

The -e option is for emmisive readings, which of course takes the measurements without the little LED. It also lets you options for measuring a CRT or LCD, so I don't think it is just for printed things. See for yourself here:
http://www.argyllcms.com/doc/spotread.html

To be specific, I used the DispcalGUI software. I think it uses the "dispcal" function for display calibration (through the VGA LUT) and the "dispread" function to get some measurement data for the display profiling function.
I want to use the post-calibration measurements (made by dispread) because I want to keep the calibration LUT loaded for 24/7. (And I posted the data format above.)

Sorry I'm a little confused here. Doesnt the calibration profile you created with DispcalGUI get disabled when you play a movie using MadVR? Wouldn't you want to take your yCMS 3dlut creation measurements with your display profile disabled?

Why would spotread not be able to measure your post-calibration profile?

I don't think so. As I know it won't make me any calibration LUT. It let you configure your hardware with instrument support aided by a cool GUI but nothing is automated.
It was developed for high-end HDTVs and projectors with internal hardware CMS features. ArgyllCMS is much better for any PC attached displays (until you have some high-end display with rewritable hardware LUTs or other type of internal hardware CMS...)

Well if even if your display doesn't have a full CMS, is it not better to calibrate as much as you can on the display-end before you use software such as yCMS to rein in the colors and/or greyscale the last little bit?

Obviously Calman requires SOME type of controls on the display, and your computer monitor sounds like it is very limited in its built-in calibration capability, so calman probably isnt ideal for you. I believe the software does walk you through the process and teaches you how to obtain a good result using whatever controls your display has.

I think I will be mad enough to buy an expensive EIZO (with rewritable internal 3DLUTs) when they sell some models with H-IPS panels. (Because this is the best LCD panel technology I ever saw --on quality/price side and may be generally too-- but current displays lacks of software support for proper calibration...) I think they should make a Foris II with a H-IPS panel. I would consider to buy one of them! :cool:

Do you watch movies with the lights on? Have they fixed the backlight bleed on PC monitors yet? Last I checked, most computer monitors couldn't measure up to the (black level) performance of a good TV or home theater projector...especially the TVs that have locally dimming LED backlights that can turn completely off in certain areas.

janos666

30th July 2010, 22:25

The -e option is for emmisive readings, which of course takes the measurements without the little LED. It also lets you options for measuring a CRT or LCD, so I don't think it is just for printed things.

I can believe that spotread could be used for LCD measurements but dispread was developed for display readings. Why do I want to use the spotread then (which was originally developed for reflective measurements)?

None of them is better or worse. Dispread produces XYZ and spotread produces Yxy. I can convert between these formats manually and the Y value is identical.

My suggestion (for yesgrey) was to accept this kind of input format. So, we can simply copy the numerous measurements from the dispread output file to achieve a color management like we have with ICC supported applications. -> Gamut, gamma and white balance correction from numerous and various measurements, instead of 100% RGB chromacity and some grayscale luminance.

And I still prefer dispread because:
- I believe that most of the instruments produce XYZ format and anything else is a converted value. (And we like to avoid the rounding errors...)
- The DispcalGUI uses this function, so it is easier to use.
- It is the one which was developed for display readings...

Sorry I'm a little confused here. Doesnt the calibration profile you created with DispcalGUI get disabled when you play a movie using MadVR? Wouldn't you want to take your yCMS 3dlut creation measurements with your display profile disabled?

No. I don't know where this rumor was born but the calibration LUT is permanent. It sits at the end of the line, right before the display output. This is the last data manipulation before the DVI/VGA/HDMI/DP/ect encoding. It is always applied until something purposely overwrites the VGA LUT data.

May be there is some D3D or OpenGL software which play with this LUT for some reasons. May be it wants to use it for gamma correction. -> You can find gamma correction option in some games... But that is a very bad act! This LUT is supposed to be untouched because we use it for device calibration. But I couldn't see anything like that since I calibrate my displays.

Why would spotread not be able to measure your post-calibration profile?

May be it can. But I talked about it above...

Well if even if your display doesn't have a full CMS, is it not better to calibrate as much as you can on the display-end before you use software such as yCMS to rein in the colors and/or greyscale the last little bit?

I have weird RGB Level graphs (the RGB color curves are crossing each other), so it is much better to leave the RGB Gains at 255 (in the service menu, because the user OSD doesn't let me change it...) and let the VGA LUT to correct the white point.

I currently have 10 bit/color DP connection but I think I would be able to achieve 12 bit/color through HDMI (the HDMI input's EDID sasy that 12 bit mode is supported but I can't get any image through HDMI with any display mode -> May be I bought a wrong cable or my third U2410 is erroneous as it's predecessors had various problems as well...). So, this is not a problem but a good method. I think that everybody should keep the RGB Gains at their maximum levels with DeepColor supported devices and let the VGA LUT to do it's job!
You can usually set the white point with 0-100 or may be 0-255 integer values. The VGA LUT uses values between 0-1024 with 10 bit/color, and it would be able to use 0-4096 values with 12 bit/color (HDMI 1.3 -> But I don't know what is wrong with DP now. It should be able to handle 12 bit/color as well. But this display is weird anyway, so I won't ask it if HDMI would work...).

My real problem is not the white point but the tonal response. There is a lot of preset modes with various gamuts and tonal response characteristics but none of them offers me a pure power gamma 2.2 curve. They are far away from that.
The sRGB mode is the only one which lies close enough to the gamma 2.2 tonal response. So, I can calibrate it without serious banding issues.

But I can't understand this behavior. The sRGB mode is close to gamma 2.2 and it has no banding while the other modes (with lower gamma values) have banding issues (out-of-box, before any manipulation through the VGA LUT!). This let me believe that a native mode would be very cool with software CMS (coupled with DeepColor support).

But the funny thing is that there is no native mode. There is a lot of preset modes but every one of them will be processed by weird real-time image manipulation or at least by a factory calibrated LUT (which are faulty in same way or other...).

Obviously Calman requires SOME type of controls on the display, and your computer monitor sounds like it is very limited in its built-in calibration capability, so calman probably isnt ideal for you.

Yes, it very limited. I had to use the service menu to gain a little access.
On the other hand... it has internal LUTs and I think these (or at least two of them) are 3DLUTs because the gamut emulation is very good in the sRGB preset.

So, (with the assumption that the native mode is close to my targets) if I could access those LUTs... I think I would be able to make a "perfect" display. :)

Do you watch movies with the lights on? Have they fixed the backlight bleed on PC monitors yet? Last I checked, most computer monitors couldn't measure up to the (black level) performance of a good TV or home theater projector...especially the TVs that have locally dimming LED backlights that can turn completely off in certain areas.

Yes, my PC room is perfectly dark (until I open the balcony door to let some fresh air to come in).

Yes, the black level is not perfect but I preferred the higher black level instead of the noise and black crush. I considered a Full-HD plasma display (with moderate sizes -> and cost) as a PC monitor but low black levels causes noise on dark areas with current displays.

I think we need materials with higher bitdepth and displays with more higher bit depths and good CMS systems to avoid this effect.
Or this will require a different transfer function as well. (But it should be in sync with the content mastering.)

I am not a fan of the projectors. I newer really liked them and they are much more expensive. (To be honest, I prefer to watch movies at home because I don't like the cinema projectors either. Even the IMAX projector can't make me fully satisfied. -> And the polarized 3D is a very big joke on IMAX! I hated to watch the Avatar movie there...)

So, I think that H-IPS is the best available choice now. (With good factory calibration or with the ability for hardware calibraton.) And I doubt they will consider this issue (noisy dark areas) for the next HD standard...

Here is my post-calibration report:
Black level = 0.14 cd/m^2
White level = 122.00 cd/m^2
Aprox. gamma = 2.19
Contrast ratio = 873:1

But the black level was increased by the calibration LUT. This panel would hit the 1000:1 contrast ratio in native mode (and may be with a proper hardware calibration as well.) It should be enough and I think that it is better than any S-PVA with higher contrast but with black crush and noisy dark tones as well. (And IPS has slightly better color reproduction too...)

Yes, some LG H-IPS panel is very inhomogeneous (the famous "tinting issue", but the real one. People mixed it with the homogeneous tinting which was caused by the faulty factory calibration...) but I am lucky because I couldn't see this problem personally. My replaced hardwares had other kind of issues. (And may be this one has problems with it's HDMI input. I think it will never end. Or may be I will wait until they release the U2411 and I will get one of those as a U2410 replacement. :D)

madshi

31st July 2010, 08:21

This let me believe that a native mode would be very cool with software CMS (coupled with DeepColor support).
What do you need DeepColor for? Thanks to dithering, yCMS/madVR introduce *zero* additional banding, even with only 8bit RGB output. The only improvement DeepColor would bring (when using madVR/yCMS) is that the dithering's white noise level would be lower.

yesgrey

31st July 2010, 12:58

The VGA LUT uses values between 0-1024 with 10 bit/color, and it would be able to use 0-4096 values with 12 bit/color (HDMI 1.3 -> But I don't know what is wrong with DP now. It should be able to handle 12 bit/color as well. But this display is weird anyway, so I won't ask it if HDMI would work...).

What do you need DeepColor for? Thanks to dithering, yCMS/madVR introduce *zero* additional banding, even with only 8bit RGB output. The only improvement DeepColor would bring (when using madVR/yCMS) is that the dithering's white noise level would be lower.

I agree. IMHO it probably would also be preferable the madVR/yCMS 16 bit dithered to 8 bit over the VGA LUT with 10 or 12 bit... People shouldn't look only to the number of bits, because that could be misleading.;)

yesgrey

31st July 2010, 21:06

yCMS v1.7 released

http://yesgrey.com/ycms.html

- New command Gamma_Curve to set the desired display calibration gamma curve.

This version allows changing the gamma curve to get after the display calibration.

I will perform today further comparisons, but from some quick tests I still prefer the standard BT.709 curve with the standard gamma value. When using a pure power function the gamut correction will be less accurate than when using the input standard function, so, for now, I still recommend sticking with curveType as 1.0. The gammaValue has less influence in the accuracy loss of the gamut correction, so you may try changing it.

Please let me know if it's working fine. If someone could measure the final gamma curve with several different settings and post the results would be great, because I cannot test it with my current setup...

janos666

1st August 2010, 01:12

I think I need some help with this Gamma_Curve function to be sure about the (theoretically) correct values. I can't understand how it works.
Gamma_Curve 0 2.2 darkens the image but the 0 2.35 values gives me even darker image. So, I think this exponent shouldn't be equal with my current display gamma or the function is faulty. (2.35 means a darker display, so this command should produce a brighter image for a compensation). So, I have to assume that this command tries to simulate the given values. But what was your assumption about the theoretically perfect display for this? A display with pure power gamma 2.2 or 2.35?
What exponent value should be applied for a display with pure power gamma 2.2 to simulate the theoretically (pure power response) display?

Will this gamma correction mess with the gamut or white balance when I don't use any gamut correction commands?

I you want to hear my subjective opinions:
- For the first look, the image looks obviously dark. I watched some random scenes from different movies and I asked myself: "Are there always night, clouded sky or solar eclipse in every movies I have?" and I realized that I watched some outdoor scenes with sunrise. :)
- On the other hand, the reverting of the changes caused the revert effect. :D "Where are the nice colors now? Why does the image look washed-out after I reverted all changes?"

The uncorrected image feels more natural (mostly for outdoor scenes), but the corrected image looks more like a well printed image (like HQ printings on photo paper -> but we should consider the visual illusion that darker colors always look nicer.)
And you can call it to placebo but I think I can notice the rounding errors on the very dark shades (even with the dithering enabled on madVR -> I didn't forget the question, I will answer it sometime).

madshi

1st August 2010, 08:51

I think I need some help with this Gamma_Curve function to be sure about the (theoretically) correct values. I can't understand how it works.
Gamma_Curve 0 2.2 darkens the image but the 0 2.35 values gives me even darker image. So, I think this exponent shouldn't be equal with my current display gamma or the function is faulty. (2.35 means a darker display, so this command should produce a brighter image for a compensation). So, I have to assume that this command tries to simulate the given values. But what was your assumption about the theoretically perfect display for this? A display with pure power gamma 2.2 or 2.35?
What exponent value should be applied for a display with pure power gamma 2.2 to simulate the theoretically (pure power response) display?
It seems that you think that you should use the Gamma_Curve command to tell yCMS how you manually calibrated your display? That is not at all what Gamma_Curve is for. yCMS already knows how your display is calibrated through the Gamma_Measurements command.

You should use the Gamma_Curve command to tell yCMS which gamma curve and gamma value you want to see on screen! Basically Gamma_Curve defines the target you want yCMS to achieve. So if you feed Gamma_Curve higher gamma values, the image gets darker...

I you want to hear my subjective opinions:
- For the first look, the image looks obviously dark. I watched some random scenes from different movies and I asked myself: "Are there always night, clouded sky or solar eclipse in every movies I have?" and I realized that I watched some outdoor scenes with sunrise. :)
In that case try decreasing the Gamma_Curve gamma value. Try 2.1 or 2.0. Or try using the BT.701 curve type, which is generally brighter, when using the same gamma value.

There is no "correct" or "incorrect" here, because there is no defined standard about which gamma curve/value your display should be calibrated to. Even the experts don't 100% agree how to calibrate your display exactly. Furthermore the ideal gamma value depends on your ambient light level, the brightness of your projector, whether your walls are white or not etc etc. So just play with the gamma curve type and gamma value in yCMS and use the setting which works best for you. Then please let us know which gamma curve and which gamma value you ended up with, and what your room conditions are...

And you can call it to placebo but I think I can notice the rounding errors
The math used by yCMS + madVR does not produce any rounding errors.

yesgrey

1st August 2010, 13:09

I will perform today further comparisons, but from some quick tests I still prefer the standard BT.709 curve with the standard gamma value.
Last night I watched a movie with a gammaValue of 2.35 instead of the standard 2.222. In the middle of the movie I switched back to the 2.222 value, but after some minutes I returned to the 2.35 value, the image looked slightly more contrasted. Of course the dark parts of the image are darker, but I did not detect any significant loss in shadow detail. So, for now, I will keep it at 2.35.
This was using the BT.709 curve (curveType 1.0). I will also test with a pure power function curve and then post my results.
My room is totally light controlled, and my walls and ceiling are fully oak covered, so the color would be a light brown.

Gamma_Curve 0 2.2 darkens the image but the 0 2.35 values gives me even darker image.
Try with Gamma_Curve 1.0 2.35. The pure power function gives a very dark image, so you might prefer using the BT.709 instead.

Will this gamma correction mess with the gamut or white balance when I don't use any gamut correction commands?
No. The gamut correction accuracy is affected only when is performed by yCMS.

try using the BT.701 curve type
You've a typo there...;)

janos666

1st August 2010, 13:38

yCMS already knows how your display is calibrated through the Gamma_Measurements command.

Well, I didn't supply any measurement data. This was the problem. Can I use the output_transfer_function command to define my display's tonal response and then refine the result with the Gamma_curve?

The math used by yCMS + madVR does not produce any rounding errors.

Do you want to tell me that there won't be any rounding errors between the source and the visualized image?
For example: Take a 8 bit gray scale image with a 8 bit display. With a correct display you will be able to see every little steps. (If you ask me, these are not so "little" steps, but this is another topic.) Can you make any effective gamma correction without loosing some information? I strongly doubt that. (You won't be able to recognize every little steps. Some of the original steps will band together. - But, of course the overall gray scale will be closer to the desired characteristics. So, it may worth it... or not...)

These (experimental) corrections will do relatively big changes (It would cause heavy banding effects without dithering).

Dithering, yes... You should know that dithering is more like an illusion than some kind of black magic. There are some side effects and some limitations as well. A smart dithering technique can improve the overall result, but still there are some rounding errors or additional noise.

Now, lets see my example:

Take a LCD panel with native 8 bit plus built-in dithering for 10 bit visualization (they call it A-FRC, I think it uses static dithering). It works with a 12 bit controller chip (and 12 bit LUTs) which also uses dithering to feed the 10 bit LCD panel (the documentation talks about "high-quality dithering" but I don't know the specifics).

So, I already have two dithering steps which I can't control. But I can feed the controller with up to 12 bit/color to reduce the rounding errors a bit (I mean the internal rounding errors through the factory LUTs and other built-in processings).

The difference between 8 and 10 bit/color (rounded from the 16 bit VGA LUT data- of course, there is no dithering here) can make hard differences when I calibrate my display. The 10 bit/color connection allows me to avoid any banding issues.

This experience made me believe that a proper DeepColor support (10+ bit/color from the frame-buffers) would be able to make significant differences when we apply relatively heavy image manipulations.

I think that madVR uses static dithering because dynamic FRC and temporal dithering cannot be too effective with 1080p24 display mode an 24 fps materials.

So, I would like to replace the dithering in madVR with DeepColor support. I have some fears about these many dithering steps together.

But may be I will change my mind if you would clarify this dithering for me. What bit depth does it try to simulate? How does it work (Is it static, temporal, dynamic, or...)?

Otherwise, I think that higher effective bit depth is always better or equal but it can never hurt (when it is properly applied).
And you can agree that higher bit depth may help in this situation (Rec709 YCC source --processings--> "some kind of display").
So, I can't understand your hard statement that "We really don't need DeepColor, we are fine with dithering."
You can still keep the dithering with DeepColor if you wish. I would disable it with DeepColor support to avid some unpredictable side effects. (With the tons of dithering steps between the source and visualization.)

yesgrey

1st August 2010, 14:09

Can I use the output_transfer_function command to define my display's tonal response and then refine the result with the Gamma_curve?
Yes, but the final result accuracy will depend highly of how accurately your display follows your output_transfer_function settings...;)

It's preferable to use the Gamma_Curve command when also using the Grayscale_Measurements command.

madshi

1st August 2010, 14:50

Do you want to tell me that there won't be any rounding errors between the source and the visualized image?
There will be no rounding errors between source and 8bit madVR output (provided the GPU doesn't stretch the data behind madVR's back).

For example: Take a 8 bit gray scale image with a 8 bit display. With a correct display you will be able to see every little steps. (If you ask me, these are not so "little" steps, but this is another topic.) Can you make any effective gamma correction without loosing some information? I strongly doubt that. (You won't be able to recognize every little steps. Some of the original steps will band together. These (experimental) corrections will do relatively big changes (It would cause heavy banding effects without dithering).
There will be no banding added on top of what the source already contains, no matter how big the yCMS changes are.

Dithering, yes... You should know that dithering is more like an illusion than some kind of black magic.
You obviously don't have a clue at all about dithering. Sorry to be so blunt. Of course it's not black magic, but it's very far from an illusion. The objective benefits of dithering can be measured very easily.

There are some side effects and some limitations as well. A smart dithering technique can improve the overall result, but still there are some rounding errors or additional noise.
There's only one limitation = side effect, which is a slightly higher noise floor.

may be I will change my mind if you would clarify this dithering for me. What bit depth does it try to simulate? How does it work (Is it static, temporal, dynamic, or...)?
TPDF dithering. "Infinite" bitdepth.

@janos666: Let me show you 2 screenshots (taken from the madVR thread):

http://madshi.net/madVR/ATI%20-%20VMR9%20-%20smallramp.png
http://madshi.net/madVR/madVR%200.4%20-%20smallramp.png

This is a 8bit (256 step) gray ramp image, scaled up to a higher resolution. If you look at the ATI image, you should see faint vertical bars in the image. These bars show you the steps between the 256 steps in the source. These bars proof that 8bit is not enough for banding-free ramps. Now look at the madVR image. The gray ramp was upscaled in floating point with a linear filter, which means that every column in the image now has a different value. There are not any longer 256 steps, but now one step for every column (= 1680 steps). That's a result of linear scaling in floating point. Do you see any steps in the picture? No, you don't. Why is that? Why don't you see any steps, although the image is stored as 8bit PNG? So the PNG only has 256 steps! That's because madVR has dithered the floating point data down to 8bit. There are no steps, only a higher noise floor. Basically the image has maintained its full floating point bitdepth. So here you have proof that madVR is able to show at least 1680 different steps without *any* visible banding. I could easily zoom that image up to 10000 steps and you would still not see any banding at all.

If that is all too hard to believe for you, simply install the madTestPatternSource filter shipping with madVR and "play" the smallramp.ytp test pattern on your display. Zoom it up to your full resolution. That should give you 1920 different gray steps, which is about 11bit true resolution. Then check if you see banding with and without yCMS calibration. If you already see banding without yCMS then either your GPU stretches the data behind madVR's back, or your display is not able to resolve 8bit. If you don't see banding with madVR without yCMS calibration, then you won't see any banding with madVR + yCMS, either, regardless of how big the yCMS changes are...

janos666

1st August 2010, 17:23

This is the same test pattern which I use for subjective before/after comparisons in the EIZO monitor test utility. I didn't notice that there is a pattern like this (smallramp.ytp) in the madVR test pattern directory. I will use it in the future. ;)

Thanks, this post helped me a lot to understand your method.
In my barbarian words (no offense, I know about my poor language and I am not an IT professional...), I would call it "static dithering" (because it works on still, discrete images, it is not carried across the video images). MadVR processes the full (discrete) image to add the required noise across the image (at the correct points, with a well defined method, of course, not like a "noise filter").

And yes, I call it to an illusion because you can clearly see the noise from a closer distance and the nice image is only a visual illusion which exists only from a greater distance (of course, the required distance depends on the pixel size).
This is a very obvious example for the visual illusions. This is an attribute of the human cognition system (eyes and brain).

Infinite bit depth? This is what I would call nonsense! There has to be a measurable/guessable "effective bit depth". You are still using 8 bit/color data and fixed physical resolutions. There are some existing physical limitations, even if you play with more than one pixel and more than one color channel at once.
I can accept if this effective bit depth is far over the human cognition abilities. But 1000 bit/pixel is better answer than "infinite", I think. :p
I would guess that it is equal with 16 bit/color if you applied this dithering across the full range of 8 bit integers. (They say that this is the limit of the human cognitive system. So, it is cool. :cool:)

And I am still resist that this kind of dithering can help a lot but it is not a "magical" solution for everything. There has to be some lost informations! This is how the world works, nothing is ever free! (But may be favorable...)

Lets forget about the test pattern now. You usually have a display with the same resolution of the Blu-Ray content's luminance map (and the Chroma map can be scaled well to this resolution as well as the sharpness depends mostly on the luminance map - these are of course, not accidents...).

So, after we forget about the YCC 4:2:0 trick, you have an image resolution which matches with the display resolution. You don't have any extra place to apply these dithering dots. You have to apply the noise on the whole image. So, you have to overwrite the original pixels to get the final, dithered image.
The test pattern builds it's gray bars from more than one pixels. So, there is a room for dithering. You don't have it with FullHD sources and FullHD displays...
Yes, yes, the final, overall image may looks much better through the human perception! I don't doubt that, I won't ever doubt that benefit!!! (You don't need to explain this!)
But still... The dithered image is only a nice looking illusion. It is not as per-pixel coherent, or exact from the theoretical chroma/luma and image information perspective as an original, native, highly detailed image.
And I didn't say anything else earlier. (May be I should place the "theoretically" words more often. :rolleyes:)

After all, I agree that I will have exactly the same amount of noise on dark areas with 10 bit/color output because this LCD panel uses the same dithering method.

My biggest concern here that I am unable to disable the display's built-in dithering algorithm.

Is it theoretically correct if madRV outputs 8 bit, the VGA LUT produces (modified) 12 bit, the display controller produces (modified) 10 bit (dithered back from the interpolated 12 bit) and the panel uses static dithering again?
May be it is not a problem but a bunch of cool features. As I imagine this, it can lead to a very serious mess! I won't know until I can test it with DeepColor support.

But there should be a real benefit from the DeepColor support (at least for me, right now). As I mentioned, my display works with 12 bit internal 3DLUTs (and I think this is the future -> the only problem is the lack of the support for home calibration). It would be able to produce less rounding errors when I feed it with 10+ bit input (instead of current 8 bit).
Of course, it should be tested for proofs as well (and I don't have any tools yet).

EDIT:
And some final thoughts: I think I have some banding issues with madVR in PC output mode and the smallramp.ytp pattern. :eek::eek::eek:
I didn't use this pattern earlier. It has to be the same problem which was mentioned by a forum member in the madVR thread! I will test his recommended yCMS settings.

People talked about some ATI HDMI PC/TV level problems there but it is the other one. It is an ATI card with DP port and this issue exists only with video renderers (EVR is a garbage anyway! :p So, never forget that I respect your work, no matter what I say as an "inspiration" for you to make it even better. :cool:). The is no banding with the EIZO test utility.

But he uses a projector with RGB limited and I need RGB Full for correct gray levels. So, I guess I have to find the correct values for myself.

EDIT2:
So, the issue: Some of the gray levels bands into full black with PC setting, while the TV setting gives me perfect result, expect that the blackest black is gray (lifted to RRG 16-16-16 as the zero point, as usually).
yCMS behaves exactly the same way with the default PC settings. There is a nice set of equally black bars together.

But may be it was designed to do it. May be the test pattern produces a Full range RGB gray scale and Blu-Ray sources uses limited range. So, the limited range is mapped into the full range and only one limited range value will produce the blackest black.

Is the limited range "absolutely" mapped into the full range or is it a bug which produces banding? I can't judge about that before I hear the developer's opinions.

If that is the case, I would request a smallramp_limited test pattern which behaves exactly as the Blu-Ray sources. :)

madshi

1st August 2010, 18:07

And yes, I call it to an illusion because you can clearly see the noise from a closer distance and the nice image is only a visual illusion which exists only from a greater distance (of course, the required distance depends on the pixel size).
This is a very obvious example for the visual illusions. This is an attribute of the human cognition system (eyes and brain).
You still don't understand the concept at all. Sure, the human cognition system helps here, but dithering is also objectively and measurably much superior to simple rounding. You need to (finally) understand that dithering is not a trick, not an illusion, but a mathematically much more correct way of reducing bitdepth of digital data.

Look, let's say you have this floating point data:

(1) 0.6, 0.6, 0.6, 0.6, 0.6, 0.6, 0.6, 0.6, 0.6, 0.6

With simple rounding you would get:

(2) 1, 1, 1, 1, 1, 1, 1, 1, 1, 1

With proper TPDF dithering applied you get something like this:

(3) 1, 0, 1, 1, 0, 0, 1, 1, 0, 1

Now do the math: Calculate the mean average of (1), (2) and (3). I hope that you will now finally understand that dithering is not an illusion at all. It produces mathematically correct results. You can measure dithered data and the measurements show that the data is virtually identical to the full bitdepth (e.g. floating point) original. The only side effect is an increased noise floor.

And I am still resist that this kind of dithering can help a lot but it is not a "magical" solution for everything. There has to be some lost informations! This is how the world works, nothing is ever free!
Dithering is not "free", it comes at the cost of a raised noise floor, as I have already explained to you several times.

So, after we forget about the YCC 4:2:0 trick, you have an image resolution which matches with the display resolution. You don't have any extra place to apply these dithering dots.
Once again you don't understand the concept of dithering *at all*. Adding extra dithering pixels is very far from how dithering works. Dithering is simply a replacement algorithm for rounding, which produces much more correct results. Simple rounding throws away heaps and tons of information. Dithering preserves the full information, but raises the noise floor.

As I imagine this, it can lead to a very serious mess!
Not really, unless the processing in your display is completely broken. But in that case you will have a serious mess, anyway, no matter what madVR/yCMS do.

This is my last post on the topic of dithering, since it's really OT here. I've explained to you how it works. Either you trust in that I know what I'm saying and doing, or not. In any case, I've also given you the instructions to double check for yourself with your display whether what I'm claiming is actually true. So either try it out, or don't.

janos666

1st August 2010, 20:10

I tried to test it (read the EDIT parts) and I tried to explain that I believe in the fact that the final, overall, perceived, virtual result is much better.
I think the misunderstanding is only belongs to the question that what is a "trick", "true math", or "illusion" in our sentences and dictionaries.

We are just talking next to each other, so yes, we should stop it. This is my last post in this topic and I don't wait for more (repeated) answers.
(But you are welcome to answer the EDIT sentences.)

I call it as a trick because every dithering method is based on cognitive illusions.
What is wrong with this statement and why do you feel it as an insult against the scientific facts?
It is not a mistake and it won't make it look "cheaper" or "worse". These are the existing scientific fats.
The nicely placed illusions and tricks are as much scientific as anything else which was engineered with a purpose. These are smart tricks and illusions, developed with a scientific purpose. But they are what they are: tricks and illusions.

Every single display is a big illusion generator! There are no true, living people and worlds built in there. This is not a warm-hole which shows other universes. This is only an illusion!

Period, end, closed (for me now).

In your example: 1, 0, 1, 1, 0, 0, 1, 1, 0, 1 instead of 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 would require dynamic changes (FRC, if you wish). The different variations of the same static video image (0 and 1) have to be displayed 4 and 6 times (in this example, but, of course, less repeats are enough), so the cognitive system can average it to one nicely perceived static image.
But you can show every video frame only in one time (with 24 fps materials and 1080p24 display mode).

For static images, when you need 0.6 for a discrete pixel but you have only 0 and 1 available, you can change the neighboring pixels to produce an overall, dithered static image which simulates higher bit dept.
Of course, the final, perceived image looks perfectly nice but in my dictionary, it is a mathematical trick which utilizes visual illusions. This is not "the image", it is some dithered data which looks like "the image" (more like the simply rounded data).

So, I thought you had to do one of these:
- You changed the neighboring pixels as well on a static image (for a nice overall image).
- You used dynamic FRC which won't work with 1080p24 display mode and moving 24 fps videos. (There is no way to show two different static images which can be averaged as one.)

Or yes. I can't understand the true nature of this dithering. But I can understand three kind of existing dithering methods. If you method is a unique method, well, I think I won't understand it easily and it would take too much effort. So, let it be uncleared then. :o

Fer

3rd August 2010, 22:04

Thank you very much yesgrey for your great work.

Let me show you some results. My display is a Sony VW60 and the calibration is made with the HCFR software and a Eye-One meter.

First I show the Gamma and the CIE Diagram of the display:

http://a.imageshack.us/img571/2184/displaygammar.th.jpg (http://img571.imageshack.us/i/displaygammar.jpg/)

The Gamma curve is obtained as a "Display gamma" in HCFR.

http://a.imageshack.us/img821/2104/displaygamut.th.jpg (http://img821.imageshack.us/i/displaygamut.jpg/)

It can be seen that the gamut is far away from the BT.709 standard, typical in the Sony projectors with oversaturated colors.

From this measurements, I have applied yCMS with this configuration:

Input_Format HD YCbCr 8

Output_Format HD RGB_PC 16

Gamut_Measurements 0.694 0.303 0.301 0.691 0.140 0.053 0.314 0.329

Grayscale_Measurements
10 0.216
20 0.850
30 1.975
40 3.411
50 5.259
60 7.605
70 10.355
80 13.643
90 17.414
100 21.713

Gamma_Curve 0.0 2.20

The results are:

http://a.imageshack.us/img291/5199/gammatf0g220.th.jpg (http://img291.imageshack.us/i/gammatf0g220.jpg/)

The Gamma curve is obtained as a "Display Gamma" in HCFR. The Gamma_Curve make a great job since the measured gamma is very near to 2.20.

http://a.imageshack.us/img821/5986/gamuttf0g220.th.jpg (http://img821.imageshack.us/i/gamuttf0g220.jpg/)

It can be seen that the gamut correction is good but not perfect yet.

Now we change to a BT.609 transfer function in the Gamma_Curve command in the last line of the configuration file

Gamma_Curve 1.0 2.35

and the results are:

http://a.imageshack.us/img717/1483/gammatf1g235.th.jpg (http://img717.imageshack.us/i/gammatf1g235.jpg/)

The Gamma curve is obtained as a "Camera Gamma" in HCFR. One more time, the Gamma_Curve make a great job since the measured gamma is very near to 2.35 (with the exception of 20 IRE and below).

http://a.imageshack.us/img821/8149/gamuttf1g2350.th.jpg (http://img821.imageshack.us/i/gamuttf1g2350.jpg/)

In this case the gamut correction is clearly better compared with the case of a pure power transfer function. It is better both in the x, y coordinates and the Y value. The delta E is below 5 for all the primaries and secondaries. Nevertheles the Y ratios Red/White = 0.197, Green/White = 0.701 and Blue/White = 0.070 are lower than the values of the BT.609 standard Red/White = 0.21, Green/White = 0.71 and Blue/White = 0.08. It would be brilliant if yCMS could manage also the Y value as FoLLgoT say before, since the colors seems something dull due to the low Y values, although my brain color perception has been severe altered in years of oversaturated colors...

So, it seems that with the pure power transfer function the gamut correction could be better.

My card is an ATI 2600XT, so it is difficult to me evaluate the image quality with both transfer functions (I have severe stuttering with 3dlut enabled). Nevertheless it seems to me that both gammas gives a very good image and is a very difficult decision say which is better. The next week will change to an ATI 4850 card and I will perform further comparisons with smooth playback (I hope so).

:thanks::thanks::thanks:

yesgrey

4th August 2010, 13:34

Let me show you some results.
Thank you very much for the detailed test and report.:)
If you could also upload me the HCFR files I would appreciate it, because it would let me analyze the results with a little more detail. If you prefer you could send them by e-mail (it's in the manual).

Gamma_Curve 0.0 2.20
It can be seen that the gamut correction is good but not perfect yet.
The accuracy of the gamut correction is highly dependent on gamma. So the highest accuracy gamut correction would be without Gamma_Curve, or using the 1.0 curveType with a gammaValue not much different from the standard.

For achieving a higher gamut correction accuracy when using a pure power function you would need to use it as the input transfer function, and then not use the Gamma_Curve command. This would give you higher accuracy when using the test patterns, but if the videos were created using the bt.709 transfer function you would have lower accuracy when watching them, even though the test patterns would look perfect.

Perfect test patterns measurements only guaranty the same accuracy when watching the videos WHEN the test patterns are mastered exactly the same way the videos are... ;)

Gamma_Curve 0.0 2.20
Gamma_Curve 1.0 2.35

When comparing different gamma curves you should keep one of the values, or the comparison would be much harder...
First you should decide which curveType you prefer, and only after that you should try different gammaValues.

It would be brilliant if yCMS could manage also the Y value as FoLLgoT say before, since the colors seems something dull due to the low Y values, although my brain color perception has been severe altered in years of oversaturated colors...
It's on my todo list, but I don't think the colors might seem dull due to that...

Nevertheless it seems to me that both gammas gives a very good image and is a very difficult decision say which is better. The next week will change to an ATI 4850 card and I will perform further comparisons with smooth playback (I hope so).
According to some people the mastering is performed with robustness in mind, to make the image look good within a certain range of gamma. So, unless you are using a very wrong gamma curve, you should get a pleasant result with several settings. You only need to decide which you will prefer, but it would not be that easy. Furthermore, it would also depend on your display, because a display with a higher contrast ratio will work better with higher gammaValues than a projector with a lower contrast ratio, so this will always be a personal setting.
And yes, you should judge the gamma curves when watching the movies. Screenshots are not a good way of doing it...

madshi

4th August 2010, 13:40

When comparing different gamma curves you should keep one of the values, or the comparison would be much harder...
First you should decide which curveType you prefer, and only after that you should try different gammaValues.
The problem is that when you only change the curveType, the image automatically gets brighter/darker, because the BT.709 curveType produces a brighter image than the pure power curve (or am I wrong?). So if people want to know which curveType they prefer, it might make sense for them to use a different gamma value for both curveTypes which produces a somewhat similar looking result. What do you think?

yesgrey

4th August 2010, 16:24

So if people want to know which curveType they prefer, it might make sense for them to use a different gamma value for both curveTypes which produces a somewhat similar looking result.
Yes, you're right, I forgot that the difference between both curve types with same gammaValues is too big, so the comparison would be meaningless...

Maybe a better approach would be something like this:
(1) set curveType to 0.0 and try with several different gammaValues and decide which you prefer.
(2) set curveType to 1.0 and try with several different gammaValues and decide which you prefer.
(3) Compare then the two preferred curves (from (1) and (2)) and decide which is the number one.

I know that in (3) we could end up with two curves with very different brightness levels, but on the other hand we would be comparing the top 2.

It's just my opinion, though, not a scientific method.;)

madshi

4th August 2010, 16:39

Just out of interest: From a mathematical point of view, which gamma value would one have to choose for curveType 1.0 to get a somewhat similar picture to curveType 0.0 (or vice versa)? There's probably a mathematical relationship?

yesgrey

4th August 2010, 17:50

From a mathematical point of view, which gamma value would one have to choose for curveType 1.0 to get a somewhat similar picture to curveType 0.0 (or vice versa)?
There isn't a single gamma value for that. To each IRE will correspond a different gamma value. Remember the previous gamma graphs from HCFR when not using the "camera gamma" setting? Though, it might be a good start if people calculate the gamma value for 75 IRE, or any other value.
I can post the formula for that, if it would be helpful...

janos666

6th August 2010, 02:13

You should change your example in the manual.txt. The empty lines counts as an IRE. I ended up with this input file:
# Source video format
Input_Format HD YCbCr 8

#3DLUT output format
Output_Format HD RGB_PC 16

Gamut_Measurements 0.677588 0.312901 0.201814 0.696344 0.151118 0.056602 0.312457 0.330534

Grayscale_Measurements 0 0.13498
0.39216 0.14294
0.78431 0.15466
1.1765 0.16328
1.5686 0.17958
1.9608 0.19381
2.3529 0.21409
2.7451 0.22772
3.1373 0.25247
3.5294 0.27298
3.9216 0.29483
4.3137 0.3216
4.7059 0.34783
5.098 0.38904
5.4902 0.41443
5.8824 0.4547
6.2745 0.48645
6.6667 0.52568
7.0588 0.57565
7.451 0.61425
7.8431 0.66877
8.2353 0.71852
8.6275 0.78184
9.0196 0.82864
9.4118 0.89781
9.8039 0.95886
10.196 1.0197
10.588 1.0952
10.98 1.1573
11.373 1.2497
11.765 1.3216
12.157 1.4103
12.549 1.485
12.941 1.5677
13.333 1.6781
13.725 1.7567
14.118 1.8674
14.51 1.9613
14.902 2.0875
15.294 2.1794
15.686 2.3047
16.078 2.4104
16.471 2.5222
16.863 2.6529
17.255 2.7607
17.647 2.9162
18.039 3.0388
18.431 3.1884
18.824 3.3103
19.216 3.4353
19.608 3.615
20 3.742
20.392 3.9147
20.784 4.0513
21.176 4.2475
21.569 4.3872
21.961 4.573
22.353 4.7259
22.745 4.8955
23.137 5.0878
23.529 5.2468
23.922 5.4634
24.314 5.6551
24.706 5.873
25.098 6.0997
25.49 6.2808
25.882 6.5325
26.275 6.7112
26.667 6.9573
27.059 7.1521
27.451 7.3695
27.843 7.6116
28.235 7.8147
28.627 8.0818
29.02 8.3067
29.412 8.575
29.804 8.7809
30.196 9.0705
30.588 9.3161
30.98 9.5282
31.373 9.8228
31.765 10.039
32.157 10.37
32.549 10.589
32.941 10.893
33.333 11.128
33.725 11.401
34.118 11.727
34.51 11.949
34.902 12.294
35.294 12.56
35.686 12.889
36.078 13.14
36.471 13.475
36.863 13.757
37.255 14.016
37.647 14.349
38.039 14.658
38.431 15.038
38.824 15.312
39.216 15.654
39.608 15.937
40 16.211
40.392 16.61
40.784 16.854
41.176 17.252
41.569 17.549
41.961 17.928
42.353 18.218
42.745 18.586
43.137 18.907
43.529 19.191
43.922 19.573
44.314 19.856
44.706 20.267
45.098 20.578
45.49 20.97
45.882 21.24
46.275 21.559
46.667 22.004
47.059 22.281
47.451 22.685
47.843 22.989
48.235 23.435
48.627 23.725
49.02 24.241
49.412 24.608
49.804 25.008
50.196 25.632
50.588 26.022
50.98 26.552
51.373 26.957
51.765 27.321
52.157 27.806
52.549 28.216
52.941 28.744
53.333 29.126
53.725 29.65
54.118 30.043
54.51 30.584
54.902 30.984
55.294 31.363
55.686 31.896
56.078 32.34
56.471 32.854
56.863 33.263
57.255 33.789
57.647 34.211
58.039 34.613
58.431 35.121
58.824 35.54
59.216 36.113
59.608 36.508
60 37.031
60.392 37.459
60.784 38.035
61.176 38.455
61.569 38.836
61.961 39.444
62.353 39.844
62.745 40.428
63.137 40.814
63.529 41.401
63.922 41.842
64.314 42.298
64.706 42.806
65.098 43.266
65.49 43.878
65.882 44.335
66.275 44.892
66.667 45.287
67.059 45.996
67.451 46.384
67.843 46.846
68.235 47.433
68.627 47.933
69.02 48.52
69.412 48.989
69.804 49.584
70.196 50.095
70.588 50.65
70.98 51.203
71.373 51.7
71.765 52.383
72.157 52.891
72.549 53.5
72.941 54.052
73.333 54.697
73.725 55.273
74.118 55.803
74.51 56.403
74.902 56.932
75.294 57.763
75.686 58.326
76.078 58.82
76.471 59.531
76.863 60.151
77.255 60.792
77.647 61.266
78.039 62.094
78.431 62.652
78.824 63.312
79.216 63.887
79.608 64.527
80 65.291
80.392 65.792
80.784 66.584
81.176 67.275
81.569 68.002
81.961 68.594
82.353 69.232
82.745 70.009
83.137 70.711
83.529 71.479
83.922 72.027
84.314 72.926
84.706 73.589
85.098 74.395
85.49 74.987
85.882 75.642
86.275 76.489
86.667 77.138
87.059 77.841
87.451 78.561
87.843 79.339
88.235 79.917
88.627 80.513
89.02 81.345
89.412 82.03
89.804 82.769
90.196 83.309
90.588 84.128
90.98 84.84
91.373 85.466
91.765 86.023
92.157 86.738
92.549 87.3
92.941 87.878
93.333 88.506
93.725 89.114
94.118 89.884
94.51 90.355
94.902 90.722
95.294 91.549
95.686 92.157
96.078 92.938
96.471 93.281
96.863 94.081
97.255 94.848
97.647 96.037
98.039 96.311
98.431 97.104
98.824 98.158
99.216 98.983
99.608 99.906
100 100

Gamma_Curve 0 2.2

Another funny thing that you will have homogeneous black or white screen when you forget to replace the , with . decimal marks. (I would expect an error message or may be a smarter behavior.) :)

Otherwise, I think I will keep away from this state. I have BANDING problems (yes, I lost some visual informations) with these settings.
G.I. Joe and Pocahontas won't lie: 01 OFF (http://img12.tar.hu/janos666/img/82410398.png) - 01 ON (http://img12.tar.hu/janos666/img/82410397.png) ; 02 OFF (http://img12.tar.hu/janos666/img/82410395.png) - 02 ON (http://img12.tar.hu/janos666/img/82410396.png) ; 03 OFF (http://img12.tar.hu/janos666/img/82410623.png) - 03 ON (http://img12.tar.hu/janos666/img/82410624.png)
And a little extra, just for you (I found it right now). Marine Hero is a shapeshifter reptilian (http://www.google.hu/search?client=opera&rls=en&q=shapeshifter+reptilian&sourceid=opera&ie=utf-8&oe=utf-8), not an real Avatar (http://img12.tar.hu/janos666/img/82411521.png). :p

yesgrey

6th August 2010, 14:00

You should change your example in the manual.txt. The empty lines counts as an IRE.

Another funny thing that you will have homogeneous black or white screen when you forget to replace the , with . decimal marks.
I will take care of it. Thanks for reporting.

I have BANDING problems (yes, I lost some visual informations) with these settings.
Where is the banding? None of the pictures show it... It seems you're calling banding to shadow detail loss, but that's not what banding is.

The losing of visual information is a result of your gamma curve changing. yCMS only is doing what you're asking.;)
A pure gamma curve with a gamma value of 2.2 is darker than a bt.709 gamma curve with the same gamma value (what you get when disabling 3DLUTs), hence the darkened image you get that even make you lose shadow detail... Try with "Gamma_Curve 0.0 1.96", that should give you a brightness similar to without 3DLUT. However, I would suggest you to also try with "Gamma_Curve 1.0 2.35", what I'm currently using.

janos666

6th August 2010, 15:44

Where is the banding? None of the pictures show it... It seems you're calling banding to shadow detail loss, but that's not what banding is.

Yes, may be I used this word in wrong syntaxes.
I mean, some of the different R=G=B=0..256 values will produce the same luminance level. The image will loose some visual informations. Two different IREs will produce the same perceived luminance. (Dark shades will be equally black, ect.)

The losing of visual information is a result of your gamma curve changing. yCMS only is doing what you're asking.;)

This is what I talked about earlier. (The weird off-topic conversation with madshi.) The dithering won't solve everything when you try to do some heavy image manipulations like this.
This is where I feel the need for 10+ bit output (henceforward combined with dithering).

I made an illustrative diagram from my measurements which I took from the Custom display mode (Unfortunately, I think it is not a "native" mode either. But this one works with the widest gamut. But it has a slightly lower contrast ratio and weird tonal response....) The green curve is the pure power gamma 2.2 with black offset: Click (http://img12.tar.hu/janos666/img/82447648.png)
The near-white scale is strange, yes. It can be a display fault or a measurement error as well. (There are some really smooth sections, and the spectrophotometers like the brighter shades, so I think it is an exaggeratedly looking display fault.)
I didn't hope too much. I was only curious what madVR would produce with a 3DLUT which is created for this display mode.
And we didn't apply a proper white balance correction yet! It will be able to cause even more detail losses.

I thought I will have more dithering noise on dark areas instead of homogeneous black swatches. So, I think this rounding error exists on the 3DLUTs because madVR won't create dithering noise to mask the homogeneous black swatches. So I won't have a chance with DeepColor either.

May be I will play with the sRGB mode next time. That one has a much more neutral tonal response curve around the pure power 2.2 (bit still not a real gamma 2.2 without a high precision calibration).
But this experiment with the above mentioned circumstances let me believe that a 10+ VGA LUT calibration will produce better results. The 3DLUT processed data is dithered back to 8 bit and it won't do a real white balance correction with the current yCMS version.

madshi

6th August 2010, 17:21

Yes, may be I used this word in wrong syntaxes.
"Banding" is if you see visible steps in a color/brightness gradiant.

I mean, some of the different R=G=B=0..256 values will produce the same luminance level.
No, they won't. Depending on the gamma curve/value you choose, they may end up with *nearly* the same luminance level, but not with the same.

This is where I feel the need for 10+ bit output (henceforward combined with dithering).
Depending on the gamma curve/value you choose, you may also end up with nearly the same luminance level when using 10+ bit output. The bitdepth has nothing to do with that. You still don't understand dithering...

I thought I will have more dithering noise on dark areas instead of homogeneous black swatches. So, I think this rounding error exists on the 3DLUTs because madVR won't create dithering noise to mask the homogeneous black swatches. So I won't have a chance with DeepColor either.
Those black swatches are a consequence of the source material combined with the gamma curve type/value you've chosen. You would see the very same effect with infinite bitdepth, too.

What you are seeing is crushed shadow detail. You need to change the gamma curve type/value to fix that. Throwing more bitdepth at it won't change a thing.

yesgrey

6th August 2010, 18:54

And we didn't apply a proper white balance correction yet! It will be able to cause even more detail losses.
You need to understand one thing: the only way of not losing any details contained in the source is by using a perfect display with perfect viewing conditions, and the closest to these conditions are the mastering studio display/room. Out of this, anyone will start losing some detail.

When correcting the display's flaws some detail loss is unavoidable in certain situations, like gamut correction, specially when the display gamut does not contain the entire desired gamut, but that's the price to pay for more accurate colors. In other situations, like gamma correction, we might be able to increase the detail when compared to no correction.

The ultimate goal of yCMS is to perform all its corrections with the minimum detail loss, but in some cases that's simple not possible, and it has nothing to do with bit depths, but with displays limitations.

Fer

6th August 2010, 22:18

I show you more measurements to complete that of the previous post.

The Gamma curve is shown as a "Camera Gamma" in HCFR for transfer function 1.0 (fit to a BT.609 function).

Gamma_Curve 1.0 2.20
http://a.imageshack.us/img829/9359/gammatf1g220.th.jpg (http://img829.imageshack.us/i/gammatf1g220.jpg/)
http://a.imageshack.us/img832/9021/gamuttf1g220.th.jpg (http://img832.imageshack.us/i/gamuttf1g220.jpg/)

Gamma_Curve 1.0 2.45
http://a.imageshack.us/img822/757/gammatf1g245.th.jpg (http://img822.imageshack.us/i/gammatf1g245.jpg/)
http://a.imageshack.us/img820/2714/gamuttf1g245.th.jpg (http://img820.imageshack.us/i/gamuttf1g245.jpg/)

Gamma_Curve 1.0 2.55
http://a.imageshack.us/img411/642/gammatf1g255.th.jpg (http://img411.imageshack.us/i/gammatf1g255.jpg/)
http://a.imageshack.us/img821/5986/gamuttf0g220.th.jpg (http://img821.imageshack.us/i/gamuttf0g220.jpg/)

If we fit this last result to a pure power transfer function ("Display gamma" option) we have

http://a.imageshack.us/img822/9196/gammatf1g255pp.th.jpg (http://img822.imageshack.us/i/gammatf1g255pp.jpg/)

so, the standard BT.609 with a gamma 2.55 is "similar" (average gamma) to a pure power function with a gamma of 2.20. It must be said that
this configuration (Gamma_Curve 0.0 2.20) is the default target that must be reached after calibration according to HCFR software
http://www.curtpalme.com/forum/viewtopic.php?t=10457
In fact, now that I have smooth playback with my new ATI4850 card, although I need more time to test watching movies, this is an option that like very much:
daylight scenes with great contrast and depth and dark scenes good enough detailled.

One more time it can be seen that Gamma_Curve make a great job since the measured average gamma is very near to the value of the Gamma_Curve command.
Also we see that the gamut correction is near perfect for gamma=2.20 (deltaE < 2.8 for all the colors) and that slowly deteriorate for higher gammas.
yesgrey, can you explain this fact?

For achieving a higher gamut correction accuracy when using a pure power function you would need to use it as the input transfer function, and then not use the
Gamma_Curve command. This would give you higher accuracy when using the test patterns, but if the videos were created using the bt.709 transfer function you
would have lower accuracy when watching them, even though the test patterns would look perfect.

Perfect test patterns measurements only guaranty the same accuracy when watching the videos WHEN the test patterns are mastered exactly the same way the videos are...

But we do not have the certainty which of both transfer functions is used in video mastering, so it would be interesting to adjust the gamut whatever will be the transfer
function and the gamma value choosen for your particular display and ambient conditions?
:thanks:

janos666

6th August 2010, 22:57

Funny. If I want to oversimplify the last two posts: One of you speaks about the fact that some detail loss is inevitable, while the other one keeps telling me that the detail loss is impossible.

@yesgrey
Yes, I know it very well. I have a given display with it's given characteristics and there is no way to perfectly reproduce any images expect those which I create on this display. And all the published contents were made with other displays (and those were not absolutely perfect either) in consideration of an assumed end-user display. Nothing will be ever absolutely perfect on Earth. Even the Earth itself is not a perfect orb, so I don't have this illusion about "the perfection".
I have some available shades with their luma and chroma values to play with them. But my display has higher bit depth than usual source materials. It leaves me a little playground (when I can use 10+ bit output) and there is the dithering to make this game more interesting.

But I think you agree that we seek the optimal state between the theoretical perfection and the practically achievable states.

So, consider this when I talk about errors and side effects. I am not talking about the literal non-perfection but non-optimal states when the sacrifice is bigger than the benefit. These are the avoidable states. And of course, these are only my personal opinions.
For example, in this situation I felt that black swatches are worse than any benefit which is achievable by any gamma correction, even when the native tonal response is very weird. Of course, this was only one test with the given softwares and one material, and one given display, ect...

@madshi
I thought we agreed that we won't push this hypothetical dispute.

There is no any infinite thing in our existence. You can't build any infinite thing from limited resources. And an usual consumer display works with very limited number of available shades and pixels.
May be you can say that a human eye or a human made instrument won't be able to indicate the difference between the dithered 8 and dithered 16 bit or between the dithered 8 bit and native 10000 bit, ect. I don't have the instruments to do it but I think the quality of your dithering can be defined by an effective bit depth value. And I think this characteristic value is not a terrifyingly huge number.
You can say that it creates the illusion of the infinite bit dept if you resist to use this "infinite" word. But you refused the "illusion" word. So, I can't find any solution which acceptable for both of us.
Let's leave it alone.

I am not sure about these black swatches. I chose this movie because it has the best quality. (Yes, the Avatar was a "Horrible IMAX3D Experience" with the polarized lens, but this Blu-Ray material is the best available Blu-Ray material now.)
If the current processing will offer me the illusion of the perfect image, then Cameron thought that I should see black swatches in his shiny 3D movie. I doubt that. I saw it on an IMAX screen, so I am sure he wanted to show me the nicely rendered hairs and backgrounds.

But here is my explanation:
MadVR worked very well with nice dithering but it used 3DLUTs with 16 bit integer values. yCMS had to do some rounding! And madVR had to render homogeneous black swatches because the 3DLUT had equal values for those shades. MadVR won't render nice hair when the 3DLUT tells him that those shades should be equally black, right!? If it does render something else, then we are in a big trouble or we found the missing part around this "dithering issue".
Or... may be... The 3DLUT contains some rounding errors AND the dithering is not magically infinite, so the combination of these things created a perceived black swath on the screen.
Or... we are totally wrong about the ideal end-user tonal response.

What do you think about the double precision shader processing (it should work with any DX11 cards) and huge 3DLUTs? It won't harm if you start to use that unrar.dll (but I would suggest a 7zip.dll :D) and you make it as an optional mode.
But I doubt it will help. May be it will help if I try to think with your head in the dithering question. But it won't help if I resist that we need to increase the native output bit depth first (even if it can't happen any time soon -> so there is no solution yet).

Otherwise, I tried to set my desktop to 6 bit mode and the quality loss was evident without the dithering but I am sure it is noticeable with dithering as well. So, I think it would be true for 10+ bit output as well...

I think I really said some mad things this time. So, don't hesitate to teach me. :D

6233638

6th August 2010, 23:20

Just scanned over this topic and it looks like theres some confusion over gamma.

A flat 2.35 gamma is the correct way to be viewing film sources. Not an something that averages 2.35, but a flat 2.35 power function. You cannot use black level compensation either.
This requires a display with a high native contrast ratio - most modern displays just don't cut it. CRT, D-ILA projectors, the Kuros and possibly the latest Panasonic PDPs are really the only displays capable of this, and you need to be viewing in a dark room.

On any other display type black levels will be crushed and the image will look too dark/murky. Most other flat panels are not even capable of a flat 2.22 gamma down to black without looking bad. I have a Panasonic LCD here and it can't even display 2.1 properly it's so low contrast.

An inverse BT.709 transfer is wrong, even an inverse BT.709 modified for a higher system gamma. It might be the best compromise on low contrast displays like LCD though.

Fer

7th August 2010, 00:59

Otherwise, I think I will keep away from this state. I have BANDING problems (yes, I lost some visual informations) with these settings.
G.I. Joe and Pocahontas won't lie: 01 OFF (http://img12.tar.hu/janos666/img/82410398.png) - 01 ON (http://img12.tar.hu/janos666/img/82410397.png) ; 02 OFF (http://img12.tar.hu/janos666/img/82410395.png) - 02 ON (http://img12.tar.hu/janos666/img/82410396.png) ; 03 OFF (http://img12.tar.hu/janos666/img/82410623.png) - 03 ON (http://img12.tar.hu/janos666/img/82410624.png)
And a little extra, just for you (I found it right now). Marine Hero is a shapeshifter reptilian (http://www.google.hu/search?client=opera&rls=en&q=shapeshifter+reptilian&sourceid=opera&ie=utf-8&oe=utf-8), not an real Avatar (http://img12.tar.hu/janos666/img/82411521.png). :p

I don't have your problem. With Gamma_Curve 0.0 2.20. I don't lose shadow detail:

http://a.imageshack.us/img835/4521/avatarft0g230.th.jpg (http://img835.imageshack.us/i/avatarft0g230.jpg/)

neither with the "similar" Gamma_Curve 1.0 2.55

http://a.imageshack.us/img835/5049/avatarft1g255.th.jpg (http://img835.imageshack.us/i/avatarft1g255.jpg/)

janos666

7th August 2010, 02:27

Did you check this (http://img12.tar.hu/janos666/img/82447648.png) graph? I used a preset mode with very strange tonal response because I wanted to test a situation with big changes. Of course, it won't harm when your display is close to the desired values.
But you can check it with my settings (copy-paste the full code, it has a lot of lines :D) to see it in action.

@yesgrey: Do you use black offset for this gamma correction? Or do you scale the available values into the ideal curve (which starts from zero luminance)?

And may be it was a bad idea to include the measures from all IREs. Spectrophotometers don't like the dark, but I used the adaptive mode with long measurement times and I made this graph to check if it looks erroneous, but it's not. My colorimeter shows similar level graphs from the near black shades. (It miss the WP only.) And I wanted the best approximation.

madshi

7th August 2010, 08:05

@madshi
I thought we agreed that we won't push this hypothetical dispute.
Well, I thought so, too. But you keep on posting technical nonsense, so I feel like having to correct you.

So, I can't find any solution which acceptable for both of us.
The funny thing is that you admit yourself that you don't fully understand dithering. But still you insist on having an opinion about it. That's a typical concept for disaster...

MadVR worked very well with nice dithering but it used 3DLUTs with 16 bit integer values. yCMS had to do some rounding!
Ok, so there is some rounding involved, but at 16bit integer, which does not have twice the number of steps available compared to 8bit, but actually 256 x the number of steps. 8bit integer has 256 steps. 16bit integer has 65536 steps. The steps offered by a 16bit 3dlut are so small that your eyes will not be able to see a difference between 2 neighbor steps. Which means that the rounding at 16bit integer level cannot possibly harm perceived image quality, unless you're Superman. I've read that humans can see differences up until about 11-12 bits. So the 16bit 3dlut still has 16x - 32x more output steps than your eyes can resolve. As both yesgrey and I told you, the problems with the image quality you're seeing are caused by the gamma curve/value/correction, and not by technical limitations like bitdepth issues etc...

BTW, posting screenshots that were made with a correction 3dlut does not make much sense, because the only way to watch these screenshots correctly is to watch them on the display they were rendered for!!! So it's impossible for us to judge how that screenshot would look like on your display.

Just as an example: If your home cinema display had a heavily pink cast, yCMS would have to heavily color correct the image. As a result, if you took a screenshot of such a heavily color corrected image and displayed it on a different display, which doesn't have that pink cast, the screenshot would look very wrong. The same applies to screenshots that were taken with a 3dlut which corrects gamma for your specific display.

yesgrey

7th August 2010, 16:38

I show you more measurements to complete that of the previous post.
Thanks for your hard work. 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?

It must be said that this configuration (Gamma_Curve 0.0 2.20) is the default target that must be reached after calibration according to HCFR software
If you've followed our recent discussion in this thread about it, that's not true. No one can say that we should target a specific curve type or gamma value, because it would depend on several factors...

this is an option that like very much:
daylight scenes with great contrast and depth and dark scenes good enough detailled.
That's the only way of knowing for sure: looking at it. Just watch some movies and choose which looks more natural to you. There is no 100% rule, just start from some of the suggestions and fine-tune to your personal set and taste.

Also we see that the gamut correction is near perfect for gamma=2.20 (deltaE < 2.8 for all the colors) and that slowly deteriorate for higher gammas.
yesgrey, can you explain this fact?
Let me try...
The gamut correction must be performed on linear light. For that, we need to remove the gamma encoding. After correcting the gamut, the colors are all where they should be, but then we need to reapply the gamma encoding to feed it in our displays. If the encoding gamma is the exact inverse of the display response, we will get the same linear light as before, hence the exact colors. Now, this has a side effect: by using the exact inverse of the display, we nullify it, and then the display response is changed to be like the transfer function used when removing the gamma encoding.
Now, comes another problem... for image processing in linear light, the correct way of removing the gamma is by using the standard transfer function, as yCMS does by default, but for watching it's not, because our watching experience (our eyes) is influenced by the surrounding ambient conditions. So, in this case, I don't think there is much that could be done, except using a compromise between both... The good on all this is that the quality of the viewing is good within a certain range of gamma values, so we don't need to lose too much color accuracy.

As I've told in the other post, we could "cheat" the test patterns by using a different source transfer function and then get perfect gamut test results, but in reality the color gamut would still be wrong, because then the colors would not be corrected in linear light as it should, though in something very close... ;)

But we do not have the certainty which of both transfer functions is used in video mastering, so it would be interesting to adjust the gamut whatever will be the transfer function and the gamma value choosen for your particular display and ambient conditions?
Yes, you could do that.
If you want, you could try using:
Input_Transfer_Function 1.0 0.0 0.454545 0.0
instead of
Gamma_Curve 0.0 2.0

You should get the same gamma response, but the gamut correction might not be as accurate, even though with this you should get an exact color gamut with the test patterns... ;)

yesgrey

7th August 2010, 16:52

If I want to oversimplify the last two posts
That's the problem of oversimplifications: you lose completely the sense of each post. The detail loss I referred is not the same detail loss madshi referred, and that's not a subtle difference... ;)

If you really want to understand dithering, look at this thread (http://www.avsforum.com/avs-vb/showthread.php?t=1011359). See posts #9 to #13. It has some great images that will show you what is banding, and how dithering works. You will also understand what madshi meant with the "infinite bit depth". It shows a 10 bit image down converted to 2 bit, and the dithered image looks very near to the original one, except with lots of noise, but that's the downside of using dithering. However, don't worry, because dithering from 16 bit to 8 bit gives much less noise than the showed case... ;)

For example, in this situation I felt that black swatches are worse than any benefit which is achievable by any gamma correction, even when the native tonal response is very weird. Of course, this was only one test with the given softwares and one material, and one given display, ect...
As I've said, try with other curve types and with other gamma values.

yesgrey

7th August 2010, 17:05

I used a preset mode with very strange tonal response because I wanted to test a situation with big changes. Of course, it won't harm when your display is close to the desired values.
As I've told you before, the "harm" was caused by the gamma curve you selected, not by yCMS.

@yesgrey: Do you use black offset for this gamma correction?
yes, but only when the 0 IRE value is set.

And may be it was a bad idea to include the measures from all IREs. Spectrophotometers don't like the dark, but I used the adaptive mode with long measurement times and I made this graph to check if it looks erroneous, but it's not. My colorimeter shows similar level graphs from the near black shades. (It miss the WP only.) And I wanted the best approximation.
If your meter is accurate enough you should use it.

yesgrey

7th August 2010, 17:09

yesgrey

7th August 2010, 17:13

A flat 2.35 gamma is the correct way to be viewing film sources. Not an something that averages 2.35, but a flat 2.35 power function. You cannot use black level compensation either.
Where is the source for this statement?

janos666

8th August 2010, 01:09

BTW, posting screenshots that were made with a correction 3dlut does not make much sense, because the only way to watch these screenshots correctly is to watch them on the display they were rendered for!!! So it's impossible for us to judge how that screenshot would look like on your display.

Just as an example: If your home cinema display had a heavily pink cast, yCMS would have to heavily color correct the image. As a result, if you took a screenshot of such a heavily color corrected image and displayed it on a different display, which doesn't have that pink cast, the screenshot would look very wrong. The same applies to screenshots that were taken with a 3dlut which corrects gamma for your specific display.

Yes, but those screenshots are not absolutely useless.
The colors may look differently on every displays, but the identical shades on the images should be identical on the given screen. The loss of the visual informations (like the shadow detail vs black swatches) should be noticeable with any kind of proper 8 bit displays (until your display produces black crush, ect).

I already checked it before I posted them. I made the corrections for the Custom display mode (wide gamut, strange tonal response) characteristics. After that, I checked both of the images (corrected and uncorrected) in Custom and sRGB (relatively nice factory-calibrated) display modes too, and I checked both of the images on my secondary display (S-PVA in "native" mode - maxed RGB Gains without any LUT calibration - relatively natural characteristics with moderate black crush) as well.

I chose the dark gray (low contrast) instead, because you rarely see real blacks on the real world either. You will rarely see movie scenes where the black should be real black because real black exists on a perfectly darkened room only. Most of the cinema movies never show you scenes where you should see real deep black (only when the camera was in a perfectly darkened room).

For example: the bug that caused the corruption of the blue at very low levels (recently fixed) was barely noticeable if the brightness level was set correctly...

Yes, it was barely noticeable but you could see it too because you corrected it. :cool:
Should I stop reporting the "barely noticeable" and "really small" errors? :rolleyes:

By the way, not Superman but Riddick. :) My eyes work well in the dark. I will read a newspaper where others start behave like a blind.
On the other hand, you will never hear me talking about problems with the near-white scale. I can barely distinguish the differences in that range with 120 cd/m^2 white luminance and gamma ~2.2 tonal response.
But I am very sensitive to the shadow details. That's why I keep myself away from the relatively cheap plasma screens with noisy dark tones and PVA LCDs with their black-crush effect.

Otherwise, this is a very god example that you could see those errors on the screenshots as well...

As I've told you before, the "harm" was caused by the gamma curve you selected, not by yCMS.

Ok, let's see it again (and in the last time, I hope/swear):

In theory first:
If yCMS with MadVR + dithering produces infinite bit depth (ÁÁÁ), and my ColorMunki (in Adaptive HighRes mode) is good enough to accurately measure the luminance values for every available gray steps on a display with ~800:1 contrast ratio (so, dark tones are not really too dark...), and the ideal display has a pure power gamma ~2.35 tonal response, and I can see black swatches, then Cameron wanted to show black swatches.
Right?

But no. There were no black swathes on the IMAX screen and here is an other user with a different display (which lays closer to the theoretically ideal and desired characteristics, I think) and he doesn't have black swatches after the corrections. (May be because he needs less corrections.)

So, there should be an "error" somewhere. It can be:
- my instrument [*1]
- my eyes [*2]
- our assumptions about the ideal display [*3]
- Or... maybe... the current softwares are unable to produce infinite bit depth on limited display hardwares and you can lose some visual informations when you apply some corrections. [*4]

[*1] But what about Fer's results then? May be he used less measures, so he got lighter corrections - but his final result is less accurate, so it is not fully authoritative then).

[*2] You saw the black swatches on the screenshots. (Of course, it is not a real proof alone, but one fact.)

[*3] I will delineate an other test later.

[*4]You can freely do any kind of gamma, gamut and white balance corrections with infinite bit depth. But I can't do relatively big corrections with the current softwares.

------------------ New test results ----------------

I played with the sRGB display mode today.

I measured the display characteristics before and after the VGA LUT calibration and I checked it subjectively as well. After that, I used the measured values from the uncalibrated state and I put them into the yCMS input file. (Primaries, white and 256 luminance values.)

The 10+ bit VGA LUT could push my display very close to my target values. The measured gamma curve is very close to the ideal gamma 2.2 curve (with black offset, of course) and the white balance is nicely corrected as well (only the near-black shades left uncorrected where you hardly notice it - confirmed by my eyes...).
Of course, it didn't correct the gamut but it is very close to the sRGB gamut (one of the reasons why I bought this display - but this is an internal emulation!).
I tried to clear and reload the VGA LUT. The gamma changed but it didn't produce anything like those black swatches.

The yCMS and madVR + dithering combination produced some black swatches again. It was not as hard as the last one in Custom mode. But yes, it was easily noticeable by the naked eye.

Don't forget, the VGA LUT was created with the same spectrophotometer and I used the same software for the calibration and the characterization.

I used the Gamma_Curve 0 2.20 command. So, yCMS theoretically did the same thing what the VGA LUT did, expect the white balance tuning across the full tonal scale.

What is your first opinion?

I think yCMS and/or madVR with 3DLUT processing is not perfect yet.

Unfortunately, I can't measure the full gray scale from a media player window for a more objective and accurate comparison.

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

Otherwise, I also tried the default gamma correction (an input file without the Gamma_curve command). It produces much less (barely noticeable) detail loss.
It feels like you have a display with higher contrast ratio and the colors are more "vivid".
So, it is worth considering.

But the color of the brighter shades change too much. And I don't feel them natural but too "vivid". This effect is much softer with Gamma_Curve 1 2.35 but it kills too much shadow details again.

So, I will keep the madVR PC settings + VGA LUT corrections for now.
But it is still an open question for me, so I will reconsider it again is the future. And I will tire my visitors with the "Look! What do you think?" questions. :cool:

6233638

8th August 2010, 04:41

Where is the source for this statement?Professional CRT monitors used for mastering content measure 2.35 gamma. EBU guidelines specify 2.35 gamma based on extensive testing and Barco monitors are set to 2.35 by default. (EBU/SMPTE compliant)

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.

Black level compensation is used to avoid crushing shadow detail on low contrast displays, not display an accurate image. It is suitable for content creation but is not how you should watch things. Again, most displays on the market are too low contrast to display 2.35 gamma accurately and look better with lower gamma values. If your display is too low contrast, it might be an acceptable compromise.

When I say gamma should be "flat" I am referring to this representation of the data:http://a.imageshack.us/img822/9196/gammatf1g255pp.th.jpg (http://img822.imageshack.us/i/gammatf1g255pp.jpg/)

yesgrey

10th August 2010, 14:26

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

11th August 2010, 06:13

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

11th August 2010, 12:59

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

11th August 2010, 19:53

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

11th August 2010, 20:20

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

12th August 2010, 10:30

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

12th August 2010, 10:54

@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

12th August 2010, 11:14

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

12th August 2010, 16:41

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

12th August 2010, 17:46

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

13th August 2010, 02:51

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

13th August 2010, 08:37

- 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

13th August 2010, 14:46

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

13th August 2010, 17:32

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

13th August 2010, 18:15

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

13th August 2010, 18:40

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

13th August 2010, 18:50

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

14th August 2010, 01:51

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

14th August 2010, 02:12

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

14th August 2010, 14:21

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

14th August 2010, 16:52

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

14th August 2010, 19:24

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

14th August 2010, 21:45

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

14th August 2010, 22:55

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

14th August 2010, 23:31

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

15th August 2010, 00:10

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

15th August 2010, 01:40

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

15th August 2010, 02:24

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

17th August 2010, 16:57

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

17th August 2010, 18:58

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

17th August 2010, 19:13

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

17th August 2010, 19:48

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

17th August 2010, 20:57

@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

17th August 2010, 21:29

yesgrey

18th August 2010, 00:34

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

18th August 2010, 00:43

@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

21st August 2010, 03:08

janos666

21st August 2010, 17:28

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

22nd August 2010, 16:14

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

22nd August 2010, 16:45

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

23rd August 2010, 06:29

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

23rd August 2010, 15:19

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

24th August 2010, 01:42

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

24th August 2010, 02:07

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

24th August 2010, 02:09

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

24th August 2010, 02:19

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

24th August 2010, 11:00

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

27th August 2010, 20:27

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

28th August 2010, 00:14

yesgrey

28th August 2010, 02:12

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...

6233638

28th August 2010, 04:18

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.Use DeltaE 94 broken into LCH components to find the best compromise for where green should be. Distance (deltaE uv) is not always most important for color. (it is for grayscale) Remember color is 3D not 2D that chart only shows half the picture.

In order of importance unless theres major deficiencies its Luminance > Hue > Saturation. YCMS is probably doing the best correction so your greens have enough yellow in them.

Also make sure your using a uv chart for gamut and both axes are the same scale to give an accurate estimate of color, xy is not perceptually correct.

tschi

28th August 2010, 09:05

I will try to find a solution for it...
Thank you, it would be great !:)

Use DeltaE 94 broken into LCH components to find the best compromise for where green should be. Distance (deltaE uv) is not always most important for color. (it is for grayscale) Remember color is 3D not 2D that chart only shows half the picture.

In order of importance unless theres major deficiencies its Luminance > Hue > Saturation. YCMS is probably doing the best correction so your greens have enough yellow in them.

Also make sure your using a uv chart for gamut and both axes are the same scale to give an accurate estimate of color, xy is not perceptually correct.

I am not sure to understand your technical lingo :confused:
Anyway, my grayscale delta E is quite good between 40 to 100 IRE (see imageshack link) with and without ycms, but I would like to adjust the gamut near the reference as best as can. I am not sure it would make a big visual difference but geometrically speaking it would be the optimum :rolleyes:

6233638

28th August 2010, 13:04

Sorry. If your measuring distance from the point in two dimensions thats the deltaE uv number. Theres different ways of calculating color error with deltaE 76, 94, 2000, uv....
dE76 is default in HCFR I think. Its suitable for grayscale errors but not color error. Ideal measure for grayscale is dE uv because it only measures distance from D65 and ignores gamma error but its very strict.

For color errors you need to use dE94. dE94 is a combination of three separate dEs. Luminance which is color brightness. Hue which is color tint. Saturation which is color.... vividness. Some programs, not sure about hcfr, let you see the LCH on their own which is great for adjusting a CMS.

Color has three dimensions. Hue, Saturation and Luminance. The gamut chart you posted only shows hue (shift left/right) and saturation (in/out) ignoring luminance. If you only look at the distance on the gamut chart this is the same as using dEuv which is not a good measure for color performance as it ignores luminance.

In order of importance for being correct its 1. Luminance 2. Hue 3. Saturation. What you said sounds like your putting saturation first and ignoring luminance completely.

The chart you posted also looks like its the default one in HCFR. You need to right click it and set it to a uv chart and export it as a square image so the x y axes are the same scale. Only then can you judge distance between the measured point and target if you dont have deltaE uv numbers.
The default xy gamut chart is not a good representation of the data its misleading.

janos666

30th August 2010, 01:32

I made a custom test chart file for DispCalGUI and an excel sheet which converts the results into an yCMS v1.7 compatible input file format.
It can be very useful for ColorMunki owners (or anybody), so I decided to "release it": yCMS_Argyll_comp_v0.1 (http://www.tar.hu/janos666/yCMS_Argyll_comp_v0.1.rar)

But the real reason why I uploaded it that I want to ask you if my calculations are correct or not. :)
I am not sure about the color space of the RGB values. I used the Rec709 color space now. Should I use the device color space?
Should I use gamma weighting for the RGB values? (I think I should not because yCMS will use them for gamma correction... but I am not sure about your assumptions about the input values. I think you tested it with the values from HCFR, and I don't know how HCFR works.)

I decided to use 128 gray steps because yCMS gave me an error when it found slightly decreasing values (instead of increasing values) and I couldn't really insert 256 IREs. [###]
But I believe that it is my display's fault because it varies with various hardware settings (I couldn't find a proper solution with this display mode yet.) It is safer for a "public release" anyway, and should be enough.
And the last ArgyCMS version still has a ColorMunki related bug (but there is no any alternative and the next bug fix version will be released soon, so...)
* I recommend the Adaptive High Resolution mode for the i1 Pro and ColorMunki spectrophotometers! (And the latest ArgyllCMS version. You should check if the new bug fix version released!)
** I think I want to go ever further and start from the spectral data (you can ask ArgyllCMS to record it) because my latest paranoia is the EIZO white paper where they stated that we should use an XYZ color space with 10˙filed of view instead of the default 2˙field of view for wide gamut displays. I think this story will never end. :p

[###] I think I figured out the source of my old problem. I tired to insert my 256 values like this:
Grayscale_Measurements 0 0.072061393 0.109495877 0.165268895
0.7874 0.075778028 0.112976172 0.168187243
Because I thought that a first empty line counts like an IRE (when I got an error that I inserted more than 256 values) but it actually ignored the first line, so there were no black offset and the near-black scale was erroneous.
I think this little format problem caused the black swatches.

I can't notice any significant detail losses on dark areas now. And I think I like it better than the hardware emulation. (The contrast ratio is slightly higher and the device itself works with much better color accuracy in the native gamut mode, so the final quality depends on the software quality which looks great now... for the first look...)

But I need an advice: Is it theoretically better to set the RGB Gains first in the device's OSD?
Pro:
- It is a dynamic iteration. I can measure, correct and measure again until I find the best solution.
- It will be handled with 12 bit internal accuracy.
- It will be close but not perfect. The RGB Level graphs will fluctuate (and sometimes) cross each others (a little bit). (So, the software will always try to make further fine tunings.) And may be it worse if we consider the further circumstances in the "contra" section ->)
Contra:
- This optimization will belong to the native characteristics. It will permanently reduce the contrast ratio and the number of the available shades before we know the final corrections.
yCMS will make heavy gamma and gamut corrections. So, may be it is better to keep as much of the available shades and contrast ratio as possible. MadVR will assume that every shade is available...
(And may be it is still available because the device works with 12 bit internal accuracy. But I can't be sure until I measure it. And I can't be absolutely sure until I measure it with a very expensive instrument which would never happen...)

I tried to calibrate and profile my display (with BasicColor) with and without the RGB Gain optimization. I achieved significantly lower dE94 values and slightly lower contrast ratio with optimized Gains (as I expected).
But this was an iterative calibration. (It could measure, correct, and measure again. In theory -> I think BasicColor use much more simple process. But, for example, ArgyllCMS works with up to 4 iteration steps...)
And this is the first ColorMunki compatible BasicColor release, so it can also have some bugs. (And it is a great software but not the best. I couldn't find anything which is better and theoretically bug free now. :p)

I think I will try to make an excel sheet for dE94 and/or dE2000 calculations. But I am not sure how can I measure video test patterns (with a ColorMunki to get an usable output).

yesgrey

1st September 2010, 12:12

I am not sure about the color space of the RGB values. I used the Rec709 color space now. Should I use the device color space?
Yes. By the way, good work with the Excel ws, but the next yCMS version will support XYZ and xyY.

Should I use gamma weighting for the RGB values?
What do you mean with that?

I decided to use 128 gray steps because yCMS gave me an error when it found slightly decreasing values (instead of increasing values) and I couldn't really insert 256 IREs. [###]
But I believe that it is my display's fault because it varies with various hardware settings (I couldn't find a proper solution with this display mode yet.)
I don't believe it's your display's fault, because that would mean that different non-consecutive input values would have the same output value, and that's very unlikely... though, with digital displays anything is possible... but don't worry, even 128 points is overkill.

I think I figured out the source of my old problem. I tired to insert my 256 values like this:
Grayscale_Measurements 0 0.072061393 0.109495877 0.165268895
0.7874 0.075778028 0.112976172 0.168187243
Because I thought that a first empty line counts like an IRE (when I got an error that I inserted more than 256 values) but it actually ignored the first line, so there were no black offset and the near-black scale was erroneous.
The example on the manual shows an empty line, so, why have you put values on it? I thought you were reporting a bug, but now I understand what you were saying with you example... I will update yCMS to give an error when data is put on the command's line.

But I need an advice: Is it theoretically better to set the RGB Gains first in the device's OSD?
As I've said previously, I don't know. You need to try both ways and decide for yourself. It would depend on the display's calibration software/hardare precision. Sometimes it might be preferable to adjust the display and then fine-tune with yCMS, othertimes it might be preferable to adjust only brightness and contrast on display and perform the full calibration with yCMS.

madshi

1st September 2010, 13:15

The example on the manual shows an empty line, so, why have you put values on it? I thought you were reporting a bug, but now I understand what you were saying with you example... I will update yCMS to give an error when data is put on the command's line.
I'm wondering: Why did janos666 get black swatches without the IRE 0 measurement? Is the IRE 0 measurement so much different from what yCMS guessed for IRE 0? If there's no IRE 0, yCMS guesses it, right?

yesgrey

1st September 2010, 13:53

If there's no IRE 0, yCMS guesses it, right?
No. When there isn't no IRE 0 yCMS considers it to be 0.0. When the lowest given IRE is not too small, it's not a problem, but when, like in janos666 case, it's very small, it's a problem, because it ends up as a big discontinuity in the gamma curve.
I guess I will have to make yCMS detect and correct it and/or outputing a warning about it...

janos666

1st September 2010, 16:18

So the problem overview:
I couldn't insert 256 IREs because I got an error ("you can't insert more than 256 IREs"), so I tried to use the first empty line and yCMS accepted the input file.
I thought that the first line can be used and it always counts as an IRE (even when it is an empty line). But no, the first line was ignored and the other 255 values were used, so there were no black offset (here come the black swatches).

But it is still a bug: The real IRE limit is 255 instead of 256.

I believe this is a display fault because the luminance graph is very smooth in the factory calibrated sRGB mode but it always behaves strangely in the Standard mode. And it also depends on other hardware settings. I just figured out this behavior yesterday when I tried to optimize the WP with the Gains (I think I finally suppled this bastard :cool:). I will post some results later (with an updated excel sheet for validation purposes ; and input_transfer_function instead of gamma_curve, because I "rediscovered" the old bug with the gamma_curve and gamut emulation accuracy :D I am trying to calculate some CIE-Lab dE values right now).

janos666

1st September 2010, 22:18

Here are my results:

Uncalibrated state (hardware Gains at 255-255-255, linear VGA LUT, etc):

http://img12.tar.hu/janos666/img/84234651.png ; http://img12.tar.hu/janos666/img/84234652.png ; http://img12.tar.hu/janos666/img/84234653.png

yCMS Calibrated state (128 IREs + Primaries ; verified with 10 IREs + Primaries at 100% luminance):

http://img12.tar.hu/janos666/img/84234654.png ; http://img12.tar.hu/janos666/img/84234656.png ; http://img12.tar.hu/janos666/img/84234657.png

It's not bad. The gamut and gamma are very close. But the white balance correction is not so good (if even exists, I think it doesn't).

A little fine-tuning with the hardware RGB Gains (a little contrast ratio reduction as the "side effect" - but this is a 12 bit display, so it can hurt a 8 bit display...):

http://img12.tar.hu/janos666/img/84234658.png ; http://img12.tar.hu/janos666/img/84234659.png ; http://img12.tar.hu/janos666/img/84234660.png

yCMS Calibrated state (128 IREs + Primaries ; verified with 10 IREs + Primaries at 100% luminance):

http://img12.tar.hu/janos666/img/84234661.png ; http://img12.tar.hu/janos666/img/84234663.png ; http://img12.tar.hu/janos666/img/84234664.png

Well, this is fine. Nearly perfect gamut, gamma and white balance. (I think the WB is untouched here as well as earlier. Don't forget that it looks much smoother because I used much less sample points. Or yCMS would do small changes only.).

The only remaining question is the ratio of the lost and remained shades (if any -- I don't want to start it over now/yet/never but it is not measured/calculated yet*) and the accuracy of the mixed colors (I found it too hard to calculate CIE-Lab dE94 values in an excel sheet to do it only for curiosity...).

* I think you can do some kind of check on the 3DLUTs to calculate the number of the lost shades (clipped values, etc).

** Another note: SpotRead doesn't support Adaptive measurement mode, so these measures were made in normal High Resolution (spectrum sampling) mode. It can be more accurate in Adaptive mode. (And I can use the Adaptive mode for capturing the uncalibrated characteristics...)

And my personal problem that the two darkest grays are equal in this display mode. But this is nothing when compared to other possible calibration "side effects".
But this display mode offers significantly higher contrast ratio than the built-in sRGB emulation mode and contrast is good for movies.
(And the gamut is closer but it can be the difference between my instrument and the factory meters. It is below the "just noticeable difference" dE94 value anyway...)

madshi

2nd September 2010, 07:35

I'm not sure why but I think primaries are usually measured at 75% Luminance?

BeNooL

2nd September 2010, 11:25

Thanks janos666, I'll give your solution a try this week end.
I have a HCFR colorimeter, not the best but that's all I have for now.

janos666

2nd September 2010, 13:28

Thanks janos666, I'll give your solution a try this week end.
I have a HCFR colorimeter, not the best but that's all I have for now.

yCMS_Argyll_comp_v0.2 (http://tar.hu/janos666/yCMS_Argyll_comp_v0.2.rar) (new: graphical validation ; changed: input_transfer_function instead of gamma_curve).

I'm not sure why but I think primaries are usually measured at 75% Luminance?

The near-black and near-white scale may have some defects on some (digital) displays (with various hardware settings). But no, most of the softwares measure them at 100% luminance. (Instruments like the higher light intensity.)

But I also thought about it and I already measured them at 75% luminance. I think it is good for error checking (to see if the gamut emulation is valid for every luminance levels or not).

Results with inaccurate device WP and hardware corrected device WP at 75% luminance (and 70% for the WP):

http://img12.tar.hu/janos666/img/84234655.png ; http://img12.tar.hu/janos666/img/84234662.png

yesgrey

2nd September 2010, 20:36

changed: input_transfer_function instead of gamma_curve.

Nice work and nice results. :)
However, you should not forget that by changing the Input_Transfer_Function instead of Gamma_Curve you get "perfect" gamut graphs but that's not a guaranty that the same will happen with your movies. I still think that the gamma should be changed by using the Gamma_Curve command.

janos666

3rd September 2010, 02:14

However, you should not forget that by changing the Input_Transfer_Function instead of Gamma_Curve you get "perfect" gamut graphs but that's not a guaranty that the same will happen with your movies. I still think that the gamma should be changed by using the Gamma_Curve command.

In my understanding, the Input_Transfer_Function defines the transfer function of the assumed end-user display. And according to my current "faith" (we can only guess but I also made some subjective tests, like a Rec709 VGA LUT calibration and uncorrected or linearized image through this calibration, etc) this should be a pure exponential curve with an exponent about 2.35 (I am not absolutely sure about the exponent [2.2 ... 2.4] but I believe that it should be a pure exponential curve).
In this case, the gamma_curve command is redundant and it's result is less accurate (theoretically and subjectively).

I watched two Blu-Ray movies (Infestation - a comedy with many daylighted or bright indoor scenes ;and; The Cave - a horror with lot of extremely dark scenes) and my overall subjective experience was good.
Of course, it depends on many other things and placebo exists, so I don't want to make a judge yet. (But it felt good. I didn't experienced the "something is not right" subconscious feeling.)

I have an idea to make an assumption about the detail loss. You should check for identical sub-matrices* in the resulted 3DLUT and divide this by the number of the available shades in the 3x16 bit palette. (Different inputs shouldn't result in equal outputs.) I also want to see this number with 8 bit 3DLUTs. What do you think? Would it be easy or hard to implement? [*how do english people call them? I think I will make a visual illustration if you don't get it. :rolleyes:]

BeNooL

5th September 2010, 13:52

So I gave a try at AgyllCMS along with janos666's excel sheet to generate yCMS input file. I only have a HCFR colorimeter and first tested with my PC's monitor: a Iiyama ProLite E2003WS

In a nutshell, it's a disaster.

First of all, as the colorimeter is not very accurate I end up having yCMS complain that the grayscale measurement are not ordered.
Exact error message is
Error! 'Grayscale_Measurements' line n.xx is invalid.
All measurements must be specified in increasing order.

I proceeded to delete those faulty lines, but apparently yCMS has a bug and the reported lines don't match. I know it counts starting from the Grayscale_Measurements line onward still at some point it would always report line n-1 at faulty. (ie: error line 111, I delete 111, now I have error line 110, repeat)

So I updated the excel sheet to include a validation that all measurements from line n are inferior to line n+1. It prints an "err" on lines that do not satisfy this check.

After deleting all lines having an "err" flag yCMS accepts the input file!

It took me some time to figure out how to make the validation measurements but already by simply looking a video with madvr and 3DLut activated I could tell something was seriously messed up.

I still did the validation measurements with AVS test patterns.

Below are the results: left before with no correction and right with ycms active.

Gamut:
http://benool.free.fr/iiyama/gamut_uncal.pnghttp://benool.free.fr/iiyama/gamut_ycms.png

White balance:
http://benool.free.fr/iiyama/white_uncal.pnghttp://benool.free.fr/iiyama/white_ycms.png

Gamma:
http://benool.free.fr/iiyama/gamma_uncal.pnghttp://benool.free.fr/iiyama/gamma_ycms.png

We clearly see a lack of blue component but what's happening with the correction made by yCMS?!
It manages not so bad at first but what happens halfway?

I will try this afternoon with my RPTV and report how it goes.

yesgrey

5th September 2010, 16:56

I proceeded to delete those faulty lines, but apparently yCMS has a bug and the reported lines don't match.
We clearly see a lack of blue component but what's happening with the correction made by yCMS?!
It manages not so bad at first but what happens halfway?
Can you send me both your input files so I can test them? The first with faulty lines and the last one used for the measurements.

BeNooL

5th September 2010, 22:57

and this time I tried to calibrate my normal movie viewing device, a Sony KDS55A2000.

Gamut:White balance:Gamma
http://benool.free.fr/kds/gamut_uncal.png:http://benool.free.fr/kds/white_uncal.png:http://benool.free.fr/kds/gamma_uncal.png

As you can see I ended up having these strange seesaw for red component. This rendered the Input file unusable as I had to delete most of the lines due to values jumping up and down from one measure to the next.

I then ran ColorHCFR to check if still had more or less the same results as I did last time.

Gamut:White balance:Gamma (measured via ColorHCFR)
http://benool.free.fr/kds/gamut_uncal_HCFR.png:http://benool.free.fr/kds/white_uncal_HCFR.png:http://benool.free.fr/kds/gamma_uncal_hcfr.png

Except for the red shift it matches what I expected.

In the end it seem argyll doesn't like my HCFR sensor so much but the process to generate yCMS input file with it and the excel sheet is working great.

janos666

6th September 2010, 01:31

Sorry about that. I wanted to include this kind of error checking but I decided to exclude it (it was ready for the 256 IREs but I deleted it from the 128 IREs version). I forgot about the yCMS bug but I ran into the same trouble when I tried to use 256 IREs.

About your results...
You should read the ArgyCMS documentation. It talks about the HCFR sensor (unresolvable problems with 64bit Windows, poor accuracy, etc.).
And don't forget: It is a simple colorimeter. It won't work on wide gamut displays until you calibrate it to the specific display. You can do it with a reference instrument (spectrophotometers in this case). But I am not sure if you can save this calibration to the instrument itself or you are limited to the HCFR software.

The native wide gamut usually looks more saturated with uncorrected colorimeters but you could measure the corrected gamut (more or less). This is why the corrected gamut is too small.

This should be a bug but you can really have jagged graphs. I have strange jumps (not as much as you but something like this) when I set my display to Game mode (low input lag mode).

And I already mentioned that yCMS doesn't make a good job with the white balance. You should try to correct it with hardware controls first (it is necessary to get nice gamut.) -> After you calibrated or replaced your instrument.

BeNooL

7th September 2010, 09:43

You don't have to be sorry at all.
I know the sensor isn't very accurate still with the HCFR software simply adjusting the white balance yields excellent subjective results (HCFR requires a reference file for the display you are calibrating so this must help).

Thunderbolt8

9th September 2010, 11:49

there seem to be a few japanese blu-rays which have the wrong black levels, they might have used the wrong colourspace here. so they either mixed up 0-255 with 16-235, or the other way round.

any way to fix this using a 3dlut file? (for PC and TV)? if so, how?

yesgrey

9th September 2010, 14:09

any way to fix this using a 3dlut file? (for PC and TV)? if so, how?
A short sample would help to see what kind of correction should be done...

Thunderbolt8

9th September 2010, 16:50

A short sample would help to see what kind of correction should be done...
here are 2 short samples from the movie vengeance is mine (eureka master of cinema BD). picked a dark scene in which there are as well shadows and if you compare the darkest colours there with for example the black of the (mpc) black bars (in windowed mode), then you'll notice the difference.

http://remixshare.com/download/w5ybd
http://remixshare.com/download/dgd8e

http://forum.blu-ray.com/united-kingdom/106707-masters-cinema-moc-discussion-thread-50.html#post3597679
http://forum.blu-ray.com/united-kingdom/106707-masters-cinema-moc-discussion-thread-50.html#post3629961
http://forum.blu-ray.com/united-kingdom/106707-masters-cinema-moc-discussion-thread-52.html#post3657537

and here http://www.glennchan.info/articles/technical/setup/75IREsetup.html
"In Japan, the standard black level was changed from 7.5 IRE to 0 IRE in 1985"

yesgrey

9th September 2010, 20:41

here are 2 short samples from the movie vengeance is mine
Short answer
Add this line at the end of your input file:
Input_Range 30 218

Detailed answer
Looking at the samples it seems that the conversion might have been something like from 0-255 to 16-235, but the black|white on the source were on 16|235 and not 0|255, as the conversion assumed. So, you should compensate for it by changing the Input_Range on your yCMS input file.

The theoretical values are 29.741 (16+(16*219/255)) for black and 217.824 (16+(235*219/255)) for white. yCMS only accepts integer values, so you should round them. This is not a big issue, because the error caused by the bad conversion is so big that the slightly error created from this rounding is not significant.

Fine tune (+/-1 on both values) to your personal taste.

Thunderbolt8

9th September 2010, 22:51

thanks for that answer. since Im a complete noob on that, I use your HD & SD PC & Video template files, so I add that line you suggested right here

# Example input file for yCMS v1.0 and up
#
# Settings for creating a 3DLUT file for watching the following Video formats:
# Blu-ray, HD DVD, ATSC HD Broadcast, DVB HD Broadcast
# without any Display correction
# Includes YCbCr->RGB conversion using PC Levels (Black: 0 and White: 255)

# Set input format
Input_Format HD YCbCr 8
Input_Range 30 218

# Set output format
Output_Format HD RGB_PC 16

and here?

# Example input file for yCMS v1.0 and up
#
# Settings for creating a 3DLUT file for watching the following Video formats:
# Blu-ray, HD DVD, ATSC HD Broadcast, DVB HD Broadcast
# without any Display correction
# Includes YCbCr->RGB conversion using Video Levels (Black: 16 and White: 235)

# Set input format
Input_Format HD YCbCr 8
Input_Range 30 218

# Set output format
Output_Format HD RGB_Video 16

apart from that:

- how did you get those result values (or those with whom you did the calculations)? did you put that sample in some kind of parser? would be good to know in case if the other BDs with the same issue should have slightly different values.

- how can I switch between the different .3dlut files in madvr? can you have more than those 4 different input names as listed in the first post which are accept by madvr, so you'd not have to rename the files manually each time before starting?

- when trying to have the colours exactly the way they are meant to be, how come you'd suggest fine tuning with +/-1, while the mathematical rounding clearly suggests using that one value and not the other? or are there maybe other slight errors which could occur and the result could mathematically be off by +/-1? or is it really just for personal taste which then might not be 100% correct in the end?

- are softsubtitles played together with that movie also affected by that colour change? if so, what to do that they keep their standard colouration (.ass subs) ?

yesgrey

10th September 2010, 10:40

so I add that line you suggested right here ... and here?
Yes.

how did you get those result values (or those with whom you did the calculations)? did you put that sample in some kind of parser?
No, I've just paused the image and used "ColorPic" (it's a free tool) to see if there were any pixels with values below 16. Since there weren't, then I suspected that had happened what you said, they probably converted a video that was already on video levels to 16-235, hence rising the black levels and, probably, lowering the white level. I couldn't confirm the white level lowering because the video samples were only of dark parts, but you can confirm it for yourself using ColorPic.

Next, assuming the standard values of 16 and 235 for black/white levels, here is the math of a conversion from 0-255 -> 16-235. It's a compression from a dynamic range of 255 (255-0) to 219 (235-16), adding an offset of 16:
out = 16 + (in * 219/255)
Assuming the original video had black at 16 and white at 235, the locations of the original black and white levels on the new video can be calculated using the formula above. For the black level, it's pretty safe to use 16 as the value, because any data below this value is not valid video data. However, for the white level this is not completely true, because some videos might have valid data above 235. If you prefer playing safe, you could use a higher value for the white level, for example 240, or 245, but I think that you could use 235 without any problems.

how can I switch between the different .3dlut files in madvr? can you have more than those 4 different input names as listed in the first post which are accept by madvr, so you'd not have to rename the files manually each time before starting?
Currently you can use 2 3DLUTs for HD and 2 for SD. The HD/SD selection is automatically performed by madVR according to the rules explained in my second post. If you want to use more, you will have to rename them. However, you could create a simple batch file just for the renaming, so you would need only a single click before watching your movies, not a big issue. I think madshi plans to support more 3DLUTs in future madVR versions, but I don't know when.

when trying to have the colours exactly the way they are meant to be, how come you'd suggest fine tuning with +/-1, while the mathematical rounding clearly suggests using that one value and not the other?
It's not exactly for personal taste, but more for "mental" comfort.

Let's look at the black level. Considering the calculated theoretical value (29.741) is the correct one, if you use 30, the correct math rounding, then the blacks would be slightly clipped - hardly noticeable. If you use 29, you will increase slightly the black level - hardly noticeable too. So, just use the value that gives you more "mental" comfort, because in the end you probably can't tell the difference...;)

are softsubtitles played together with that movie also affected by that colour change? if so, what to do that they keep their standard colouration (.ass subs)?
Yes, because they are rendered on the image before the 3DLUT usage. If you want to keep their standard colouration you should change their colours on the subtitle renderer filter using the inverse formula. However, try it first, because they should only become darker, so it might not be a big issue...

Thunderbolt8

10th September 2010, 13:13

I've just paused the image and used "ColorPic" (it's a free tool) to see if there were any pixels with values below 16.
how did you do that? I dont have any field for black or white from 0-255, only hue, sat, val, red, green and blue. black only seems to be expressed as a percentage there.

in case you mean the val field, ive found values as low as 11 so far (from the samples I made) and also 255.

heres a sample for val 255 (parts of the umbrella): http://remixshare.com/download/bncy5

yesgrey

10th September 2010, 15:53

how did you do that? I dont have any field for black or white from 0-255, only hue, sat, val, red, green and blue. black only seems to be expressed as a percentage there.

in case you mean the val field, ive found values as low as 11 so far (from the samples I made) and also 255.
First, setup madVR disabling the 3DLUT and selecting PC levels. Then, look for the R,G,B values to see the highest of them (black and white are when R,G,B have exactly the same values). I've looked and val is always the same value as the highest of R, G or B, so you can use it. I confirmed that the umbrella have both R and G at 255, so it seems only the blacks are wrong...

Considering the above it might be preferable using:
Input_Range 25 235
(25 because: 16 + 11*219/255 = 25.45)
For the output, select video levels or PC levels according to what your display is expecting...

To be more precise, all the process also might have messed up the gamma, so probably you will also need to perform some gamma correction, but let's first try setting the range and see how do you feel about the image...

Thunderbolt8

10th September 2010, 16:23

now I've found val = 6, but its R2 G4 B6, that doesn't count, right? in that case, I cannot confirm if that val 11 I found had 2 times the same value for R,B,G

Im a bit confused now. so e.g. val 14 would be ok if you had like R 14, G something else, and B 14 again? what if you had R & B 14, but G and therefore val would be 16?

edit: ok, Ive definately found now val 11 with RGB all 11.

edit²: according to a changed 3dlut like that, if we did it all right then we should be able to find val 0 RGB 0 and val 255 RGB 255 when checking on those samples again, right?

can only find val 255 RG 255, but blue seems to be a little off like around 248 at best. so I guess the assumed black end for the input range still wasnt entirely correct?

jaydee81

10th September 2010, 18:58

Does it make any sense to use this with a PC Monitor?
Thanks,
JD

Thunderbolt8

10th September 2010, 21:23

next update, I've found a value with 0, RGB = 0 now somewhere in the movie. in case that should somehow not be valid, then val & RGB 3.

so in the end, the line should be "input_range 16 235" ? (in case of 0)

edit: but then theres no difference at all when using the lut file or not -.- but the picture definately looks somehow wrong that way

janos666

10th September 2010, 22:44

Does it make any sense to use this with a PC Monitor?
Thanks,
JD

Yes, very much. PC monitors may require more corrections because TVs and Home Cinema projectors were made for movies (this is another topic if they are really optimized for this purpose or not -> like WCG HDTVs without internal color management...) while PC displays were made for general PC usage.

yesgrey

10th September 2010, 23:14

next update, I've found a value with 0, RGB = 0 now somewhere in the movie. in case that should somehow not be valid, then val & RGB 3.
I forgot one setting. For analyzing the image you must set all scaling algorithms to "nearest neighbour". That's the only way of knowing which are the lowest/highest values on the source image, because when other scaling algorithms are used some lower/higher values could appear but only as a result of the chroma upsampling and/or rescaling of the image, which is not real data.

Thunderbolt8

10th September 2010, 23:48

hm it didnt change anything, I still keep finding val 0 RGB 0 or val 2 RGB 2. so 0 really seems to be the lowest value in the movie (quite at the beginning of the movie).

heres a sample for some 0 val 0 rgb values: http://remixshare.com/download/bmqe6

but why does the movie then still look so wrong? looks much better with that lut file which keeps input black at 16 or 11. even in places where its very dark and there are some 0 val blacks around, the colour is still greyer than the black of the mpc-hc black bars.

yesgrey

11th September 2010, 01:32

but why does the movie then still look so wrong?
Because it's wrong.

The fact that you could find some RGB 0 values only shows that the video suffered some kind of processing, and those values are the symptom of that. The black level is clearly wrong, so you have to move it down. OTOH the white level seems to be fine, so I think you should only correct for the black.

Thunderbolt8

11th September 2010, 03:31

yes, but to which values for the input_range? if I take those lowest and highest values of 0 and 255 into that formula you gave me, then Ill end up with 16 - 235 which then makes no difference compared to watching with PC levels & without the 3dlut file (unless I made some math mistake).

and why does finding values below 16 make the black levels wrong, while finding values over 235 makes white correct? im confused again :S shouldnt it either be both correct or both wrong? why taking the 255 we found into consideration for the formula, but not the 0 we found?

yesgrey

11th September 2010, 11:38

yes, but to which values for the input_range? if I take those lowest and highest values of 0 and 255 into that formula you gave me, then Ill end up with 16 - 235
The white level is fine, so you should use 255 into the formula. The black level is not, so you should not use 0, but one of the other values instead. If you want to play a little safer you could go with 11, but from looking at the samples you upload you don't lose anything if you use 16 into the formula.

and why does finding values below 16 make the black levels wrong, while finding values over 235 makes white correct? im confused again :S shouldnt it either be both correct or both wrong?
If you look at the sample n.3, where the 255 values are, it's perfectly noticeable the crushing on the whites if you do not use 255. Look at the umbrella, it almost look as a 1 full bright umbrella. Furthermore, the machinery behind the umbrella also disappears.

If you look at the other samples, with dark imagery, you cannot watch any detail loss when using 11 or 16. The only thing you would notice is the lowering of the black level, nothing more. The lower values you are detecting are just noise, and not valid data.

Now, let's look into this in another way... Let's quote a sentence from one of your previous posts:
"In Japan, the standard black level was changed from 7.5 IRE to 0 IRE in 1985"
This also justify what's happening... This movie is from 1979, so probably they simply got the old video with the black level at 7.5 IRE, hence only the black level being flawed.
Now, let's find which value in 8 bit corresponds to 7.5 IRE:
7.5/100*256 = 19.2
So, probably you could go a little further and use 19 into the formula (gives 32) without losing any shadow detail, because it seems that below that value there is not any valid data, only noise/processing artifacts. I've tried it, and did not found any losses on shadow detail, but maybe the image is too much dark for your taste... try it for yourself and decide.

Thunderbolt8

11th September 2010, 14:12

ok so what you say in order to find out I basically need to try and compare values, using them and not using them in a 3dlut files and in case theres a difference, I would have to use the full spectrum (as with white) and if no difference in detail (as with black), then Im fine with 16 (or maybe 19.2 to be more accurate)? I only find it very hard to spot differences in detail in such darkness :S

is there any way I can compare those 2 different settings with 30 and 32 by switching (e.g. switching 3dlut files on the fly)? cant take screenshots with madvr yet.

To be more precise, all the process also might have messed up the gamma, so probably you will also need to perform some gamma correctionalright, since the black level thing above seems to be solved now, what about this, how to do this?

yesgrey

11th September 2010, 14:29

ok so what you say in order to find out I basically need to try and compare values, using them and not using them in a 3dlut files and in case theres a difference, I would have to use the full spectrum (as with white) and if no difference in detail (as with black), then Im fine with 16 (or maybe 19.2 to be more accurate)?
Right.
There is a shortcut in madVR for switching from PC->video levels and back without opening the settings dialog (Ctrl+Alt+Shift+Y).
I always use it when I want to compare 2 different 3DLUT files. It's easy to spot differences this way, in case they exist.

I just find it very hard to spot differences in detail in such darkness :S
This sentence almost answer your own question... If it's hard for you to see any detail in that area, even if exist any, why bother? Simply lower the black level and enjoy a better viewing experience. Watching those films with such a raised black level would be a lot worse, IMHO.;)

I will reply later about the gamma correction. I have to think about it, and now I'm very busy working on the next version of yCMS...

yesgrey

11th September 2010, 14:32

is there any way I can compare those 2 different settings with 30 and 32 by switching (e.g. switching 3dlut files on the fly)?
Yes. In addition to what I've said on my previous post about the shortcut, you just need to rename one of the files as the PC levels and the other as Video levels. When you switch a OSD label appears showing which is in use. Use exclusive fullscreen for the testing, because on windowed mode the label sometimes doesn't appear...

yesgrey

12th September 2010, 17:56

yCMS v1.8 released

http://yesgrey.com/ycms.html

- Added verification of measurements below 30 IRE.
- Added new parameter 'format' to Grayscale_Measurements.
- Added Yxy and XYZ support on Grayscale_Measurements.
- Removed RGB support on Grayscale_Measurements.
- Changed error messages to show the input file line number where it ocurrs.
- Added test to verify if a command has surplus parameters.
- Fixed bug on maximum number of grayscale measurements. It was max-1.

yCMS does not support RGB measurements on Grayscale_Measurements anymore. From now on should be used Yxy or XYZ formats instead.

These new formats should allow yCMS to perform color balance correction, but I did not test it. I haven't my new PC configured for using my calibration equipment, so I would like if anyone could test these two modes and report back their results.

These new formats should also allow a more accurate final gamma curve when using the Gamma_Curve command. Please confirm that too.

Enjoy.:)

janos666

12th September 2010, 19:17

Thanks for the new version. It looks promising. I will test it. ;)
By the way, last time I decided to calibrate my display with the VGA LUT (targets: D65 and gamma 2.35) and do only gamut correction with yCMS. The reason was the better error handling.
- If yCMS receives equal or slightly decreasing Y values for different (increasing) IREs, it simply refuses to make a 3DLUT file. It always assumes that it is a measurement error.
- If ArgyCMS/Dispcal finds that a display is broken, it tries to fix it. For example, when R=0, R=1, R=2 produces the same luminance (or it shows decrease instead of increase - oh ya, the random measurement deviation exists as well, but this is another story), the LUT will start from R>2

I think you should consider this error handling. You should let the user to decide if he believes in the measurement data and thinks that the display is broken (and he wants to compensate it) or he wants to ignore the seemingly erroneous measurements.

I am sure that in my specific case, the measurements are correct and the display is faulty. I can see it with my own eyes as well and I can measure much lower luminance levels with my instrument. This is not some extraordinary thing with digital LCD displays.

tschi

12th September 2010, 19:45

Hi yesgrey,
Thanks for the new version :)
here some results (colorhcfr files)
http://www.mediafire.com/?9gjodlhsvhgoxpb
no ycms /ycms with XYZ formats + gamma_curve 0 2.2 / ycms with XYZ formats default gamma curve
Is the choice of the format (XYZ / Yxy) can change the result ?

janos666

12th September 2010, 19:53

Is the choice of the format (XYZ / Yxy) can change the result ?

You can easily convert the values between the XYZ and xyY formats with a simple linear formula. So, no, it can't change anything or something is wrong.
You should use the XYZ format because the xyY is calculated from it. (You can avoid the conversion errors and rounding, etc.)

tschi

12th September 2010, 20:03

ok, thanks

yesgrey

12th September 2010, 20:29

here some results (colorhcfr files)?
Wow, you were fast! :)

The results look promising... Above 40/50 IRE the results are very good, but below don't. That made me think: did you use the XYZ or xyz values from HCFR? HCFR users must be very careful with this, because they should select the "XYZ", all in capitals, and not the "xyz" in lower case.

You should use the XYZ format because the xyY is calculated from it. (You can avoid the conversion errors and rounding, etc.)
I agree with you on this, but considering the above I think I would suggest to use Yxy instead. The conversion errors by the software should be insignificant, but if people use xyz instead of XYZ it would be way worse...

tschi

12th September 2010, 21:17

I use XYZ because colorHCFR does not export xyY to .xls :(
And it 's so easy & quick to copy and paste results in ycms text files using .xls :rolleyes:

yesgrey

12th September 2010, 22:50

I think you should consider this error handling. You should let the user to decide if he believes in the measurement data and thinks that the display is broken (and he wants to compensate it) or he wants to ignore the seemingly erroneous measurements.
The current method was made to call the attention to the user that he might have switched, by mistake, some values. I did not consider that it could be errors from the meter. I will add some error handling on the next version. Thanks for the suggestion.

I use XYZ because colorHCFR does not export xyY to .xls :(
No, problem. As janos666 said it's preferable to use XYZ, only be careful to not use xyz by mistake... ;)

janos666

13th September 2010, 00:57

Well. I didn't find any other bugs but I think the white balance is still not corrected.
I inserted 255 XYZ points (I had to skip the second erroneously decreasing value) but the white balance looks untouched. And the offset white point still degrades the precision of the gamut emulation too.

You could see my results with hardware gain corrected WP and offset WP. Now, here are my new results with offset WP and XYZ inputs:

http://img12.tar.hu/janos666/img/88329968.png http://img12.tar.hu/janos666/img/88329969.png http://img12.tar.hu/janos666/img/88329970.png
http://img12.tar.hu/janos666/img/88329965.png http://img12.tar.hu/janos666/img/88329966.png http://img12.tar.hu/janos666/img/88329967.png

Just a small notice, but can you accept XYZ format for the gamut_measurements command too?
For example, the xy format would go into the first line and an empty first line would mean XYZ format where you can copy your XYZ values in separate lines.

By the way, it is redundant to ask for white xy coordinates when you specify the 100% IRE with three dimensional format. It will ask for a slight correction which is the measurement deviation and/or format conversion related difference.

Thunderbolt8

14th September 2010, 15:51

any idea of what I could try about the gamma correction of that movie of mine yet? ;)

janos666

25th September 2010, 01:32

http://forum.doom9.org/showpost.php?p=1445481&postcount=4605
"I do not plan to do any CMS kind of stuff myself. That is yCMS' job. What you could do is go to the yCMS thread and ask yesgrey there to add an ICC -> 3dlut conversion utility."

@yesgrey: What do you think?

yesgrey

25th September 2010, 13:00

About what?

janos666

25th September 2010, 14:52

About using lcms2 (http://www.littlecms.com/index.html) to calculate gamut and gamma corrections for 3DLUTs.
I think an ICC profile based CMS can theoretically give us better result than the current yCMS engine. (But I can't compare it, so I am not sure.)

yesgrey

25th September 2010, 17:03

About using lcms2 (http://www.littlecms.com/index.html) to calculate gamut and gamma corrections for 3DLUTs.
That's out of question. I will not use any code from other people on yCMS. The only exception is ALGLIB project, but that's only for the interpolation of the grayscale measurements. However, as soon as I find the time for it, I will write my own code for it and drop ALGLIB.

madshi

25th September 2010, 17:37

Would it be difficult/useful to implement ICC profile import functionality to yCMS? Don't really know, just a thought...

janos666

25th September 2010, 20:23

Well, I think he can read out some informations from an ICC file for basic yCMS processing easily (matrix tag for gamut and average gamma for gamma correction). But this is not what I want to see. I am not sure about a real, ICC LUT based processing.
But why do you resist to use other's work when it's done and available for free? Yes, it's nice to write your own code and you should continue it but why won't you implement an existing code until you don't have any better solution?
(Yes, it's another question if lcms2 is better or worse but it is theoretically better.)

[And I can't understand your statement about ALGLIB. I would never hesitate to use something which is already done and available for free. May be I would improve it for my needs and share the improved version with others, etc/aso. But re-create something which is already exists? In my eyes, it's the absolute waste of time. You can do something much more useful instead...)

I am not talented enough to do it but I would do it for myself if I know the structure of the 3DLUT files.

yCMS 1.8 uses 2D primary color and white point coordinates with a single 3D gamma curve. This is something what an ICC file would call "matrix+shaper profile". It is nice for high-end displays which behaves close to a perfectly additive/linear display. But the usual LCD and plasma displays often lay far from that.
A LUT based ICC file can be constructed from theoretically infinite number of measurement data. You can measure single channels and secondary colors at various luminance levels to make a much better guess about the effects of the corrections.
As you can see it on my graphs above, yCMS isn't really able to correct the white balance. I think it's because it knows the current state (color luminance levels and chroma coordinates) of the grays but it doesn't know anything else about the display. It can't make any real guess what can happen when it tries to correct the white balance. If the display is not a perfectly additive/linear device, it can produce even worst results.

That's why I decided to make a high quality VGA LUT calibration to D65 and gamma 2.35 targets and 3DLUT processing like this:
Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Input_Transfer_Function 1.0 0.0 0.425531915 0
Gamut_Measurements 0.6817928 0.307676391 0.204774561 0.696317393 0.150704032 0.055593849 0.310563576 0.326995079
Output_Transfer_Function 1.0 0.0 0.425531915 0
The calibration pushes my display closer to an additive display, so a matrix calculation for gamut emulation can be successful.
But my other display works with 8 bit/color only, so I shouldn't calibrate it with the VGA LUT for targets like these. But it would be nice with dithering. (I am using MPC-HC with EVR-CP + ICC based CMS for this display right now. But it has other drawbacks. For example, I think they forgot to use black offset. But it is not that bad, colors looks good. And I hope they fix the black crush soon.)

madshi

25th September 2010, 21:43

A 3dlut can theoretically map any possible color to any other possible color. So basically there's almost no limit to what you can (theoretically) do with a 3dlut. The only question is how to calculate the 3dlut to make it work perfectly. I don't think that an ICC profile is theoretically better than using a 3dlut. Actually I think it's the other way round - provided that the 3dlut is calculated in a good way. yesgrey is constantly working on improving yCMS, so you can't just take the current version as the ceiling of image quality you can potentially get by 3dlut processing.

Suggesting to us to simply use lcms2 doesn't really make much sense, because it's a totally different concept. yesgrey would basically have to throw away all his work. And that for a solution which IMHO is not actually any better at all? Furthermore, lcms2 does not really fit the madVR + yCMS approach. yCMS does the calculations offline and madVR simply uses them. This way yesgrey and I can split the work. When using an ICC type of solution, splitting the work would be very difficult. Probably I would have to do all the work alone. And again: All that for a solution which is IMHO not any better?

Please note that when I'm talking about whether ICC profiles or the 3dlut approach is better or worse, I'm talking about potential, and not necessarily about the current state of things.

A LUT based ICC file can be constructed from theoretically infinite number of measurement data.
The same is true for 3dluts.

You can measure single channels and secondary colors at various luminance levels to make a much better guess about the effects of the corrections.
The same is true for 3dluts.

As you can see it on my graphs above, yCMS isn't really able to correct the white balance.
Not the current version, maybe (yesgrey?). But that's not a shortcoming of the general 3dlut concept, but just something yCMS does not appear to do correctly just yet.

janos666

25th September 2010, 22:06

memmerson

26th September 2010, 09:39

Hi,
I am getting the following error when attempting to generate a 3dlut:

Error! Line 6 - Previous measurement was higher. All measurements must be specified in increasing order.
My input file is as follows:
Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16

Grayscale_Measurements 1
33 0.926286 0.29594 0.324745
37 1.18544 0.293792 0.322481
41 1.44325 0.292435 0.321269
45 1.75784 0.290731 0.318757
50 2.11293 0.291182 0.319109
54 2.45289 0.290722 0.317749
58 2.85725 0.290821 0.318597
62 3.25171 0.291342 0.318807
66 3.69734 0.291563 0.318772
70 4.17525 0.292272 0.319191
74 4.63349 0.291336 0.319286
79 5.15526 0.292582 0.319647
83 5.65992 0.292276 0.319268
87 6.17528 0.29152 0.319866
91 6.75987 0.291674 0.318983
95 7.29939 0.291294 0.31888
100 7.90411 0.291128 0.318659

Gamut_Measurements 0.666 0.326 0.284 0.707 0.135 0.052 0.291 0.318
I guess it is referring to the ire 37 measurement, but I am unsure what to do about it. Any suggestions?

Thanks

yesgrey

26th September 2010, 10:46

I guess it is referring to the ire 37 measurement, but I am unsure what to do about it. Any suggestions?
That's a bug. Previously I was expecting the user to enter the Luminance values for each color channel, so I always tested all color channels when looking for lower values. Now, I should test only the Luminance channel, and not the others. I will try to correct it soon and release a new version - hopefully today.

Thanks for reporting.

yesgrey

26th September 2010, 11:06

But why do you resist to use other's work when it's done and available for free?
And why shouldn't I? I do this for fun, because I want to learn more about it, and the only way of really understand and know something is doing it.

Yes, it's nice to write your own code and you should continue it but why won't you implement an existing code until you don't have any better solution?
Because the time I would "waste" on that is time I can use on doing what I want to do.

But re-create something which is already exists? In my eyes, it's the absolute waste of time. You can do something much more useful instead...)
Everything that people do in their life is simply wasting time. We only chose how we want to waste ours. ;)

I am not talented enough to do it but I would do it for myself if I know the structure of the 3DLUT files.
That's public: http://thr3dlut.sourceforge.net/

yCMS 1.8 uses 2D primary color and white point coordinates with a single 3D gamma curve. This is something what an ICC file would call "matrix+shaper profile". It is nice for high-end displays which behaves close to a perfectly additive/linear display. But the usual LCD and plasma displays often lay far from that.
I'm perfectly aware that yCMS has several shortcomings, even though the current results are already very good. I plan to improve yCMS by correcting them, but that would only happen in yCMS v2.x. I want to make v1.x stable before starting working on the next major version, and I think it's almost there.

madshi

26th September 2010, 11:13

I think I didn't drew it correctly. I know that the problem is not the 3DLUT itself but the calculation of the corrections. So, yes, you can keep the 3DLUT concept.
And yes, I know that a different (and external) solution would make the current engine useless. But this doesn't mean that we shouldn't try if it can be theoretically better.

I wanted to suggest that may be yesgray should try to use an existing ICC based CMS software to create the corrected 3DLUT files. It doesn't sound like a big job. He only need to send through every possible RGB colors and save the results into a 3DLUT.
And if it works significantly better, than he should work on his own solution which works even better. But it can show the path if yCMS should work with measurement data from single channel and secondary color measurements, like the engines of the compilers of the LUT based ICC profiles. (It would prove that 2D primary color coordinates and 3D gray coordinates are not always enough and you need more samples from other colors as well. - at least for average LCDs)
Ok, that makes more sense. If you want, you can ask the lcms2 programmer if he would be willing to add a madVR+yCMS compatible 3dlut output option. That might make for a nice alternative for people who already have a good ICC profile. However, if you want to do that, I'd wait a bit before asking him, because the 3dlut input/output formats used by madVR are going to change soon (currently: 8bit YCbCr -> 16bit RGB, soon: 8bit RGB -> 16bit RGB).

Personally, my bets are on yCMS, because there are some things yesgrey and I have not told anybody yet.

madshi

26th September 2010, 11:24

P.S:

Yes, it's nice to write your own code and you should continue it but why won't you implement an existing code until you don't have any better solution?
You argue as if yesgrey would have unlimited time. That is not the case. His time is limited. He has to decide how to spend his available programming time. He can either implement existing code, or he can work on his own solution. If he implements existing code, that costs time which is lost for working on his own solution. So your suggestion wastes a lot of precious time by first spending time to implement some code written by someone else, and then afterwards trying to develop a better solution. yesgrey doesn't have any time to waste. So he directly tries to develop a solution which is better than anything else out there. And in that he has my full support.

But re-create something which is already exists? In my eyes, it's the absolute waste of time.
Re-creating something (madVR) which is already exists (EVR)? In your eyes, it's the absolute waste of time.

If everybody would think like that ("there already exists a solution which is good enough"), there would not *ever* be any progress, because nobody would ever try to develop something better than already exists.

yesgrey

26th September 2010, 19:35

any idea of what I could try about the gamma correction of that movie of mine yet? ;)
Add this line at the end of your files:
Output_Transfer_Function 4.5 0.099 0.45 0.018
This will specify the output gamma of the file. You should change the bold value to your taste. The standard value is 0.45 (1/2.2222). If you want to make the image brighter decrease the value (for example 0.40 (1/2.5)), if you want to make it darker increase it. However, I think you would not want that in this case... Don't forget to lower the black level with the Input Range command.

I have tried Input_Range 30 235 with 0.40 as the gamma and the results looked good. Give it a try... remember you could create different 3DLUT files using different values and compare.

Thunderbolt8

26th September 2010, 22:09

thanks. is there any way here again as with the input range to get a mathematical 'correct ' result how the original gamma is supposed to be (assuming we found the correct lowest black level values)? or is it just 'try what suits you best' here?

janos666

26th September 2010, 22:26

Re-creating something (madVR) which is already exists (EVR)? In your eyes, it's the absolute waste of time.

If everybody would think like that ("there already exists a solution which is good enough"), there would not *ever* be any progress, because nobody would ever try to develop something better than already exists.

You know, I talked about the usage of the ALGLIB here (as an example). I don't do any programming (but I know the very basics of C++ programming) but this ALGLIB looks like a cool stuff for me. If I would write an own program which requires some of these functions, I would be happy that I can use it instead of creating an own solution with hard work.
The ignoring of the ALGLIB sounds something like the ignoring of the stdio.h for me. But ok, I don't want to argue about that. I can understand the other motivations behind these kind of thinking (even if I would never behave like this).

You argue as if yesgrey would have unlimited time.
I would agree if I asked for a complete ICC cLUT based engine from scratch, just for fun. I thought it's not a big deal to use an existing CMS software to send through the RGB numbers and save the corrected results.
I think I will be able to do it for myself after you switch to RGB->R'G'B' 3DLUTs because the only missing part is the YCrCb->RGB conversion which I don't want to re-create for myself (and I think I am simply not talented enough to do it...). I have the tools for an easy RGB->R'G'B' implementation right now. (That's why I thought that it would be easy for yesgrey if he accept to use other's work.)

It's easy to create the input (every possible RGB combinations in given order) and send it through ArgyllCMS/icclu (http://www.argyllcms.com/doc/icclu.html) to get the corrected colors. Now, I can see that the 3DLUT specifications is public, so the only missing part is the YCbCr->RGB conversion. But yesgrey already has it, so it sounds like "one hour of programming" for somebody who is already familiar with these things.

But OK, it was only an idea. I accept the "NO" answer. :o

Personally, my bets are on yCMS, because there are some things yesgrey and I have not told anybody yet.
I'm perfectly aware that yCMS has several shortcomings, even though the current results are already very good.
Ok, don't blame me if I can't see into your brains. I can't wait to see it. :rolleyes:

yesgrey

27th September 2010, 00:32

is there any way here again as with the input range to get a mathematical 'correct ' result how the original gamma is supposed to be (assuming we found the correct lowest black level values)?
Unfortunately no. It might be possible with a more complex processing chain, but considering that we would only be guessing what it might be I think it's not worthy. Furthermore, the benefit might be very small, because the gamma in a movie is supposed to be more robust than the black level, so a slight difference from the ideal is not so critical.

Just try some values and go for the one that pleases you more. Either way, it's an old movie with not a very big quality, so you would never be able to make it look much better...;)

Let me know how it ended up, and if you enjoyed a good movie experience after applying all these corrections...

janos666

27th September 2010, 01:33

I know, the XYZ support is still young but I already have a new feature request: support for the CIE 1964 (FOV10) observer based XYZ color space.
EIZO (and others) thinks (http://www.eizo.com/global/support/wp/pdf/wp_08-002.pdf) that this observer produces much better results in certain real-life situations than the usual 1931 (FOV2) observer.

I tried to calibrate my display with this observer setting and the result is promising. But I can't use these XYZ.10 values with yCMS. And there are certain problems:
- If I take XYZ.2 measures on the XYZ.10 calibrated display, the white point won't looks like D65, so the gamut will be drifted around the offset white point.
- There is still some gamut drift when I use the XYZ.2 measurements with a "fake" D65 white point. (This observer differs in the luminance tracking as well, so my output_transfer_function is a false number now, even if I calibrated my display to the same targets...)

I think that the usage of this observer may be able to provide better results but it should be supported by the CMS application too. (It doesn't work when you try to use your XYZ.10 values in a software which is supposed to work with XYZ.2 values.)

(The EIZO document talks about wide gamut displays. But this is not limited to WCG displays. It is a general thing. But you can see the limitations of the XYZ.2 color space based calibration when you try to compare different displays, and WCG differs from sRGB...)

Is it even possible? (I mean I know that the world is built to the XYZ.2 color space. New standardized observers are exist but if nobody really use them, then it can be hard to find the formulas for your calculations. And we need to find the reference points/curves of the Rec709 standard in this color space which sounds hard.)

And I am sorry if this is a bad idea (I think I had some in the near past). :o

madshi

27th September 2010, 07:34

You know, I talked about the usage of the ALGLIB here (as an example).
Ok, I see your point about ALGLIB. I thought you were talking about lcms2, mainly.

I think I will be able to do it for myself after you switch to RGB->R'G'B' 3DLUTs because the only missing part is the YCrCb->RGB conversion which I don't want to re-create for myself
Well, if you do manage to create an ICC -> 3dlut "conversion" tool, you're very welcome to publish it, of course, so everybody can use it and compare it to yCMS.

Thunderbolt8

28th September 2010, 01:29

Let me know how it ended up, and if you enjoyed a good movie experience after applying all these corrections...
I think I will go with input 32 235 and then gamma either 0.40 or 0.41. both look a tiny bit better in one scene or another, cant take the middle I guess :D

but the movie looks much better now than before, thank you very much for your help! ;)

yesgrey

28th September 2010, 12:06

I think I will go with input 32 235 and then gamma either 0.40 or 0.41. both look a tiny bit better in one scene or another, cant take the middle I guess :D
In fact you can. That's a double number, so you can use up to 14 decimal places, so you could go with 0.405.;)

the movie looks much better now than before, thank you very much for your help! ;)
Great.:)

madshi

28th September 2010, 12:19

That's a double number
For the non-programmers out there "double" is a high precision floating point data type, allowing up to 14 decimals. When I first read that sentence I thought "it's a double=twice number"? :)

yesgrey

28th September 2010, 16:00

thanks madshi, I should have been more clear...

Thunderbolt8

3rd October 2010, 16:06

I think I will go with input 32 235 and then gamma either 0.40 or 0.41. both look a tiny bit better in one scene or another, cant take the middle I guess :D

but the movie looks much better now than before, thank you very much for your help! ;)aww, forgot about the subs.
you said the colour of the subs changes as well with all these changes being made, so I'd have to adjust them.

the colours I usually use for my .ass subs are 246 245 222 for primary, 255 0 0 for secondary and 0 0 0 for outline and shadow.
what would I have to do here with input 32 235 and gamma 0.405? im not very good at maths :S

darkbasic

2nd November 2010, 11:43

Hi, I can't achieve decent color correction with yCMS, can you help me?
Here is the thread: http://forum.doom9.org/showthread.php?t=157722

Thank you

yesgrey

3rd November 2010, 00:45

Hi, I can't achieve decent color correction with yCMS, can you help me?
Until 4th November I'm a little busy, but after that I will read the thread.

I've missed your thread because I usually only follow this one, so it's always a good idea to drop a note here in case anyone decide to create a new thread.

darkbasic

3rd November 2010, 00:50

Until 4th November I'm a little busy, but after that I will read the thread.

I know, madshi told me. Thank you.

sepheas

14th November 2010, 10:49

sorry for that, but I don't know since when, I cannot create any 3dlut file.

I run the command prompt. Then, chdir with the right repertory.

Then, "yCMS HD_PC.txt HD_PC"

And nothing happens !

I've got Eset smart security on my computer. I tried to disable real time protection but I've got the same problem.

Any idea ?

edit: the only that I did was changing my cpu. From a E2180 to a pentium E6600

edit2 : In fact Ycms.exe is using 50% of my cpu continually

yesgrey

14th November 2010, 14:07

That's odd...
Have you tried deleting the entire yCMS directory, download it again and replace it?

Another possibility could be your securuty software, because since yCMS it's an exe file those programs usually consider all exe files as possible threats... Whenever I create a new yCMS version on my computer I have to give permission for it...

You could also post your input file so I could test it.

sepheas

14th November 2010, 15:49

I just reinstalled win 7. ( because of the new cpu ).

I run yCMS with nod32 with the same results. Then, I run yCMS without nod32 and I've got the same thing.

What the hell ? My new pentium E6600 is broken ? I've just got a sensor failure on core1. But it's not a big problem generally. I ran loooots of test on my cpu to be sure ! ( sandra lite, occt, etc...) ( I still think it's odd to have 6.4 with the windows perf. test but with sandra it's ok ).
DO you think it's the integrity of this cpu ? What can I do to test it in depth ?

The input I use for testing is the standard :

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

yesgrey

14th November 2010, 16:15

DO you think it's the integrity of this cpu ? What can I do to test it in depth ?
I don't know... have you tried using prime95 for stress testing your cpu? If you haven't, try it in conjunction with RealTemp, so you could be able to control your cpu temperature.

Furthermore, yCMS only requires SSE support, nothing more, to guaranty a broader compatibility range, so, unless your cpu's SSE unit is flawed it should work OK.

The standard script is safe, so the problem should be in any other place...

The only time I had a behavior like what you are describing was when I had selected a wrong option on my firewall settings (Comodo) for yCMS access. I needed to clear all custom settings for all files to make it work again, but it solved the problem.

You could try running yCMS under "safe mode" to be sure that it's not the ESET or the firewall that are blocking it.

sepheas

14th November 2010, 17:45

ok... I know it's "hors sujet" but it's strange no ?

I run ycms in "safe mode" with the same results. 50% of cpu occupation continually.

Second, I run a prime95 1 hour test. ( in-large large fft ). With no error.

Furthermore, yCMS only requires SSE support, nothing more, to guaranty a broader compatibility range, so, unless your cpu's SSE unit is flawed it should work OK.

well, is it possible that my E6600 have a problem with SSE unit ?
How can I test it ? ( wich soft ? )

I also used this Intel-Processor-Diagnostic-Tool (http://www.softpedia.com/get/System/System-Info/Intel-Processor-Diagnostic-Tool.shtml) and it's ok

I submit the results

MMX - Intel MMX Technology Feature Supported --> Yes---> PASS
SSE - Streaming SIMD Extensions Feature Supported --> Yes---> PASS
SSE2 - Streaming SIMD Extensions 2 Feature Supported --> Yes---> PASS
SSE3 - Streaming SIMD Extensions 3 Feature Supported --> Yes---> PASS
SSSE3 - Supplemented SSE 3 Feature Supported --> Yes---> PASS

Would you like more information ?

gorgeousjorge

15th November 2010, 15:47

Hi.

I´ve been reading over the last several days this subjects about madvr and now ycms.

I have some questions namely about the last,ycms.
My "probe" is an huey "pro" and from looking at the calibration report file i can see the gamut values,but with the gamma i only have the rgb data; so my question is how do i find the IRE values based on this.

The software i use is their own,huey is not supported by hfcr.
If i don`t enter any gamma correction i´ll my picture suffice any "degradaction"?

Another thing i´m confusing is the fact that i have a profile in windows icm wich is affecting all the desktop,this also affects the videos wich i play on that same desktop?
So if i run ycms on top of this,i´ll i have a "double" color correction?

Tx for any help you can provide.
Best regards.

janos666

16th November 2010, 01:03

No, you won't have "double correction".
The Windows ICM works with CMS softwares. It isn't effective for the whole desktop! Windows loads the VGA LUT from the ICC/ICM files but it doesn't apply any "fullscreen correction".

If you calibrated you display, you know your calibration target. Set this curve with the output_transfer_function command!
And be careful, the ICC/ICM files contain the gamut coordinates relatively to D50, so you need to do a chromatic adaptation to get those coordinates relatively to D65.

gorgeousjorge

16th November 2010, 01:58

Tx for the clarifications.

So windows doesn`t apply the profile i`ve created to the video playing in mpc-hc for example in fullscreen mode?
It will apply it for any window that pops up when a software is fired up,sorry for the noobish but i think i`m confusing all this things a bit.

When i calibrated with the pantone software it asked me to wich color temperature to set and i have choosed d65; so i guess it`s all good?

Best regards.

janos666

16th November 2010, 03:19

No, no and no. :)

MPC-HC may use it when you enable the color management module which works with the EVR-CP renderer only. It won't work with madVR but madVR+yCMS is better than EVR+lcms (lcms is integrated to MPC-HC but it's not enabled by default).

Windows won't do any color corrections. It fills the VGA LUT with your calibration LUT during the startup process, but it won't do any ICC based color corrections. The color correction (mostly the gamut correction if you already calibrated your display to proper target gamma and WP...) has to be done by the softwares. (For example, Photoshop, Windows Image Viewer, IrFanView, MPC-HC, etc. And OK, there is CMS engine in Windows, but it won't work until the software calls it, so...)

You can calibrate your display to any target WP, it won't change the gamut. The ICC standard demands from the software to save the XYZ coordinates relatively to D50. (So, if you calibrate your display to D65, your ICC file will store XYZ gamut coordinates which are relative to D50, but you need to convert them again to find the XYZ values which are relative to D65, because Rec709 is based on D65 and I think yCMS 1.8 is not able do this conversion properly. - Is it?)

gorgeousjorge

16th November 2010, 15:33

Thanks again for your thoughts on the subject,yesterday i finally understood how this thing works,i was confusing things a lot.
It was here that i`ve had clarified my doubts:

http://photo.net/digital-darkroom-forum/00FYil

And thanks to you too janos.

Now i wasn`t aware of the gamut thing,you say my icc profile as information of the gamut relative to d50 and not d65.
Is this true with the colormeters,namely mine the huey?
How do i convert them?

Best regards.

sepheas

16th November 2010, 19:03

I'm confused about that. Seriously, I don't know if I must call and Intel tech support to tell him about this malfunction. I'm thinking of that because I'm the apparently the only one who have this problem !

hey, someone can help me to know if my cpu is broken ? I really need to know :confused:

I made a clearcmos, I reinstall windows 7, I tested my cpu with stress software. I don't know what to do now...

And sorry for this alternative subject.

janos666

17th November 2010, 00:29

It won't help you (this is why I didn't tell it earlier ; and I don't have a solution) but I had this problem with and older version of yCMS.
I calibrated one of my friend's display and I wanted to set up MPC-HC+madVR+yCMS for him (he had relatively good hardwares but he used them on a stupid way :D).
When I wanted to create the 3DLUT files, the yCMS.exe used the CPU cores but it never finished it's work. It was a Q9650 and I installed the Win7 x64 OS for him. (It was a fresh installation from my DVD with my usual settings, like a real administrator account, etc...)
I didn't search for a solution because I could use an other PC to create the 3DLUT files for him (it was a cheap, old laptop with XP x86).
It was a stable hardware. He can work (AutoCAD, MathCAD, MS Office, etc.) and play (recent "up-to-DX11" games) on his machine without any problems. (But I wasn't able to run yCMS.)

gorgeousjorge

17th November 2010, 01:43

After reserch the net and trying to understand this later issue about the d50-d65 conversion.

From reading the manual i guess it was to be done manually because ycms doesn`t do it automatically.

I am right here?

Best regards.

yesgrey

17th November 2010, 20:14

Would you like more information ?
Zip your yCMS.exe file and send it to me (yesgrey (at) gmx (dot) com).

This is a very strange thing, and without reproducing it would be very hard to fix...

janos666

25th December 2010, 03:34

Could you please give me a 1.8b version where you remove this stupid limitation that every X, Y and Z column should have increasing numbers? (Yes, I know the reason of this leftover. But I think it would be better to disable this check than leave it here for months, until you fix it...)
I didn't ask it earlier because I thought it's useless anyway (the last version with R G B values didn't seem to touch the white balance and I didn't test this because it refused a lot of lines) but I did a quick test with some random XYZ values and it seems that it works with 1.8, so I think I would use it.

cyberbeing

25th December 2010, 09:45

While this feedback is months late, I just want to give thanks to yesgrey for listening to my request and adding the Gamma_Curve parameter. It works well, but it's not particularly intuitive in naming and description.

It's worth noting for those unaware that the Gamma_Curve parameter is for specifying Camera Gamma and not Display Gamma (this probably should be specified in a future Manual.txt). If you've calibrated your display with the likes of Argyll, ProfileMaker, basICColor, etc, which use Display Gamma, you need to be careful with what you enter for this value. By default, ycms defaults to a Camera Gamma of 2.2 (If you've calibrated your display to a Display Gamma of 2.2 this will result in your video being displayed with a Display Gamma of ~1.9). In other words this messes with the gamma you targeted when you calibrated your display.

In order to get ycms to match a calibrated Display Gamma of 2.2 with curveType 1.0, you seem to need to specify a Gamma_Curve of 2.6 in ycms.

Gamma_Curve 1.0 2.6
Measured Display Gamma of 2.2 + ycms Camera Gamma 2.6 = Measured Display Gamma 2.2 (no change)

Or alternatively

Gamma_Curve 1.0 2.2
Measured Display Gamma of 2.6 + ycms Default Camera Gamma 2.2 = Measured Display Gamma 2.2 should also be true, but this could mess up your video since such a large modification is very destructive.

Unless your display can't for whatever reason reach your desired gamma, or you want your videos displayed at a different gamma then your desktop, always use
the Camera Gamma which is equal to your Display Gamma so your original targeted gamma is maintained. It's always preferable to let your Display take the lead when attempting to reach a calibration target, and only modifying the source material when you're fine-tuning areas where your display is lacking.

Below are the settings I'm using, and they seem to give good results with only very subtle gamma changes (as expected) on my CRT which was already calibrated to sRGB Gamma of 2.2 before using ycms:
# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

# IRE Grayscale Measurements
Grayscale_Measurements 2
15 1.439 1.517 1.735
20 2.391 2.519 2.856
25 3.808 4.014 4.587
30 5.728 6.050 6.865
35 8.031 8.502 9.388
40 10.688 11.310 12.419
45 13.873 14.658 15.825
50 17.312 18.125 20.105
55 21.545 22.653 24.873
60 25.738 27.011 29.991
65 31.257 32.778 35.980
70 36.832 38.914 42.454
75 43.403 45.642 49.700
80 49.823 52.544 56.810
85 57.344 60.309 65.975
90 65.348 68.943 75.033
95 73.944 77.909 84.853
100 82.131 86.449 94.321

# Target Camera Gamma
Gamma_Curve 1.0 2.6

# Display Gamut Measurements
Gamut_Measurements 0.626 0.343 0.294 0.607 0.149 0.078 0.3127 0.3290

Peekstra

26th December 2010, 12:02

janos666

26th December 2010, 16:58

Never mind, my latest practice accidentally solved this problem.
I set D65 WP with the OSD Gains and this slight adjustment fixed the near-white-crash (for a cost of a slight contrast ratio reduction), so every column has increasing numbers now. I am happy with the current result.
I tested MPC-HC with lcms and HQ cLUT profiles (constructed from numerous multidimensional patch measurements) in floating point and dithered 10-bit mode (real 10-bit doesn't work) and I am not sure if it is more precise on colorimetric side but my overall subjective result is much better with madVR+yCMS. I think the difference in the YCC 4:2:0 -> RGB conversion is much more noticeable than the difference between matrix+shaper style <-> cLUT based color correction.

@cyberbeing
I vote for this kind of corrections/assumptions:
Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Input_Transfer_Function 1.0 0.0 0.425531915 0.0
Gamut_Measurements 0.682317569 0.307322062 0.205227114 0.696319629 0.15098312 0.056274784 0.312179044 0.32865249
Grayscale_Measurements 2
0 0.106242 0.111464 0.17869
0.39216 0.107896667 0.112873333 0.18019
0.78431 0.1102 0.1153475 0.18288
1.1765 0.11629 0.1215175 0.18927
1.5686 0.123358 0.129064 0.196224
1.9608 0.137176 0.143006 0.20708
2.3529 0.15885 0.16535 0.22914
2.7451 0.17961 0.18768 0.25096
3.1373 0.2085 0.21843 0.28034
3.5294 0.24306 0.25241 0.31307
3.9216 0.28933 0.30282 0.3584
4.3137 0.33707 0.35266 0.41374
4.7059 0.38994 0.40797 0.46775
5.098 0.44489 0.46658 0.52788
5.4902 0.51609 0.53755 0.59943
5.8824 0.59657 0.62356 0.68813
6.2745 0.67403 0.70667 0.78272
6.6667 0.75296 0.78951 0.87302
7.0588 0.83687 0.87731 0.96406
7.451 0.93631 0.97449 1.0657
7.8431 1.0459 1.0951 1.1932
8.2353 1.1469 1.2052 1.3153
8.6275 1.2521 1.3133 1.431
9.0196 1.3556 1.4248 1.5558
9.4118 1.4709 1.5436 1.682
9.8039 1.604 1.6781 1.8352
10.196 1.7355 1.8208 1.9889
10.588 1.8593 1.9527 2.1353
10.98 1.9858 2.0864 2.278
11.373 2.1107 2.2239 2.4252
11.765 2.2466 2.3601 2.5791
12.157 2.402 2.5163 2.7564
12.549 2.5651 2.6928 2.9477
12.941 2.7043 2.8406 3.1184
13.333 2.849 2.9938 3.2856
13.725 2.9993 3.1488 3.4604
14.118 3.1432 3.3081 3.6327
14.51 3.3139 3.4799 3.8195
14.902 3.4913 3.6581 4.0364
15.294 3.6603 3.8453 4.2355
15.686 3.8237 4.0206 4.4167
16.078 4.0004 4.2044 4.623
16.471 4.1656 4.3876 4.8197
16.863 4.3362 4.5611 5.0108
17.255 4.5167 4.7448 5.2248
17.647 4.714 4.9446 5.4662
18.039 4.902 5.1469 5.6704
18.431 5.1 5.3548 5.9009
18.824 5.2996 5.5738 6.1265
19.216 5.5019 5.7772 6.3674
19.608 5.6977 5.9885 6.5811
20 5.8822 6.1764 6.8209
20.392 6.0915 6.3868 7.0668
20.784 6.3187 6.622 7.3178
21.176 6.533 6.8462 7.5561
21.569 6.7385 7.072 7.8024
21.961 6.9653 7.3148 8.0559
22.353 7.1826 7.5342 8.296
22.745 7.3923 7.7659 8.5596
23.137 7.6064 7.9861 8.7965
23.529 7.8459 8.223 9.0687
23.922 8.0888 8.4757 9.3648
24.314 8.3252 8.7271 9.6165
24.706 8.559 8.9722 9.91
25.098 8.8475 9.2712 10.228
25.49 9.0857 9.5205 10.507
25.882 9.33 9.7834 10.802
26.275 9.5712 10.035 11.072
26.667 9.8258 10.293 11.353
27.059 10.098 10.567 11.653
27.451 10.337 10.812 11.921
27.843 10.6 11.104 12.239
28.235 10.844 11.347 12.554
28.627 11.111 11.632 12.883
29.02 11.352 11.888 13.1
29.412 11.619 12.167 13.408
29.804 11.889 12.441 13.7
30.196 12.169 12.74 14.041
30.588 12.442 13.009 14.348
30.98 12.719 13.306 14.614
31.373 13.013 13.615 15.04
31.765 13.299 13.914 15.345
32.157 13.587 14.218 15.694
32.549 13.842 14.482 15.941
32.941 14.132 14.796 16.273
33.333 14.446 15.102 16.635
33.725 14.734 15.392 16.966
34.118 15.021 15.696 17.283
34.51 15.311 16 17.678
34.902 15.606 16.315 17.95
35.294 15.896 16.629 18.276
35.686 16.193 16.929 18.655
36.078 16.477 17.231 18.949
36.471 16.798 17.577 19.255
36.863 17.099 17.865 19.676
37.255 17.408 18.186 20.028
37.647 17.694 18.487 20.364
38.039 18.007 18.825 20.695
38.431 18.323 19.153 21.054
38.824 18.615 19.46 21.372
39.216 18.916 19.766 21.749
39.608 19.242 20.122 22.154
40 19.556 20.442 22.479
40.392 19.877 20.779 22.791
40.784 20.199 21.1 23.112
41.176 20.516 21.446 23.514
41.569 20.854 21.814 23.953
41.961 21.158 22.124 24.309
42.353 21.478 22.455 24.657
42.745 21.796 22.797 25.008
43.137 22.125 23.134 25.383
43.529 22.461 23.479 25.717
43.922 22.793 23.815 26.125
44.314 23.156 24.17 26.507
44.706 23.528 24.538 26.894
45.098 23.905 24.91 27.316
45.49 24.289 25.282 27.784
45.882 24.692 25.721 28.23
46.275 25.092 26.119 28.659
46.667 25.495 26.554 29.07
47.059 25.887 26.951 29.564
47.451 26.309 27.384 30.001
47.843 26.705 27.806 30.567
48.235 27.1 28.216 31.02
48.627 27.523 28.675 31.463
49.02 27.935 29.122 31.932
49.412 28.346 29.552 32.411
49.804 28.767 29.983 32.847
50.196 29.278 30.506 33.493
50.588 29.682 30.94 34.002
50.98 30.104 31.386 34.463
51.373 30.517 31.816 34.992
51.765 30.962 32.3 35.513
52.157 31.362 32.723 35.952
52.549 31.769 33.16 36.441
52.941 32.211 33.628 36.961
53.333 32.636 34.06 37.411
53.725 33.066 34.511 37.827
54.118 33.462 34.939 38.304
54.51 33.873 35.37 38.804
54.902 34.323 35.839 39.338
55.294 34.729 36.293 39.789
55.686 35.161 36.745 40.353
56.078 35.564 37.183 40.85
56.471 35.992 37.628 41.279
56.863 36.447 38.103 41.73
57.255 36.887 38.564 42.27
57.647 37.278 38.965 42.801
58.039 37.715 39.427 43.345
58.431 38.177 39.918 43.868
58.824 38.607 40.39 44.28
59.216 39.039 40.846 44.783
59.608 39.462 41.296 45.331
60 39.894 41.742 45.935
60.392 40.366 42.248 46.379
60.784 40.793 42.707 46.909
61.176 41.21 43.128 47.35
61.569 41.667 43.608 47.812
61.961 42.133 44.11 48.35
62.353 42.566 44.568 48.896
62.745 42.989 45.032 49.471
63.137 43.418 45.473 50.066
63.529 43.86 45.942 50.558
63.922 44.334 46.444 51.084
64.314 44.802 46.95 51.434
64.706 45.222 47.344 52.047
65.098 45.7 47.868 52.593
65.49 46.154 48.353 53.107
65.882 46.611 48.822 53.462
66.275 47.048 49.285 54.034
66.667 47.5 49.796 54.744
67.059 47.953 50.257 55.149
67.451 48.43 50.76 55.497
67.843 48.913 51.253 56.136
68.235 49.376 51.736 56.83
68.627 49.853 52.232 57.197
69.02 50.349 52.758 57.817
69.412 50.809 53.235 58.383
69.804 51.295 53.733 58.935
70.196 51.739 54.219 59.586
70.588 52.232 54.738 59.89
70.98 52.724 55.23 60.43
71.373 53.211 55.76 60.913
71.765 53.733 56.309 61.559
72.157 54.222 56.815 62.018
72.549 54.686 57.292 62.479
72.941 55.204 57.863 63.127
73.333 55.726 58.417 63.77
73.725 56.2 58.93 64.346
74.118 56.66 59.405 64.934
74.51 57.181 59.966 65.229
74.902 57.677 60.448 65.935
75.294 58.361 61.159 66.633
75.686 58.835 61.651 67.327
76.078 59.354 62.198 67.856
76.471 59.849 62.722 68.399
76.863 60.372 63.289 69.105
77.255 60.862 63.761 69.745
77.647 61.413 64.381 70.159
78.039 61.947 64.947 70.534
78.431 62.543 65.525 71.491
78.824 63.064 66.08 72.178
79.216 63.614 66.634 72.726
79.608 64.139 67.183 73.253
80 64.714 67.779 73.94
80.392 65.273 68.362 74.629
80.784 65.862 68.999 75.202
81.176 66.404 69.546 75.82
81.569 66.93 70.094 76.628
81.961 67.494 70.682 77.32
82.353 68.08 71.283 77.97
82.745 68.656 71.909 78.589
83.137 69.236 72.482 79.267
83.529 69.828 73.118 79.853
83.922 70.423 73.751 80.612
84.314 71.002 74.374 81.434
84.706 71.623 75.019 82.03
85.098 72.225 75.639 82.478
85.49 72.782 76.234 83.258
85.882 73.391 76.862 84.147
86.275 74.027 77.535 84.807
86.667 74.639 78.178 85.453
87.059 75.224 78.72 86.159
87.451 75.887 79.446 86.885
87.843 76.49 80.1 87.558
88.235 77.072 80.769 88.232
88.627 77.714 81.439 89.019
89.02 78.288 82.026 89.712
89.412 78.83 82.603 90.655
89.804 79.427 83.226 91.225
90.196 80.06 83.951 91.944
90.588 80.721 84.597 92.455
90.98 81.329 85.235 93.11
91.373 81.896 85.848 93.825
91.765 82.525 86.522 94.557
92.157 83.108 87.167 95.354
92.549 83.764 87.79 96.04
92.941 84.399 88.463 96.815
93.333 84.96 89.103 97.756
93.725 85.576 89.812 98.324
94.118 86.162 90.405 99.084
94.51 86.704 91.026 99.682
94.902 87.301 91.661 100.05
95.294 87.796 92.131 101.2
95.686 88.389 92.796 101.96
96.078 88.948 93.342 102.4
96.471 89.585 94.024 102.97
96.863 90.209 94.781 103.89
97.255 90.711 95.319 104.75
97.647 91.2514 95.888 105.264
98.039 91.9506 96.5128 106.274
98.431 92.659 97.2676 107.168
98.824 93.35 98.0552 107.96
99.216 93.7922 98.5518 108.894
99.608 94.2948 99.1406 109.254
100 94.9796 99.9916 109.276

yesgrey

26th December 2010, 23:44

Could you please give me a 1.8b version where you remove this stupid limitation that every X, Y and Z column should have increasing numbers?
That's not a stupid limitation, it's a bug. It would be fixed on next version.

I think that I'm experiencing the same problem on my quad core Q8400 based PC. yCMS works fine on my dual core E5200 system though.
It seems to be a compiler bug. The next version should fix it.

cyberbeing

27th December 2010, 00:47

yesgrey, while using Grayscale_Measurements 2 or Grayscale_Measurements 1 if you list only the Y value, does ycms realize this and automatically use CIE Y on just those values?

For example:

Grayscale_Measurements 2
15 1.439 1.517 1.735
20 2.391 2.519 2.856
25 3.808 4.014 4.587
30 5.728 6.050 6.865
35 8.031 8.502 9.388
40 10.688 11.310 12.419
45 13.873 14.658 15.825
50 17.312 18.125 20.105
55 21.545 22.653 24.873
60 25.738 27.011 29.991
65 31.257 32.778 35.980
70 36.832 38.914 42.454
75 43.403 45.642 49.700
80 49.823 52.544 56.810
85 57.344 60.309 65.975
90 65.348 68.943 75.033
95 73.944 77.909 84.853
100 82.131 86.449 94.321
to
Grayscale_Measurements 2
15 1.517
20 2.519
25 4.014
30 5.728 6.050 6.865
35 8.031 8.502 9.388
40 10.688 11.310 12.419
45 13.873 14.658 15.825
50 17.312 18.125 20.105
55 21.545 22.653 24.873
60 25.738 27.011 29.991
65 31.257 32.778 35.980
70 36.832 38.914 42.454
75 43.403 45.642 49.700
80 49.823 52.544 56.810
85 57.344 60.309 65.975
90 65.348 68.943 75.033
95 73.944 77.909 84.853
100 82.131 86.449 94.321

If this no longer works, can you re-add the ability to do so in the next version? This is useful for when you your sensor can get accurate luminance values near-black but not accurate colorimetry.

If you don't want to make it automatic again, would something like the following make more sense, where ycms would combine multiple Grayscale_Measurements modes specified in a settings file, if no IRE values overlapped?

Grayscale_Measurements 0
15 1.517
20 2.519
25 4.014

Grayscale_Measurements 2
30 5.728 6.050 6.865
35 8.031 8.502 9.388
40 10.688 11.310 12.419
45 13.873 14.658 15.825
50 17.312 18.125 20.105
55 21.545 22.653 24.873
60 25.738 27.011 29.991
65 31.257 32.778 35.980
70 36.832 38.914 42.454
75 43.403 45.642 49.700
80 49.823 52.544 56.810
85 57.344 60.309 65.975
90 65.348 68.943 75.033
95 73.944 77.909 84.853
100 82.131 86.449 94.321

yesgrey

27th December 2010, 13:53

yesgrey, while using Grayscale_Measurements 2 or Grayscale_Measurements 1 if you list only the Y value, does ycms realize this and automatically use CIE Y on just those values?
No, it will consider those as invalid lines.

This is useful for when you your sensor can get accurate luminance values near-black but not accurate colorimetry.
Agreed. I will add it to the next version.

If you don't want to make it automatic again, would something like the following make more sense, where ycms would combine multiple Grayscale_Measurements modes specified in a settings file
I don't want to make it automatic, because when using format XYZ the first column is 'X', not 'Y', and that would be confusing. I have considered the possibility of entering the values on XYZ format as YXZ, but I didn't like the idea.

I like your suggestion of accepting the Grayscale_Measurements command more than once, so probably it would be like that.

yesgrey

3rd January 2011, 02:42

yCMS v1.9 released

http://yesgrey.com/ycms.html

- Fixed bug on Grayscale_Measurements order verification.
- Changed Grayscale_Measurements: 'format' is set for each measurement.
- Added new parameter 'format' to Gamut_Measurements.
- Added Yxy and XYZ support on Gamut_Measurements.
- Changed Gamma_Curve algorithm to improve its accuracy.

yesgrey

3rd January 2011, 02:45

I think I will go with input 32 235 and then gamma either 0.40 or 0.41. both look a tiny bit better in one scene or another, cant take the middle I guess :D
Do you still need this?

In fact Ycms.exe is using 50% of my cpu continually
I think that I'm experiencing the same problem on my quad core Q8400 based PC.
Please let me know if the new version fixes it.

Thunderbolt8

3rd January 2011, 03:21

Do you still need this?Im not sure how to understand this, as I cannot really tell what the listed changes of 1.9 mean.
does it mean that now all greyscale adjustment is done automatically and it should be enough, only to do the colour adjustment as in that case of mine?

yesgrey

3rd January 2011, 14:45

Im not sure how to understand this
Sorry, wrong quote... :o

aww, forgot about the subs.
you said the colour of the subs changes as well with all these changes being made, so I'd have to adjust them.

the colours I usually use for my .ass subs are 246 245 222 for primary, 255 0 0 for secondary and 0 0 0 for outline and shadow.
what would I have to do here with input 32 235 and gamma 0.405? im not very good at maths :S
Do you still need this?

Thunderbolt8

3rd January 2011, 15:15

if its not too much of an inconvenience, yes please.

cyberlolo

4th January 2011, 14:10

Hi yesgrey.

Thanks for the new build, but I have a newbie problem: with the previous versions, I used this command for color correction:

Gamut_Measurements 0.6350 0.3321 0.2890 0.6007 0.1528 0.0647 0.3127 0.3294

just as it was intended to be:

Gamut_Measurements redx redy greenx greeny bluex bluey whitex whitey

But now, with this new build, this is not possible, and the procedure seems to be as in this example:

Gamut_Measurements 1
21.26 0.676 0.321
71.52 0.308 0.685
7.22 0.144 0.045
100.00 0.3127 0.3290

But what is that first column (bold)? When the calibrator did his job on my TV, he gave me the xy coordinates and they were 2 numbers for each component, not 3!!

How can I solve this?

Thanks in advance.

janos666

4th January 2011, 16:24

How normal is it? (It looks strange for me, but not impossible with a 3DLUT and may be it makes sense, but...) I made these screenshots with the same settings and the same 3DLUT: 01 (http://img12.tar.hu/janos666/img/97491175.png), 02 (http://img12.tar.hu/janos666/img/97491174.png)

The near-white is correct while the near-R, near-G, near-B looks strange. It would be impossible with 2D CMS and RGB output, I guess.

yesgrey

4th January 2011, 16:33

But what is that first column (bold)?
The first column are the Luminance values of each primary. However, yCMS is not yet using that info, so for now you could use the same values (in bold) that you see in the example and that would be fine, but don't forget to use 'format' 1.;)

cyberlolo

4th January 2011, 17:49

The first column are the Luminance values of each primary. However, yCMS is not yet using that info, so for now you could use the same values (in bold) that you see in the example and that would be fine, but don't forget to use 'format' 1.;)

Ok, thanks. By the way, do you recommend me to generate new 3dluts with the last version, or keep the ones that I generated with v0.6? I'm using only this input parameters (these are for HD, but I use the same for SD):

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_Video 16

Gamut_Measurements 0.6350 0.3321 0.2890 0.6007 0.1528 0.0647 0.3127 0.3294

Input_Range 16 238
Output_Range 0 255

cyberbeing

4th January 2011, 17:55

yesgrey, I seem to get strong coloration of grayscale steps when using Grayscale_Measurements mode 1 & 2. Even when entering the exact same color temperature for all values using Grayscale_Measurements mode 1, there is still some coloration. Whatever color correction you are doing with IRE chromaticity doesn't appear to be working all that well.

Below is what I was using when I first noticed the problem (it's particularly bad with a RGB_Video 3dlut near white):
If you're curious how I came up with the xy values for IRE 0,2,4,6, and 8, I just used the xy values from IRE 10 which I figure is better then just using Grayscale_Measurements mode 0.
# IRE Grayscale Measurements
Grayscale_Measurements
0 1 0.14689 0.31527 0.32457
2 1 0.16114 0.31527 0.32457
4 1 0.19540 0.31527 0.32457
6 1 0.24432 0.31527 0.32457
8 1 0.44471 0.31527 0.32457
10 2 0.68909 0.70942 0.78720
12 2 1.01600 1.05940 1.15260
14 2 1.42000 1.44420 1.58220
16 2 1.82010 1.89070 2.01030
18 2 2.29720 2.38500 2.51430
20 2 2.82590 2.93710 3.10350
22 2 3.36740 3.47210 3.73200
24 2 3.97970 4.14340 4.47720
26 2 4.67530 4.88760 5.13810
28 2 5.35610 5.58070 6.00030
30 2 6.39890 6.67560 7.16940
32 2 7.42060 7.72820 8.45530
34 2 8.55820 8.99120 9.67810
36 2 9.71040 10.2020 10.9550
38 2 10.9860 11.5430 12.3990
40 2 12.3140 12.9340 13.8630
42 2 13.5040 14.1550 15.4300
44 2 14.9720 15.7370 16.8310
46 2 16.4300 17.3380 18.6440
48 2 17.9920 18.8880 20.2450
50 2 20.1580 21.1570 22.6120
52 2 21.9270 23.0990 24.7490
54 2 23.7100 24.8830 26.6020
56 2 25.6300 27.0160 28.9390
58 2 27.8920 29.3350 31.4350
60 2 30.0900 31.6720 33.9680
62 2 32.0000 33.6770 36.0050
64 2 34.5660 36.3080 38.8730
66 2 36.9120 38.9550 41.7120
68 2 39.5260 41.4930 44.9560
70 2 42.4650 44.7020 48.7940
72 2 45.3890 47.7390 51.8430
74 2 47.9880 50.5540 54.8440
76 2 50.8050 53.6500 58.5290
78 2 54.1080 56.9430 62.3890
80 2 57.0140 60.3300 65.3030
82 2 60.1620 63.4190 69.4190
84 2 63.4210 67.0090 72.5200
86 2 66.6250 70.4210 77.0140
88 2 69.9350 73.7780 79.9540
90 2 75.0960 79.0490 84.9870
92 2 78.6640 82.9110 88.9520
94 2 82.3160 86.7250 93.8370
96 2 87.0590 91.9160 97.8380
98 2 90.8390 95.3970 103.090
100 2 95.1410 100.000 108.730

# Target Camera Gamma
Gamma_Curve 1.0 2.6

# Display Gamut Measurements
Gamut_Measurements 2
45.3340 24.6690 2.30880
31.5860 65.5520 10.3620
18.2290 9.39720 94.0110
95.1410 100.000 108.730

http://img813.imageshack.us/img813/271/shader.th.png (http://img813.imageshack.us/img813/271/shader.png) MadVR Shader

http://img708.imageshack.us/img708/6417/3dlut0.th.png (http://img708.imageshack.us/img708/6417/3dlut0.png) Grayscale_Measurements mode 0

http://img190.imageshack.us/img190/5647/3dlut.th.png (http://img190.imageshack.us/img190/5647/3dlut.png) Grayscale_Measurements mode 1&2

yesgrey

4th January 2011, 23:42

How normal is it?
Please post your 3DLUT configuration file.

yesgrey

4th January 2011, 23:45

do you recommend me to generate new 3dluts with the last version, or keep the ones that I generated with v0.6?
There is no v0.6, but I guess you're referring to v.1.6 ;) , and considering your configuration file you wouldn't need to create new 3DLUTs. The changes won't affect you.

cyberlolo

4th January 2011, 23:53

There is no v0.6, but I guess you're referring to v.16 ;) , and considering your configuration file you wouldn't need to create new 3DLUTs. The changes won't affect you.

You're right, I meant v1.6... :)

Ok then, I won't recreate 3DLUTs. Thanks for your support!

janos666

4th January 2011, 23:56

Please post your 3DLUT configuration file.

Done. (http://forum.doom9.org/showpost.php?p=1466574&postcount=394)

yesgrey

5th January 2011, 00:34

yesgrey, I seem to get strong coloration of grayscale steps when using Grayscale_Measurements mode 1 & 2.
Can you post your test pattern video? I've tried with one I have here but it worked fine without any coloring issues...

yesgrey

5th January 2011, 00:40

Done.
I forgot one thing... please post the test pattern video too.

Thanks.

cyberbeing

5th January 2011, 05:36

Can you post your test pattern video? I've tried with one I have here but it worked fine without any coloring issues...

In my images above can you see how the Grayscale_Measurements mode 1&2 image has a strong red cast in the first 2 white steps and a blue cast on the 3rd white step?

I think janos666 and I are using the same mp4 test pattern set which can be found here: http://www.avsforum.com/avs-vb/showthread.php?t=948496

The 2-Grayscale Steps.mp4 can be found in ...\MP4-2c\Misc Patterns\A - Additional\ after extracted.

The 4-Color Clipping.mp4 which janos666 used can be found in ...\MP4-2c\Misc Patterns\A - Additional\ as well.

The 3-White Clipping.mp4 which janos666 used can be found in ...\MP4-2c\Basic Settings\.

yesgrey

5th January 2011, 14:40

In my images above can you see how the Grayscale_Measurements mode 1&2 image has a strong red cast in the first 2 white steps and a blue cast on the 3rd white step?
Yes, I saw it, but when I tried with a test pattern I have here it was OK, hence why I wanted to know which test you were using.

I think janos666 and I are using the same mp4 test pattern set which can be found here: http://www.avsforum.com/avs-vb/showthread.php?t=948496
OK, I have those too. I will test.

yesgrey

5th January 2011, 17:48

cyberbeing

5th January 2011, 20:12

Ah, I forgot that the YCbCr input preset uses a Video range.

PC->PC
Input_Format HD YCbCr 8
Input_Range 0 255
Output_Format HD RGB_PC 16

Well that fixed the strong red cast above 235, but not the color cast below 235.

First, the problem only happens when you are using RGB_Video as the output mode.
This is incorrect, the problem also happens with RGB_PC output. I just used RGB_Video output as the example because the color cast appeared worse (which I now know was because of the LUT misconfiguration).

TV->PC
Input_Format HD YCbCr 8
Input_Range 0 255
Output_Format HD RGB_PC 16

Grayscale_Measurements 0
http://img824.imageshack.us/img824/6830/hdpcgs0.th.png (http://img824.imageshack.us/img824/6830/hdpcgs0.png)

Grayscale_Measurements 2
From the top-right, first step white (235), second step bluish, third step greenish, forth step redish.
http://img375.imageshack.us/img375/6761/hdpcgs2.th.png (http://img375.imageshack.us/img375/6761/hdpcgs2.png)

http://img254.imageshack.us/img254/7043/30to100gray.png
With Grayscale_Measurements 2, I confirmed a bit of this irregularity with HFCR. Notice the irregular color temperature humps at 45%, 65%, 90%, and 95%. In order to maintain a smooth grayscale, the color temperature between steps should be averaged and linearized so there is a smooth transition between steps. Those abrupt jumps up and down in color temperature are what make the grayscale steps colorful, when they should appear neutral.

For comparison purposes, below is what color temperature looked like naturally with Grayscale_Measurements 0. Nice linear transitions, without any abrupt humps:
http://img192.imageshack.us/img192/5642/30to100gray0.png

madshi

5th January 2011, 20:30

FWIW, watching at these screenshots on a monitor other than the display they've been rendered for does not give an accurate result. E.g. if your display had a big lack of red at a specific part of the grayscale, yCMS would probably try to correct that. As a result there would be a red cast on the screenshot (when watched on a different display), but the grayscale would still look neutral on your target display.

That said, I can clearly see a red cast on one of those steps with my naked eyes. And that seems a bit too strong to make sense? But I don't really know, let's wait what yesgrey says about that... :)

yesgrey

5th January 2011, 23:52

Ah, I forgot that the YCbCr input preset uses a Video range.
YEs, but if you want to keep the BTB and WTW data you should use Input_Range 1 254. 0 255 is to be used only with full range material, which is not very common.

Well that fixed the strong red cast above 235, but not the color cast below 235.
As madshi wisely pointed the color cast would be wrong only when watched through the display for which the 3DLUT was created for. Simply grabbing a png image from the video player and posting it is meaningless. You should play it on the calibrated display and take a photo of the screen, or, even better, measuring a new grayscale to see how the corrected grayscale looks.

With Grayscale_Measurements 2, I confirmed a bit of this irregularity with HFCR. Notice the irregular color temperature humps at 45%, 65%, 90%, and 95%.
Now this is a relevant picture. If it's the result after the calibration it shows something needs to be improved.

For comparison purposes, below is what color temperature looked like naturally with Grayscale_Measurements 0. Nice linear transitions, without any abrupt humps:
I don't get it. The color temperature should be a straight line from 0 to 100 IRE. With the picture above you almost get it, even though there are still some bumps, but this picture is really bad, so I don't understand what you're trying to say...:confused:

Another thing is the Gamma_Curve you are using... Why do you want a BT.709 curve with a 2.6 gamma? Other than a BT.709 with ~2.2, or a pure power with ~2.35 I think it might be looking for trouble...;)

madshi

6th January 2011, 00:00

Another thing is the Gamma_Curve you are using... Why do you want a BT.709 curve with a 2.6 gamma? Other than a BT.709 with ~2.2, or a pure power with ~2.35 I think it might be looking for trouble...;)
A pure power curve is darker than a BT.709 curve. So a 2.35 pure power curve should be somewhat similar to a 2.6 BT.709 curve, or am I wrong?

yesgrey

6th January 2011, 00:59

So a 2.35 pure power curve should be somewhat similar to a 2.6 BT.709 curve, or am I wrong?
Here is an image comparing both (blue BT.709 with 2.6 gamma and red pure power curve with 2.35 gamma). They seem to be somewhat similar, but the difference at low IREs would be enough to damage color accuracy significantly.
11931

Furthermore, I don't believe any studios would master any movies with a BT.709 transfer function with a 2.6 gamma.;)

cyberbeing

6th January 2011, 09:42

I don't get it. The color temperature should be a straight line from 0 to 100 IRE. With the picture above you almost get it, even though there are still some bumps, but this picture is really bad, so I don't understand what you're trying to say...:confused:
The Grayscale_Measurements 0 is before color correction, the Grayscale_Measurements 2 is after color correction. It gives you a idea of what yCMS did when it corrected the color temperature. If I had only posted the Grayscale_Measurements 2 image, you would be unable to make conclusion about whether yCMS grayscale color correction improved things, or made them worse.

Grayscale_Measurements 0, while not perfect (6400 near black and 6550 near white) doesn't have any abrupt jumps up and down in color temperature. When the color temperature changes, it happens in a straight line.

When you go warm -> very cool -> very warm -> neutral on subsequent grayscale steps, they appear colorful.

When you go warm -> slightly warm -> neutral -> slightly cool -> cool, they don't appear colorful since the transition is smooth.

Here is the default view of the same images as before to help you better visualize what I'm saying:
Grayscale_Measurements 2
http://img440.imageshack.us/img440/2264/hdpcgs2b.png

Grayscale_Measurements 0
http://img811.imageshack.us/img811/7016/hdpcgs0b.png

From 65-100 IRE Grayscale_Measurements 2 is making the color temperature worse overall then Grayscale_Measurements 0.

From 30-60 IRE Grayscale_Measurements 2 is better overall then Grayscale_Measurements 0, but has a couple irregular bumps.

From 0-25 IRE Grayscale_Measurements 2 once again makes things worse then Grayscale_Measurements 0.

Conclusion: ycms color correction doesn't work well outside of midtones.

Another thing is the Gamma_Curve you are using... Why do you want a BT.709 curve with a 2.6 gamma? Other than a BT.709 with ~2.2, or a pure power with ~2.35 I think it might be looking for trouble...;)
I explained this before.

yCMS uses a BT.709 curve with a Camera Gamma of ~2.2. This results in a Display Gamma of ~1.9 after applied.

I calibrate my display to a Display Gamma of ~2.2. By setting Camera Gamma to 2.6 I get a Display Gamma close to 2.2, which is what I want.

I think you are misunderstanding something about transfer functions yesgrey. I was under the impression most ISF calibrators used a target Display Gamma between 2.2 and 2.6.

http://i43.tinypic.com/opxulz.png
Here is a good image which shows a 2.2 Power Curve, a BT.709 gamma curve, and a BT.709 2.5 gamma curve (BT.709 with a 1.125 power function).
The source is the thread here: http://www.avsforum.com/avs-vb/showthread.php?t=1008297&page=5
I use BT.709 2.6 gamma curve (BT.709 with a 1.17 power function). This results in a Display Gamma of ~2.22.
When I tried BT.709 with a 2.5 gamma curve (BT.709 with a 1.125 power function) awhile back, I believe my Display Gamma was ~2.17.

cyberbeing

6th January 2011, 10:38

From 65-100 IRE Grayscale_Measurements 2 is making the color temperature worse overall then Grayscale_Measurements 0.

From 30-60 IRE Grayscale_Measurements 2 is better overall then Grayscale_Measurements 0, but has a couple irregular bumps.

From 0-25 IRE Grayscale_Measurements 2 once again makes things worse then Grayscale_Measurements 0.

Conclusion: ycms color correction doesn't work well outside of midtones.

By using the following 3DLUT (which only color corrects from 30-64 IRE) I seem to have proven my above conclusion was correct:
# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

# IRE Grayscale Measurements
Grayscale_Measurements
0 0 0.14689
2 0 0.16114
4 0 0.19540
6 0 0.24432
8 0 0.44471
10 0 0.70942
12 0 1.05940
14 0 1.44420
16 0 1.89070
18 0 2.38500
20 0 2.93710
22 0 3.47210
24 0 4.14340
26 0 4.88760
28 0 5.58070
30 2 6.39890 6.67560 7.16940
32 2 7.42060 7.72820 8.45530
34 2 8.55820 8.99120 9.67810
36 2 9.71040 10.2020 10.9550
38 2 10.9860 11.5430 12.3990
40 2 12.3140 12.9340 13.8630
42 2 13.5040 14.1550 15.4300
44 2 14.9720 15.7370 16.8310
46 2 16.4300 17.3380 18.6440
48 2 17.9920 18.8880 20.2450
50 2 20.1580 21.1570 22.6120
52 2 21.9270 23.0990 24.7490
54 2 23.7100 24.8830 26.6020
56 2 25.6300 27.0160 28.9390
58 2 27.8920 29.3350 31.4350
60 2 30.0900 31.6720 33.9680
62 2 32.0000 33.6770 36.0050
64 2 34.5660 36.3080 38.8730
66 0 38.9550
68 0 41.4930
70 0 44.7020
72 0 47.7390
74 0 50.5540
76 0 53.6500
78 0 56.9430
80 0 60.3300
82 0 63.4190
84 0 67.0090
86 0 70.4210
88 0 73.7780
90 0 79.0490
92 0 82.9110
94 0 86.7250
96 0 91.9160
98 0 95.3970
100 0 100.000

# Target Camera Gamma
Gamma_Curve 1.0 2.6

# Display Gamut Measurements
Gamut_Measurements 2
45.3340 24.6690 2.30880
31.5860 65.5520 10.3620
18.2290 9.39720 94.0110
95.1410 100.000 108.730

http://img717.imageshack.us/img717/5294/hdpcgs2mod.png

yesgrey

7th January 2011, 18:40

How normal is it?
Perfectly normal. Exactly as it should be.

The near-white is correct while the near-R, near-G, near-B looks strange.
All of them are correct. They show that the color correction is being performed, because when you perform the gamut correction only the colors are affected, the grayscale remains unchanged.

If no gamut correction is performed, all the primaries clip at 235. However, after the gamut correction, you will see the less saturated primaries, which have lower RGB values than the uncorrected ones, hence the not clipping at the 235 point as would happen with the uncorrected ones.;)

yesgrey

7th January 2011, 19:26

Let's split the discussion of gamma and the color correction issues to make it easier to follow. I will now comment about the color correction issues and will comment about gamma on another post.

The Grayscale_Measurements 0 is before color correction, the Grayscale_Measurements 2 is after color correction. It gives you a idea of what yCMS did when it corrected the color temperature.
That's better. It's the only way of keeping the discussion on a scientific level.

Grayscale_Measurements 0, while not perfect doesn't have any abrupt jumps up and down in color temperature.
I understand your point, and I agree that even though the GS 0 has a less constant color temperature scale the end result migh be preferable because those bumps might be too noticeable, despite the more accurate color temperature on the other IRE levels.

From 0-25 IRE Grayscale_Measurements 2 once again makes things worse then Grayscale_Measurements 0.
I will not give much importance to low IRE values, because as you admitted your meter is not too accurate at lower values, so we can't really know if the measurements are reliable enough or not. Furthermore, with GS 2 you are using guessing values for <10 IRE, and that might be increasing the errors instead of reducing them.

Conclusion: ycms color correction doesn't work well outside of midtones.
Your example did not prove this. Overall the color temperature is more accurate, the problem are the bumps and not the overall correction, so it should be correctable.

As I've told when released v1.8, I have not thoroughly tested this, and in fact I've detected that something strange is happening with yCMS when applying the color correction, so I will now investigate to see what's happening...

By using the following 3DLUT (which only color corrects from 30-64 IRE) I seem to have proven my above conclusion was correct
That would be a good interim solution until I solve the problems, but don't generalize, this conclusion is true only for your situation, and might not be the same for everyone... ;)

cyberbeing

8th January 2011, 00:07

I agree with what you said. As for my EyeOne Pro, it's only not very accurate on my CRT at Low IRE (below 20 IRE in the above posts) in ColorHCFR. With Argyll Highres Spectral, it gets much more consistent colorimetry measurements low luminance down to around 0.1cd/m2, and that is how I get measurements for my 3DLUTs recently.

I did a bit more investigation, and it appears that those bumps happen when yCMS makes an error targeting the gamma at a particular IRE, or more that there is an unexpected bump in the gamma at the same IRE where there is an unexpected bump in color temperature.

I also ran into a weird bug which seemed to break grayscale color correction in yCMS with the following 3DLUT:

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

# IRE Grayscale Measurements
Grayscale_Measurements
0 2 0.072291 0.076557 0.061430
2 2 0.106180 0.121710 0.094321
4 2 0.211860 0.240240 0.252810
6 2 0.453610 0.503020 0.510340
8 2 0.757130 0.807570 0.880250
10 2 1.148000 1.208800 1.333700
12 2 1.550800 1.628500 1.800500
14 2 1.942100 2.085900 2.208400
16 2 2.472200 2.609700 2.836200
18 2 2.992800 3.202300 3.400900
20 2 3.657800 3.850600 4.163400
22 2 4.267800 4.499200 4.863700
24 2 4.920300 5.195200 5.604600
26 2 5.806600 6.136500 6.474900
28 2 6.678700 7.038200 7.623900
30 2 7.799400 8.220100 8.903600
32 2 8.928000 9.434300 10.00400
34 2 10.01400 10.56000 11.44500
36 2 11.12900 11.74100 12.71800
38 2 12.27200 12.94900 14.05600
40 2 13.56600 14.31900 15.53500
42 2 15.01600 15.79600 17.45400
44 2 16.54300 17.51400 19.10300
46 2 18.15600 19.14700 20.76600
48 2 19.85100 20.88400 23.03500
50 2 21.89900 23.03600 25.37900
52 2 23.63900 24.87200 27.41600
54 2 25.47000 26.80500 29.54000
56 2 27.24700 28.71700 31.25600
58 2 29.25300 30.83300 33.50700
60 2 31.83700 33.55500 36.51700
62 2 33.99700 35.81900 38.98100
64 2 36.72400 38.75600 41.68900
66 2 39.15300 41.25200 44.94400
68 2 41.49800 43.78100 47.13600
70 2 44.55100 46.77400 50.89300
72 2 46.86600 49.38500 53.87300
74 2 49.43800 52.14700 56.28600
76 2 52.26100 55.11100 59.56200
78 2 55.23300 58.16900 63.58200
80 2 58.63700 61.55300 67.12800
82 2 61.68300 64.75000 70.62800
84 2 65.27900 68.69700 75.16700
86 2 68.49100 72.09600 78.93900
88 2 71.88500 75.65800 82.86300
90 2 76.18700 80.17400 87.93300
92 2 79.81800 83.99100 92.09900
94 2 83.95600 88.07200 96.44000
96 2 88.01000 92.66600 100.8800
98 2 91.89500 96.74900 105.4300
100 2 95.05100 100.0000 109.0600

# Target Camera Gamma
Gamma_Curve 1.0 2.555555

# Display Gamut Measurements
Gamut_Measurements 2
44.52300 24.20800 2.091800
31.72700 65.82100 10.34800
18.22600 9.450000 95.30100
95.05100 100.0000 109.0600
My display is calibrated to a 2.222222 Display Gamma Power Curve with Argyll.

Gamma_Curve 1.0 2.5
Correct color temperature, Display Gamma 2.17

Gamma_Curve 1.0 2.6
Correct color temperature, Display Gamma 2.28

Gamma_Curve 1.0 2.555555
Horrible color temperature, Display Gamma 2.21

For whatever reason, when I used the above 3DLUT with Gamma_Curve 2.55555, yCMS undershot the color temperature considerably and was very inconsistent across the entire grayscale range, while Gamma_Curve 1.0 2.5 and Gamma_Curve 1.0 2.6 were just fine overall (with the exception of a couple small color temperature bumps).

yesgrey

8th January 2011, 00:39

I did a bit more investigation, and it appears that those bumps happen when yCMS makes an error targeting the gamma at a particular IRE, or more that there is an unexpected bump in the gamma at the same IRE where there is an unexpected bump in color temperature.
Yes, it's related to that. I'm currently investigating the problem.

My display is calibrated to a 2.222222 Display Gamma Power Curve with Argyll.
I will explain it more deeply when I reply to the gamma part, but if that's what you want why don't you stop using the BT.709 gamma curve (or camera as you call it), and simply use:
Gamma_Curve 0.0 2.222222
to get the response you want? If you read the manual you can see that curveType 0.0 is a pure power curve (or display gamma as you call it).;)

janos666

8th January 2011, 01:02

Your last post reminds me to a problem: Sometimes I have to use 0.0 number format as an input value because a simple 0 is denied.
It happened when I copy-pasted values from excel. I had to manually correct it or change the type from number to text and enter 0.0 manually first.

yesgrey

8th January 2011, 01:52

Sometimes I have to use 0.0 number format as an input value because a simple 0 is denied.
That's strange, but unless you show me a specific example it would be hard to fix because I don't know where to look at.

cyberbeing

8th January 2011, 02:08

why don't you stop using the BT.709 gamma curve (or camera as you call it), and simply use:
Gamma_Curve 0.0 2.222222
to get the response you want? If you read the manual you can see that curveType 0.0 is a pure power curve (or display gamma as you call it).;)

When I tried it in 0.18 awhile back, I seemed to get a totally different gamma then I specified. I just tried it in 0.19 and it seems to work properly now, which is good to know.
Edit: It seems grayscale color correction is much worse with Gamma_Curve 0.0 2.22222 then Gamma_Curve 1.0 2.6 is. I'm beginning to wonder if yCMS just doesn't like Gamma curves of more than a single decimal place.

The problem is that I actually do want BT.709 video displayed with a BT.709 gamma curve, so Gamma_Curve 1.0 is the only option. Gamma_Curve 1.0 modifies your current gamma curve to match the input gamma curve, correct? For that reason I need yCMS to scale the BT.709 curve as close to my calibrated gamma curve as possible, so only a minimal adjustment is made and the average gamma of my screen doesn't change. The answer appears to be Gamma_Curve 1.0 2.555555, but grayscale color correction is broken with that particular gamma for some reason.

If you are wondering why I'm calibrating to a 2.222222 power curve in Argyll, it's for simplicities sake (Previously I was calibrating to a 2.22 sRGB curve with BasICColor, since a sRGB curve is similar to the BT.709 curve). It's hard to target a specific gamma with BT.709 in Argyll, since it bases it on ambient light measurements. The last time I tried, I ended up with a BT.709 curve with a Display Gamma of ~2.7 or something which would be the equivalent of something like Gamma_Curve 1.0 3.0 in yCMS.

yesgrey

9th January 2011, 11:47

if its not too much of an inconvenience, yes please.
I've thought about it and it would take me a lot of time, while you should be able to find a good match with some trial and error in a few minutes.

Sorry.:(

Thunderbolt8

9th January 2011, 13:39

alright then, nvm.

cyberbeing

9th January 2011, 18:12

Furthermore, I don't believe any studios would master any movies with a BT.709 transfer function with a 2.6 gamma.;)

Now that your image attachment finally got approved day later, in relation to this comment, I'm unsure where you are getting these ideas from.

Your default BT.709 curve in yCMS (what yCMS calls 2.222222) effectively de-gamma's the image to produce a linear 1.0 gamma. Nothing would be mastered at a linear gamma, since it does not have the correct contrast enhancement suitable for viewing. The BT.709 gamma would be increased by power function to a average display gamma of 2.2-2.6 (BT.709 w/ 1.175-1.375 power function) at which it would be mastered.

That said, what yCMS considers a BT.709 2.6 gamma (or BT.709 /w 1.2 power function), would actually be very close to the absolute minimum gamma acceptable for mastering.

Edit: On a somewhat unrelated note, yCMS "Gamma_Curve 1.0" doesn't even produce the BT.709 camera gamma you specify. "Gamma_Curve 1.0 2.5" actually produces a 2.6 camera gamma, and "Gamma_Curve 1.0 2.6" produces a 2.7 camera gamma. Since you are currently looking into gamma bugs in yCMS you are probably already aware of this, but if not it's worth noting when fixing things.

Edit2: I gave calibrating to BT.709 in Argyll another try, since it's been many revisions since I tried last time. By setting Ambient Light in Argyll to 32 lux, I ended up with a BT.709 curve with an average gamma of 2.38 which is acceptable. I'm now convinced that yCMS gamma correction is broken, since after I set Gamma_Curve 1.0 2.7, yCMS appeared to be turning my BT.709 curve into a 2.38 power curve. Could you add an option to yCMS to use Grayscale_Measurements for color correction, but leave the gamma as-is?

janos666

12th January 2011, 00:15

[...] after the gamut correction, you will see the less saturated primaries, which have lower RGB values than the uncorrected ones, hence the not clipping at the 235 point as would happen with the uncorrected ones.

It's just weird. And it's strange after lcms2 in MPC-HC doesn't cause anything like this. (On the other hand, lcms likes to cause near-black banding. :()

That's strange, but unless you show me a specific example it would be hard to fix because I don't know where to look at.
Try this:
Input_Transfer_Function 1 0 0.425531915 0
As I can remember, this caused the problem for me but I didn't check it again (sorry).

BeNooL

26th January 2011, 19:19

A somewhat long time ago I tried to use yCMS with my poor HCFR colorimeter and was not able to achieve much. The quality of the meter was definitively to blame so I just let it be.

Things have changes since as I bought a decent meter. I was eager to give yCMS a new try and would like to relate here the results.

First of all, I calibrated my display with my primary source, an Oppo BDP-83, using the AVS HD709 patterns disc. The display has no CMS but has a White Balance menu allowing adjustment of primaries' gain/bias. The following results were obtained (calibration software CalMAN 4):
http://img511.imageshack.us/img511/793/oppobdp83whitebalance.th.png (http://img511.imageshack.us/i/oppobdp83whitebalance.png/)
A very nice white balance after calibration especially in the 20-80 IRE range. It rises at extremities but remains under 2.

http://img31.imageshack.us/img31/3422/oppobdp83gamut.th.png (http://img31.imageshack.us/i/oppobdp83gamut.png/)
Having no CMS I can't do much here but results are not too catastrophic

Now to move on the PC.
Initial measurements without any correction. Using MPC-HC with madVR on an ATI 4550 set in RGB PC Standard mode.
http://img375.imageshack.us/img375/1323/pcwhitebalancenormal.th.png (http://img375.imageshack.us/i/pcwhitebalancenormal.png/)
quite a different WB from before

http://img227.imageshack.us/img227/871/pcgamutnormal.th.png (http://img227.imageshack.us/i/pcgamutnormal.png/)
white point moved but we basically have the same extended gamut

After measurements were done with ArgyllCMS, I compiled this input file for yCMS.

Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Gamut_Measurements 2
49.787 22.566 0.39131
26.635 70.618 1.0149
16.223 6.3478 93.516
92.336 99.857 92.722
Grayscale_Measurements
0.40984 2 0.19656 0.2173 0.29234
0.81967 2 0.19704 0.21693 0.29294
1.2295 2 0.20501 0.21997 0.2967
1.6393 2 0.22411 0.22729 0.31592
2.0492 2 0.23832 0.2355 0.33466
2.459 2 0.25738 0.25113 0.35658
2.8689 2 0.28234 0.27719 0.39714
3.2787 2 0.31349 0.3033 0.42918
3.6885 2 0.31395 0.29871 0.4408
4.0984 2 0.3427 0.33095 0.47644
4.5082 2 0.38989 0.37029 0.52448
4.918 2 0.48421 0.45961 0.63333
5.3279 2 0.52503 0.50603 0.68509
5.7377 2 0.57961 0.55097 0.74415
6.1475 2 0.57323 0.55014 0.7402
6.5574 2 0.64953 0.62507 0.81154
6.9672 2 0.70777 0.68133 0.88415
7.377 2 0.7664 0.74397 0.94728
7.7869 2 0.85319 0.83235 1.0304
8.1967 2 0.87866 0.85696 1.0578
8.6066 2 0.88026 0.85462 1.0568
9.0164 2 0.89526 0.88149 1.0808
9.4262 2 0.94857 0.92353 1.1312
9.8361 2 0.97063 0.94927 1.1568
10.246 2 0.99381 0.97357 1.1757
10.656 2 1.0192 1.0002 1.2087
11.066 2 1.0698 1.0517 1.2497
11.475 2 1.0685 1.0537 1.261
11.885 2 1.1534 1.1344 1.3367
12.295 2 1.202 1.1868 1.3876
12.705 2 1.289 1.2752 1.4723
13.115 2 1.3713 1.3692 1.5595
13.525 2 1.5 1.4973 1.6805
13.934 2 1.6334 1.6416 1.8035
14.344 2 1.76 1.7816 1.9319
14.754 2 1.9058 1.9299 2.0594
15.164 2 2.0138 2.0483 2.1622
15.574 2 2.1676 2.2094 2.3034
15.984 2 2.2929 2.3405 2.4187
16.393 2 2.292 2.3443 2.419
16.803 2 2.4317 2.4944 2.5668
17.213 2 2.5907 2.6752 2.698
17.623 2 2.7138 2.8061 2.8197
18.033 2 2.8954 2.9976 2.9809
18.443 2 3.0273 3.146 3.0985
18.852 2 3.1612 3.2948 3.2328
19.262 2 3.1682 3.2973 3.2418
19.672 2 3.3454 3.4958 3.3945
20.082 2 3.5388 3.7048 3.6086
20.492 2 3.6934 3.8684 3.7684
20.902 2 3.8855 4.0938 3.974
21.311 2 4.0982 4.3077 4.1856
21.721 2 4.2168 4.4276 4.3017
22.131 2 4.2148 4.4248 4.3039
22.541 2 4.4809 4.7505 4.5994
22.951 2 4.8206 5.1118 4.9473
23.361 2 4.997 5.3138 5.1068
23.77 2 5.1829 5.5182 5.3173
24.18 2 5.1842 5.5125 5.3034
24.59 2 5.4204 5.7498 5.5862
25 2 5.6198 5.9803 5.7705
25.41 2 5.8239 6.2164 6.0138
25.82 2 5.9833 6.401 6.1631
26.23 2 6.0953 6.5386 6.2748
26.639 2 6.3213 6.7667 6.4656
27.049 2 6.4557 6.9363 6.589
27.459 2 6.6758 7.1523 6.8276
27.869 2 6.8222 7.333 6.9925
28.279 2 6.9753 7.4911 7.1772
28.689 2 7.1768 7.6874 7.3836
29.098 2 7.3701 7.8973 7.6002
29.508 2 7.5364 8.0962 7.7717
29.918 2 7.6371 8.2271 7.9247
30.328 2 7.9014 8.5347 8.1841
30.738 2 8.1069 8.7287 8.4185
31.148 2 8.3125 8.9659 8.6419
31.557 2 8.5085 9.1857 8.8023
31.967 2 8.8415 9.5592 9.1487
32.377 2 9.0827 9.8345 9.4105
32.787 2 9.269 10.026 9.6175
33.197 2 9.4961 10.24 9.8378
33.607 2 9.6921 10.479 10.051
34.016 2 9.938 10.748 10.312
34.426 2 10.182 11.002 10.544
34.836 2 10.347 11.207 10.712
35.246 2 10.657 11.527 11.057
35.656 2 10.86 11.729 11.256
36.066 2 11.148 12.083 11.542
36.475 2 11.413 12.334 11.868
36.885 2 11.67 12.641 12.045
37.295 2 11.877 12.897 12.18
37.705 2 12.119 13.16 12.352
38.115 2 12.339 13.359 12.706
38.525 2 12.624 13.694 12.996
38.934 2 12.972 14.073 13.385
39.344 2 13.247 14.361 13.627
39.754 2 13.479 14.624 13.844
40.164 2 13.703 14.883 14.097
40.574 2 14.019 15.215 14.448
40.984 2 14.62 15.879 15.016
41.393 2 14.911 16.188 15.308
41.803 2 15.134 16.452 15.55
42.213 2 15.508 16.862 15.982
42.623 2 15.748 17.181 16.216
43.033 2 16.016 17.386 16.487
43.443 2 16.329 17.759 16.733
43.852 2 16.632 18.076 17.052
44.262 2 16.908 18.37 17.368
44.672 2 17.26 18.802 17.744
45.082 2 17.661 19.198 18.106
45.492 2 17.876 19.477 18.337
45.902 2 18.199 19.754 18.694
46.311 2 18.528 20.186 19.17
46.721 2 18.803 20.537 19.264
47.131 2 19.137 20.849 19.633
47.541 2 19.472 21.238 19.951
47.951 2 19.674 21.479 20.119
48.361 2 20.119 21.979 20.582
48.77 2 20.432 22.192 21.021
49.18 2 20.793 22.6 21.397
49.59 2 21.144 22.965 21.808
50 2 21.885 23.816 22.288
50.41 2 22.236 24.211 22.597
50.82 2 22.654 24.689 23.05
51.23 2 23.057 25.074 23.54
51.639 2 23.413 25.504 23.88
52.049 2 23.886 25.986 24.354
52.459 2 24.353 26.512 24.842
52.869 2 24.583 26.773 25.031
53.279 2 25.008 27.23 25.561
53.689 2 25.437 27.744 25.867
54.098 2 25.895 28.193 26.3
54.508 2 26.139 28.434 26.616
54.918 2 26.613 28.948 27.143
55.328 2 26.987 29.36 27.58
55.738 2 27.423 29.908 27.919
56.148 2 27.84 30.313 28.368
56.557 2 28.283 30.756 28.844
56.967 2 28.764 31.364 29.268
57.377 2 28.998 31.57 29.398
57.787 2 29.529 32.097 29.96
58.197 2 29.942 32.487 30.416
58.607 2 30.429 33.14 30.854
59.016 2 30.961 33.7 31.46
59.426 2 31.792 34.691 32.189
59.836 2 32.223 35.122 32.657
60.246 2 32.73 35.617 33.247
60.656 2 33.11 35.985 33.661
61.066 2 33.527 36.437 33.945
61.475 2 34.066 37.04 34.551
61.885 2 34.645 37.61 34.985
62.295 2 34.895 38.052 35.356
62.705 2 35.432 38.627 35.903
63.115 2 35.823 39.041 36.231
63.525 2 36.258 39.498 36.796
63.934 2 36.804 40.1 37.255
64.344 2 37.402 40.799 37.981
64.754 2 37.725 41.199 37.947
65.164 2 38.22 41.757 38.422
65.574 2 38.719 42.343 38.799
65.984 2 39.184 42.815 39.352
66.393 2 38.033 41.4 38.268
66.803 2 40.109 43.853 40.25
67.213 2 40.722 44.545 40.982
67.623 2 41.177 44.977 41.424
68.033 2 41.756 45.608 42.121
68.443 2 42.695 46.717 42.968
68.852 2 43.064 47.185 43.174
69.262 2 43.731 47.778 43.915
69.672 2 44.305 48.415 44.378
70.082 2 44.796 49.091 45.117
70.492 2 45.309 49.589 45.663
70.902 2 45.82 50.168 46.094
71.311 2 46.379 50.84 46.665
71.721 2 46.8 51.473 47.011
72.131 2 47.577 52.069 47.972
72.541 2 48.048 52.472 48.153
72.951 2 48.411 52.791 48.697
73.361 2 49.067 53.576 49.231
73.77 2 49.614 54.257 49.756
74.18 2 50.155 54.886 50.397
74.59 2 50.773 55.497 51.211
75 2 51.306 56.125 51.469
75.41 2 52.078 56.82 52.478
75.82 2 52.609 57.43 52.956
76.23 2 53.358 58.306 53.835
76.639 2 53.478 58.552 53.81
77.049 2 53.941 58.903 54.098
77.459 2 55.251 60.285 55.516
77.869 2 56.034 61.174 56.313
78.279 2 56.647 61.684 57.051
78.689 2 56.944 62.033 57.217
79.098 2 57.766 62.898 57.948
79.508 2 58.332 63.537 58.47
79.918 2 59.148 64.318 59.316
80.328 2 59.902 65.156 60.057
80.738 2 60.219 65.562 60.075
81.148 2 60.984 66.447 60.877
81.557 2 61.438 66.797 61.23
81.967 2 62.124 67.544 61.965
82.377 2 62.716 68.076 62.704
82.787 2 63.477 69.072 63.356
83.197 2 64.041 69.59 63.928
83.607 2 64.828 70.462 64.612
84.016 2 65.206 70.902 64.954
84.426 2 65.905 71.776 65.634
84.836 2 66.443 72.185 66.337
85.246 2 67.096 72.712 67.037
85.656 2 67.868 73.556 67.583
86.066 2 68.395 74.22 68.242
86.475 2 69.55 75.379 69.288
86.885 2 70.308 76.098 70.227
87.295 2 71.072 77.068 70.863
87.705 2 71.606 77.531 71.45
88.115 2 72.216 78.178 72.151
88.525 2 73.074 79.19 73.349
88.934 2 73.808 79.994 73.545
89.344 2 74.162 80.329 73.773
89.754 2 74.849 81.055 74.398
90.164 2 75.688 81.953 75.486
90.574 2 76.47 82.903 75.999
90.984 2 77.163 83.479 77.073
91.393 2 77.949 84.333 77.822
91.803 2 78.276 84.674 78.043
92.213 2 79.323 85.772 79.232
92.623 2 79.815 86.289 79.665
93.033 2 80.812 87.452 80.735
93.443 2 81.489 88.31 81.464
93.852 2 82.149 88.881 82.168
94.262 2 83.037 89.858 83.042
94.672 2 83.422 90.212 83.392
95.082 2 84.298 91.215 84.435
95.492 2 85.762 92.857 85.832
95.902 2 86.849 94.316 86.774
96.311 2 87.367 94.708 87.364
96.721 2 88.171 95.28 88.555
97.131 2 88.234 95.453 88.149
97.541 2 89.047 96.407 88.832
97.951 2 89.849 97.238 89.8
98.361 2 90.709 98.243 90.559
98.77 2 91.526 99.116 91.768
99.18 2 92.195 99.846 92.398
99.59 2 92.409 99.985 92.726
100 2 92.336 99.857 92.722

It does complain about some inaccurate measurements:
Warning: Grayscale measurement on line 49 might be inaccurate.
Warning: Grayscale measurement on line 42 might be inaccurate.
Warning: Grayscale measurement on line 30 might be inaccurate.
Warning: Grayscale measurement on line 23 might be inaccurate.
The file '..\HD - PC.3dlut' was successfully created.
Running time: 6703ms; Computation time: 5718ms (85.3%)
but does complete.

The same measurements were done again this time with 3D LUT active in madVR:
http://img827.imageshack.us/img827/2350/pcwhitebalanceycms.th.png (http://img827.imageshack.us/i/pcwhitebalanceycms.png/)
Each primary has been flattened but no correction on the blue shift

http://img208.imageshack.us/img208/3784/pcgamutycms.th.png (http://img208.imageshack.us/i/pcgamutycms.png/)
on the gamut side, the improvement is quite clear but white point hasn't moved

And that's it. I'm really posting those results to check with you if that's the expected behavior of yCMS or if you can see a flaw in the measurement process applied.

Subjectively (and I saved that for the bottom line) the picture with the PC and CMS looks absolutely stunning! I think I'll buy an external CMS solution so that all sources can benefit from it.

janos666

26th January 2011, 20:13

yesgrey

27th January 2011, 00:37

I was eager to give yCMS a new try and would like to relate here the results.
Thanks for such a detailed test. I will analyse your results to see if I can find the reason for your results. It seems the color balance is still not working OK...

BeNooL

27th January 2011, 14:48

What is your current sensor? Is it a colorimeter or a spectrophotometer? I am not familiar with this software and it's GUI. But for the fist look, it looks like your primaries are still out of the map (and the world of current display technologies).
May be it's only a presentation fault and their CIE diagram is not the usual full CIE chart. Or you are still using an incompatible instrument.

I think you should include the IRE_0.000 to get black point compensation.

By the way, if your display work with only 8 bit internal precision then you shouldn't use the RGB Gains. It will cause big rounding errors.
Check a gray gradient test image to see if the hardware adjustments cause banding or not. If the gradient is still smooth then use them. If it has visible banding than restore the defaults (or try to find a spot where you have the most available shades to start with) and leave them alone.

Yes the gamut points out of the chart have me worried a bit too. I'll have to try again another time to check if this is reproducible but I'm a bit fed up with doing measurements at the moment :)

The sensor is a variant of the Eye-One Display 2 called X2 and sold by Spectral.

Thanks for the advise on RGB gains. I'll check but most of the corrections were done with the bias controls.

janos666

27th January 2011, 21:40

The sensor is a variant of the Eye-One Display 2 called X2 and sold by Spectral.

It seems you didn't really learn about the last incident with improper sensors...
The gamut looks over-saturated because the Eye One is an old colorimeter which couldn't work on any wide gamut displays on it's own. You have two choices:
- Buy an own spectrophotometer (like the EyeOne Pro or the ColorMunki).
- Rent a spectrophotometer and use it to make a custom correction matrix for your given WCG-display+colorimeter combination. It will be usable with ArgyllCMS. And I think you can use it with CalMan too (not the ArgyllCMS specific file itself but this is basically 9 numbers in a 3x3 matrix. It won't require too much skills to edit some text files with notepad and insert these numbers in the proper format for different softwares...)
- If you would have a retail i1d2 (not an OEM one as you said), you could send it back to the factory (X-Rite) for factory-recalibration and ask for a new firmware which has some preset matrices too. -> Nearly as expensive as a new instrument (and a better instrument if you consider the spectros...)

adam777

28th January 2011, 09:58

Hello all,
I don't mean to disrupt the flow of this wonderful discussion, but I have a small question of my own.
I'm using a plain notebook screen as my main display device, so obviously I will not calibrate it in any way.
Considering the above, is there any advantage of creating vanilla 3DLUTs using the templates for use in madVR comparing to not using 3DLUTs at all?
Thanks in advance, Adam.

janos666

28th January 2011, 13:09

I'm using a plain notebook screen as my main display device, so obviously I will not calibrate it in any way.
Considering the above, is there any advantage of creating vanilla 3DLUTs using the templates for use in madVR comparing to not using 3DLUTs at all?

No.
May be if you can find an ICC profile for you display (manufacturer's website, forums or review sites where somebody uploaded one) you can read out the gamut coordinates which may help a bit with color saturation (TNs usually have narrow gamuts).

yesgrey

6th February 2011, 18:22

yCMS v1.10 released

http://yesgrey.com/ycms.html

- Added support for sYCC and xvYCC.
- Added sYCC, xvYCC_HD and xvYCC_SD videoStandards to Input/Output_Format.
- Added sYCC and xvYCC videoStandards to Input/Output_Transfer_Function.
- Fixed bug that caused some commands to not accept integers as FP values.
- Added Necsel videoStandard to Input/Output_Primaries.

This is a version with preliminary support for sYCC and xvYCC. I don't have any source files in any of these formats, so I cannot be sure that it's working fine. Please test and report the results.

I have added the Necsel primaries (laser) to help people test the new formats, because it would be able to hold almost all the colors. However, don't forget that when watched on a display with standard primaries the colors would be wrong, it is only for testing purposes.

I am still working on the related problems about the color balance correction.

cyberbeing

7th February 2011, 07:28

Could you add an option to yCMS to use Grayscale_Measurements for color correction, but leave the gamma as-is?
Do you plan to implement this request?

An option to use the gamma curve yCMS calculates from Grayscale_Measurements as the target gamma, instead of the Gamma_Curve parameter?

Was there anything else minor changed in yCMS 0.10 which would warrant recreation of 3DLUTs from 0.9? It doesn't sound like it, but just making sure.

yesgrey

7th February 2011, 14:34

Do you plan to implement this request?
I will think about it.

Was there anything else minor changed in yCMS 0.10 which would warrant recreation of 3DLUTs from 0.9?
No. Previous 3DLUTs are still valid.

starlight2

12th February 2011, 15:41

hello guys, I tried to use 3dlut but when active madvr tells me: "ready 3dlut file header failed. " Ycms and 'the latest version, I tried different strings but I always get the same error.
This' is an example:

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

# Display Gamut Measurements
Gamut_Measurements 2
44.52300 24.20800 2.091800
31.72700 65.82100 10.34800
18.22600 9.450000 95.30100

Help me? Thanks!

yesgrey

12th February 2011, 16:49

# Display Gamut Measurements
Gamut_Measurements 2
44.52300 24.20800 2.091800
31.72700 65.82100 10.34800
18.22600 9.450000 95.30100

Your Gamut_Measurements command is missing the last line, the white point measurements.

starlight2

12th February 2011, 16:58

You can post an example please refer to? So 'copy and paste the file into the HD-video.3dlut and see if it works?
Sorry for my english!

cyberbeing

12th February 2011, 17:19

Gamut_Measurements 2
44.52300 24.20800 2.091800
31.72700 65.82100 10.34800
18.22600 9.450000 95.30100
Those measurements look familiar... they're ones I posted in this thread... starlight2, you need to use measurements from your own display. Using mine won't help at all.

Do not paste text into a 3DLUT file. yCMS needs to create the 3DLUT.

Navigate to C:\...\madVR\yCMS\

Run yCMS.exe "template - HD - PC.txt" "HD - PC"

Copy 96MB "HD - PC.3dlut" to C:\...\madVR\ directory.

yesgrey

12th February 2011, 17:23

You can post an example please refer to? So 'copy and paste the file into the HD-video.3dlut and see if it works?
Sorry for my english!
When you measured your display's primaries, it was supposed that you also had measured you display's white point... That would be the correct approach.

As a quick solution, just for you to make it work for now, use this (the bold line is what's missing in your file):
Gamut_Measurements 2
44.52300 24.20800 2.091800
31.72700 65.82100 10.34800
18.22600 9.450000 95.30100
95.04560 100.0000 108.90578

starlight2

12th February 2011, 17:37

I know I have to do measurements on my display but I wanted to see if it worked temporarily with some string, I just copied from you:)
However I did not understand how it works ..
The procedure that I do and I 'as follows:
1) Within the folder Madvr / Ycms yCMS.exe and then run it (it does not open anything and does not create any files)
2) Within the root / madvr and open with both blocknote (HD - PC.3dlut) that (HD - Video.3dlut), paste it into parameters like this:

Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Gamut_Measurements 2
70.28325 31.64575 1.074425
24.9915 84.4635 11.7725
23.6385 8.894625 124.175
118.385 124.48 136.145

Then I open a MKV with MPCHC ---- ---- madvr 3dlut active but the screen goes black and I get this error in red:
Ready 3dlut file header failed "

yesgrey

12th February 2011, 17:44

After measurements were done with ArgyllCMS, I compiled this input file for yCMS.

Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Gamut_Measurements 2
49.787 22.566 0.39131
26.635 70.618 1.0149
16.223 6.3478 93.516
92.336 99.857 92.722
Grayscale_Measurements
0.40984 2 0.19656 0.2173 0.29234
0.81967 2 0.19704 0.21693 0.29294
1.2295 2 0.20501 0.21997 0.2967
1.6393 2 0.22411 0.22729 0.31592
2.0492 2 0.23832 0.2355 0.33466
2.459 2 0.25738 0.25113 0.35658
2.8689 2 0.28234 0.27719 0.39714
3.2787 2 0.31349 0.3033 0.42918
3.6885 2 0.31395 0.29871 0.4408
4.0984 2 0.3427 0.33095 0.47644
4.5082 2 0.38989 0.37029 0.52448
4.918 2 0.48421 0.45961 0.63333
5.3279 2 0.52503 0.50603 0.68509
5.7377 2 0.57961 0.55097 0.74415
6.1475 2 0.57323 0.55014 0.7402
6.5574 2 0.64953 0.62507 0.81154
6.9672 2 0.70777 0.68133 0.88415
7.377 2 0.7664 0.74397 0.94728
7.7869 2 0.85319 0.83235 1.0304
8.1967 2 0.87866 0.85696 1.0578
8.6066 2 0.88026 0.85462 1.0568
9.0164 2 0.89526 0.88149 1.0808
9.4262 2 0.94857 0.92353 1.1312
9.8361 2 0.97063 0.94927 1.1568
10.246 2 0.99381 0.97357 1.1757
10.656 2 1.0192 1.0002 1.2087
11.066 2 1.0698 1.0517 1.2497
11.475 2 1.0685 1.0537 1.261
11.885 2 1.1534 1.1344 1.3367
12.295 2 1.202 1.1868 1.3876
12.705 2 1.289 1.2752 1.4723
13.115 2 1.3713 1.3692 1.5595
13.525 2 1.5 1.4973 1.6805
13.934 2 1.6334 1.6416 1.8035
14.344 2 1.76 1.7816 1.9319
14.754 2 1.9058 1.9299 2.0594
15.164 2 2.0138 2.0483 2.1622
15.574 2 2.1676 2.2094 2.3034
15.984 2 2.2929 2.3405 2.4187
16.393 2 2.292 2.3443 2.419
16.803 2 2.4317 2.4944 2.5668
17.213 2 2.5907 2.6752 2.698
17.623 2 2.7138 2.8061 2.8197
18.033 2 2.8954 2.9976 2.9809
18.443 2 3.0273 3.146 3.0985
18.852 2 3.1612 3.2948 3.2328
19.262 2 3.1682 3.2973 3.2418
19.672 2 3.3454 3.4958 3.3945
20.082 2 3.5388 3.7048 3.6086
20.492 2 3.6934 3.8684 3.7684
20.902 2 3.8855 4.0938 3.974
21.311 2 4.0982 4.3077 4.1856
21.721 2 4.2168 4.4276 4.3017
22.131 2 4.2148 4.4248 4.3039
22.541 2 4.4809 4.7505 4.5994
22.951 2 4.8206 5.1118 4.9473
23.361 2 4.997 5.3138 5.1068
23.77 2 5.1829 5.5182 5.3173
24.18 2 5.1842 5.5125 5.3034
24.59 2 5.4204 5.7498 5.5862
25 2 5.6198 5.9803 5.7705
25.41 2 5.8239 6.2164 6.0138
25.82 2 5.9833 6.401 6.1631
26.23 2 6.0953 6.5386 6.2748
26.639 2 6.3213 6.7667 6.4656
27.049 2 6.4557 6.9363 6.589
27.459 2 6.6758 7.1523 6.8276
27.869 2 6.8222 7.333 6.9925
28.279 2 6.9753 7.4911 7.1772
28.689 2 7.1768 7.6874 7.3836
29.098 2 7.3701 7.8973 7.6002
29.508 2 7.5364 8.0962 7.7717
29.918 2 7.6371 8.2271 7.9247
30.328 2 7.9014 8.5347 8.1841
30.738 2 8.1069 8.7287 8.4185
31.148 2 8.3125 8.9659 8.6419
31.557 2 8.5085 9.1857 8.8023
31.967 2 8.8415 9.5592 9.1487
32.377 2 9.0827 9.8345 9.4105
32.787 2 9.269 10.026 9.6175
33.197 2 9.4961 10.24 9.8378
33.607 2 9.6921 10.479 10.051
34.016 2 9.938 10.748 10.312
34.426 2 10.182 11.002 10.544
34.836 2 10.347 11.207 10.712
35.246 2 10.657 11.527 11.057
35.656 2 10.86 11.729 11.256
36.066 2 11.148 12.083 11.542
36.475 2 11.413 12.334 11.868
36.885 2 11.67 12.641 12.045
37.295 2 11.877 12.897 12.18
37.705 2 12.119 13.16 12.352
38.115 2 12.339 13.359 12.706
38.525 2 12.624 13.694 12.996
38.934 2 12.972 14.073 13.385
39.344 2 13.247 14.361 13.627
39.754 2 13.479 14.624 13.844
40.164 2 13.703 14.883 14.097
40.574 2 14.019 15.215 14.448
40.984 2 14.62 15.879 15.016
41.393 2 14.911 16.188 15.308
41.803 2 15.134 16.452 15.55
42.213 2 15.508 16.862 15.982
42.623 2 15.748 17.181 16.216
43.033 2 16.016 17.386 16.487
43.443 2 16.329 17.759 16.733
43.852 2 16.632 18.076 17.052
44.262 2 16.908 18.37 17.368
44.672 2 17.26 18.802 17.744
45.082 2 17.661 19.198 18.106
45.492 2 17.876 19.477 18.337
45.902 2 18.199 19.754 18.694
46.311 2 18.528 20.186 19.17
46.721 2 18.803 20.537 19.264
47.131 2 19.137 20.849 19.633
47.541 2 19.472 21.238 19.951
47.951 2 19.674 21.479 20.119
48.361 2 20.119 21.979 20.582
48.77 2 20.432 22.192 21.021
49.18 2 20.793 22.6 21.397
49.59 2 21.144 22.965 21.808
50 2 21.885 23.816 22.288
50.41 2 22.236 24.211 22.597
50.82 2 22.654 24.689 23.05
51.23 2 23.057 25.074 23.54
51.639 2 23.413 25.504 23.88
52.049 2 23.886 25.986 24.354
52.459 2 24.353 26.512 24.842
52.869 2 24.583 26.773 25.031
53.279 2 25.008 27.23 25.561
53.689 2 25.437 27.744 25.867
54.098 2 25.895 28.193 26.3
54.508 2 26.139 28.434 26.616
54.918 2 26.613 28.948 27.143
55.328 2 26.987 29.36 27.58
55.738 2 27.423 29.908 27.919
56.148 2 27.84 30.313 28.368
56.557 2 28.283 30.756 28.844
56.967 2 28.764 31.364 29.268
57.377 2 28.998 31.57 29.398
57.787 2 29.529 32.097 29.96
58.197 2 29.942 32.487 30.416
58.607 2 30.429 33.14 30.854
59.016 2 30.961 33.7 31.46
59.426 2 31.792 34.691 32.189
59.836 2 32.223 35.122 32.657
60.246 2 32.73 35.617 33.247
60.656 2 33.11 35.985 33.661
61.066 2 33.527 36.437 33.945
61.475 2 34.066 37.04 34.551
61.885 2 34.645 37.61 34.985
62.295 2 34.895 38.052 35.356
62.705 2 35.432 38.627 35.903
63.115 2 35.823 39.041 36.231
63.525 2 36.258 39.498 36.796
63.934 2 36.804 40.1 37.255
64.344 2 37.402 40.799 37.981
64.754 2 37.725 41.199 37.947
65.164 2 38.22 41.757 38.422
65.574 2 38.719 42.343 38.799
65.984 2 39.184 42.815 39.352
66.393 2 38.033 41.4 38.268
66.803 2 40.109 43.853 40.25
67.213 2 40.722 44.545 40.982
67.623 2 41.177 44.977 41.424
68.033 2 41.756 45.608 42.121
68.443 2 42.695 46.717 42.968
68.852 2 43.064 47.185 43.174
69.262 2 43.731 47.778 43.915
69.672 2 44.305 48.415 44.378
70.082 2 44.796 49.091 45.117
70.492 2 45.309 49.589 45.663
70.902 2 45.82 50.168 46.094
71.311 2 46.379 50.84 46.665
71.721 2 46.8 51.473 47.011
72.131 2 47.577 52.069 47.972
72.541 2 48.048 52.472 48.153
72.951 2 48.411 52.791 48.697
73.361 2 49.067 53.576 49.231
73.77 2 49.614 54.257 49.756
74.18 2 50.155 54.886 50.397
74.59 2 50.773 55.497 51.211
75 2 51.306 56.125 51.469
75.41 2 52.078 56.82 52.478
75.82 2 52.609 57.43 52.956
76.23 2 53.358 58.306 53.835
76.639 2 53.478 58.552 53.81
77.049 2 53.941 58.903 54.098
77.459 2 55.251 60.285 55.516
77.869 2 56.034 61.174 56.313
78.279 2 56.647 61.684 57.051
78.689 2 56.944 62.033 57.217
79.098 2 57.766 62.898 57.948
79.508 2 58.332 63.537 58.47
79.918 2 59.148 64.318 59.316
80.328 2 59.902 65.156 60.057
80.738 2 60.219 65.562 60.075
81.148 2 60.984 66.447 60.877
81.557 2 61.438 66.797 61.23
81.967 2 62.124 67.544 61.965
82.377 2 62.716 68.076 62.704
82.787 2 63.477 69.072 63.356
83.197 2 64.041 69.59 63.928
83.607 2 64.828 70.462 64.612
84.016 2 65.206 70.902 64.954
84.426 2 65.905 71.776 65.634
84.836 2 66.443 72.185 66.337
85.246 2 67.096 72.712 67.037
85.656 2 67.868 73.556 67.583
86.066 2 68.395 74.22 68.242
86.475 2 69.55 75.379 69.288
86.885 2 70.308 76.098 70.227
87.295 2 71.072 77.068 70.863
87.705 2 71.606 77.531 71.45
88.115 2 72.216 78.178 72.151
88.525 2 73.074 79.19 73.349
88.934 2 73.808 79.994 73.545
89.344 2 74.162 80.329 73.773
89.754 2 74.849 81.055 74.398
90.164 2 75.688 81.953 75.486
90.574 2 76.47 82.903 75.999
90.984 2 77.163 83.479 77.073
91.393 2 77.949 84.333 77.822
91.803 2 78.276 84.674 78.043
92.213 2 79.323 85.772 79.232
92.623 2 79.815 86.289 79.665
93.033 2 80.812 87.452 80.735
93.443 2 81.489 88.31 81.464
93.852 2 82.149 88.881 82.168
94.262 2 83.037 89.858 83.042
94.672 2 83.422 90.212 83.392
95.082 2 84.298 91.215 84.435
95.492 2 85.762 92.857 85.832
95.902 2 86.849 94.316 86.774
96.311 2 87.367 94.708 87.364
96.721 2 88.171 95.28 88.555
97.131 2 88.234 95.453 88.149
97.541 2 89.047 96.407 88.832
97.951 2 89.849 97.238 89.8
98.361 2 90.709 98.243 90.559
98.77 2 91.526 99.116 91.768
99.18 2 92.195 99.846 92.398
99.59 2 92.409 99.985 92.726
100 2 92.336 99.857 92.722

It does complain about some inaccurate measurements:
Warning: Grayscale measurement on line 49 might be inaccurate.
Warning: Grayscale measurement on line 42 might be inaccurate.
Warning: Grayscale measurement on line 30 might be inaccurate.
Warning: Grayscale measurement on line 23 might be inaccurate.
The file '..\HD - PC.3dlut' was successfully created.
Running time: 6703ms; Computation time: 5718ms (85.3%)
but does complete.

Are you sure that the file you used was the one posted above? I've decided to try it now to see if I could find the reason for your results and yCMS doesn't even complete. There are several values that can't be correct, with lower Luminances for higher IREs...

cyberbeing

12th February 2011, 17:52

You need to run yCMS from command prompt. madVR is throwing an error because it sounds like you are editing your 3DLUT like a text file. Your 3DLUT should be a 96MB binary file.

copy

Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Gamut_Measurements 2
70.28325 31.64575 1.074425
24.9915 84.4635 11.7725
23.6385 8.894625 124.175
118.385 124.48 136.145
into a txt file. For example HDPC.txt, and place it in your yCMS directory.

Start Menu -> Run -> CMD
(Replace "C:\...\madVR\yCMS\" with your yCMS directory.)
cd "C:\...\madVR\yCMS\"
ycms HDPC.txt "HD - PC"
Copy the 96MB "HD - PC.3dlut" from your yCMS directory to your madVR directory.

starlight2

12th February 2011, 18:04

oooooooookkkkkk Thanks now work :)
:thanks:

yesgrey

12th February 2011, 18:20

1) Within the folder Madvr / Ycms yCMS.exe and then run it (it does not open anything and does not create any files)
yCMS is a command line tool. So, if you want to run it directly you should do as stated in the manual (you should find it in the same folder as yCMS).

2) Within the root / madvr and open with both blocknote (HD - PC.3dlut) that (HD - Video.3dlut), paste it into parameters like this:

Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Gamut_Measurements 2
70.28325 31.64575 1.074425
24.9915 84.4635 11.7725
23.6385 8.894625 124.175
118.385 124.48 136.145

Then I open a MKV with MPCHC ---- ---- madvr 3dlut active but the screen goes black and I get this error in red:
Ready 3dlut file header failed "
You should never mess up with the .3dlut files. That's why you are getting the wrong header messages.

If you want madVR to create your custom 3dlut files you need to edit the template files inside yCMS dir, and delete the .3dlut files inside madVR's dir, then madVR automatically creates new ones using the template files.

Edit: cyberbeing was faster than me.;)

cyberbeing

13th February 2011, 05:59

This just shows that yCMS is in need of a simple GUI. Anybody volunteer to code one?

Input file (Browse...)
Output file (Browse...)
Create 3DLUT Button

Matching_Mole

22nd February 2011, 19:24

I tried to use yCMS 1.10 but the results that I got were clearly wrong and I don't understand exactly why. So maybe you can help me to understand where I make mistakes.

Currently I use 3dlut generated by yCMS via avisynth rgb3dlut filter (until that Madvr got subtitle pin renderer implemented). First I calibrated my screen using a generic 3dlut using the template HD - PC provided in the archive, so without any gamut correction. To achieve this calibration I used the HCFR Color software to make the proper measurements. And here my results:

CIE diagram:
http://img217.imageshack.us/img217/6413/cieb.jpg

Gamma 2.22 curve:
http://img251.imageshack.us/img251/9739/gammaxr.jpg

RGB curves:
http://img254.imageshack.us/img254/6469/rgbf.jpg

They can be improved but overall they are basically correct. So I set up a new configuration file for yCMS using the results provided by HCFR Color software in order to activate the gamut correction :

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 8

Grayscale_Measurements
20 2 0.476231 0.498518 0.544421
30 2 1.143894 1.190155 1.312287
40 2 2.184862 2.281045 2.506261
50 2 3.701128 3.88613 4.243921
60 2 5.451791 5.701056 6.29546
70 2 7.560717 7.962676 8.715774
80 2 10.087325 10.599005 11.655849
90 2 13.124062 13.78758 15.200966
100 2 16.386612 17.515921 18.950571

But when I used the 3dlut generated using these parameters, the results were awful. I didn't save the measurements but basically:
- the Gamma curve was around 1.9 instead of 2.22
- obviously, the luminance curve was not correct at all showing a wrong contrast level.
- the CIE diagram was far too small with the red and green points very near of the white point. Only the blue point was correct.

I checked up the parameters and, from what I read in the yCMS manual, they seem correct to me but obviously they are not. Can you help me to find out what I make wrong?

cyberbeing

22nd February 2011, 19:40

First thing, your values aren't correct. No way does your display have max luminance of 17.5 cd/m2. Where did those values come from? They need to correlate to the IRE value on the left.

You should be using Gamut_Measurements and probably Gamma_Curve as well.

Grayscale_Measurements only, won't perform gamut correction. For Gamut_Measurements you need 100% Red, Green, Blue, and White values.

Without Gamma_Curve specified you will get a native REC.709 curve (you don't want this).
For a 2.22 power-curve, specify Gamma_Curve 0.0 2.22.

Matching_Mole

22nd February 2011, 20:20

Hi cyberbeing,

Here you will find the HCFR Color software file with all the measures used to create the config file: http://www.megaupload.com/?d=NHA0WH70

Regarding the config file itself, you're right, I forgot to paste the part of the gamut measurement. Here the complete set up that I used:
# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 8

Grayscale_Measurements
20 2 0.476231 0.498518 0.544421
30 2 1.143894 1.190155 1.312287
40 2 2.184862 2.281045 2.506261
50 2 3.701128 3.88613 4.243921
60 2 5.451791 5.701056 6.29546
70 2 7.560717 7.962676 8.715774
80 2 10.087325 10.599005 11.655849
90 2 13.124062 13.78758 15.200966
100 2 16.386612 17.515921 18.950571

Gamut_Measurements 2
0.668 0.313 0.018
0.342 0.602 0.056
0.149 0.059 0.792
0.31 0.331 0.359

Gamma_Curve 1.0 2.22

So as you can see I already tried exactly what you described but the Gamma_Curve had no effect because I measured still a gamma of 1.9. I think it is related to your comment:
First thing, your values aren't correct. No way does your display have max luminance of 17.5 cd/m2.

But, as you will maybe see with the color measurement file, I use exactly (but surely in a wrong way) the data coming from it.

NB: I try to set up a projector (Mitsubishi HC3100) plugged to my HTPC with an old - but fine - ATI 2600XT

cyberbeing

22nd February 2011, 21:13

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 8

Grayscale_Measurements
20 2 0.476231 0.498518 0.544421
30 2 1.143894 1.190155 1.312287
40 2 2.184862 2.281045 2.506261
50 2 3.701128 3.88613 4.243921
60 2 5.451791 5.701056 6.29546
70 2 7.560717 7.962676 8.715774
80 2 10.087325 10.599005 11.655849
90 2 13.124062 13.78758 15.200966
100 2 16.386612 17.515921 18.950571

Gamut_Measurements 2
5.276597 2.473455 0.145127
7.777954 13.700308 1.270094
3.291976 1.309318 17.513829
16.386612 17.515921 18.950571

Gamma_Curve 0.0 2.22

Fix what I put in bold. You were using the incorrect format (xyz instead of XYZ). This is half your problem.

I have no explanation as to why your measurements are so dark, since I've never measured a projector. One of the others here, may have some insight though. This is the other half of your problem.

Matching_Mole

22nd February 2011, 21:21

Thank you very much cyberbeing. But I'm a little scared by your comment :
I have no explanation as to why your measurements are so dark

I will try and let you know!

cyberbeing

22nd February 2011, 21:55

I would think that it would either be:

A) You are taking measurements improperly and blocking too much light
B) You have a bad diffuser attachment which is blocking 90%+ of your light
C) Your projector is set way too dim or it needs a lamp replacement.

Matching_Mole

22nd February 2011, 23:20

I think more than it's because I deactivated the dynamical Iris of my projector which has for effect to push down its luminosity and improve the contrast. Here was some measures of Grayscale done with the Iris open :
Grayscale_Measurements
20 2 1.121525 1.184980 1.293971
30 2 2.611451 2.756565 3.025924
40 2 4.838468 5.090042 5.618061
50 2 8.334608 8.754509 9.589975
60 2 12.325047 12.908206 14.268075
70 2 17.568790 18.475361 20.200340
80 2 23.318539 24.431971 26.901741
90 2 30.545799 32.065472 35.328152
100 2 38.276417 40.097961 43.476048

I tried your settings and the result is still the same... red is far to white and Gamma is incorrect and so on.

Here my call in Avisynth :
ConvertToYUY2()
rgb3dlut(lutfile="mylutfile",threads=4)

If I understand well the config set up of yCMS, the lutfile is designed to convert YUV2 data to RGB32 gamut corrected data. This is the assumption of my avisynth call. Do I wrong here?

yesgrey

22nd February 2011, 23:24

For a 2.22 power-curve, specify Gamma_Curve 1.0 2.22.
No. For a pure power curve you should use:
Gamma_Curve 0.0 2.22

I would think that it would either be:

A) You are taking measurements improperly and blocking too much light
B) You have a bad diffuser attachment which is blocking 90%+ of your light
C) Your projector is set way too dim or it needs a lamp replacement.
D) You are putting your meter too far away from your projector/screen.

cyberbeing

22nd February 2011, 23:46

No. For a pure power curve you should use:
Gamma_Curve 0.0 2.22
Oops, yesgrey is correct.

Matching_Mole

23rd February 2011, 11:05

No. For a pure power curve you should use:
Gamma_Curve 0.0 2.22

D) You are putting your meter too far away from your projector/screen.

My sensor (Eye_one Display) was around 40~50 cm of the projected screen so I'm not sure it was so far away.

The wrong gamma curve setting can explain the wrong result that I seen? Anyway I will try to make another test during the week and let you know.

:thanks:

j5627429

25th February 2011, 04:03

I finally bought calibration software to go with my spectrophotometer. I am curious how others who own a meter+calibration software are using yCMS in conjunction with this.

Admittedly, yCMS is much easier to use than any TV's built-in controls, and in my case with a JVC RS40 projector, I do not even have a CMS to separately adjust primaries.

So in my case, I'm going to try this:

1) Measure primaries and correct gamut with yCMS
2) With gamut-correction 3dlut enabled, use calibration software and projector's controls to set gamma, adjust greyscale, etc so they are overall better but maybe not perfect (I'm no expert).
3) Remeasure primaries (3dlut ON) to make sure they're still correct. if they've moved, re-measure primaries (3dlut off) and create new 3dlut with yCMS to fix them.
4) Enter the "somewhat corrected" greyscale numbers achieved in step (2) into yCMS to further perfect the greyscale, and also set desired gamma_curve to match the gamma set in step (2).

Is this a logical progression? The only thing I am uncertain about is step (3). The first 3dlut will only correct the primary coordinates, so will it be okay to take measurements for a second 3dlut with greyscale correction while the first 3dlut is enabled?

Thanks in advance for any help/advice

yesgrey

25th February 2011, 22:00

Is this a logical progression?
...
will it be okay to take measurements for a second 3dlut with greyscale correction while the first 3dlut is enabled?
I would suggest two methods:
Method A (simplest)
1) measure display primaries (with 3DLUT off)
2) measure display grayscale (with 3DLUT off)
3) feed those values to yCMS and create a 3DLUT to use.

Method B
1) use your display controls to correct any problems in the grayscale (with 3DLUT off)
2) measure display primaries (with 3DLUT off)
3) measure display grayscale (with 3DLUT off)
4) feed those values to yCMS and create a 3DLUT to use.

The only difference between both methods is the correction using the display controls. If your display controls are good you probably would get better results using method B, but in case they aren't you might be better with A.

j5627429

26th February 2011, 16:35

I appreciate your advice yesgrey. It looks like I was over-complicating things.

Method B is going to be ideal for me, because I can already get greyscale pretty good with the display's controls, but the primary coordinates seem to drift quite a bit. yCMS should allow me to put them back into place and further correct the greyscale to perfection.

Thanks and keep up the good work!

janos666

20th March 2011, 02:30

I made a quick test today with a weirdly behaving c-PVA display.
I think it's a good test specimen because the gray-scale is horrible (serious black-crush, some white-crush, fluctuating color temperature across the gray shades, etc). (It can be nicely calibrated with a Radeon HD VGA which applies dithering to the 8-bit output but not with older Radeons or any Geforce cars...)

So, I measured the primaries and 128 gray patches and used the XYZ values to construct the yCMS input file.

It did a very great job with smoothing out the gray scale: no more black/white-crush or banding or fluctuations.
But I noticed that it's slightly warmer than it should be, and I also found that every gray color has a color temperature about 6250K which is the original uncorrected white point.

So, there is no any problem (I mean bug) with the color temperature correction. yCMS basically use a Relative colorimetric intent (according to the ICC terms) but does it very well. (The only problem is that I [and may be others who are sensitive to color temperature] prefer the Absolute colorimetric intent where the white point is also corrected to match with the device white.
It only requires an additional step where you transform the colors to match with the chosen white point (the rounded D65 in most television standards).

madshi

20th March 2011, 08:48

@janos666, that's a very good analyzation on your part. Spot on. You'll like the next yCMS version yesgrey has been working on. Oooops, maybe I shouldn't have said that... :o

yesgrey

20th March 2011, 13:15

The only problem is that I [and may be others who are sensitive to color temperature] prefer the Absolute colorimetric intent where the white point is also corrected to match with the device white.
You're right.

There are two ways of solving the problem:
(1) Chromatically adapt the colors to display's white point
(2) Correct display's white point.

Both situations should look correct to the user, but I understand that some users might prefer to have nice measuring charts.;)

I'm working on it, and the next version should allow both working methods.

Oooops, maybe I shouldn't have said that... :o
:)

janos666

23rd March 2011, 03:38

However, I don't like the built-in black point compensation. The shadows are brightened up too much.
So I am still using the VGA LUT calibration + the input_transfer_function command. (The only thing I changed recently that my calibration target is gamma 1.74 which is the closest matching pure-power curve - with black output offset and relative scaling - instead of forcing gamma ~2.35 through the VGA LUT).

yesgrey

23rd March 2011, 11:49

However, I don't like the built-in black point compensation. The shadows are brightened up too much.
The black point compensation only happens when you specify the 0 IRE measurement. If you omit it, the black point compensation would not be performed.

yesgrey

2nd April 2011, 11:06

Thunderbolt8

2nd April 2011, 17:05

whats up with yrgb? do I have to redo the normal HD and SD 3dluts ive been using with madvr so far with it? or can/should I still use ycms? will the same command line produce the same result with ycms and yrgb? (e.g. with that movie we were looking for the correct black levels for example)

madshi

2nd April 2011, 17:53

yRGB will be used by a future madVR version (and not the very next one). Until that future madVR version is out, yRGB is of no use for you. I will discuss the exact purpose of yRGB once that new madVR version is out.

yesgrey

2nd April 2011, 18:03

can/should I still use ycms?
The program is still yCMS. yRGB is not a new program name, it's only a color encoding format, like BT.709, PAL, NTSC, AdobeRGB, etc.

Since it was I who created it I gave it the initial of my name, hence the "y".;)

Until madshi release that new madVR version there is no need to update to yCMS v1.11.

6th April 2011, 23:29

Hi,
is there a tutorial somewhere how to use yCMS to create a 3dlut file for madVR? I´ve got an DTP 94 and my monitor (asus pa246q) is software calibrated using Quato iColor.
madVR says it bypasses the graphics card gamma correction etc., so the ICM file from iColor is useless for yCMS.

I read about argyllCMS, how do I use it to measure my monitor and pass the data to yCMS?

Mark_A_W

7th April 2011, 01:18

madVR doesn't bypass the gamma correction (that's overlay).

But I would also like a tutorial, I'm lost. I have a HCFR sensor and software (and it works fine, calibrated against Colorfacts and gave a close enough result for me).

Yellow_

7th April 2011, 13:34

yCMS v1.11 released

http://yesgrey.com/ycms.html

- Created a new RGB color encoding "yRGB" to contain HD, PAL and NTSC.
- Added yRGB videoStandard to Input/Output_Format.
- Added yRGB videoStandard to Input/Output_Primaries.
- Added yRGB videoStandard to Input/Output_Transfer_Function.

I have created a new color encoding: "yRGB".

For now, it is big enough to contain BT.709, PAL and NTSC video standards
without any color clipping, but it may change in the future. I will
public its full specification as soon as I decide for the final one.

madshi will chime in with more details when he feels it is the time.

I was going to ask if Adobe Wide could be implemented.

http://en.wikipedia.org/wiki/Wide_Gamut_RGB_color_space

But your own. :-) Look forward to trying it out.

However is it possible to actually get yRGB gamut images / frames out of Avisynth or is that not the purpose? re madVR comments

janos666

7th April 2011, 20:20

I guess yRGB will be used as some kind of intermediate space (like the Lab or XYZ ˝profile connection space˝s in the ICC terminology).
May be madvr will convert the various YCC inputs (HDTV, PAL, NTSC) to this custom color space, so we will only need a single 96Mb 3DLUT file which holds the corrections between the reference yRGB space and our displays.
But this is only my guess...

madshi

7th April 2011, 22:20

Yellow_

12th April 2011, 08:53

How possible is it to edit a LUT or emulate with lower precision for speed and generate a higher precision one for processing with. Thinking something like HSL sliders in AVSPmod and then generate LUT via yCMS?

BeNooL

13th April 2011, 06:50

Yellow_

13th April 2011, 23:33

If I am not mistaken the whole concept of LUT (look up table) is to reduce computation time by simply searching for a corresponding value for a given input. The only processing intensive part is the generation of the LUT itself.

Correct, but putting aside strict conversions to specifications where the 'corresponding values' are generated to known formula and consider custom 3D LUT generation where the 'corresponding values' are derived from tweaking in a LUT editor, because the 'intensive' part is 'the generation of the LUT itself' there is a time delay in minutes, so to be able to generate low precision or a sudo LUT faster whilst tweaking, see the effect on the source and when happy generate the high precison LUT for processing the source, for example before conversion to RGB, was what I was getting at really.

Yellow_

17th April 2011, 16:34

yesgrey, could you suggest values needed to generate a LUT to convert YCbCr to sRGB where the UV levels range 1 - 254 is treated as 16 - 240 and Y 0 - 255 by, if my thinking is correct moving the color primaries to prevent the increased saturation that would occur mapping UV 16 - 240 to 1 - 254. Would the whitepoint need to move too?

yesgrey

18th April 2011, 01:54

could you suggest values needed to generate a LUT to convert YCbCr to sRGB where the UV levels range 1 - 254 is treated as 16 - 240 and Y 0 - 255 by, if my thinking is correct moving the color primaries to prevent the increased saturation that would occur mapping UV 16 - 240 to 1 - 254. Would the whitepoint need to move too?
Sorry, but I cannot understand. Your writings sometimes are very confusing and hard to understand...

It would be a lot easier if you could give me a detailed example, or maybe someone here could help me understand what you need...

janos666

19th April 2011, 14:32

Would the whitepoint need to move too?

The white point correction is a matter of your taste but yCMS doesn't really support it right now, so no...

my thinking is correct moving the color primaries to prevent the increased saturation that would occur mapping UV 16 - 240 to 1 - 254.

The range limits won't change the color gamut. If the gamut mapping is not correct then you need to redesign your input/output transfer function parameters or include your gray-scale measurements (and check the precision and consistency of your sensor).

I don't think you would change your RGB range limits like that. It should be limited range input and limited or full range output, according to your VGA pixel format and display settings (you should try with Full Range first).

Yellow_

19th April 2011, 22:09

Sorry, but I cannot understand. Your writings sometimes are very confusing and hard to understand...

Yes, sorry, convoluted. I'm a dabbler with no real understanding of video engineering. :-)

Basically I was looking at the plausability of 'gaining' an extra 30 levels (8bit) over and above 16 - 240 for the UV channels for use in an intermediate file without changing the overall appearance as a result of remapping the levels and considered moving the colour primaries might maintain the visual appearance as if it were 16 - 240?

My limited understanding is that 8bit vid to sRGB calculation use's the 'limited' range and that full range luma can be used but assume this just brightens the resultant image? Where as xvYCC uses 1 - 254 UV and 0 - 255 Y but this results in a wider gamut as the color primaries remain the same.

My query is really about seeing if there is any benefit in using extra 30 levels of UV + full luma range, for image manipulation in an intermediate file before squeezing back to 16 - 240 UV for reencoding to BT601/709.

Looking to use SmoothAdjust for the interpolation of values or maybe a LUT in the remapping of UV before conversion to RGB.

The range limits won't change the color gamut. If the gamut mapping is not correct then you need to redesign your input/output transfer function parameters or include your gray-scale measurements (and check the precision and consistency of your sensor).

I don't think you would change your RGB range limits like that. It should be limited range input and limited or full range output, according to your VGA pixel format and display settings (you should try with Full Range first).

I'm sorry I don't have sufficient knowledge to understand your comment. I'm looking at image manipulation with gamut agnostic tools before mapping back to BT601/709 levels.

It's probably the case that my query is fundementally wrong and pointless. :-)

**EDIT**

oops, just realised I've posted my query in the wrong thread, should be in the 'gamut conversion' thread not 'software players'. sorry.

yesgrey

21st April 2011, 19:44

My query is really about seeing if there is any benefit in using extra 30 levels of UV + full luma range, for image manipulation in an intermediate file before squeezing back to 16 - 240 UV for reencoding to BT601/709.
The benefit would be meaningless.

The problem is that the YCbCr color space is much wider than the RGB color space, so, when you have the same bit depth on both, only a small portion of the YCbCr space is used compared with the RGB. For example, in the case of our video sources with an 8 bit bit depth, only less than 25% of the YCbCr space is used. So, increasing it further like you suggest would be pointless, because you would end up with even more unused space.

21st April 2011, 22:45

Can anybody tell me how to convert a ICC/ICM file (of calibrated monitor) to something yCMS can read to make a LUT?

yesgrey

21st April 2011, 23:07

Can anybody tell me how to convert a ICC/ICM file (of calibrated monitor) to something yCMS can read to make a LUT?
Please do a search on this thread. I think someone already asked that question before and someone told him how...

21st April 2011, 23:39

Please do a search on this thread. I think someone already asked that question before and someone told him how...
I did, and I found the question, but no answer (at least no answer I understand, I´m not familiar with argyllcms).

janos666

22nd April 2011, 00:03

I did, and I found the question, but no answer (at least no answer I understand, I´m not familiar with argyllcms).

Use the wxProfileDump tool to read out the XYZ coordinates of your primaries.
If it's a "matrix+curve(s)" profile than you can try to use the numerically defined curve(s) too (it may needs some re-structuring in excel first).
If it's a "matrix+gamma(s)" profile then you can try to use the gamma value(s) too. (But don't ask me how to average the values, may be linear math is acceptable as it's not a perfectly precise number to start with.)

* Sorry, but I am still not sure if you need to reverse the chromatic adaptation or not. (You theoretically don't because yCMS asks for the white point too but I am not sure how it actually handles it, so... ; try to use your original numbers first...)

22nd April 2011, 00:57

Use the wxProfileDump tool to read out the XYZ coordinates of your primaries.Done.
If it's a "matrix+curve(s)" profile than you can try to use the numerically defined curve(s) too (it may needs some re-structuring in excel first).
If it's a "matrix+gamma(s)" profile then you can try to use the gamma value(s) too. (But don't ask me how to average the values, may be linear math is acceptable as it's not a perfectly precise number to start with.)
I´m not sure. It contains the "chromaticAdaptionTag" with a 3x3 Matrix and a gamma table for gpu ("vcgt" tag), as well as a gamma info for all colors (which is 2.1993 for all).
What should I do with this and what do you mean with re-structuring?
* Sorry, but I am still not sure if you need to reverse the chromatic adaptation or not. (You theoretically don't because yCMS asks for the white point too but I am not sure how it actually handles it, so... ; try to use your original numbers first...)Please explain

Thanks

janos666

22nd April 2011, 12:03

gamma info for all colors (which is 2.1993 for all).

It's a "matrix+gamma" profile then. You can use this gamma value with the Output_Transfer_Function command in your yCMS input file as follows:
Output_Transfer_Function 1.0 0.0 0.455 0.0
And I suggest to use it in conjunction with this:
Input_Transfer_Function 1.0 0.0 0.4166666666666667 0.0
It will change your perceived gamma to 2.4 which is better for movies than 2.2 (2.2 was your calibration target which is good for usual PC usage but also common for most HDTVs too...).
Or leave it as:
Input_Transfer_Function 1.0 0.0 0.45 0.0
This means gamma 2.2, but I don't suggest yCMS's default behavior (the Inverse-Rec709-Encode curve when you don't specify anything manually ; but you are free to try...).

Please explain

The ICC standards chose the D50 illuminant as standard reference white point. This means that every color coordinates in every ICM files are relative to this illuminant (*).

However, the HDTV (just like NTSC, PAL, etc) is based on the D65 illuminant.
This means that you can calibrate your display to D65 but the profiler will chromatically adapt the color coordinates to be relative to D50.

* The Lab space which is used in the ICM profiles uses limited range of integer values and it's always relative to D50, that's sure (it's limited in absolute size too, so my display cannot be characterized by this profile type).
But... I think the XYZ space is absolute and you always have absolute XYZ coordinates in every profile. The only relativism in this space is that your primaries are relative to the measured white (not a standard illuminant, but the actual display white). I am not sure. That's why I like to use the ArgyllCMS output directly where I have control over the conversion between the spectral readings and XYZ values and nothing is adapted to anything (yet).

22nd April 2011, 12:05

That was my first try (primaries from profiledump), I used Output_Transfer_Function 5 because gamma is set to 2.2 (AdobeRGB) and corrected by graphics card lut:
Output_Primaries 0.6060 0.2733 0.2255 0.6824 0.1327 0.0443 0.3127 0.3290
Output_Transfer_Function 5
Output_Matrix_Coefficients 0
Output_Range 0 255
Output_Bit_Depth 16But colors are not fitting, looking very different from other calibrated applications or MPC+EVR+Colorspace. But it´s correct that madVR does not circumvent the gamma correction by graphics card?

janos666

22nd April 2011, 12:13

But it´s correct that madVR does not circumvent the gamma correction by graphics card?

No, it's the same as EVR, both leave the VGA LUT as is.
The latest MPC-HC from Janwillem's mediafire folder works well. I am currently using that instead of madVR (until yCMS will support white point correction).

yesgrey

22nd April 2011, 12:44

And I suggest to use it in conjunction with this:
Input_Transfer_Function 1.0 0.0 0.4166666666666667 0.0
It will change your perceived gamma to 2.4 which is better for movies than 2.2 (2.2 was your calibration target which is good for usual PC usage but also common for most HDTVs too...).
I suggest you to use the Input_Format command instead, and, if you want to try other gamma values, use the Gamma_Curve command. It will give you the same results and it will keep your config file cleaner.

I think the XYZ space is absolute and you always have absolute XYZ coordinates in every profile. The only relativism in this space is that your primaries are relative to the measured white (not a standard illuminant, but the actual display white).
The XYZ (and Yxy) space is an absolute space, so no correction is needed, you simply use those values and you will be fine.

The primaries are not relative to the white point. The primaries and the white point define a certain color space. You can have two displays with the same primaries and different white points. That means that you will need to map your source colors differently, because the output color spaces are different, as simply as that. So, you don't need to chromatically adapt any colors, as long as you tell yCMS the respective white point.

Output_Primaries 0.6060 0.2733 0.2255 0.6824 0.1327 0.0443 0.3127 0.3290

Are you sure about these primaries and white point?

22nd April 2011, 13:07

Are you sure about these primaries and white point?
The primaries are exactly those from wxProfileDump (red/green/blueColorantTag). The whitepoint, I´m not sure. The VGA Lut corrects it to 6500K, so I used the values for that, but there is also a mediaWhitePointTag: X=0.9642, Y=1.0000, Z=0.8249
But that values won´t work at all.

janos666

22nd April 2011, 13:24

yesgrey

22nd April 2011, 14:01

The primaries are exactly those from wxProfileDump (red/green/blueColorantTag).
Post the exact values, so I can see them.

The VGA Lut corrects it to 6500K, so I used the values for that
I know it might not be an option for you, but you would get better results if you use only yCMS for fixing the colors without letting the VGA Lut correcting anything... that might be your problem.

22nd April 2011, 14:13

The values in the profile are normalized to Y=1. Use the exact values from the profile, like this (don't bother about the decimal point, leave it as is) R, G, B, W (note the different command and the "2" which means XYZ):
Gamut_Measurements 2
53.8560000 24.4000000 0.87808000
20.6750000 68.2460000 9.62860000
21.2020000 7.85660000 111.610000
95.2260000 100.010000 121.310000
Where do I get those values from? I have a luminaceTag which is not normalized, but all other values are.

Post the exact values, so I can see them.
R/G/B XYZ:
0.6060 0.2733 0.0083
0.2255 0.6824 0.0901
0.1327 0.0443 0.7264
I know it might not be an option for you, but you would get better results if you use only yCMS for fixing the colors without letting the VGA Lut correcting anything... that might be your problem.If there is an option in madVR bypassing VGA lut, no problem.
But I tried disabling VGA lut, it still doesn´t look correct.

yesgrey

22nd April 2011, 18:07

R/G/B XYZ:
0.6060 0.2733 0.0083
0.2255 0.6824 0.0901
0.1327 0.0443 0.7264

OK. I see what's your problem... The Output_Primaries command expects x,y values from xyY, and you are using X, Y values from XYZ, and they are not the same.

Try to use this command instead of the Output_Primaries one:
Gamut_Measurements 2
0.6060 0.2733 0.0083
0.2255 0.6824 0.0901
0.1327 0.0443 0.7264
0.9642 1.0000 0.8249
And test it disabling the vga LUT.

janos666

22nd April 2011, 19:08

He shouldn't disable the VGA LUT because it will cause him to loose the known gamma 2.2 TRC and the gamut emulation won't be correct either (so nothing will be correct).

@xv
You already have these values. They are divided by the white luminance but that doesn't matter, just insert them and use the WP from yesgrey's post.

22nd April 2011, 19:12

I already tried exactly those values for Gamut_Measurements, did not work.
I calculated the xy values from XYZ, that seems to work!
The image is a bit brighter than in GIMP, but that could be the different conversion (loaded in avisynth, ConvertToRGB24(Matrix="Rec709"), opened in Virtualdub, copy/paste to color-managed GIMP), but colors are ok. Disabling VGA LUT makes everything a lot worse.
Input_Format HD YCbCr 8
Output_Primaries 0.68274 0.307909 0.225952 0.683768 0.14689 0.049037 0.3127 0.3290
Output_Transfer_Function 5
Output_Matrix_Coefficients 0
Output_Range 0 255
Output_Bit_Depth 16
Is it everything I have to do? iColor (the color management software I use) measured hundreds of colors and all I need is this 6 values? Or is everything else done in VGA LUT? Output_Transfer_Function 5 is correct when my VGA LUT is expecting gamma 2.2 (not sRGB gamma)?

yesgrey

22nd April 2011, 22:15

He shouldn't disable the VGA LUT because it will cause him to loose the known gamma 2.2 TRC and the gamut emulation won't be correct either (so nothing will be correct).
Yes, you're right, I forgot he was using the Output_Transfer_Function to match the lut gamma.

I already tried exactly those values for Gamut_Measurements, did not work.
Strange...

Is it everything I have to do? iColor (the color management software I use) measured hundreds of colors and all I need is this 6 values? Or is everything else done in VGA LUT?
Yes, the rest is done in the VGA LUT.

However, you can also do everything with yCMS. Disable the VGA 3dlut, measure the grayscale and your display primaries with your meter, and use them to create a 3DLUT that will match your display.

Output_Transfer_Function 5 is correct when my VGA LUT is expecting gamma 2.2 (not sRGB gamma)?
Well, the best one would be 3, because 5 is for AdobeRGB which has a gamma value of 2.19921875.

yesgrey

22nd April 2011, 22:43

I already tried exactly those values for Gamut_Measurements, did not work.
The whitepoint, I´m not sure. The VGA Lut corrects it to 6500K, so I used the values for that, but there is also a mediaWhitePointTag: X=0.9642, Y=1.0000, Z=0.8249
But that values won´t work at all.
I've confirmed, the mediaWhitePointTag value is the same as D50. So, if the LUT is correcting the display white point to D65 that's the one you should use, hence why you got it right when you converted the XYZ coordinates to xyY and then used the D65 white points coordinates.

If you want to use the Gamut_Measurements commands here are the D65 white point coordinates in XYZ: 0.95047 1.00000 1.08883

janos666

23rd April 2011, 00:17

Was your calibration target D50 or D65 (~5000K or ~6500K)? [You should consider to change it to D65 if it was D50, unless you do some print jobs or anything like that...]

But may be it's a profiler bug: Did I tell about the "ICC is relative to D50" issue or didn't I? It's a complete mess because not every profiler software can do the things right. (Some of them will assume that the display WP is an illuminant and guess what is the default illuminant if not D50...)

I think you should use the search and figure out how to use ArgyllCMS to get the yCMS inputs. I have many posts about these things in this forum section. (But ArgyllCSM is better anyway, you should use it for simple VGA LUT calibration too.)

23rd April 2011, 00:51

However, you can also do everything with yCMS. Disable the VGA 3dlut, measure the grayscale and your display primaries with your meter, and use them to create a 3DLUT that will match your display.Does that give me any advantage/quality improvement? As the VGA lut cannot be circumvented by madVR I would have to disable it everywhere, but programs using icc profiles need it.
Well, the best one would be 3, because 5 is for AdobeRGB which has a gamma value of 2.19921875.I calibrated for AdobeRGB and in the icc file it says gamma 2.1992, so 5 is the correct choice :)
Does this small difference matter anyway?
I've confirmed, the mediaWhitePointTag value is the same as D50. So, if the LUT is correcting the display white point to D65 that's the one you should use, hence why you got it right when you converted the XYZ coordinates to xyY and then used the D65 white points coordinates.

If you want to use the Gamut_Measurements commands here are the D65 white point coordinates in XYZ: 0.95047 1.00000 1.08883Is there any advantage/difference when using Gamut_Measurements?

Was your calibration target D50 or D65 (~5000K or ~6500K)? [You should consider to change it to D65 if it was D50, unless you do some print jobs or anything like that...]Monitor is set to 6500K, but it does not fit perfectly, so the LUT corrects it, I calibrated for 6500K and gamma 2.2 (AdobeRGB).
But may be it's a profiler bug: Did I tell about the "ICC is relative to D50" issue or didn't I? It's a complete mess because not every profiler software can do the things right. (Some of them will assume that the display WP is an illuminant and guess what is the default illuminant if not D50...)I´m not sure I understand that correctly, but yesgrey said the mediaWhitePointTag was D50.I think you should use the search and figure out how to use ArgyllCMS to get the yCMS inputs. I have many posts about these things in this forum section. (But ArgyllCSM is better anyway, you should use it for simple VGA LUT calibration too.)I want color management not only in madVR, but also in other applications by using the profile and the VGA LUT (I think thats the only way) and I don´t want to reconfigure everything when I´m going to watch a video. Is there another way to achieve that? So what is the advantage of ArgyllCMS? Is it more precise? Is there a tutorial how to create icc profile and vga lut?

janos666

23rd April 2011, 01:54

This is what I do:
I use my display's built-in sRGB mode (real sRGB gamut emulation in hardware ; good but not perfect) for every software which doesn't have high quality color management. But this is not an option for you, so move along...
I calibrate the Standard display mode to native gamma (~1.72) and white point (~6300K) and use it with softwares like MPC-HC and PhotoShop. The VGA LUT is almost linear, so there is no any banding, and the softwares do what they must (correct the gamut, gamma and white point -> so everything what they can, as much as they can...).

Oh well, I will write something for you but I am sure this is a redundant post. :)

- Set your display back to factory defaults
- Disable every fancy features like dynamic contrast, ECO mode, EXTRA SUPER MASTER ALIEN UFO TECH FOR COLOR AND FREE HONEY AND HORES, etc (I think you get it...)
- Set your brightness to a comfortable value (use your eyes, not your sensor)
- Use a 8-bit gray gradient (full 256 step version) to check if your display offers as much different color shades as it can (max 255) -> play with your contrast settings if you must...
- Leave the display OSD alone (don't even think about using the RGB Gains unless you have a professional display like NEC, EIZO, etc) and run a calibration with ArgyllCMS/dispcal, using DispcalGUI
- Create a "Single gamma + matrix" profile with ArgyllCMS/colprof using DispcalGUI

Recommended calibration settings:
- Choose native gamma and native WP if you plan to use your display mostly with softwares which offer high quality color management (very few, most of them does terrible things in the name of "performance" and it's actually worse than no correction - like firefox...)
- Choose gamma 2.2 and 6504K if you want fairly good colors in softwares without color management capability too.
- 100% black output offset, 0% black point correction (keep the 4.0 rate), native black and native white luminance.
- NO ambient light adaptation.

If you chose to correct your WP then you can use the current yCMS version but I recommend to use MPC-HC with "absolute colorimetric rendering intent" if you didn't (this mode will correct the white point too).
You will find the XYZ measurements in a directory under [systempartition]:\Users\[username]\appdata\rouming\dispcalgui\[projectname]\*.ti3
The default test palette will be fine to get the primaries and WP.

* You can use the "Report on uncalibrated display" function in DispcalGUI to find your current gamma if you plan to use it as a target.

** I recommend to use native (yes, even native gamma and white point) targets because it will probably preserve the most color shades and offer the highest possible contrast ratio while this is the most flexible setup. (It honors the native display characteristics but every source profile can be different, so you will never be in he situation where you do "correction" against yourself and end up worse than "no corrections"...)

yesgrey

23rd April 2011, 12:03

Does that give me any advantage/quality improvement?
The VGA LUTs are 10bit per channel, and madVR uses a 16 bit 3DLUT dithered to 8bit, which should give a slightly more precise result.

I calibrated for AdobeRGB and in the icc file it says gamma 2.1992, so 5 is the correct choice :)
Does this small difference matter anyway?
OK. No, such a small difference doesn't matter, but if you can use the right value why using another one instead? ;)

Is there any advantage/difference when using Gamut_Measurements?
No. It would only save you the trouble of converting from XYZ->xyY, but you already did it. :)

janos666

23rd April 2011, 13:08

The VGA LUTs are 10bit per channel, and madVR uses a 16 bit 3DLUT dithered to 8bit, which should give a slightly more precise result.

Yes, but the subjective result after a calibration with ArgyllCMS/dispcal is much better than yCMS alone.

For example, I already told you that I find the black point compensation too heavy (the black remains black but the next few gray shades are way too bright, the luminance increases too fast between the near-black shades).
The black output offset in dispcal is much milder.

I repeat this because I remember that one of your displays (a CRT) had serious banding issues which you didn't really recognize as a hardware error... so may be you should consider to take a look at it and may be reconsider your black point compensation method.

(May be it's a problem with my sensor's low luminance accuracy which is somehow compensated by ArgyllCMS. Doesn't matter until dispcal gives me good results repeatably but yCMS gives "overcompensation" repeatably.)

Another noticeable thing that lcms (in MPC-HC ; with numerical curve or YXZ LUT type profiles) gives me subjectively bad results too but that shows me too dark gray shades instead of too bright grays (they are still distinguishable in a dark room with highly increased back-light luminance and special test patterns but it looks like a serious near-black banding during normal viewing and makes every scenes look like twilight scenes...).

And both dispcal and lcms let me correct the white point (in the 1D VGA LUT or in the software 3DLUT) if I want to (yes, I know, it's "under development" and I appreciate your work but until then...).

yesgrey

23rd April 2011, 13:24

For example, I already told you that I find the black point compensation too heavy (the black remains black but the next few gray shades are way too bright, the luminance increases too fast between the near-black shades).
OK. I will look into it.

I repeat this because I remember that one of your displays (a CRT) had serious banding issues which you didn't really recognize as a hardware error...
This will make it harder for me to fix the problem, because I won't be able to see any difference, but I will try. I'm sure I could count on you to test it. ;)

And both dispcal and lcms let me correct the white point (in the 1D VGA LUT or in the software 3DLUT) if I want to (yes, I know, it's "under development" and I appreciate your work but until then...).
Yes, I'm working on it...

23rd April 2011, 16:20

This is what I do:
I use my display's built-in sRGB mode (real sRGB gamut emulation in hardware ; good but not perfect) for every software which doesn't have high quality color management. But this is not an option for you, so move along...
I calibrate the Standard display mode to native gamma (~1.72) and white point (~6300K) and use it with softwares like MPC-HC and PhotoShop. The VGA LUT is almost linear, so there is no any banding, and the softwares do what they must (correct the gamut, gamma and white point -> so everything what they can, as much as they can...).I'm using Standard Mode with white point set to 6500K and gamma 2.2 (default settings).
Oh well, I will write something for you but I am sure this is a redundant post. :)

- Set your display back to factory defaults
- Disable every fancy features like dynamic contrast, ECO mode, EXTRA SUPER MASTER ALIEN UFO TECH FOR COLOR AND FREE HONEY AND HORES, etc (I think you get it...)
- Set your brightness to a comfortable value (use your eyes, not your sensor)
- Use a 8-bit gray gradient (full 256 step version) to check if your display offers as much different color shades as it can (max 255) -> play with your contrast settings if you must...
- Leave the display OSD alone (don't even think about using the RGB Gains unless you have a professional display like NEC, EIZO, etc) and run a calibration with ArgyllCMS/dispcal, using DispcalGUI
- Create a "Single gamma + matrix" profile with ArgyllCMS/colprof using DispcalGUI

Recommended calibration settings:
- Choose native gamma and native WP if you plan to use your display mostly with softwares which offer high quality color management (very few, most of them does terrible things in the name of "performance" and it's actually worse than no correction - like firefox...)
- Choose gamma 2.2 and 6504K if you want fairly good colors in softwares without color management capability too.
- 100% black output offset, 0% black point correction (keep the 4.0 rate), native black and native white luminance.
- NO ambient light adaptation.Thanks! ArgyllCMS seems to be a lot better than iColor, I did not modify anything in the monitor osd, used gamma 2.2 / 6504K (not native). The curves seem to be very similar to those in iColor and the primaries are about the same, it looks much better.
If you chose to correct your WP then you can use the current yCMS version but I recommend to use MPC-HC with "absolute colorimetric rendering intent" if you didn't (this mode will correct the white point too).
You will find the XYZ measurements in a directory under [systempartition]:\Users\[username]\appdata\rouming\dispcalgui\[projectname]\*.ti3
The default test palette will be fine to get the primaries and WP.Isn´t that done by VGA lut?
** I recommend to use native (yes, even native gamma and white point) targets because it will probably preserve the most color shades and offer the highest possible contrast ratio while this is the most flexible setup. (It honors the native display characteristics but every source profile can be different, so you will never be in he situation where you do "correction" against yourself and end up worse than "no corrections"...)Native doesn´t look that good. Also my monitor is set to to same settings, all it does is to slightly correct.
The VGA LUTs are 10bit per channel, and madVR uses a 16 bit 3DLUT dithered to 8bit, which should give a slightly more precise result.My monitor is connected via DisplayPort and supports 10 bit, when madVR dithers down to 8 bit that would reduce quality, cause VGA lut stays 10 bit and is dithered down to 8 bit in the monitor (FRC)?
No. It would only save you the trouble of converting from XYZ->xyY, but you already did it. :)That´s not too difficult. But it would be still great if you could implement reading primaries and transfer function from an icc file in some future version, that would make things a lot easier after recalibration.

yesgrey

24th April 2011, 15:38

when madVR dithers down to 8 bit that would reduce quality, cause VGA lut stays 10 bit and is dithered down to 8 bit in the monitor (FRC)?
I don't think so. Since the bit depth has already been converted, I guess another dithering step would not hurt that much, however, it would be preferable to avoid it. Maybe one day madshi decide to add 10 bit output to madVR and that would not be a problem anymore.

Damien147

24th April 2011, 22:27

xv's question and the last posts helped me too(same situation):thanks: Bye bye evr for now:p

I just added this to the templates and then enabled 3dlut for madvr to create it:

Gamut_Measurements 2
0.60117 0.30779 0.01680
0.22330 0.63179 0.06697
0.13971 0.06039 0.74110
0.96419 1.00000 0.82489

That's all,right?

25th April 2011, 00:52

I don't think so. Since the bit depth has already been converted, I guess another dithering step would not hurt that much, however, it would be preferable to avoid it. Maybe one day madshi decide to add 10 bit output to madVR and that would not be a problem anymore.
I´m not sure madVR dithers down to 8 bit, changelog says for v0.3:
* if 10bit textures are not available, 8bit textures are used insteadDoesn´t that mean madVR is using 10 bit output when possible, also from features list:
- final 16bit processing result is dithered down to RGB output bitdepth
Unfortunately I was unable to create a 10 bit source for madVR to test (I created a nice 16-bit tiff with a greyscale ramp in photoshop that is displayed fine there (using 10 bit output), but shows major banding in IrfanView and even worse in Gimp), any idea how to convert that into a video? Tried with ffmpeg, but all created files cannot be played.

That also leads me to another question: If the source is 10 Bit, the lut of ycms wouldn´t work anymore, because it takes 8 bit input. A 10->16 Bit 3dlut would also be somewhat impossible, because it would be about 64 times larger than a 8->16 bit lut (6GB vs. 96MB).

And of course :thanks: to yesgrey and janos666 for helping me getting this working so far, you helped me a lot and least one other person too :)

yesgrey

25th April 2011, 02:03

I´m not sure madVR dithers down to 8 bit
Trust me, it does. I think madshi intends to add 10 bit output support (16 bit dithered to 10 bit) to madVR, but it might take some time... only he can say for sure.

Unfortunately I was unable to create a 10 bit source for madVR to test (I created a nice 16-bit tiff with a greyscale ramp in photoshop that is displayed fine there (using 10 bit output), but shows major banding in IrfanView and even worse in Gimp), any idea how to convert that into a video?
Well, there is the possibility of using x264 10 bit, but I don't know if there is already any h264 10 bit decoder available... Another possibility would be madshi to add support for 16 bit images, but I don't know if that would be very hard to do or the wrong place to do it.

That also leads me to another question: If the source is 10 Bit, the lut of ycms wouldn´t work anymore, because it takes 8 bit input.
That's not a problem. madVR uses tri-linear interpolation to increase the input precision, and the results are very good.

A 10->16 Bit 3dlut would also be somewhat impossible, because it would be about 64 times larger than a 8->16 bit lut (6GB vs. 96MB).
And would be useless. With a 16 bit output 3DLUT you will not gain any precision by using more than 8 bit input 3DLUTs, compared with an 8 bit input one with tri-linear interpolation.

And of course :thanks: to yesgrey and janos666 for helping me getting this working so far, you helped me a lot and least one other person too :)
You're welcome. :)

yesgrey

25th April 2011, 02:05

I just added this to the templates and then enabled 3dlut for madvr to create it:

Gamut_Measurements 2
0.60117 0.30779 0.01680
0.22330 0.63179 0.06697
0.13971 0.06039 0.74110
0.96419 1.00000 0.82489

That's all,right?
I don't think so. Your last line might be wrong... at least with xv it didn't work OK. Is your display white point D50, or D65?

Damien147

25th April 2011, 12:06

I don't think so. Your last line might be wrong... at least with xv it didn't work OK. Is your display white point D50, or D65?

It's D65.The pics are with color management on.

evr (http://i.imgur.com/BATkb.png) madvr (http://i.imgur.com/cGwUz.png)

With black clipping test pattern I don't notice any change with 3dlut on or off,is this good or bad?

yesgrey

25th April 2011, 12:22

It's D65.
So, you should use as your last line the D65 coordinates: 0.95047 1.00000 1.08883

With black clipping test pattern I don't notice any change with 3dlut on or off,is this good or bad?
You need to tell me what's the black clipping test pattern...

Damien147

25th April 2011, 12:54

So, you should use as your last line the D65 coordinates: 0.95047 1.00000 1.08883

To tell everything osd settings are changed also(rgb,brightness,contrast.white point set at 6500k).In general you mean that I should use the standard coordinates of d65 and not the ones provided by my profile.right?

You need to tell me what's the black clipping test pattern...

Downloaded from here (http://www.avsforum.com/avs-vb/showthread.php?t=948496) and looks like this (http://i.imgur.com/0IH07.png)

yesgrey

25th April 2011, 17:58

To tell everything osd settings are changed also(rgb,brightness,contrast.white point set at 6500k).In general you mean that I should use the standard coordinates of d65 and not the ones provided by my profile.right?
In general you should use the measured white point, but if you cannot do it probably you would be safer using D65 than the one provided by the profile, because according to Janos666 that value might be wrong...

With black clipping test pattern I don't notice any change with 3dlut on or off,is this good or bad?
Downloaded from here
OK, it's the AVSForum one.

It's natural that you cannot see any difference. Unless your grayscale was very bad, or you were using a different levels setting, you should get more or less the same results.

Damien147

26th April 2011, 01:31

In general you should use the measured white point, but if you cannot do it probably you would be safer using D65 than the one provided by the profile, because according to Janos666 that value might be wrong...

The word might is killing me:confused::p
I wanted to try mpc hc with absolute colorimetric rend. intent that Janos666 mentioned for comparison but when checked white became bluish(mpc hc 1.5.2.3052).
I will leave it as it is untill I find a proper way to check it.Thank you very much for your time.

janos666

26th April 2011, 02:42

In that post, I also suggested to use ArgyllCMS because [colprof] creates proper ICM profiles (with correct white point).
Another alternative is to choose D50 as calibration target (foolish idea, but should work as a "workaround" for the profiler bug, just to see that the problem is in the profiler software...).

Damien147

28th April 2011, 12:36

http://www.luminous-landscape.com/forum/index.php?topic=45161.0

The "wtpt" (media white point) tag of a display profile should be D50 regardless of what the actual white point is. To quote from the ICC spec here:

http://color.org/ICC1v42_2006-05.pdf

"For displays, the values specified must be those of D50 normalized such that Y = 1,0 (i.e. 0,9642 1,0 0,8249)."

The actual white point of the display gets encoded into the "chad" chromatic adaptation matrix tag, and this is not something that you can easily reverse to see the value.

http://color.org/ICC1v42_2006-05.pdf
page 33
The Profile Connection Space illuminant field shall contain the CIEXYZ values of the illuminant used for the Profile Connection Space encoded as an XYZNumber. At present the only illuminant permitted for the Profile Connection Space is D50 (where X= 0,9642; Y = 1,0 and z=0,8249)

page 47

9.2.25 mediaWhitePointTag
Tag signature: ‘wtpt’ (77747074h)
Allowed tag type: XYZType
This tag, which is used for generating ICC-absolute colorimetric intent, specifies the XYZ tristimulus values of the media white point. If the media is measured under an illumination source which has a chromaticity other than D50, the measured values must be adjusted to D50 using the chromaticAdaptationTag matrix before recording in the tag. For reflecting and transmitting media, the tag values are specified relative to the perfect diffuser (which is normalized to a Y value of 1,0) for illuminant D50. For displays, the values specified must be those of D50 normalized such that Y = 1,0 (i.e. 0,9642 1,0 0,8249).

So there's nothing wrong with the white point tag(which has D50 values) but what you are saying is that I should use the "chad" chromatic adaptation matrix tag.Right?

janos666

28th April 2011, 19:54

I am not sure but may be that tag only exists on V4 profiles. And the media white point is sometimes broken in some profiles (profiler bug).

If the absolute colorimetric intent failed in MPC-HC then there is a problem with your profile! If it's bluish then your media white point was recorded as D50 instead of D65.

I spent some time with rewriting the CMS related stuff in the MPC-HC code.
I always tested the results with a profile which I made for my display which was calibrated to "native" white point (~6300K). The absolute colorimetric intent was able to correct the WP to D65.

But make sure you use one of JanWillem's test build (only those builds contain my changes right now) but at least choose a fresh daily build of the official SVN (which has the updated lcms GIT version).
-> I reported a bug to Matri (the author of LittleCMS) which he fixed in a GIT release of lcms. (There was a problem with the absolute colorimetric intent.)

Damien147

28th April 2011, 21:44

But make sure you use one of JanWillem's test build (only those builds contain my changes right now)

I just did and everything's fine ,no bluish thingy:D

So...edit:I was wrong and this is right I don't think so. Your last line might be wrong... (but nothing changes either with D65 coordinates by the way)
Am I missing any other parameter?I don't know.I tried Gamut_Measurements 1 also and had the same result,then I copied what xv did(thanks mate) and white point correction is obvious.I had "muddy" image compared to what I see now in some occasions and with black clipping test pattern there's a slight improvement.The image is indeed is a bit brighter as xv mentioned.

Input_Format HD YCbCr 8
Output_Primaries 0.649380 0.332473 0.242175 0.685194 0.148438 0.064163 0.345702 0.358541
Output_Transfer_Function 3
Output_Matrix_Coefficients 0
Output_Range 0 255
Output_Bit_Depth 16

Thank you!:)

Damien147

30th April 2011, 18:07

Update!I don't know if you're gonna say no sh*t sherlock but I found out what was missing from Gamut_Measurements and the last line had no effect.You have to add Output_Transfer_Function.That's why me and xv had no results with white point values.
So the correct one for me to just add to the default templates is:

Output_Transfer_Function 3
Gamut_Measurements 2
0.60117 0.30779 0.01680
0.22330 0.63179 0.06697
0.13971 0.06039 0.74110
0.96419 1.00000 0.82489
I'm quite happy with the result:)

pics with 3dlut off (http://i.imgur.com/1q5Tv.png) and on (http://i.imgur.com/TXEhd.png)

xv can you test it please?
Here's yours with your values

Output_Transfer_Function 3
Gamut_Measurements 2
0.6060 0.2733 0.0083
0.2255 0.6824 0.0901
0.1327 0.0443 0.7264
0.9642 1.0000 0.8249

janos666

30th April 2011, 18:12

I won't say that. I say we told it at the beginning and x.v. did it already.

Damien147

30th April 2011, 18:26

I'm sorry then,I got confused by these posts
The values in the profile are normalized to Y=1. Use the exact values from the profile, like this (don't bother about the decimal point, leave it as is) R, G, B, W (note the different command and the "2" which means XYZ
I already tried exactly those values for Gamut_Measurements, did not work.I calculated the xy values from XYZ, that seems to work!
and missed that.

Yellow_

3rd May 2011, 16:27

yesgrey, are you looking at adding support for Log space at all, for Log to Rec709 for example?

yesgrey

3rd May 2011, 23:02

yesgrey, are you looking at adding support for Log space at all, for Log to Rec709 for example?
I never thought about it, but I could. As long as I know which are the specifications. But I guess that you might add it as a custom mode...

Yellow_

4th May 2011, 08:04

Yes a custom mode would be useful, I know you'll probably laugh but a company called Technicolor has released a camera curve profile for Canon DSLRs that supposedly takes the RAW sensor data which I doubt and convert it to LOG space supposedly worked close with Canon to do this and they offer a LUT nothing more than a RGB curve file to convert LOG to REC709 but the curve file is only about 10kb and they describe it as a LUT :-) Look up table it is but.....

yesgrey

6th May 2011, 12:24

Can anybody please send me an icc or icm profile for testing purposes? I'm considering to add some kind of support for it in yCMS and I would like some sample files.

Thanks.

Damien147

6th May 2011, 17:30

Great!!!!

@yesgrey
http://www.tftcentral.co.uk/articles/icc_profiles.htm

yesgrey

6th May 2011, 19:24

Thanks.:)

janos666

6th May 2011, 20:36

Look up table it is but.....

1D lookup -> perfect for TRC description if you have constant primaries.
Big 3DLUTs are only necessary if you need to do HQ CMS on many big images in real-time (like madVR does with HD video) or you have a non-additive device (weird digital processing in the user's device).

Yellow_

7th May 2011, 08:19

1D lookup -> perfect for TRC description if you have constant primaries.
Big 3DLUTs are only necessary if you need to do HQ CMS on many big images in real-time (like madVR does with HD video) or you have a non-additive device (weird digital processing in the user's device).

janos666 thank you for info again, I'd read recently whilst looking at Sony Imageworks open source OpenColorIO CMS that 1D are ideal for the task and reversible without loss but I assume that it is with regard to same colour space, ie RGB or YCbCr.

The HD video source it's YCbCr? The Technicolor camera profile (transfer curve if I understand correctly) is loaded into the camera and gives a LOG space appearance to the video, applied before encoding to h264 .movs

Once the LOG space YCbCr is imported into the video editing app colour processing will be done RGB, the makers suggest applying the 1D LUT after import or grading the LOG appearance directly, this would be done on RGB data or could the 1D LUT be applied to YCbCr then converted to RGB for colour grading etc?

If I were going LOG YCbCR -> RGB with normal appearance, ie: non LOG, a 3D LUT would be more applicable / suitable?

Yellow_

7th May 2011, 11:05

Sorry if this is a bit off topic but theoretically, if it is possible to create a camera curve (is this a transfer curve?) to manipulate the linear data off a 12bit imaging sensor and create a LOG space output in a h264 mov file would it be possible in theory to create a curve which would map whatever LOG black level is to 1 in a YCbCr file and LOG white to 254 in that YCbCr file? In this situation what would need to happen to the U & V? Or are there other factors to consider?

Then use a codec such as FFMPEG which wouldn't mess with the levels on decompression and export to RGB at higher bit depth to provide room to manipulate those 8 bit levels up and down into a REC709 / sRGB image?

yesgrey

7th May 2011, 11:52

this would be done on RGB data or could the 1D LUT be applied to YCbCr then converted to RGB for colour grading etc?
The transfer functions are always applied in RGB color space, and then converted to YCbCr. So, in your case, first the YCbCr will be converted to RGB and only after that the removal of the LOG is performed.

Yellow_

7th May 2011, 15:49

The transfer functions are always applied in RGB color space, and then converted to YCbCr. So, in your case, first the YCbCr will be converted to RGB and only after that the removal of the LOG is performed.

Ok, great.

With regard to previous discussion about xvYCC and I know this is probably not your field of expertise, if it is possible to affect the linear data off a camera sensor with a custom transfer curve as it appears can be done with with the Canon DSLR, do you consider it theoretically possible to lay down 1 - 254 LOG or xvYCC data via a transfer curve into the h264 codec?

I know I'm pushing my luck here. :-)

fairchild

8th May 2011, 09:54

Can anybody please send me an icc or icm profile for testing purposes? I'm considering to add some kind of support for it in yCMS and I would like some sample files.

Thanks.

I just recently bought a meter (an i1DisplayLT to calibrate my TV's and PC monitors) and was wondering if there was a way to get yCMS working with the ICC file that it generated for my monitor.

Is there some easy way to pull the data from it and use that to map the coordinates to yCMS? I've always been curious of using MadVR with 3dlut file created by yCMS. Thanks in advance if someone at least can point me in the right direction.

This is the data from my ICC file:

KEYWORD "SampleID"
KEYWORD "SAMPLE_NAME"
NUMBER_OF_FIELDS 5
BEGIN_DATA_FORMAT
SampleID SAMPLE_NAME RGB_R RGB_G RGB_B
END_DATA_FORMAT
NUMBER_OF_SETS 42
BEGIN_DATA
1 A1 0.00 0.00 0.00
2 A2 0.00 0.00 128.00
3 A3 0.00 0.00 255.00
4 A4 0.00 128.00 0.00
5 A5 0.00 128.00 128.00
6 A6 0.00 128.00 255.00
7 B1 0.00 255.00 0.00
8 B2 0.00 255.00 128.00
9 B3 0.00 255.00 255.00
10 B4 128.00 0.00 0.00
11 B5 128.00 0.00 128.00
12 B6 128.00 0.00 255.00
13 C1 128.00 128.00 0.00
14 C2 128.00 128.00 128.00
15 C3 128.00 128.00 255.00
16 C4 128.00 255.00 0.00
17 C5 128.00 255.00 128.00
18 C6 128.00 255.00 255.00
19 D1 255.00 0.00 0.00
20 D2 255.00 0.00 128.00
21 D3 255.00 0.00 255.00
22 D4 255.00 128.00 0.00
23 D5 255.00 128.00 128.00
24 D6 255.00 128.00 255.00
25 E1 255.00 255.00 0.00
26 E2 255.00 255.00 128.00
27 E3 255.00 255.00 255.00
28 E4 0.00 0.00 32.00
29 E5 0.00 0.00 64.00
30 E6 0.00 0.00 160.00
31 F1 0.00 0.00 192.00
32 F2 0.00 0.00 224.00
33 F3 0.00 32.00 0.00
34 F4 0.00 64.00 0.00
35 F5 0.00 160.00 0.00
36 F6 0.00 192.00 0.00
37 G1 0.00 224.00 0.00
38 G2 32.00 0.00 0.00
39 G3 64.00 0.00 0.00
40 G4 160.00 0.00 0.00
41 G5 192.00 0.00 0.00
42 G6 224.00 0.00 0.00
END_DATA
text LGOROWLENGTH 6
CREATED "5/8/2011" # Time: 03:51
INSTRUMENTATION "eye-one display"
MEASUREMENT_SOURCE "Illumination=Unknown ObserverAngle=Unknown WhiteBase=Abs Filter=Unknown"
KEYWORD "SampleID"
KEYWORD "SAMPLE_NAME"
NUMBER_OF_FIELDS 8
BEGIN_DATA_FORMAT
SampleID SAMPLE_NAME XYZ_X XYZ_Y XYZ_Z LAB_L LAB_A LAB_B
END_DATA_FORMAT
NUMBER_OF_SETS 42
BEGIN_DATA
1 A1 0.17 0.17 0.20 1.50 0.55 -1.16
2 A2 1.72 0.88 8.58 7.91 27.52 -52.84
3 A3 7.37 3.66 39.16 22.51 46.18 -89.62
4 A4 2.91 6.12 1.30 29.72 -41.37 28.74
5 A5 4.52 6.85 9.95 31.47 -24.32 -16.97
6 A6 10.29 9.70 41.14 37.30 7.42 -66.71
7 B1 13.07 27.38 4.98 59.32 -67.80 51.41
8 B2 14.68 28.12 13.70 60.00 -60.60 21.09
9 B3 20.47 30.97 45.03 62.48 -40.01 -28.14
10 B4 4.34 2.40 0.29 17.47 33.60 24.60
11 B5 6.02 3.18 8.68 20.77 39.89 -31.03
12 B6 11.70 5.98 39.20 29.37 52.01 -77.85
13 C1 7.19 8.55 1.43 35.11 -9.84 36.33
14 C2 8.93 9.36 10.09 36.67 -0.84 -8.46
15 C3 14.72 12.22 41.24 41.57 19.09 -59.48
16 C4 17.59 30.37 5.21 61.97 -52.52 54.79
17 C5 19.37 31.19 13.92 62.67 -46.26 25.13
18 C6 25.19 34.06 45.23 65.01 -29.54 -24.02
19 D1 18.40 9.80 0.56 37.48 57.35 54.08
20 D2 20.48 10.78 8.93 39.21 60.37 -0.12
21 D3 26.24 13.62 39.38 43.69 66.74 -53.40
22 D4 21.28 15.99 1.71 46.96 30.79 53.64
23 D5 23.41 17.01 10.34 48.27 34.90 10.72
24 D6 29.30 19.91 41.46 51.74 44.16 -42.22
25 E1 31.75 37.92 5.49 67.96 -16.64 63.73
26 E2 33.90 38.94 14.19 68.71 -12.24 34.82
27 E3 39.82 41.88 45.45 70.79 -1.76 -14.32
28 E4 0.25 0.20 0.60 1.82 2.14 -8.23
29 E5 0.53 0.33 2.11 2.95 8.53 -26.24
30 E6 2.71 1.34 14.01 11.58 33.23 -63.20
31 F1 3.98 1.95 20.88 15.22 38.28 -72.68
32 F2 5.54 2.72 29.29 18.87 42.64 -81.51
33 F3 0.30 0.45 0.24 4.02 -5.22 2.39
34 F4 0.77 1.48 0.44 12.48 -22.53 13.29
35 F5 4.66 9.79 1.97 37.47 -48.40 34.64
36 F6 6.97 14.67 2.83 45.18 -55.43 40.48
37 G1 9.80 20.59 3.85 52.50 -61.95 46.08
38 G2 0.38 0.28 0.20 2.55 4.54 0.55
39 G3 1.12 0.68 0.21 6.13 17.75 6.53
40 G4 6.75 3.68 0.35 22.57 39.77 32.23
41 G5 10.12 5.46 0.42 28.00 46.21 40.37
42 G6 13.97 7.47 0.49 32.86 51.99 47.45
END_DATA
text Version = "ProfilingLib 5.0.6 1.75.16.2 May 31 2006"
ProfilerType = 3
GopMode = false
ProfileSize = 0
UseLinearization = 1
Perceptual = 1
Options = {
Copyright = "Copyright by LOGO GmbH, Steinfurt"
BlackCompensation = "0"
.MntrTargetGamma = "2.2"
.MntrTargetTemperature = "6500"
.MntrMinLuminance = "0.2"
.MntrLuminance = "42"
.MntrTemperatur = "6500"
MonitorGammaModel = "1"
}

Also a couple of questions. I'm new to using yCMS with MadVR, I followed the instructions and used the following to create an hd - video.3dlut file for MadVR to use based off my XYZ values from colorHCFR calibration for my plasma. This is the script I used:

# Example input file for yCMS v1.0 and up
#
# Settings for creating a 3DLUT file for watching the following Video formats:
# Blu-ray, HD DVD, ATSC HD Broadcast, DVB HD Broadcast
# without any Display correction
# Includes YCbCr->RGB conversion using Video Levels (Black: 16 and White: 235)

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_Video 16

# Gamut correction
Gamut_Measurements 2
29.337633 14.905519 0.311223
24.173937 48.360615 8.171843
11.6501 5.079493 61.377029
67.897636 71.366028 77.666367

# Grayscale correction
Grayscale_Measurements
20 2 5.633381 6.013391 6.206069
30 2 12.678645 13.380329 14.603946
40 2 21.888653 23.050667 24.894945
50 2 33.598476 35.463295 38.17054
60 2 45.89315 48.153221 52.76033
70 2 62.197613 65.305878 72.128578
80 2 77.689598 82.063866 89.158974
90 2 95.332352 100.23542 109.85508
100 2 112.380272 119.142937 128.697388

# Gamma correction
Gamma_Curve 0.0 2.22

My measured gamma was 1.76 during the calibration (I know it sucks, it's one of the bad parts of my Panasonic TC-P42S2 plasma). I added the Gamma_Curve at the end which should make my gamma better, but I don't really notice much of a difference with it or without it when I create the 3dlut file. My last question is, once I create the hd - video.3dlut file and put it in the MadVR directory do I need to do the same thing for the sd videos or should I use the automatically generated one that MadVR creates?

If I do need to create a sd - video.3dlut do I just use the same code for the hd version?

One other things I noticed is on the AVS HD 709 test patterns that I use to check my levels and that my calibration is still correct, I noticed the White Clipping test goes from being able to see up to the 252 bar, gets clipped down to the 247 bar. The Black Clipping test gets a bit darker, you can still see bar 17, but it's a bit less visible than without using the 3dlut file. And lastly, the Color Clipping test shows less clipping, where as without 3dlut I get some clipping sooner (this is a good thing I'd imagine).

Thanks a ton for this awesome program btw!

yesgrey

8th May 2011, 14:50

do you consider it theoretically possible to lay down 1 - 254 LOG or xvYCC data via a transfer curve into the h264 codec?
Does the h264 codec support 1-254 or does it support only 16-235?

yesgrey

8th May 2011, 15:18

I just recently bought a meter (an i1DisplayLT to calibrate my TV's and PC monitors) and was wondering if there was a way to get yCMS working with the ICC file that it generated for my monitor.
The ICC file usage I'm planning for yCMS would be more for people without any meter that want to convert their ICC files to a 3DLUT file that could be used with madVR. So, since you have a meter, I would advise you to take the necessary measurements and crreate a 3DLUT file directly from them instead.

I added the Gamma_Curve at the end which should make my gamma better, but I don't really notice much of a difference with it or without it when I create the 3dlut file.
Well, the Grayscale_Measurements command already compensates for your display gamma, turning it onto a BT.709 gamma curve. Comparing that with a 2.22 power curve the difference is not that big.
If you want to compare the "Gamma_Curve 0.0 2.22" against your display's natural gamma, set it to "Gamma_Curve 0.0 1.76". ;)

However, for serious watching you might also want to try using "Gamma_Curve 0.0 2.35", or "Gamma_Curve 1.0 2.35". Fine tune it to your personal taste and/or surrounding environment.

Yellow_

8th May 2011, 16:15

Does the h264 codec support 1-254 or does it support only 16-235?

From what I've read h264 is one of the only codecs that is said to support xvYCC and full luma certainly is supported. With regard to LOG I'm wondering that due to LOGs desaturated state that even 16 - 240 UV would probably be sufficient for chroma? IF h264 was found not to support 1 - 254 in the case of the camera in question.

yesgrey

8th May 2011, 17:23

From what I've read h264 is one of the only codecs that is said to support xvYCC and full luma certainly is supported.
If it supports xvYCC then it should support both full luma and chroma. However, even though the specs might support it you need to know if any of the available encoders support that part of the spec. ;)

With regard to LOG I'm wondering that due to LOGs desaturated state that even 16 - 240 UV would probably be sufficient for chroma?
No. The usage of the LOG or other kind of transfer function is to decrease quantization errors due to the limited bit depth available for the encoding. You will still need full support of chroma.

fairchild

8th May 2011, 23:43

The ICC file usage I'm planning for yCMS would be more for people without any meter that want to convert their ICC files to a 3DLUT file that could be used with madVR. So, since you have a meter, I would advise you to take the necessary measurements and crreate a 3DLUT file directly from them instead.

Well, the Grayscale_Measurements command already compensates for your display gamma, turning it onto a BT.709 gamma curve. Comparing that with a 2.22 power curve the difference is not that big.
If you want to compare the "Gamma_Curve 0.0 2.22" against your display's natural gamma, set it to "Gamma_Curve 0.0 1.76". ;)

However, for serious watching you might also want to try using "Gamma_Curve 0.0 2.35", or "Gamma_Curve 1.0 2.35". Fine tune it to your personal taste and/or surrounding environment.

Alright thanks for the responses. I'll try messing with different gamma curve values.

:thanks:

Yellow_

9th May 2011, 06:11

If it supports xvYCC then it should support both full luma and chroma. However, even though the specs might support it you need to know if any of the available encoders support that part of the spec. ;)

No. The usage of the LOG or other kind of transfer function is to decrease quantization errors due to the limited bit depth available for the encoding. You will still need full support of chroma.

Assuming the h264 does support chroma over whole range the camera curve manipulation is done by taking a RAW image from the camera and using HSL to manpulate the image into the desired apperance and then generate a camera curve Picture Style from that, sounds like this curve may work on gamma encoded data rather than linear off the sensor? Or not necessarily?

Based on that in theory do you think it possible to distribute the chroma / luma across full range in the h264?

Thank you for your comments.

yesgrey

9th May 2011, 16:33

sounds like this curve may work on gamma encoded data rather than linear off the sensor? Or not necessarily?
It's hard to believe that consumer level equipment would use linear on any step... the bit depths used are too low for that and it would result in high quantization errors.

do you think it possible to distribute the chroma / luma across full range in the h264?
It would be possible but not with a transfer function. A transfer function always keeps the same highest and lowest values (1.0 and 0.0). For what you want you would need to perform a range conversion, but I don't think it would be worth it...

Yellow_

9th May 2011, 21:02

It's hard to believe that consumer level equipment would use linear on any step... the bit depths used are too low for that and it would result in high quantization errors.

Ok, so HSL adjustments on gamma encoded source then encoding.
With regard to quantization errors, I've read a little about it following your last mention but where you commented that luma and chroma ranges should be in same range.

I assume this is at input into the encoder as many vidcams provide full luma in the encoded output and assume it is technically ok to use the full luma when converting to RGB even at 8 bit? Just a brighter more desaturated image? Or am I setting myself up for artifacts and anomolies. For example very common for NLEs to squeeze the full luma to 16 - 235 for conversion to RGB for a reason?

It would be possible but not with a transfer function. A transfer function always keeps the same highest and lowest values (1.0 and 0.0). For what you want you would need to perform a range conversion, but I don't think it would be worth it...

Would this be done by a HSL curve in camera, would a 1 - 254 LOG output be a posibility then?

fairchild

9th May 2011, 22:03

I got around to measure my display after applying 2.22 gamma boost with yCMS and this is what it looks like now (it was sitting at 1.76 average gamma without yCMS)

http://img228.imageshack.us/img228/7687/222gammaboost.jpg (http://imageshack.us/photo/my-images/228/222gammaboost.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

And this is the CIE chart

http://img828.imageshack.us/img828/764/cieycms.jpg (http://imageshack.us/photo/my-images/828/cieycms.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

And finally my RGB, the dE's got a bit worse, but I think ultimately the increased gamma and color's should make the picture look better overall. (my de's went from 0.3 to 2.7 from 30-100 IRE and now with yCMS they are 0.6 to 4.1)

http://img17.imageshack.us/img17/1153/rgbycms.jpg (http://imageshack.us/photo/my-images/17/rgbycms.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

yesgrey

11th May 2011, 09:36

I assume this is at input into the encoder as many vidcams provide full luma in the encoded output and assume it is technically ok to use the full luma when converting to RGB even at 8 bit?
Yes, it would be OK, but only if it is really full luma.

For example very common for NLEs to squeeze the full luma to 16 - 235 for conversion to RGB for a reason?
I guess the reason is simply to follow the most used standard.

Would this be done by a HSL curve in camera, would a 1 - 254 LOG output be a posibility then?
Yes.

yesgrey

11th May 2011, 09:49

I got around to measure my display after applying 2.22 gamma boost with yCMS and this is what it looks like now
If you could send me your hcfr result files for me to take a look I would appreciate that. My e-mail is in the manual, at the bottom.

the dE's got a bit worse
That's how it's supposed to be. The current yCMS version does not allow white point correction. It only allows chromatic adaptation to display's white point. Even though the perception of the colors would be right, the measurements would always be off.

I'm currently developing the white point correction so that it could measure well too, but I cannot give an ETA for it.

Yellow_

11th May 2011, 13:14

Yes, it would be OK, but only if it is really full luma.

I guess the reason is simply to follow the most used standard.

Yes.

Ok, thanks I'll try and find information on how to do a 'range conversion' with HSL curves and a suitable editor to make that as easy possible.

I guess it's not as simple as a basic calculation to generate the curves to go from HD camera source ie: BT709 primaries, BT601 matrix, full luma, to 1 - 254 LOG as a 'proof of concept' and test camera h264 encoding.

Then tweak the curves in an editor after for certain ranges like skin tone, high / low contrast scenes etc.

Thank for your time again. :-)

fairchild

12th May 2011, 00:15

If you could send me your hcfr result files for me to take a look I would appreciate that. My e-mail is in the manual, at the bottom.

That's how it's supposed to be. The current yCMS version does not allow white point correction. It only allows chromatic adaptation to display's white point. Even though the perception of the colors would be right, the measurements would always be off.

I'm currently developing the white point correction so that it could measure well too, but I cannot give an ETA for it.

Alright, sent you the hcfr files from the original calibration + 2.22 and 2.35 gamma boost.

Thanks for clarification on the increased dE's.

yesgrey

12th May 2011, 11:26

Alright, sent you the hcfr files from the original calibration + 2.22 and 2.35 gamma boost.
Thanks. I will take a look and then will let you know.

yesgrey

12th May 2011, 11:45

I'm using the 2.22 gamma boost as the 2.35 is a tad too dark to my eyes and in dark scenes I'm getting a bit too much black crush. (2.22 gamma boost also has a tiny bit of black crush but I think this is expected when you are going from a 1.76 gamma to 2.22ish)
The black crush could also be related with you being using a pure power curve. Try Using Gamma_Curve 1.0 2.22 instead, it will decrease the black crush.
If you feel it's too much then try other values for curveType, maybe 0.5, or any other value between 0.0-1.0.

P.S.: Sorry for quoting part of your e-mail here, but I felt that your question and my answer would be helpful for other people.

fairchild

13th May 2011, 01:23

Roger that. I tried a smaller curveType, currently using a 0.5 with a 2.22 gamma boost and indeed you get a bit more shadow detail. I'll have to do a measurement with the different curveType to see if I'm still getting the benefit of improved gamma over my crappy 1.76

Changing the curveType should still give a decent gamma boost I'm assuming? My main reason for using yCMS at the moment is to improve my gamma as my set's gamma is poor and has no adjustment in the user menu or service menu.

yesgrey

14th May 2011, 00:09

I'll have to do a measurement with the different curveType to see if I'm still getting the benefit of improved gamma over my crappy 1.76
You will. However, you should be aware that HCFR gamma graphs are accurate only for power curves or BT.709 curves, so with a curve in-between the results might look less good that you would expect, but that doesn't mean that yCMS is not working correctly.

Changing the curveType should still give a decent gamma boost I'm assuming?
You can change two parameters of a gamma curve: the curveType, and the gammaValue.

Changing the curveType affects the shadow detail amount. 0.0 will give you the least, and 1.0 the most. Select the value that gives you the most natural look.

Changing the gammaValue affects the image "punch". A lower value gives a flatter image, and a higher one a punchier one. Select the value that gives you the most pleasant image. There is no "gold standard" for the gammaValue. Some claim a value of 2.35 (the one I use), but in the end it would depend on the display...

Yellow_

16th May 2011, 18:28

yesgrey, I wonder if you could elaborate on range conversion via HSL curve re discussion on this thread a few days ago I'm struggling to find info on how to go about this.

yesgrey

17th May 2011, 11:06

I wonder if you could elaborate on range conversion via HSL curve re discussion on this thread a few days ago I'm struggling to find info on how to go about this.
I'm not working with HSL color space, and probably never will, so I cannot help you with that. When I referred the range conversion I was thinking in doing it in YCbCr or RGB, not in HSL.

I found this (http://lodev.org/cgtutor/color.html) link on google, maybe it could help you...

janos666

21st May 2011, 22:35

Yah, the gamma value is a strange question. I always preferred 2.35 on every LCDs (doesn't matter if it was a 800:1 WCG-CCFL H-IPS, 900:1 <sRGB WLED-LCD or 2500:1 ~sRGB CCFL c-PVA) but I am happy with the default gamma 2.20 response of my current PDP (~3800:1 at 50 or 60Hz and ~2300:1 at 96Hz).
I don't know why but the picture on this PDP just looks better for me even if it's less colorimetrically accurate. I don't even use any color corrections, I only set the correct contrast/brightness and white point but that's all. (I don't feel the "itch" to correct anything, even if I know it's not that accurate if I ask my spectrophotometer to tell me the truth...)

Thunderbolt8

5th June 2011, 18:56

how can I now make my custom input file for japanese HD movies with messed up black levels with the new madVR version of 0.62 and above?

# Example input file for yCMS v1.0 and up
#
# Settings for creating a 3DLUT file for watching the following Video formats:
# Blu-ray, HD DVD, ATSC HD Broadcast, DVB HD Broadcast
# without any Display correction
# Includes YCbCr->RGB conversion using PC Levels (Black: 0 and White: 255)

# Set input format
Input_Format HD YCbCr 8
Input_Range 32 235

# Set output format
Output_Format HD RGB_PC 16

Output_Transfer_Function 4.5 0.099 0.405 0.018

madshi

5th June 2011, 19:45

Carpo

5th June 2011, 22:20

Okay, i am totaly lost with yCMS, can someone explain how i would go about finding the primary/gamut measurements for an LG Electronics RZ-37LZ55, its connected to PC via DVI to HDMI connection, I play all types of files, HD, SD, DVD, NTSC, PAL

I will admit i am about as n00b as n00b can get on this :confused: Finally decided i should tweak the hell out of the HTPC, and after reading all i have and getting the migraine i got i wish i never started :mad:

Any help would be greatly appricated

madshi

5th June 2011, 22:31

@Carpo, ideally you need to have a meter, so you can measure your display. If you don't have a meter you can try googling if somebody else has ever posted measurements for your display. But even if you do find measurements from somebody else, it's questionable if you should use them because you don't know if the other guy's display is really 100% identical, has the same factory settings etc. IMHO, if you don't have your own meter (and don't plan to get one - it costs money) then simply use madVR as it is, without yCMS. The main purpose of yCMS is to correct any faults your display may have, but you do need a meter, ideally a good one, to achieve that aim.

On the other hand: If you can find a good review of your display with gamut & gamma measurements, maybe that review will give you advice how to configure the LG to achieve good Blu-Ray playback quality. If you can do that, that would benefit madVR playback, too.

Thunderbolt8

6th June 2011, 01:42

Try this one:

Input_Format yRGB RGB_Video 8
Input_Range 32 235
Output_Format HD RGB_Video 16
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Not sure about the "Output_Transfer_Function", though, cause I don't know why yours is the way it is.afaik the output transfer thing is for gamma correction and also should be used, because now after the colour change the gamma is too dark. 0.405 is the value for gamma here, default was afaik 0.45 according to yesgrey.

janos666

6th June 2011, 02:26

Output_Transfer_Function could be used to describe the actual TRC of your display, not the desired one.
You can assume that your display already has a power-like TRC and guess the exponent (more likely 2.2) but unless you previously calibrated your display to that TRC (through your VGA LUT or an internal hardware LUT, etc) you should use the Grayscale_Measurements instead.

madshi

6th June 2011, 06:48

Carpo

6th June 2011, 08:24

I don't think he has a meter. He's using the 3dlut only to "fix" crappy encodes, as fasr as I understand.

wouldn't say 1080p encodes using -crf19 were crappy madshi ;)

Thunderbolt8

6th June 2011, 11:29

I don't think he has a meter. He's using the 3dlut only to "fix" crappy encodes, as fasr as I understand.

@Thunderbolt8, try using your special Output_Transfer_Function and use the other 3 lines from my suggestion. Does that give you the same image with v0.62 than you got with older versions?
need to check on that with a sample. but wont have time to do so before next weekend :S

but it would only be a rough estimation anyway, because I cannot lay comparison pics from an older madvr version and of the current one next to each other. a screenshot function in madvr would be very handy now (if it was included in a pre 0.62 version just for purposes of comparison as well) :D

janos666

6th June 2011, 22:11

I think PrintScreen always works with windowed mode and D3DFS shouldn't change anything with the current versions (may be later with 10-bit output).

---

I still don't understand why do you need to change the output transfer function, it always has to match with the display TRC. If the source is encoded with an unusual TRC then you should change the input transfer function parameter which describes the TRC of the source. (And if you don't know the actual TRC of the display then you should assume a pure-power TRC with gamma 2.2)

Thunderbolt8

7th June 2011, 00:33

dont ask me technically about it...all I know is that this line includes changes to gamma which are also adviceable to apply after correction the black levels (and it looks indeed better or "more correct" with these gamma changes)

the printscreen thing is a good idea though, Ill try that at the weekend (I assume there are no flaws when comparing the PQ of screenshots from two different madvr versions that way?)

janos666

7th June 2011, 03:16

Just save them in a lossless format, preferably in 8-bit/channel (usually labeled as 24-bit without and 32-bit with the Alpha channel which is irrelevant now) RGB bitmap or PNG (if you plan to upload it to web).

lych_necross

7th June 2011, 04:42

Okay, reading this thread has makes me want to get a meter and try yCMS for myself. Can someone recommend a good meter that doesn't cost too much?

janos666

7th June 2011, 05:49

Okay, reading this thread has makes me want to get a meter and try yCMS for myself. Can someone recommend a good meter that doesn't cost too much?

Spyder Pro (http://www.datacolor.eu/en/products/monitor-calibration/spyder3pro/index.html) -> They say the new (2010 and later) models can work on WCG displays and they are fairly accurate on low IREs too. (So they are equally good or may be slightly better than i1LT or i1d2. They say that there are some freshly re-certificated/calibrated i1d2s with WCG compatible matrices but they are hard to find, may be from second hand...)

cyberlolo

7th June 2011, 13:01

Hi yesgrey.

Until now, I've been using this command for color correction:

Gamut_Measurements 0.6350 0.3321 0.2890 0.6007 0.1528 0.0647 0.3127 0.3294

just as it was intended to be:

Gamut_Measurements redx redy greenx greeny bluex bluey whitex whitey

But now, with the new builds (and the new madvr version), this is not possible, and the procedure seems to be as in this example:

Gamut_Measurements 1
21.26 0.676 0.321
71.52 0.308 0.685
7.22 0.144 0.045
100.00 0.3127 0.3290

You told me that the first column (bold) was the Luminance, but when the calibrator did his job on my TV, he gave me the xy coordinates and they were 2 numbers for each component, not 3!! So I don't have that info. Is there any way to generate 3Dluts without luminance? How can I solve this?

Thanks in advance.

yesgrey

7th June 2011, 14:40

Gamut_Measurements 1
21.26 0.676 0.321
71.52 0.308 0.685
7.22 0.144 0.045
100.00 0.3127 0.3290

You told me that the first column (bold) was the Luminance, but when the calibrator did his job on my TV, he gave me the xy coordinates and they were 2 numbers for each component, not 3!! So I don't have that info. Is there any way to generate 3Dluts without luminance? How can I solve this?
You can always continue to use the previous method by creating the 3DLUT yourself. However, if you want to use the new madVR GUI, just use the Luminance values that are in bold, followed by your x,y coordinates. Like this:
Gamut_Measurements 1
21.26 redx redy
71.52 greenx greeny
7.22 bluex bluey
100.00 whitex whitey

yCMS is not yet using the luminance values, so the values on the first column are not important.;)

cyberlolo

7th June 2011, 15:48

You can always continue to use the previous method by creating the 3DLUT yourself.

I don't know how to do it with the new version, so I think you mean using an old yCMS version, don't you?

However, if you want to use the new madVR GUI, just use the Luminance values that are in bold, followed by your x,y coordinates. Like this:
Gamut_Measurements 1
21.26 redx redy
71.52 greenx greeny
7.22 bluex bluey
100.00 whitex whitey

yCMS is not yet using the luminance values, so the values on the first column are not important.;)

So can I enter any value (because they're ignored) or do I have to use those exact values?

yesgrey

7th June 2011, 20:49

I don't know how to do it with the new version, so I think you mean using an old yCMS version, don't you?
No. The new version works pretty much the same. I think you should be asking about how to create a 3DLUT file compatible with the new madVR. For that, you can still use your old configuration file but using yRGB as the input color space in video levels, like:
Input_Format yRGB RGB_Video 8

For output, you can use whatever RGB color space you want as long as you use video levels, like:
Output_Format whatever RGB_Video 16

So can I enter any value (because they're ignored)
Yes.

Thunderbolt8

7th June 2011, 21:51

so can how would I have to change my input file?

Input_Format HD YCbCr 8
Input_Range 32 235

Output_Format HD RGB_PC 16

Output_Transfer_Function 4.5 0.099 0.405 0.018

to something like this?

Input_Format HD yRGB RGB_PC 8
Input_Range 32 235

Output_Format HD RGB_PC 16

Output_Transfer_Function 4.5 0.099 0.405 0.018

and how do I have to name the 3dlut file, afaik theres now only 1 file for all 4 former PC/Video/HD/SD 3dlut files?

tschi

7th June 2011, 22:40

Hi Yesgrey,
I have some big issue using madVR (test 0.62 and 0.64) : the gamut correction is very bad, the red is almost pink and blue & green are quite bad
here madVR config :
http://imageshack.us/photo/my-images/24/sansregt.png/
w/o ycms in madVR :
http://imageshack.us/photo/my-images/577/capturedcran20110607233.png/
using ycms in madVR :
http://imageshack.us/photo/my-images/84/capturedcran20110607233.png/

my chc files:
http://www.mediafire.com/?315317y1t7f9127

I calibrated and recalibrated several times, check everything, deleted everything, test with grayscale and not, but I can not find where I mistake :(

Thank you very much for your help

yesgrey

7th June 2011, 22:44

so can how would I have to change my input file?
Like this:

Input_Format yRGB RGB_Video 8
Input_Range 32 235
Output_Format HD RGB_Video 16
Output_Transfer_Function 4.5 0.099 0.405 0.018

and how do I have to name the 3dlut file, afaik theres now only 1 file for all 4 former PC/Video/HD/SD 3dlut files?
You can use any name, and you can put it in any dir you want. You just need to select external 3DLUT in madVR settings and point it to the file.

The 4 former options can now be executed within madVR's GUI. There is no more need for 4 3DLUTs.;)

yesgrey

7th June 2011, 22:48

Hi Yesgrey,
I have some big issue using madVR (test 0.62 and 0.64) : the gamut correction is very bad, the red is almost pink and blue & green are quite bad
Was the calibration working OK with previous madVR versions?

tschi

7th June 2011, 22:56

I use ycms v1.8 before:o and all madVR version since 0.12 it was ok
I was happy with that :)
Ok, I think you means to test last ycms with madvr < 0.62 ;) ..
I will check that

yesgrey

7th June 2011, 23:04

OK. First I will measure the new madVR with my own display just to be sure that everything is fine on madVR's side. Until then, I would suggest you to keep using the old one...

madshi

7th June 2011, 23:05

@tschi, can you try the latest yCMS version with madVR v0.61? Do you get proper results that way?

fairchild

7th June 2011, 23:10

I also was experiencing weird color issues as well with the latest MadVR + the yCMS feature in the new version. I tried entering in Yxy as well as XYZ, tried entering just the gamuts and gamuts+greyscale, but still am seeing a red tinge in my test patterns as well as some weirdness in my color clipping pattern with blue.

I haven't been able to measure with my meter but I guess I could try when I get some time. These are the measurements I entered into the new yCMS integrated into madVR. I can provide an HCFR chc file if requested:

Gamut_Measurements 1
10.081485 0.660916 0.332686
29.748291 0.296783 0.609976
3.789106 0.149306 0.065182
48.580326 0.311850 0.326137

Grayscale_Measurements
30 1 8.235306 0.312919 0.327159
40 1 14.348957 0.311858 0.326344
50 1 22.056358 0.311059 0.327702
60 1 32.212700 0.310529 0.325851
70 1 43.527546 0.311982 0.327575
80 1 55.227596 0.311502 0.325526
90 1 70.423340 0.311393 0.328095
100 1 83.712715 0.312210 0.326144

tschi

7th June 2011, 23:16

@tschi, can you try the latest yCMS version with madVR v0.61? Do you get proper results that way?
I try with madVR 0.60 (I didn't see your post) and generated 3dlut with last ycms (with txt file), the result is OK. I didn't take mesures but red is red, not like with the new madVR (red is pink)

fairchild

7th June 2011, 23:28

I just tested as was suggest to tschi, I installed madVR 0.61 and created an HD 3dlut file, no glitching on blue with my test pattern. Basically blue gets clipped at 235 and has some flickering of the blue bars below 235, and red gets clipped at 241 with the newer MadVR and it's GUI generated yCMS 3dlut. Where as when I'm using the older version 0.61 with the generated ycms 3dlut using the command line and the below script, I get no clipping on any color.

# Example input file for yCMS v1.0 and up
#
# Settings for creating a 3DLUT file for watching the following Video formats:
# Blu-ray, HD DVD, ATSC HD Broadcast, DVB HD Broadcast
# without any Display correction
# Includes YCbCr->RGB conversion using Video Levels (Black: 16 and White: 235)

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_Video 16

# Gamut correction
Gamut_Measurements 1
10.081485 0.660916 0.332686
29.748291 0.296783 0.609976
3.789106 0.149306 0.065182
48.580326 0.311850 0.326137

# Grayscale correction
Grayscale_Measurements
30 1 8.235306 0.312919 0.327159
40 1 14.348957 0.311858 0.326344
50 1 22.056358 0.311059 0.327702
60 1 32.212700 0.310529 0.325851
70 1 43.527546 0.311982 0.327575
80 1 55.227596 0.311502 0.325526
90 1 70.423340 0.311393 0.328095
100 1 83.712715 0.312210 0.326144

# Gamma correction Gamma_Curve 0.0 2.22 (has the most black crush 1.0 curve has almost no black crush)
Gamma_Curve 0.0 2.22

cyberlolo

7th June 2011, 23:50

No. The new version works pretty much the same. I think you should be asking about how to create a 3DLUT file compatible with the new madVR. For that, you can still use your old configuration file but using yRGB as the input color space in video levels, like:
Input_Format yRGB RGB_Video 8

For output, you can use whatever RGB color space you want as long as you use video levels, like:
Output_Format whatever RGB_Video 16

Yes.

Ok. :thanks:

madshi

8th June 2011, 11:50

Here's a madVR v0.65 test build with higher internal precision:

http://madshi.net/madVRprecision.rar

Does that improve anything?

fairchild

8th June 2011, 12:35

Here's a madVR v0.65 test build with higher internal precision:

http://madshi.net/madVRprecision.rar

Does that improve anything?

I downloaded and installed that build but the same issue. Here is a screenshot so you can get an idea of the glitch (not optimal but at least you can see I entered things correct and can kind of see the glitch).

http://img405.imageshack.us/img405/1704/madvrycmsbug.th.jpg (http://imageshack.us/photo/my-images/405/madvrycmsbug.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

madshi

8th June 2011, 12:42

Is this one better?

http://madshi.net/madVRprecision2.rar

fairchild

8th June 2011, 12:52

Is this one better?

http://madshi.net/madVRprecision2.rar

That one fixed the glitching on the blue level! :)

But it broke something with the video levels/black levels. It's now clipping white levels/colors and the black levels are borked.

http://img819.imageshack.us/img819/8238/madvrycmsblacklevels.th.jpg (http://imageshack.us/photo/my-images/819/madvrycmsblacklevels.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

I'd love to keep helping you try to figure this out, but I have to go now, I'll be back later on. But maybe some others can get to the bottom of this. :thanks:

Mark_A_W

8th June 2011, 14:33

Yesgrey

I've had a go, based on this workflow:

1. Set PC gamma back to "flat".

2. Calibrate projector as best as I can with the internal controls, using colorimeter (I use HCFR software as the source and HCFR sensor).

3. The final calibration result is the input to yCMS/madVR. Generated by measuring the primary colours, and greyscale.

4. Input the values into madVR. Make sure the formats match.

5. Set my desired gamma in madVR (if it's not 2.2). 2.0 looks much better on my CRT.

I didn't bother Calibrating the projector with it's internal controls, it's a bit out, I changed some boards without re-calibrating. However it looks ok, perhaps a touch too much red down low, but not bad.

But the results are awful. The colours are wrong. White below 235 is completely purple and black below 16 is green.

I did get confused by the formats. You want Yxy. HCFR has xyY. Are they the same?

These are my results, I think I have transcribed them properly:

red, Yxy, 5.112, 0.628, 0.337
green, Yxy, 9.018, 0.294, 0.595
blue, Yxy, 1.672, 0.156, 0.078
white, Yxy, 10.833, 0.321, 0.342

20, Yxy, 0.301, 0.338, 0.349
30, Yxy, 0.179, 0.316, 0.333
40, Yxy, 2.705, 0.311, 0.335
50, Yxy, 5.037, 0.311, 0.340
60, Yxy, 7.476, 0.315, 0.340
70, Yxy, 10.364, 0.320, 0.341
80, Yxy, 10.603, 0.320, 0.341
90, Yxy, 10.749, 0.321, 0.342
100, Yxy, 10.850, 0.321, 0.342

Here is the result

http://dl.dropbox.com/u/1372034/purple.jpg

http://dl.dropbox.com/u/1372034/purple3.jpg
RGB levels before correction

http://dl.dropbox.com/u/1372034/purple2.jpg
Final Result

I think I'm doing something wrong....:eek:

Cheers

Mark

madshi

8th June 2011, 14:43

@Mark, the official madVR version has a bug resulting in quite serious problems. This one is an improvement:

http://madshi.net/madVRprecision2.rar

It does not handle BTB and WTW correct yet, but the rest should be fine. A fully fixed version should be available soon. Not sure if this is the cause of your problem, though. Maybe there's another problem added on top of the madVR bugs. I'll let yesgrey comment on that.

madshi

8th June 2011, 15:23

Here's comes the next try. I think this one should work pretty well:

http://madshi.net/madVRprecision3.rar

tschi

8th June 2011, 17:03

Hi, just come back from work, I test madVRprecision3 but I still have pink for red primary :(
I try to generate a 3dlut and load it in madVR using this code
# Set input format
Input_Format yRGB RGB_Video 8

# Set output format
Output_Format HD RGB_PC 16

Gamut_Measurements 1
19.283 0.652 0.320
83.538 0.280 0.593
9.781 0.142 0.077
114.411 0.313 0.329
but madVR said the 3dlut file does not match the output format required.
I also test
Output_Format yRGB RGB_PC 16 without any sucess, what should be a correct code ? thanks

madshi

8th June 2011, 17:09

You need to use "Output_Format yRGB RGB_Video 16". Switching between video <-> PC levels is done via shader code. The 3dlut must always be video levels input/output for madVR v0.61+.

tschi

8th June 2011, 17:15

Thanks !
I generate 3Dlut using this code
# Set input format
Input_Format yRGB RGB_Video 8

# Set output format
Output_Format yRGB RGB_Video 16

Gamut_Measurements 1
19.283 0.652 0.320
83.538 0.280 0.593
9.781 0.142 0.077
114.411 0.313 0.329
I am able to load it in madVR :)
But red is still pink :(
I can provide video pattern and 3dlut files if needed...

yesgrey

8th June 2011, 17:24

I did get confused by the formats. You want Yxy. HCFR has xyY. Are they the same?

Yes, only the position of Y is different. Both expressions are used.

But the results are awful. The colours are wrong. White below 235 is completely purple and black below 16 is green.
But red is still pink :(
There is a bug in madVR. madshi and I are working on it... until then, you should use v0.61 if you want to use the 3DLUT files.

tschi

8th June 2011, 17:53

ok, thank you both for all your hard work :cool:

fairchild

8th June 2011, 20:12

Here's comes the next try. I think this one should work pretty well:

http://madshi.net/madVRprecision3.rar

Alright, just got home and gave this new one a try. It fixed the black/white levels but the original issue is back. (blue glitching and being clipped, red being clipped early, red tinge in white levels in APL clipping pattern)

@Mark, can you post or link me your chc file generated by HCFR after the calibration. Because I think your values are not correct. It shouldn't be causing results like you posted in that grayscale image.

Mark_A_W

8th June 2011, 22:28

Yes, only the position of Y is different. Both expressions are used.

There is a bug in madVR. madshi and I are working on it... until then, you should use v0.61 if you want to use the 3DLUT files.

I'm sorry, I don't quite understand what you mean by "both expressions are used".

Both Yxy and xyY are the same aren't they, just the values in different order? Hope so, as that's how I transcribed the numbers.

I tried the precision3 madVR version, that's not the problem. I think either my measurements or transcribing are funky.

Alright, just got home and gave this new one a try. It fixed the black/white levels but the original issue is back. (blue glitching and being clipped, red being clipped early, red tinge in white levels in APL clipping pattern)

@Mark, can you post or link me your chc file generated by HCFR after the calibration. Because I think your values are not correct. It shouldn't be causing results like you posted in that grayscale image.

Fairchild, chc file is here: http://dl.dropbox.com/u/1372034/XG-1101LC%20MP%20Mods.chc

And here is my settings.bin, you can grab the values out of it, if you like: http://dl.dropbox.com/u/1372034/settings.bin

Thanks

pankov

8th June 2011, 23:01

guys,
how do you export the values from colorHCFR in madVR/yCMS compatible format?
Is there a .chc to yCMS "converter"?
Please, don't tell me I'll have to convert (copy&paste) them manually one by one.

fairchild

8th June 2011, 23:54

Fairchild, chc file is here: http://dl.dropbox.com/u/1372034/XG-1101LC%20MP%20Mods.chc

And here is my settings.bin, you can grab the values out of it, if you like: http://dl.dropbox.com/u/1372034/settings.bin

Thanks

Ok first thing, this was the absoulte best results you could achieve on your grayscale? dE's optimally you want to have them under 5.0 from 30-100 IRE and you had a bunch over 10 and only one under 5.0 (30 IRE you have at 3.7).

Secondly, once you have your grayscale how you want, you work on the color. If you are going to use this calibration, your luminance on red is way too high, you want it to be 0.21 of your white (I'm assuming you took measurements of your primaries with the same level of the white). So if that's correct your white Luminance is 10.833 so you want your red luminance to around 2.275 and yours is over twice that much. If your display has a working CMS, you could bring the dE of the primaries much better.

If you are confused on this, here is a guide which is really good and breaks stuff down clearly.

http://www.curtpalme.com/forum/viewtopic.php?t=10457

Moving along, this is what you would enter into yCMS given the data from your calibration file. You can compare this to what you entered. First is the primaries/gamut, it seems you entered some incorrect grayscale values at the early IRE's which is probably what is screwing you up:

Gamut_Measurements 1
5.112210 0.628470 0.336796
9.017853 0.293739 0.595465
1.672253 0.155996 0.077642
10.833004 0.321126 0.341560

Then these are for the grayscale/gamma:

Grayscale_Measurements
30 1 1.179433 0.315635 0.333479
40 1 2.705139 0.311259 0.334691
50 1 5.036874 0.310992 0.340356
60 1 7.476284 0.315073 0.340151
70 1 10.363506 0.320395 0.341030
80 1 10.603373 0.320395 0.341423
90 1 10.748604 0.320739 0.342232
100 1 10.849747 0.320797 0.342380

@pankov
The fastest way I know of is just to copy and paste from the colorHCFR interface. It only takes me around 3-5 minutes to copy and paste everything formatted properly like I did in this post for another forum member. You can copy the 3 values at once (xyY or XYZ then just format it like I did above)

yesgrey

9th June 2011, 00:08

Both Yxy and xyY are the same aren't they, just the values in different order?
Yes.

I tried the precision3 madVR version, that's not the problem. I think either my measurements or transcribing are funky.
Trust me. madVR is not working right. Until it gets fixed it would be a waste of time looking for problems on your measurements transcription.

Please, don't tell me I'll have to convert (copy&paste) them manually one by one.
Go to Advanced->Export and export the values to a xls or csv file. Then you can copy all the values to the format yCMS needs and then create your 3DLUT file manually, or using madVR.

Mark_A_W

9th June 2011, 00:46

Ok first thing, this was the absoulte best results you could achieve on your grayscale? dE's optimally you want to have them under 5.0 from 30-100 IRE and you had a bunch over 10 and only one under 5.0 (30 IRE you have at 3.7).

Secondly, once you have your grayscale how you want, you work on the color. If you are going to use this calibration, your luminance on red is way too high, you want it to be 0.21 of your white (I'm assuming you took measurements of your primaries with the same level of the white). So if that's correct your white Luminance is 10.833 so you want your red luminance to around 2.275 and yours is over twice that much. If your display has a working CMS, you could bring the dE of the primaries much better.

If you are confused on this, here is a guide which is really good and breaks stuff down clearly.

http://www.curtpalme.com/forum/viewtopic.php?t=10457

Moving along, this is what you would enter into yCMS given the data from your calibration file. You can compare this to what you entered. First is the primaries/gamut, it seems you entered some incorrect grayscale values at the early IRE's which is probably what is screwing you up:

Gamut_Measurements 1
5.112210 0.628470 0.336796
9.017853 0.293739 0.595465
1.672253 0.155996 0.077642
10.833004 0.321126 0.341560

Then these are for the grayscale/gamma:

Grayscale_Measurements
30 1 1.179433 0.315635 0.333479
40 1 2.705139 0.311259 0.334691
50 1 5.036874 0.310992 0.340356
60 1 7.476284 0.315073 0.340151
70 1 10.363506 0.320395 0.341030
80 1 10.603373 0.320395 0.341423
90 1 10.748604 0.320739 0.342232
100 1 10.849747 0.320797 0.342380

@pankov
The fastest way I know of is just to copy and paste from the colorHCFR interface. It only takes me around 3-5 minutes to copy and paste everything formatted properly like I did in this post for another forum member. You can copy the 3 values at once (xyY or XYZ then just format it like I did above)

Thanks Fairchild.

The first thing is I have a CRT projector. It's quirky. And no, there is no CMS, you can't move the primaries, they are set by the phosphur and the filtering on the lenses.

(The forum you link to is the CRT projector forum BTW.)

The second thing is no, that is not the best I can do, I didn't even try to tweak the CRT colours, this was more about the process. I just measured and then dove into yCMS. Like said I recently swapped some relevant boards (testing mods) and haven't recalibrated.

Also, I put the PC gamma control back to flat before I started - I normally use a custom curve with different curves per colour. To compensate for a stubborn CRT. This caused the greyscale to play up a bit.

As for the red luminance...I really can't explain why it's high. If you look at the greyscale on the previous page, the red and green are identical at 100% white.
You can see the typical blue hump of a CRT (blue saturates) and NEC XGs always seem to have way too much red down low.
My gamut is not that far off REC709, two colours are a touch shy, and one is over, but not by much.

And I'll check the numbers again, I thought I did it without error, but there are a lot of numbers, and the order from HCFR to yCMS (in madVR) differ.

However I also recognise that Yesgrey said there's a bug.

Cheers

Mark

fairchild

9th June 2011, 01:33

(The forum you link to is the CRT projector forum BTW.)

That guide works with Plasma, LCD, DLP, SXRD, LCOS, CRT, etc.

Mark_A_W

9th June 2011, 01:59

Yeah, I know, but Curt Palme is the CRT projector forum. The other stuff has just sort of grown around the sides, but when we all got shoved off AVS forum we all went to Curt's forum.

jmone

10th June 2011, 06:57

madshi suggested I post here for advice over the madVR thread on what affordable gear I need to buy if I want to do my own calibration. Any suggestions? I have a Pio LX608a that has been calibrated by an ISF Tech a few years ago. It is fed via a Yami V2700, from a HTPC running madVR over HDMI from a HD5670, I did book him in to recalibrate the TV and grab some measurements but he postponed.
Thanks
Nathan

jimwhite

10th June 2011, 15:55

check out the ColorMunki.... i1pro type performance for much less $$$$ :p

_EDIT_: Wow!! it took 6 years to post 22 times :eek: Master Level lurker :D

tschi

10th June 2011, 16:33

jmone : I use x-rite eye-one display 2, yeah, I know that's not the best one :p but only 200$, it's ok for watching tv and if no professional use. I have a friend with eye one pro model , I should compare the result with a 1000$ stuff ... but I guess it 's not so far on my 5 years LCD :rolleyes:

madshi

10th June 2011, 18:59

Here's a new test build, anybody willing to test?

http://madshi.net/madVRfinally.rar

fairchild

10th June 2011, 19:12

Here's a new test build, anybody willing to test?

http://madshi.net/madVRfinally.rar

I am still experiencing the same issues.

tschi

10th June 2011, 19:18

Here's a new test build, anybody willing to test?
http://madshi.net/madVRfinally.rar
I have still the same pink-red color :(

madshi

10th June 2011, 19:30

Argh, thanks for testing, though.

jmone

10th June 2011, 22:43

Thanks Jim/tschi, lools like the ColorMunki is in the right sort of price/performance bracket for me, but there seems to be different bundles all at similar prices:
ColorMunki Photo Vs ColorMunki Design
(Image Specific Vs Spot Color Optimization)
(Nil Vs Pantone Matching and Geo)
(DigitalPouch Image Transport Vs Nil)
(Interactive CD Vs Nil)

Then there are bundles like "ColorMunki Photo + Colorchecker Passport":

I "presume" that Photo is all I need or are there other addons/accessories?

Thanks
Nathan

*Touche*

11th June 2011, 19:31

yesgrey

11th June 2011, 20:06

I have an ICC profile for my monitor, but no access to a meter to re-do the measurements. It would be great if it could be converted to a yCMS compatible format and used in madVR. Any plans and possible ETA for this feature?
It's in my plans, but no ETA. However, do a search, because I guess some people here were able to create a 3DLUT file by using some data from their ICC files...

Dogway

14th June 2011, 11:39

Is there something wrong in my code?

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_Video 16

# Gamut correction
Gamut_Measurements 0.608 0.324 0.292 0.575 0.146 0.087 0.323 0.354

# Grayscale IRE Measurements
Grayscale_Measurements
0.320 0.290 0.329
1.057 0.314 0.349
2.712 0.319 0.352
6.367 0.322 0.358
11.875 0.320 0.355
19.461 0.320 0.353
28.516 0.322 0.355
39.409 0.323 0.355
52.761 0.325 0.357
69.888 0.325 0.355
88.791 0.323 0.355

yCMS says "Error! Line 17 - Invalid Format: Gamut_Measurements '0.608'"

I will make another one for SD, which one do I supply to madVR?

yesgrey

14th June 2011, 12:50

Is there something wrong in my code?
Which yCMS version are you using? The Gamut_Measurements and Grayscale_Measurements commands syntax is not that any more since v1.9.

which one do I supply to madVR?
Maybe you would be better by feeding your measurements into madVR and let it create the 3DLUT for you...;)

Dogway

14th June 2011, 13:39

Maybe you would be better by feeding your measurements into madVR and let it create the 3DLUT for you...;)

True, but learning always comes handy. I ended up using the next txt:
# Set input format
Input_Format yRGB RGB_Video 8

# Set output format
Output_Format yRGB RGB_Video 16

# Gamut correction
Gamut_Measurements 1
20.471 0.608 0.324
61.856 0.292 0.575
7.109 0.146 0.087
88.739 0.323 0.354

# Grayscale IRE Measurements
Grayscale_Measurements
10 1 1.057 0.314 0.349
20 1 2.712 0.319 0.352
30 1 6.367 0.322 0.358
40 1 11.875 0.320 0.355
50 1 19.461 0.320 0.353
60 1 28.516 0.322 0.355
70 1 39.409 0.323 0.355
80 1 52.761 0.325 0.357
90 1 69.888 0.325 0.355
100 1 88.791 0.323 0.355
Thank you
Warn me if something is wrong.

yesgrey

14th June 2011, 13:53

True, but learning always comes handy.
100% agreed. :)

Warn me if something is wrong.
I would remove the comments above the first two commands. I'm not sure that madVR is ignoring them...
Input_Format yRGB RGB_Video 8
Output_Format yRGB RGB_Video 16

madshi

14th June 2011, 14:30

madVR is stupid, but not that stupid... :D The comments don't harm.

yesgrey

14th June 2011, 15:11

OK. I did not test it thoroughly.;)

Dogway

16th June 2011, 01:21

What software can I use to tweak the results of my calibrated display? (laptop monitor) I used the spyder2 software, but it defaults to D55, where it seems digital content should use D65. How do I fix that and other off parameters after calibration? Sorry if its a bit offtopic, I tried looking for a calibration thread in doom9. I guess the values I feed to yCMS are measurements done with my profile already loaded, is it right? So madVR can compensate the slightly off values...

I also measured my TV, I used the internal TV menu sets to approximate to ideal Gamut and Greyscale, by measure->tweaking a dozen times. I finally got fairly decent parameters and gamma curve by setting contrast to 25 and brightness to 55 in TV, but it looks my whites are clipped and a bit low, if I set contrast to 70 ("before" line) it looks ok but my gamma curve is back to wrong place. I thought on using the "before" parameters (straight line), and just use in madVR a 1.80 value for Power Curve, Is this correct? If so which of them, the one in "calibration" or "color & gamma"?
http://i212.photobucket.com/albums/cc35/Dogway/Misc/gamma.png

tschi

16th June 2011, 07:14

Hi, If I make 3dlut with like this (madVR 0.61) Input_Format HD YCbCr 8
Input_Range 13 235
Output_Format HD RGB_PC 16
....
Would I have BTB informations like ffdshow level ?
http://red.skully.free.fr/Divers/levels_2.jpg
With madVR>0.61, (and yRGB 3dlut format) is it working ?
thx

TheElix

18th June 2011, 14:22

Does anybody know how EDID Color characteristics data of the monitor influences anything? Here's what I have:
Color characteristics
Default color space...... Non-sRGB
Display gamma............ 2.20
Red chromaticity......... Rx 0.640 - Ry 0.345
Green chromaticity....... Gx 0.291 - Gy 0.635
Blue chromaticity........ Bx 0.163 - By 0.093
White point (default).... Wx 0.288 - Wy 0.296
Additional descriptors... None
This isn't sRGB, and this isn't REC.709 either. I have my HDTV calibrated as REC.709 with 2.35 gamma. And I used that data with yCMS. Now I'm wondering how this EDID data influences anything...

TheElix

19th June 2011, 20:28

Something I've looked up about EDID:
Color Characteristics – defines the RGB color space conversion technique to be used by the display
So that means that those numbers really do influence the picture? If so then I'm not content with this, beacause those numbers are wrong.

janos666

24th June 2011, 21:15

Something I've looked up about EDID:

So that means that those numbers really do influence the picture? If so then I'm not content with this, beacause those numbers are wrong.

No, those numbers do nothing. They are just there if a software would use them but it's very rare.

How do you know they are wrong? These numbers can be either very accurate readings from a reference grade sensor in the factory or completely false decorations.
What kind of sensor did you use for measuring?

TheElix

24th June 2011, 23:55

What kind of sensor did you use for measuring?i1 Display 2. I know it's not so accurate yet I calibrated my plasma with it to a satisfactory result and can tell those numbers in EDID are way off. Nor they are close to any color stadard.
Well, if you say they don't influence anything then I'm relieved...

janos666

25th June 2011, 21:42

i1 Display 2. I know it's not so accurate yet I calibrated my plasma with it to a satisfactory result and can tell those numbers in EDID are way off. Nor they are close to any color stadard.
Well, if you say they don't influence anything then I'm relieved...

I don't think they are unbelievable if I just look at them.
They don't need to be close to any standards, they are supposed to show the actual characteristics. (And by actual, I mean the real physical primaries, not the emulated ones. The hardware CMS settings don't affect these numbers.)

Which plasma? All of the primaries are over-saturated on my PDP.
I don't have it anymore to test it on my PDP but my old i1LT was useless on my U2410. I could tell it without questions that the calibration result is worse than the factory state. I picked up a ColorMunki Photo and I found that it improved the calibration of my older l220x as well. It had a sRGB<X<AdobeRGB gamut (smaller but more similar to my current PDP).

However the low light accuracy of the ColorMunki doesn't enough for my current PDP, so I need to buy a colorimeter too. I want one of those new Display III sensors but not until ArgyllCMS will support them.

madshi

27th June 2011, 14:35

TheElix

27th June 2011, 16:18

Are you using Grayscale_Measurements command? Without it is not likely for you to have perfect results...
Yes, here's my data:
20, Yxy, 3.143497, 0.313949, 0.320639
30, Yxy, 7.019581, 0.314259, 0.326342
40, Yxy, 12.641442, 0.314473, 0.326627
50, Yxy, 20.403746, 0.312119, 0.326721
60, Yxy, 31.174128, 0.315227, 0.332607
70, Yxy, 43.673073, 0.315350, 0.331502
80, Yxy, 58.332012, 0.314300, 0.329078
90, Yxy, 76.145157, 0.314849, 0.330899
100, Yxy, 96.699242, 0.313689, 0.328451

yesgrey

27th June 2011, 17:22

Yes, here's my data
OK, so it's your display that is limiting you. The blue and red are limited, hence why you cannot achieve the standard values. In the green the difference is minimal, and you would not notice any difference.

TheElix

27th June 2011, 18:03

OK, so it's your display that is limiting you. The blue and red are limited, hence why you cannot achieve the standard values. In the green the difference is minimal, and you would not notice any difference.The point of yCMS then...?

tschi

27th June 2011, 18:49

I just made a very small test w/o meter and the red primary is red now, with my eyes at least. Thanks :cool:

yesgrey

27th June 2011, 20:40

The point of yCMS then...?
With your current display only to correct any flaws in your display's gamma curve, if there are any. Try with the 3DLUT and without and judge for yourself what looks better...

cyberbeing

27th June 2011, 20:49

* instead of yRGB, madVR/yCMS are now using the measured display primaries
Can you explain why you are doing this?

All the below would do is correct the white point, since the RGB primaries are identical in input and output. Also keep in mind that Gamut_Measurements overrides Output_Primaries so Gamut_Mesurments isn't needed how you currently are creating the 3dlut because they both have identical data.

Where in the display chain is the gamut being corrected, considering the 3dlut is no longer doing so? Are the shaders now taking into account the display primaries and doing the gamut adjustment before feeding the 3dlut?

Input_Primaries 0.626473564822893 0.34138544756587 0.294038817005545 0.608576709796673 0.148466540292538 0.0774905646709701 0.31272661468101209 0.32902313032606195
Output_Primaries 0.626473564822893 0.34138544756587 0.294038817005545 0.608576709796673 0.148466540292538 0.0774905646709701 0.313032323542798 0.329082368907846

Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0

Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0

Input_Range 16 235
Output_Range 16 235

Input_Bit_Depth 8
Output_Bit_Depth 16

Gamut_Measurements 2
44.8790 24.4560 2.3025
31.8150 65.8480 10.5370
18.2410 9.5207 95.1010
95.1206 99.9977 108.7500

madshi

27th June 2011, 20:58

Can you explain why you are doing this?
Because we've run into some problems with yRGB and we're not sure yet where they're coming from. So the v0.66 solution is a workaround for now. Maybe I'll stay with this solution, or maybe I'll go back to yRGB once the problems are sorted out. Not decided yet.

All the below would do is correct the white point, since the RGB primaries are identical in input and output.
The white point is corrected by the 3dlut, with chromatic adaption (which madVR can't do). Also the 3dlut has specific algorithms to handle out of gamut colors. Which madVR also doesn't have. Furthermore, the gamma response of the display is fixed, if you provide grayscale measurements.

Also keep in mind that Gamut_Measurements overrides Output_Primaries so Gamut_Mesurments isn't needed how you currently are creating the 3dlut because they both have identical data.
Having both doesn't harm.

Are the shaders now taking into account the display primaries and doing the gamut adjustment before feeding the 3dlut?
Yes. But the shaders are not doing white point correction (because the 3dlut can do that better) and are not handling out of gamut colors in any way.

cyberbeing

27th June 2011, 21:07

The shaders are doing gamut correction but not handling out of gamut colors? How does the 3dlut handle out of gamut colors in this case? Setting Input_Primaries to the display primaries makes the 3dlut assume their are no out-of-gamut colors. Unless you are talking about out-of-gamut colors created during white point correction? In any case this shouldn't be a problem, just trying to understand how it works now.

When I have some time later I'll do some measurements and see if this resolved my problem with 0.65.

madshi

27th June 2011, 21:10

The shaders are doing gamut correction but not handling out of gamut colors? How does the 3dlut handle out of gamut colors in this case? Setting Input_Primaries to the display primaries makes the 3dlut assume their are no out-of-gamut colors.
Out of gamut colors are in the BTB and WTW areas. The 3dlut is RGB *video* levels. Some out of gamut colors might be clipped by the shader math into the BTB/WTW range, though. Of course using yRGB would be better for out of gamut handling, but it was about time we fixed the broken calibration. So I preferred to offer a 99% solution over a 0% solution.

cyberbeing

27th June 2011, 21:39

madshi

27th June 2011, 21:53

I'm a bit confused since BTB and WTW has to do with levels not gamut, but you are referring to them as out-of-gamut colors.

BT.709 is a gamut. Your display primaries represent a gamut. If your display primaries have a larger gamut than the BT.709 gamut, the shaders would need to handle out-of-gamut colors during gamut conversion, before feeding the 3dlut in madVR 0.66. That is what's happening, correct?
I think we're talking about different out-of-gamut colors here. You're thinking about a bigger display gamut than source gamut. I was thinking of a smaller display gamut than source gamut. You're thinking about colors which are out of gamut *before* the gamut conversion. I was thinking about colors which are out of gamut *after* the gamut conversion.

Anyway, I'm not really an expert in calibration matters.

What I can say is that madVR does not have any out-of-gamma specific processing at all while I know that yCMS has some sort of out-of-gamma special handling. It'd probably be better if I left this discussion to yesgrey.

cyberbeing

27th June 2011, 22:33

yCMS 3dlut's only handle BTB/WTW and White Point how they are being created with madVR 0.66.
The Input_Primaries needs to represent the primaries of the video madVR is using as input for the 3dlut.

Which means madVR 0.66 is as follows with a BT.709 video? Gamut correction performed by shaders? WTW/BTB and White Point correction performed by the 3dlut?
madVR:
(1) input = 8bit Y'CbCr, 709 primaries/gamut, 709 gamma, WTW/BTB, D65 White Point
(2) convert -> 32bit float R'G'B', 709 primaries/gamut, 709 gamma, WTW/BTB, D65 White Point
(3) convert -> 32bit float RGB, 709 primaries/gamut, linear light, WTW/BTB, D65 White Point
(4) convert -> 32bit float RGB, Display primaries/gamut, linear light, WTW/BTB, D65 White Point
(5) convert -> 32bit float R'G'B', Display primaries/gamut, pure power 2.2 gamma, WTW/BTB, D65 White Point
3dlut:
(6) input = 8bit float R'G'B', Display primaries/gamut, pure power 2.2 gamma (with trilinear interpolation), WTW/BTB, D65 White Point
(7) convert -> 64bit float RGB, Display primaries/gamut, linear light, 16-235, D65 White Point
(8) convert -> 64bit float RGB, Display primaries/gamut, linear light, 16-235, Display White Point
(9) convert -> 16bit int R'G'B', Display primaries/gamut, Display corrected gamma, 16-235, Display White Point
madVR:
(10) input = 16bit int R'G'B', Display primaries/gamut, Display corrected gamma, 16-235, Display White Point
(11) dither down to 8bit R'G'B', Display primaries/gamut, Display corrected gamma, 16-235, Display White Point

yesgrey

27th June 2011, 22:45

(7) convert -> 64bit float RGB, Display primaries/gamut, linear light, 16-235, Display White Point

(7) is not correct. It should be:

(7) convert -> 64bit float RGB, Display primaries/gamut, linear light, 16-235, D65 White Point

yesgrey

27th June 2011, 22:48

What I can say is that madVR does not have any out-of-gamma specific processing at all while I know that yCMS has some sort of out-of-gamma special handling.
Correct. That's why we are still working to correct the problems with the yRGB idea. This is an interim solution until we sort out all the problems with yRGB. However, for people whose displays have gamuts wider than BT.709, PAL and NTSC, the current method does not affect them negatively, because there would be no out of gamut colors to handle.;)

cyberbeing

27th June 2011, 22:49

Fixed. Otherwise is that how things are working in madVR 0.66 yesgrey?

yesgrey

27th June 2011, 22:51

Fixed. Otherwise is that how things are working in madVR 0.66 yesgrey?
If I only pointed an error in (7) what do you think?... ;)
Yes.

cyberbeing

27th June 2011, 22:51

This is an interim solution until we sort out all the problems with yRGB. However, for people whose displays have gamuts wider than BT.709, PAL and NTSC, the current method does not affect them negatively, because there would be no out of gamut colors to handle.;)
So this means that for displays with a gamut smaller than the source video gamut, no correction is done in madVR 0.66?

fairchild

30th June 2011, 14:52

Thanks yesgrey and madshi for your work on yCMS + MadVR, new version is working good again.

Can I get a clarification because I think I've confused myself. What is the correct method to setup MadVR + yCMS correctly when outputting from my HTPC to my Panasonic plasma through HDMI?

Do I first go into MadVR and set it up with: disable calibration controls for this display Then using my meter take readings being output by MadVR to my plasma and input those readings into MadVR + yCMS interface?

or

Do I just use the calibrated readings that I achieved by calibrating my plasma TV from my set-top blu-ray player?

I had been using the readings from the latter. (these settings have been providing good image quality for my set-top blu-ray player + my cable HDTV signal + HTPC output (all use HDMI so the settings works accross all devices)).

yesgrey

30th June 2011, 23:22

Do I first go into MadVR and set it up with: disable calibration controls for this display Then using my meter take readings being output by MadVR to my plasma and input those readings into MadVR + yCMS interface?

or

Do I just use the calibrated readings that I achieved by calibrating my plasma TV from my set-top blu-ray player?

For now, both should give the same end result. However, just to be sure, you can measure the final results using madVR and the created 3DLUT and see if the calibration is OK.

Thunderbolt8

1st July 2011, 03:51

when trying to create and use an external 3dlut file for current madvr and ycms versions, are these lines still valid?

Input_Format yRGB RGB_Video 8
Input_Range 32 235

Output_Format HD RGB_Video 16
Output_Transfer_Function 4.5 0.099 0.405 0.018

edit: ok no. but that also doesnt work:

Input_Format yRGB RGB_Video 8
Input_Range 20 235

Output_Format yRGB RGB_Video 16

-.- so how can I now create a valid 3dlut file for madvr 0.66 which uses Input_range 20 235? Im always being told "This 3DLUT file does not match the input format required by madVR."

fairchild

1st July 2011, 05:37

For now, both should give the same end result. However, just to be sure, you can measure the final results using madVR and the created 3DLUT and see if the calibration is OK.

Thanks for the reply, I went ahead and re-measured tonight. My red primary which was over-saturated is now much closer to reference, while green is a bit under-saturated now and blue continues almost spot on too. It also improved my gamma response from an average of 1.71ish to an average of 2.11

So far so good. :thanks:

yesgrey

1st July 2011, 18:51

so how can I now create a valid 3dlut file for madvr 0.66 which uses Input_range 20 235? Im always being told "This 3DLUT file does not match the input format required by madVR."
See madshi instructions. I put a link on the second (http://forum.doom9.org/showthread.php?p=1402013#post1402013) post of this thread...

Thunderbolt8

1st July 2011, 20:38

I read that (which doesnt help me much, because its too complicated for me), but even when I copy his lines 1:1 in the input file, then I get the same error.

so something is missing or wrong, but I dont know what it is.

yesgrey

1st July 2011, 21:51

but even when I copy his lines 1:1 in the input file, then I get the same error.

so something is missing or wrong, but I dont know what it is.
post the file you're using so I can see...

Thunderbolt8

2nd July 2011, 01:35

Input_Primaries 0.640000000000000 0.330000000000000 0.300000000000000 0.600000000000000 0.150000000000000 0.060000000000000 0.31272661468101209 0.32902313032606195
Output_Primaries 0.640000000000000 0.330000000000000 0.300000000000000 0.600000000000000 0.150000000000000 0.060000000000000 0.31272661468101209 0.32902313032606195

Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0

Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0

Input_Range 16 235
Output_Range 16 235

Input_Bit_Depth 8
Output_Bit_Depth 16

Gamut_Measurements 1
1.0 0.640000000000000 0.330000000000000
1.0 0.300000000000000 0.600000000000000
1.0 0.150000000000000 0.060000000000000
1.0 0.312726614681012 0.329023130326062
just copy & pasted the example madshi wrote to get it working somehow.

want to include Input_Range 20 235 at some point, but cannot get it to work with v0.66 even without it -.-

yesgrey

2nd July 2011, 13:44

just copy & pasted the example madshi wrote to get it working somehow.

want to include Input_Range 20 235 at some point, but cannot get it to work with v0.66 even without it -.-
You must be doing something wrong... I've tried creating a 3DLUT with your commands above and madVR v0.66 accepted it. It also accepted one with the 20 235 range like you want.

How are you creating the 3DLUT files? Are you using yCMS v1.11?

Thunderbolt8

2nd July 2011, 15:05

yes.

just the normal way as before, ycms input.txt output.3dlut
and thats it

edit: guess I found the problem, it was in those lines beginning with '#'
they used to be no problem in the past, but apparently now madvr doesnt like them any more. when I deleted those, it got accepted fine.

so whats the most basic command line I can do atm with the current madvr version?
basically, all I need is that input_range line added as only modification. everything else should remain the same/basic.

Input_Format yRGB RGB_Video 8
Output_Format yRGB RGB_Video 16

doesnt seem to work and madshis example line already seems to modify too much (or is this wrong perception?)

yesgrey

2nd July 2011, 16:50

so whats the most basic command line I can do atm with the current madvr version?
Only madshi can answer that, so I suggest you to stick with his example.

Input_Format yRGB RGB_Video 8
Output_Format yRGB RGB_Video 16

doesnt seem to work and madshis example line already seems to modify too much (or is this wrong perception?)
Yes. We are working to solve the problems with the yRGB idea. Currently nobody should use yRGB.

The code from madshi doesn't change anything. Stick to it. You can add your Input_Range 20 235 line if you want, though.

Thunderbolt8

2nd July 2011, 16:54

ok thanks.

afaik those format_input values have to be integer, meaning 20.something wont change anything compared to just 20, right?

yesgrey

2nd July 2011, 18:02

those format_input values have to be integer, meaning 20.something wont change anything compared to just 20, right?
Considering the majority of video sources are limited to 8 bit it would not make much sense. Furthermore, the effect would be negligible, so I prefer to keep it as simple as possible.

Mark_A_W

3rd July 2011, 02:08

The latest madVR version (v0.66) should now finally fix the problems introduced by the last couple releases:

http://madshi.net/madVR.zip

I've once again changed the 3dlut requirements. If you let madVR create the 3dlut for you then you can skip the rest of this post.

If you want to manually create a 3dlut, it should be created like this:

(1) input/output must be RGB video levels
(2) input bitdepth must be 6, 7 or 8 bits
(3) output bitdepth must be 16 bit
(4) input transfer function must be a 2.20 pure power curve
(5) input/output primaries must match the measured gamut
(6) input white point must be D65

madVR v0.66 will refuse to use external 3dluts with different bitdepths. It will also refuse to use external 3dluts which contain the text "RGB_PC" or "YCbCr", or which do *not* contain the "Input_Primaries" command.

Here's an example of how madVR v0.66 itself creates 3dluts now:

Input_Primaries 0.640000000000000 0.330000000000000 0.300000000000000 0.600000000000000 0.150000000000000 0.060000000000000 0.31272661468101209 0.32902313032606195
Output_Primaries 0.640000000000000 0.330000000000000 0.300000000000000 0.600000000000000 0.150000000000000 0.060000000000000 0.31272661468101209 0.32902313032606195

Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0

Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0

Input_Range 16 235
Output_Range 16 235

Input_Bit_Depth 8
Output_Bit_Depth 16

Gamut_Measurements 1
1.0 0.640000000000000 0.330000000000000
1.0 0.300000000000000 0.600000000000000
1.0 0.150000000000000 0.060000000000000
1.0 0.312726614681012 0.329023130326062
Make sure you always replace the last two floating point numbers in "Input_Primaries" with "0.31272661468101209 0.32902313032606195", which is the D65 white point. For the "Output_Primaries" use the measured white point instead.

Please note that this is just the way it *currently* works. I might go back to yRGB sooner or later.

Hi madshi/yesgrey

I'm trying to get the new version working.

I have deleted and let madVR re-download yCMS.

- With 3D LUT created with previous version, I get an error that the 3D LUT does not contain primary colours info (yes it did!).

- After deleting the old 3D LUT, madVR is unable to create a new one. I get a "Creating the 3DLUT for the display blah blah failed" error.

The measurements are the same dodgy ones I had before - for testing only (I'm testing the robustness of your system ;) )

Primaries:

red, Yxy, 5.112, 0.628, 0.337
green, Yxy, 9.018, 0.294, 0.595
blue, Yxy, 1.672, 0.156, 0.078
white, Yxy, 10.833, 0.321, 0.342

Greyscale:

20, Yxy, 0.301, 0.338, 0.349
30, Yxy, 0.179, 0.316, 0.333
40, Yxy, 2.705, 0.311, 0.335
50, Yxy, 5.037, 0.311, 0.340
60, Yxy, 7.476, 0.315, 0.340
70, Yxy, 10.364, 0.320, 0.341
80, Yxy, 10.603, 0.320, 0.341
90, Yxy, 10.749, 0.321, 0.342
100, Yxy, 10.850, 0.321, 0.342

Any ideas? Do you want me to activate debug mode.bat? (How do you deactivate it?)

jmone

5th July 2011, 08:57

I see some posts on X-Rite ColorMunki's new "Display" model and that the output may/may not be compatible with madVR. Do I buy this or the older "Photo" model?
Thanks
Nathan

salora

11th July 2011, 20:11

hi there
I've been following this and using madvr for a while, and I bought an eye one display to use the calibration option

so I took measurements with hcfr colorimeter and entered the data in madvr ycms tool

but everything is getting worth, my reds are more pink for example

it seems ycms and 3Dlut are working in the opposite way than they must do

anyone can help please?

regards

yesgrey

11th July 2011, 21:56

anyone can help please?
Post your measurements and your yCMS config file. If you could also send me your hcfr results file it would be even better.

salora

12th July 2011, 00:03

thank u yesgrey so here is the hcfr measurements, how can I send u the file?

greyscale measurements

% Grey 0 10 20 30 40 50 60 70 80 90 100
X 0,235968 0,346697 0,566339 0,904434 1,213372 1,58459 2,04543 2,568081 3,115475 3,75879 4,413152
Y 0,16129 0,282778 0,518842 0,889592 1,267085 1,706788 2,239217 2,865244 3,515726 4,262369 5,026543
Z 0,242194 0,370251 0,609809 0,974333 1,336218 1,782859 2,307657 2,922225 3,578988 4,326621 5,078697
R 0,396007 0,504242 0,733708 1,077692 1,318141 1,622528 2,035843 2,460827 2,90737 3,471629 4,042527
G 0,083929 0,209838 0,449758 0,832732 1,256504 1,740141 2,314111 3,007493 3,72452 4,532751 5,363346
B 0,236241 0,352984 0,570277 0,898782 1,221501 1,624586 2,096359 2,647369 3,239371 3,91315 4,588663

gamut

Measure Red Green Blue Yellow Cyan Magenta
X 2,183501 1,471347 1,007507 3,462801 2,463016 3,017612
Y 1,289556 2,713232 0,629746 4,210671 3,528374 1,833353
Z 0,385254 0,531081 3,996318 0,706389 4,96012 4,859451
R 4,9016 0,332482 0,304507 4,396823 0,084923 4,538054
G 0,318836 3,685971 0,370936 4,572214 4,438043 0,716456
B 0,265655 0,08976 4,151968 0,080396 4,660443 4,930661

TheElix

12th July 2011, 00:15

I think he's interested in seeing graphs and such (along with the data). You may archive your .chc file and upload it on a some file sharing service. And you forgot to post measurements in your yCMS file.

yesgrey

12th July 2011, 02:51

how can I send u the file?

You may archive your .chc file and upload it on a some file sharing service. And you forgot to post measurements in your yCMS file.
You can do that, or you can e-mail it to me. My e-mail address is at the end of yCMS's manual.

salora

12th July 2011, 07:06

OK
So , yesgrey I sent you the file by email and here is the ycms file generated by madvr

Input_Primaries 0.566 0.334 0.312 0.575 0.179 0.112 0.31272661468101209 0.32902313032606195
Output_Primaries 0.566 0.334 0.312 0.575 0.179 0.112 0.304 0.346

Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0

Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0

Input_Range 16 235
Output_Range 16 235

Input_Bit_Depth 8
Output_Bit_Depth 16

Gamut_Measurements 1
1.290 0.566 0.334
2.713 0.312 0.575
0.630 0.179 0.112
5.027 0.304 0.346

Grayscale_Measurements
0 1 0.161 0.369 0.252
10 1 0.283 0.347 0.283
20 1 0.519 0.334 0.306
30 1 0.890 0.327 0.321
40 1 1.267 0.318 0.332
50 1 1.707 0.312 0.336
60 1 2.239 0.310 0.340
70 1 2.865 0.307 0.343
80 1 3.516 0.305 0.344
90 1 4.262 0.304 0.345
100 1 5.027 0.304 0.346

thank you guys

TheElix

12th July 2011, 09:30

From what I see your calibration is a far cry from being decent. What calibrator did you use? What tutorial? What display have you calibrated?
Also, it seems like your cailbrator gave you false readings on dark patterns (0 and 10). So it's better to avoid using these lines in yCMS to avoid incorrect gamut management.
0 1 0.161 0.369 0.252
10 1 0.283 0.347 0.283

salora

12th July 2011, 09:36

I'm using eye one display with hcfr and hcfr tutorial, it's a panasonic ptae2000

I'm hoping to have time to make others measurements, using curtpalme tutorial.
also it's the data before calibration

yesgrey

12th July 2011, 12:54

here is the ycms file generated by madvr
What display do you have? From what I can see your display has a very narrow color gamut, much smaller than the standard ones, so, a lot of clipping is happening. Therefore, with the current yCMS software you will not gain anything by using it to correct your display's color gamut. I'm planning to add clipping code to overcome situations similar to yours, but considering that the current trend is wider gamuts it's not one of my top priorities...

However, you might still benefit from yCMS by using it to correct your gamma curve. Try creating a 3DLUT with this file:
Input_Primaries 0.6400 0.3300 0.3000 0.6000 0.1500 0.0600 0.31272661468101209 0.32902313032606195
Output_Primaries 0.6400 0.3300 0.3000 0.6000 0.1500 0.0600 0.31272661468101209 0.32902313032606195

Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0

Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0

Input_Range 16 235
Output_Range 16 235

Input_Bit_Depth 8
Output_Bit_Depth 16

Grayscale_Measurements
0 1 0.161 0.369 0.252
10 1 0.283 0.347 0.283
20 1 0.519 0.334 0.306
30 1 0.890 0.327 0.321
40 1 1.267 0.318 0.332
50 1 1.707 0.312 0.336
60 1 2.239 0.310 0.340
70 1 2.865 0.307 0.343
80 1 3.516 0.305 0.344
90 1 4.262 0.304 0.345
100 1 5.027 0.304 0.346
You might also try removing the 0, 10 and 20 IRE lines from grayscale measurements command. It might give you better results in case those values are not that accurate. Some meters aren't very accurate at very low luminance levels...

@madshi
This is a case where a user would benefit from using the Grayscale_Measurements command but not the Gamut_Measurements. The grayscale is flawed but the color gamut is too small, so it's better not to touch it. Of course this is valid only for current yCMS.;)

salora

12th July 2011, 16:14

it's a 4 years old with 1400h of playing, panasonic ptae2000

with your file gamma is better but still my black are going green and my red pink

better give up i think

thank u

yesgrey

13th July 2011, 10:53

with your file gamma is better but still my black are going green and my red pink
Strange... can you try removing also the Grayscale_Measurements command? This way you should get the same picture as before, so, if you're still getting the color changes than something else might be wrong... By the way, are you using madVR v0.66?

salora

13th July 2011, 12:47

yes madvr 0.66

jmone

15th July 2011, 01:10

I see some posts on X-Rite ColorMunki's new "Display" model and that the output may/may not be compatible with madVR. Do I buy this or the older "Photo" model?
Thanks
Nathan

Appologies if this is not the correct thread (if so what would be the correct one)?

jimwhite

16th July 2011, 10:23

Colormunki Display is a colorimeter, not a spectrophotometer like the Colormunki Photo or Design. As such, it is a newer, less costly and less accurate alternative which may or may not be supported in the future.

jmone

17th July 2011, 07:01

Thanks Jim - put an order in for a Colormunki Photo.

Fer

18th July 2011, 18:00

Hi yesgrey

Can you say me the way I have to change my old configuration file in order that can be used to generate an external 3dlut compatible with the new versions of madvr?

This is the file:

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

Gamut_Measurements 1
18.97 0.693 0.304
72.89 0.299 0.692
6.77 0.140 0.053
100.00 0.314 0.329

# Grayscale IRE Measurements
Grayscale_Measurements
10 0 0.247
15 0 0.517
20 0 0.945
25 0 1.468
30 0 2.087
35 0 2.788
40 0 3.554
45 0 4.548
50 0 5.507
55 0 6.522
60 0 7.730
65 0 9.117
70 0 10.642
75 0 12.238
80 0 13.936
85 0 15.821
90 0 17.906
95 0 20.198
100 0 22.373

Gamma_Curve 1.0 2.60

Thank you very much.

yesgrey

18th July 2011, 19:09

Can you say me the way I have to change my old configuration file in order that can be used to generate an external 3dlut compatible with the new versions of madvr?

Use this:

Input_Primaries 0.693 0.304 0.299 0.692 0.140 0.053 0.31272661468101209 0.32902313032606195
Output_Primaries 0.693 0.304 0.299 0.692 0.140 0.053 0.314 0.329

Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0

Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0

Input_Range 16 235
Output_Range 16 235

Input_Bit_Depth 8
Output_Bit_Depth 16

Gamut_Measurements 1
18.97 0.693 0.304
72.89 0.299 0.692
6.77 0.140 0.053
100.00 0.314 0.329

# Grayscale IRE Measurements
Grayscale_Measurements
10 0 0.247
15 0 0.517
20 0 0.945
25 0 1.468
30 0 2.087
35 0 2.788
40 0 3.554
45 0 4.548
50 0 5.507
55 0 6.522
60 0 7.730
65 0 9.117
70 0 10.642
75 0 12.238
80 0 13.936
85 0 15.821
90 0 17.906
95 0 20.198
100 0 22.373

The "Gamma_Curve 1.0 2.60" should be removed because madVR now supports it directly. Enable "Gamma processing" in madVR and use it instead.

Fer

18th July 2011, 23:26

Thank you so much. Your file seems work correctly. Are correct the following?:

-The equivalent to Gamma_Curve 1.0 2.60 in the madvr color & gamma menu is BT.709/ 601 curve.

- I think that I can yet use the Gamma_Curve command in the configuration file in the case that the gamma value I want does not exits in the madvr menu (for example the highest is just 2.60), of course with no enable gamma processing in madvr.

Fer

19th July 2011, 02:05

Unfortunately my preliminary observations were wrong. The following configuration (the calibrated several months ago that gives me a wonderfull image):

A) madVR 0.56 and

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

Gamut_Measurements 1
18.97 0.693 0.304
72.89 0.299 0.692
6.77 0.140 0.053
100.00 0.314 0.329

# Grayscale IRE Measurements
Grayscale_Measurements
10 0 0.247
15 0 0.517
20 0 0.945
25 0 1.468
30 0 2.087
35 0 2.788
40 0 3.554
45 0 4.548
50 0 5.507
55 0 6.522
60 0 7.730
65 0 9.117
70 0 10.642
75 0 12.238
80 0 13.936
85 0 15.821
90 0 17.906
95 0 20.198
100 0 22.373

Gamma_Curve 1.0 2.60

is not equivalent to any of the following:

1) madVR 0.67 and

Input_Primaries 0.693 0.304 0.299 0.692 0.140 0.053 0.31272661468101209 0.32902313032606195
Output_Primaries 0.693 0.304 0.299 0.692 0.140 0.053 0.314 0.329

Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0

Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0

Input_Range 16 235
Output_Range 16 235

Input_Bit_Depth 8
Output_Bit_Depth 16

Gamut_Measurements 1
18.97 0.693 0.304
72.89 0.299 0.692
6.77 0.140 0.053
100.00 0.314 0.329

# Grayscale IRE Measurements
Grayscale_Measurements
10 0 0.247
15 0 0.517
20 0 0.945
25 0 1.468
30 0 2.087
35 0 2.788
40 0 3.554
45 0 4.548
50 0 5.507
55 0 6.522
60 0 7.730
65 0 9.117
70 0 10.642
75 0 12.238
80 0 13.936
85 0 15.821
90 0 17.906
95 0 20.198
100 0 22.373

with enable gamma processing (BT.709/601 curve, 2.60) in the madVR menu.

2) madVR 0.67 and

Input_Primaries 0.693 0.304 0.299 0.692 0.140 0.053 0.31272661468101209 0.32902313032606195
Output_Primaries 0.693 0.304 0.299 0.692 0.140 0.053 0.314 0.329

Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0

Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0

Input_Range 16 235
Output_Range 16 235

Input_Bit_Depth 8
Output_Bit_Depth 16

Gamut_Measurements 1
18.97 0.693 0.304
72.89 0.299 0.692
6.77 0.140 0.053
100.00 0.314 0.329

# Grayscale IRE Measurements
Grayscale_Measurements
10 0 0.247
15 0 0.517
20 0 0.945
25 0 1.468
30 0 2.087
35 0 2.788
40 0 3.554
45 0 4.548
50 0 5.507
55 0 6.522
60 0 7.730
65 0 9.117
70 0 10.642
75 0 12.238
80 0 13.936
85 0 15.821
90 0 17.906
95 0 20.198
100 0 22.373

Gamma_Curve 1.0 2.60

with NO enable gamma processing in the madVR menu.

The observed gamma of the image in case 1) is clearly lower than that of A) (brighter image).

The observed gamma of the image in case 2) is clearly higher than that of A) (darker image).

So, sadly I have to continue with madVR 0.56 and the old color and gamma management.

Thank you so much.

(The measured results of configuration A) are very near to the last images shown in the post number #238).

madshi

19th July 2011, 07:36

Fer

20th July 2011, 03:52

madVR currently applies a correction factor to the gamma value, if you choose a BT.709 transfer function. The BT.709 transfer function is always brighter than the pure power function. The correction factor makes the overall brightness of the BT.709 and pure power curves similar, so if you switch the curve type in madVR (BT.709 <-> pure power), the overall brightness stays the same. The current correction factor is 1.25x, which means if you use a BT.709 curve of 2.6, madVR actually uses a BT.709 curve of 2.6 * 1.25. Try a BT.709 curve with a gamma value of 2.1, that should be near to what you had with madVR v0.56.

yesgrey already asked me to remove this correction factor. I'm not sure if I should or not. If I remove it, I'd have to increase the gamma value range to probably up to 3.0, or even higher. And it would then be much more difficult to quickly compare the different looks of the two curve types.

I have several doubts about the color and gamma management that make now madVR. Perhaps something is wrong. I refer to the configurations of my previous post.

- With the configuration 1) the observed image gamma is clearly lower than that of A). So this fact is against your comment about the correction factor of 2.6 * 1.25 for a BT.709 curve, since such factor would increase the gamma (not decrease as observed).

- Configuration 2) and A) (in both cases the gamma management is made in the yCMS configuration file and not in madVR) should be equivalent, but surprisingly they are not since the observed gamma of the image in case 2) is clearly higher than that of A). Which is the reason? If both yCMS configuration files are equivalent the only explication is that madVR 0.67 treat the external 3dluts files in a different way (wrong way?) than that of madVR 0.56.

So seems to me that there is not a way to reproduce exactly my previous calibrated gamma with the present madVR versions.

Taking this problems into account, it would be possible that new versions of madVR have an option, of something similar, that allows to use the "old" external 3dlut files in the "old" way? Sorry for this kind of petition, but is a little bit frustating that I can not use the very pleasant previous calibration in the future madVR versions.

Thank you so much for your patience.

madshi

20th July 2011, 08:21

With the configuration 1) the observed image gamma is clearly lower than that of A). So this fact is against your comment about the correction factor of 2.6 * 1.25 for a BT.709 curve, since such factor would increase the gamma (not decrease as observed).
When you say "the observed gamma is lower" what do you mean exactly? Do you mean the image got brighter or darker? Have you tried my suggestion to use a 2.1 gamma with a BT.609 curve?

Configuration 2)...
... is not what you're supposed to do.

So seems to me that there is not a way to reproduce exactly my previous calibrated gamma with the present madVR versions.

Taking this problems into account, it would be possible that new versions of madVR have an option, of something similar, that allows to use the "old" external 3dlut files in the "old" way?
You're jumping to conclusions much too early. If there is a problem with the new way (and I'm still not convinced that there is) then let us fix that instead of returning to an old solution. If the new way proves to be broken and if we can't find a way to fix it, THEN we can talk about making the old solution available again.

alph@

20th July 2011, 11:02

I used a sensor x rite and the soft hcfr to calibrate my Sony hx 700,with this result
http://www.zimagez.com/miniature/sonygris.png

config.Ati 5750 panel full rgb 4:4:4-0.255,potplayer,diavc rgb 32,resize ffdshow out yv12 (only for movies if reso is not 1920/1080) lav splitter,madvr 0,67 with function 'calibrate this display use ycms.
http://www.zimagez.com/miniature/ycms.png (http://www.zimagez.com/zimage/ycms.php)

the gamut before corect by ycms
http://www.zimagez.com/miniature/sonygamutavant.png (http://www.zimagez.com/zimage/sonygamutavant.php)
and after corect by ycms
http://www.zimagez.com/miniature/sonygamutapres.png (http://www.zimagez.com/zimage/sonygamutapres.php)
corect is made in the blue green not in the red,I read that ycms can not expand the game only reduct,how to be good with the range of red.
thank for your job yesgrey and madshi:)

madshi

20th July 2011, 11:18

I find it surprising that a lot of people seem to have displays which are short on gamut. I thought most of today's display would have larger primaries than needed, not smaller. Very weird.

@alph@, does your Sony have color controls? Maybe different color modes? You could try to find a color mode which has primaries which are large enough. I'd suggest to set all the Sony color controls to neutral values as a start. Then switch through the different color modes.

alph@

20th July 2011, 12:00

madshi,I tried all modes of sony,(normal,warm 1,warm 2),You think that I could not reach the red gamme,
@alph@, does your Sony have color controls?.
What control, a cms

http://www.zimagez.com/miniature/delta9.png (http://www.zimagez.com/zimage/delta9.php)
the delta E after corect by ycms

yesgrey

20th July 2011, 12:05

- I think that I can yet use the Gamma_Curve command in the configuration file in the case that the gamma value I want does not exits in the madvr menu (for example the highest is just 2.60), of course with no enable gamma processing in madvr.
No, you can't. The Gamma_Curve command should not be used with madVR v0.66+. It should be used the gamma processing option in madVR instead.

- Configuration 2) and A) (in both cases the gamma management is made in the yCMS configuration file and not in madVR) should be equivalent, but surprisingly they are not
They're not equivalent, so it's no surprise. The Gamma_Curve command should not be used.

yesgrey

20th July 2011, 12:14

yesgrey already asked me to remove this correction factor. I'm not sure if I should or not. If I remove it, I'd have to increase the gamma value range to probably up to 3.0, or even higher. And it would then be much more difficult to quickly compare the different looks of the two curve types.
When I saw the comparison between the pure power and the BT.709 gamma curves with equivalent brightness, with the former looking better, I stopped asking you to remove it. However, I still think that you should give the true BT.709 transfer function as an option, because like it is now some people might wrongly assume that a pure power and a BT.709 with the same gamma values are almost the same, and we know that they aren't. ;)

Yes, I know that you don't want that many options inside madVR, and I agree with that on a user-friendliness level, but then some cases like this one from Fer might happen again.;)

yesgrey

20th July 2011, 12:28

corect is made in the blue green not in the red,I read that ycms can not expand the game only reduct,how to be good with the range of red.
It's not only yCMS, the color gamut can never be expanded. That's a hardware limitation of the display.

I find it surprising that a lot of people seem to have displays which are short on gamut. I thought most of today's display would have larger primaries than needed, not smaller. Very weird.
Not quite. Several LCD models still have small gamuts. It should be cheaper?...

You could try to find a color mode which has primaries which are large enough. I'd suggest to set all the Sony color controls to neutral values as a start. Then switch through the different color modes.
Yes, try that. Maybe you are using a color mode which shrinks the original wider gamut to try to fit the standard ones. Your gamut is not very far from the standard, so it might be that.

madshi,I tried all modes of sony,(normal,warm 1,warm 2)
Are those the only modes available? From a quick googling I got these modes:
Picture Mode Vivid / Standard / Custom / Cinema / Game-Standard / Game-Original / Graphics / Sports / Photo-Vivid / Photo-Standard / Photo-Original / Photo-Custom

Have you tried the vivid and the custom ones?

jmone

20th July 2011, 12:28

While waiting for my colormunki to arrive, some newbie questions if you don't mind:

Setup: HTPC / Win7 / nvidia GTS450 --> HDMI --> yami V2700 receiver --> Pio LX607a plasma

Should I make any changes to the default settings in the nvidia config prior to running the colormunki? eg should I:
1) change the format from "Limited" to Full"
2) use the AVSForum "Brightness and Contrast" test clips to adjust Black and White level first or will the yCMS also do this?
3) ??? Other stuff ???

Thanks
Nathan

nevcairiel

20th July 2011, 12:39

Fer

20th July 2011, 12:47

EDIT: According to yesgrey conf. 2) is not option. Disregard conf. 2) in the following.

When you say "the observed gamma is lower" what do you mean exactly? Do you mean the image got brighter or darker? Have you tried my suggestion to use a 2.1 gamma with a BT.609 curve?

I mean the image got brighter and washed out, with less contrast.

With conf. 2) I tried Gamma_Curve 1.0 2.08, where 2.08 is 2.6/1.25 (as I understand you suggest), and the result is different to the old conf. A). Again the observed gamma is lower than A). Even Gamma_Curve 1.0 2.20 gives a little bit lower observed gamma than A).

With conf. 1) the effect of the selection 2.1 gamma with a BT.609 curve in the madVR menu is what would be expected. The observed gamma is lower than with 2.6 gamma with a BT.609 curve in the madVR menu and so much lower than conf. A).

... is not what you're supposed to do.

So the yCMS configuration files of A) and 2) are not equivalent? yCMS generate with them equivalent 3dlut files or not? Is not allowed now the command Gamma_Curve 1.0 in madVR? or they are not equivalent in the final observed gamma curve due to the 1.25 factor and something more that now do madVR?

You're jumping to conclusions much too early. If there is a problem with the new way (and I'm still not convinced that there is) then let us fix that instead of returning to an old solution. If the new way proves to be broken and if we can't find a way to fix it, THEN we can talk about making the old solution available again.

I will be happy if you reach the way that conf. 1) or 2) gives "exactly" the observed or measured gamma curve of the old conf. A).

Thank you so much :thanks:.

Fer

20th July 2011, 12:54

When I saw the comparison between the pure power and the BT.709 gamma curves with equivalent brightness, with the former looking better, I stopped asking you to remove it. However, I still think that you should give the true BT.709 transfer function as an option, because like it is now some people might wrongly assume that a pure power and a BT.709 with the same gamma values are almost the same, and we know that they aren't. ;)

Yes, I know that you don't want that many options inside madVR, and I agree with that on a user-friendliness level, but then some cases like this one from Fer might happen again.;)

Thank you yesgrey for the clarification. I rule out conf. 2) as an alternative.

jmone

20th July 2011, 12:58

Before measuring, you should always do the most basic adjustments with what the TV offers on controls, eg. Black/White level should be as good as you can get them.

Sadly, the NVIDIA option to change Limited to Full does not do what you think it would. It only affects EVR rendering output, not the actual output of the GPU. NVIDIA HDMI defaults to limited RGB, it only does Full Range if you create a custom resolution (or by some trick you have to apply to the driver inf file, i forgot what it was though). I always create me a 24p, 50p and 60p resolution anyway, so i don't suffer from that issue anymore.

Great :( .... FYI I've already had the TV Calibrated by an ISF Tech but I'm a complete nvidia newbie. With ATI GPU, I'd adjust my brightness and contrast using the test clips with it set to Full Range. I did try to do this on the nvidia (using madVR) but it did not seem to make any difference and in the end I had to leave it at Limited to be able to pick detail in dark areas. Does the uCMS only effect colour gamut or does it also adjust contrast / brightness?

Thanks
Nathan

madshi

20th July 2011, 13:04

I mean the image got brighter and washed out, with less contrast.

With conf. 2) I tried Gamma_Curve 1.0 2.08, where 2.08 is 2.6/1.25 (as I understand you suggest), and the result is different to the old conf. A). Again the observed gamma is lower than A). Even Gamma_Curve 1.0 2.20 gives a little bit lower observed gamma than A).

With conf. 1) the effect of the selection 2.1 gamma with a BT.609 curve in the madVR menu is what would be expected. The observed gamma is lower than with 2.6 gamma with a BT.609 curve in the madVR menu.
Ok, to clear this all up a bit, can you make screenshots of a video playing with:

(1) Your old config A).
(2) New config 2) with gamma processing enabled in madVR and set to a BT.709 curve of 2.6.
(3) New config 2) with gamma processing enabled in madVR and set to a BT.709 curve of 2.1.
(4) New config 2) with gamma processing enabled in madVR and set to a pure power curve of 2.6.

I think when we have those images to look at, things might get a bit clearer. Thanks!

(Of course it would help a lot if your screenshots used the same frame, to make things really comparable.)

So the yCMS configuration files of A) and 2) are not equivalent? yCMS generate with them equivalent 3dlut files or not? Is not allowed now the command Gamma_Curve 1.0 in madVR?
The 3dlut files are very different. E.g. the old one was YCbCr -> RGB, while the new one is RGB -> RGB. The whole approach is different. The Gamma_Curve command should not be used for newer madVR versions, anymore, because what Gamma_Curve did when using A) is now done by madVR's "gamma processing". The purpose of this change is that you can switch gamma values and curve types in madVR on the fly now, which of course is much more comfortable than creating various 3dlut files with different gamma curves/values.

Fer

20th July 2011, 13:20

madshi

20th July 2011, 13:39

Sorry yes, meant 1).

yesgrey

20th July 2011, 14:08

Does the uCMS only effect colour gamut or does it also adjust contrast / brightness?
I guess you meant yCMS.;)

You can use it to adjust contrast / brightness, but that would be sub-optimal. contrast / brightness should be adjusted on the display because that's the only way for you to use its full dynamic range, otherwise you will use only a small part of it.

Let's imagine your display's ON/OFF contrast ratio is 10,000:1. If you have your contrast / brightness controls bad adjusted you might end up with a lower contrast ratio. Of course yCMS could change the image so that you would be able to full all colors without any clipping, but that would be at the cost of part of the contrast ratio, and your black level would be much higher than it could be, or the display would look dimmer than it could.

The only controls that you should set-up before using yCMS are these two, exactly to allow you to use the full dynamic range of the display.

alph@

20th July 2011, 19:31

http://www.zimagez.com/miniature/gamma5.png

after corect by ycms the gamma curve is unbalanced,in madvr 'pure power curve at 2.20'

http://www.zimagez.com/miniature/gamut0.png (http://www.zimagez.com/zimage/gamut0.php)

the corect is good in green,But the Reds were reduced

http://www.zimagez.com/miniature/gamutgraph.png (http://www.zimagez.com/zimage/gamutgraph.php)

the red delta is 2.3 before corect and 5.6 after why?

Fer

20th July 2011, 23:46

Ok, to clear this all up a bit, can you make screenshots of a video playing with:

(1) Your old config A).
(2) New config 2) with gamma processing enabled in madVR and set to a BT.709 curve of 2.6.
(3) New config 2) with gamma processing enabled in madVR and set to a BT.709 curve of 2.1.
(4) New config 2) with gamma processing enabled in madVR and set to a pure power curve of 2.6.

(1) The old config A):

http://img27.imageshack.us/img27/8892/13181498.th.jpg (http://imageshack.us/photo/my-images/27/13181498.jpg/)

(2) New config 1) with gamma processing enabled in madVR and set to a BT.709 curve of 2.6:

http://img405.imageshack.us/img405/4099/bt2601.th.jpg (http://imageshack.us/photo/my-images/405/bt2601.jpg/)

(3) New config 1) with gamma processing enabled in madVR and set to a BT.709 curve of 2.1:

http://img52.imageshack.us/img52/2452/bt2101.th.jpg (http://imageshack.us/photo/my-images/52/bt2101.jpg/)

(4) New config 1) with gamma processing enabled in madVR and set to a pure power curve of 2.6:

http://img37.imageshack.us/img37/3313/pp2601.th.jpg (http://imageshack.us/photo/my-images/37/pp2601.jpg/)

(5) New config 1) with gamma processing enabled in madVR and set to a pure power curve of 2.2:

I have added this screenshot since the experimental data of the measured gamma for config A) adjust to a pure power curve with an average gamma value of about 2.20 (see the measurements of post #238 for a Gamma_Curve 1.0 2.55). So this screenshot should be similar to the screenshot (1). As you can see both are very similar. This fact seems to indicate that the implementation that madVR makes of pure power curves for gamma mangement is correct.

http://img155.imageshack.us/img155/9577/pp2201.th.jpg (http://imageshack.us/photo/my-images/155/pp2201.jpg/)

madshi

21st July 2011, 07:31

Thanks, those are interesting images. FWIW, if you set madVR to a pure power curve of 2.2, neither madVR nor yCMS are practically doing any gamma curve/value changes at all. Try disabling gamma processing in madVR. The image should look exactly like that with a pure power curve of 2.2.

After looking at those images I'm wondering whether yCMS or madVR do not handle the BT.709 gamma curve correctly. What do you think, yesgrey?

@Fer, could you do one more test: With your old config A), can you make a screenshot with Gamma_Curve 1.0 2.6 (wait, you already have) and another one with A) and Gamma_Curve 0.0 2.2? Please make sure you screenshot *exactly* the same frame. Then we can check if there's any difference at all. The screenshots of A) 1.0 2.6 looks pretty much identical to 1) 0.0 2.2 to me. So I'm kinda wondering whether A) 1.0 2.6 used a pure power curve of 2.2 for some weird reason?

Fer

21st July 2011, 07:59

@Fer, could you do one more test: With your old config A), can you make a screenshot with Gamma_Curve 1.0 2.6 (wait, you already have) and another one with A) and Gamma_Curve 0.0 2.2? Please make sure you screenshot *exactly* the same frame. Then we can check if there's any difference at all. The screenshots of A) 1.0 2.6 looks pretty much identical to 1) 0.0 2.2 to me. So I'm kinda wondering whether A) 1.0 2.6 used a pure power curve of 2.2 for some weird reason?

I will take the frame later, but although the static frames (1) and (5) are very similar, during movie playback a difference can be observed. Config (1) shows a little bit more depth and sharpness. So I think that (1) and (5) do not give exactly the same gamma curve. The difference must be subtle but it have an observable impact. Nevertheless the config of (5) may be also an interesting option for the movie playback.

:thanks:

Fer

21st July 2011, 18:17

@Fer, could you do one more test: With your old config A), can you make a screenshot with Gamma_Curve 1.0 2.6 (wait, you already have) and another one with A) and Gamma_Curve 0.0 2.2? Please make sure you screenshot *exactly* the same frame. Then we can check if there's any difference at all. The screenshots of A) 1.0 2.6 looks pretty much identical to 1) 0.0 2.2 to me. So I'm kinda wondering whether A) 1.0 2.6 used a pure power curve of 2.2 for some weird reason?

(6) The old config A) with Gamma_Curve 0.0 2.2 instead of Gamma_Curve 1.0 2.6:

http://img88.imageshack.us/img88/9393/a1pp220.th.jpg (http://imageshack.us/photo/my-images/88/a1pp220.jpg/)

The frame is similar to (1) and (5) frames of the previous post.

madshi

21st July 2011, 18:55

Unfortunately the old config A) with 2.6 is a different frame. Anyway, from what I can see, the following three images appear to have exactly the same gamma curve:

- old config 2.6 BT.709 curve
- old config 2.2 pure power curve
- new config 2.2 pure power curve

I can't see any difference in gamma between these images. And that means that IMHO you never really used a 2.6 BT.709 curve. You actually used a 2.2 pure power curve, without knowing it. At least that's my current impression...

@yesgrey?

yesgrey

21st July 2011, 19:48

the red delta is 2.3 before corect and 5.6 after why?
This is a recurrent question, so I think it's time for me to create a FAQ. I will try to do it soon, stay tuned.;)

yesgrey

21st July 2011, 20:21

After looking at those images I'm wondering whether yCMS or madVR do not handle the BT.709 gamma curve correctly. What do you think, yesgrey?
I think both are handling it correctly.

and another one with A) and Gamma_Curve 0.0 2.2?
@Fer,
Could you do one more with Gamma_Curve 0.0 2.1?
Thanks.

So I'm kinda wondering whether A) 1.0 2.6 used a pure power curve of 2.2 for some weird reason?
I think that didn't happen. Maybe on that frame a BT.709 2.6 looks similar to a pure power 2.2.

from what I can see, the following three images appear to have exactly the same gamma curve:

- old config 2.6 BT.709 curve
- old config 2.2 pure power curve
- new config 2.2 pure power curve

I can't see any difference in gamma between these images. And that means that IMHO you never really used a 2.6 BT.709 curve. You actually used a 2.2 pure power curve, without knowing it. At least that's my current impression...
Let's wait for the image I requested before taking any conclusions...

Fer

21st July 2011, 23:08

@Fer,
Could you do one more with Gamma_Curve 0.0 2.1?
Thanks.

Here is the screenshot.

(7) The old config A) with Gamma_Curve 0.0 2.1 instead of Gamma_Curve 1.0 2.6:

http://img829.imageshack.us/img829/9853/a1pp210.th.jpg (http://imageshack.us/photo/my-images/829/a1pp210.jpg/)

As could be expected the frame is different to (6) (Gamma_Curve 0.0 2.2). Now the image has lower contrast due to a lower gamma.

I think that didn't happen. Maybe on that frame a BT.709 2.6 looks similar to a pure power 2.2.

I agree with you. As I said before, although the static frames (1) and (5) are very similar, during movie playback a difference can be observed between both gamma curves.

jmone

22nd July 2011, 06:09

I'm stuggling (I still don't get it). I have my colormunki but just dont really know where to start (again if this is the wrong thread for a newbie please point me to the correct one). I 'assume' that I need to:
1) Create a custom res in the nvidia panel and switch it to Full Range
2) Use the colormunki SW to create and apply Colour Profile (ICM) for my TV in Windows 7 (I can see the output change at this point), but: ColorMunki SW during calibration wants me to change the Brightness and Contrast settings of the TV, do I do this on the TV itself OR via the nvidia control panel?
3) If the TV now has a ICM setup what is the purpose of yCMS in madVR and how to I extract the data from ColorMunki (or the ICM it created)

Thanks
Nathan

nvidia GTS450 --> HDMI --> Yami V2700 --> HDMI --> Pio LX608a Plasma (was professionally calilbrated a few years ago but will not doubt be off by now)

nevcairiel

22nd July 2011, 07:24

I didn't create any ICM profile.

What i did, basically:
1) Custom resolution for 24p, 50p and 60p
2) Setup Black/White point using display in-built controls
3) Measure gray-scale using ColorHCFR
4) Adjust gray-scale settings using TV in-built constrols until its much closer to the target (i have 10-point IRE settings in the TV, as well as 2-point settings - i'm using the 2 point now, it was much simpler to setup, and gives a pretty good result)
5) Confirm Black/White point are still good, if not, go back to 2)
6) Measure gray-scale and primaries with ColorHCFR
7) Enter results in madVR to create a 3DLUT

Tada!

You could add an extra point between 6 and 7, adjusting primaries in your display, if it offers those options. Any settings you can do in your display will usually be better then correcting through the 3DLUT.

Measuring in ColorHCFR was done using the AVS calibration videos running directly in madVR, which was switched to doing no calibration by itself.
I do however not know if ColorMunki is supported by ColorHCFR.

jmone

22nd July 2011, 07:43

Thanks nevcairiel - off to read about ColorHCFR and if Colormunki is supported!

madshi

22nd July 2011, 08:16

I think both are handling it correctly.
Sorry, but I disagree. We have a screenshot from the old config with a BT.709 2.6 gamma, and we have a screenshot from the new config with a BT.709 2.1 gamma (2.1 * 1.25 correction factor = 2.625), and they're noticeably different. The 2.625 image isn't just brighter, it has that grayer look to it, that the BT.709 curve always seems to produce with the newer madVR versions. I believe there must be a problem in either yCMS or in madVR.

@Fer, sorry for asking you for yet another screenshot, but could you do one with the new config with a BT.709 gamma curve and a gamma value of 2.05? That way we would have the following 3 screenshots to compare:

(1) old config, BT.709 curve, 2.6000
(2) new config, BT.709 curve, 2.6250
(3) new config, BT.709 curve, 2.5625

If (1) is right in the middle between (2) and (3) then everything seems to be fine. But I rather think that both (2) and (3) will have a different look to them compared to (1). Which would mean that either yCMS or madVR has a bug (or both).

yesgrey

22nd July 2011, 10:59

@Fer, sorry for asking you for yet another screenshot, but could you do one with the new config with a BT.709 gamma curve and a gamma value of 2.05?
Even better would be a screenshot of the old config with a 2.625 value, by using Gamma_Curve 1.0 2.625, this way we can compare exactly the same gamma curves via old and new configs.

madshi

22nd July 2011, 11:34

Yeah, good thinking.

salora

22nd July 2011, 12:03

Strange... can you try removing also the Grayscale_Measurements command? This way you should get the same picture as before, so, if you're still getting the color changes than something else might be wrong... By the way, are you using madVR v0.66?

I was thinking maybe there is something wrong in my computer settings, because I downloaded measurements from hcfr forum of my display and the gamut is normal

so here is my settings

I use MPC-HC with ffdshow video decoder output set to YV12, and madvr 0.66 set on tv display range
I have a Nvidia GT520 graphic cards set on rgb display for the desktop and set on "control by player" for the video settings
is there something wrong?
thanks

Fer

22nd July 2011, 13:44

@Fer, sorry for asking you for yet another screenshot, but could you do one with the new config with a BT.709 gamma curve and a gamma value of 2.05? That way we would have the following 3 screenshots to compare:

(1) old config, BT.709 curve, 2.6000
(2) new config, BT.709 curve, 2.6250
(3) new config, BT.709 curve, 2.5625

If (1) is right in the middle between (2) and (3) then everything seems to be fine. But I rather think that both (2) and (3) will have a different look to them compared to (1). Which would mean that either yCMS or madVR has a bug (or both).

(8) The old config A) with Gamma_Curve 1.0 2.6:

http://img194.imageshack.us/img194/9009/a1bt2600.th.jpg (http://imageshack.us/photo/my-images/194/a1bt2600.jpg/)

(9) The old config A) with Gamma_Curve 1.0 2.625:

http://img854.imageshack.us/img854/8070/a1bt2625.th.jpg (http://imageshack.us/photo/my-images/854/a1bt2625.jpg/)

(10) New config 1) with gamma processing enabled in madVR and set to a BT.709 curve of 2.05 (two near frames to falicitate comparison):

http://img684.imageshack.us/img684/7862/bt2051a.th.jpg (http://imageshack.us/photo/my-images/684/bt2051a.jpg/)

http://img836.imageshack.us/img836/7952/bt2051b.th.jpg (http://imageshack.us/photo/my-images/836/bt2051b.jpg/)

madshi

22nd July 2011, 13:54

Ok, thanks. So clearly, as I said earlier, either yCMS has a bug or madVR, or both. yesgrey, can you investigate?

alph@

22nd July 2011, 17:43

Not quite. Several LCD models still have small gamuts. It should be cheaper?...
hello yesgrey,the sony is supposed to be wide gamut http://www.neox.fr/Televions-Hi-Fi-Home-cinema/Televisions/TV-LCD/46-pouces/Sony/KDL-46HX700/KDL46HX700AEP/809386.html#_index :confused:
This is a recurrent question, so I think it's time for me to create a FAQ. I will try to do it soon, stay tuned.;)
yes,thanks it's necessary.

yesgrey

23rd July 2011, 21:07

I use MPC-HC with ffdshow video decoder output set to YV12, and madvr 0.66 set on tv display range
madVR 0.66 is not working correctly with the 3DLUT. Try with the last one and let me know if everything is working fine.

Sorry, I've missed your post when you stated the version you were using.

yesgrey

23rd July 2011, 21:08

(8) The old config A) with Gamma_Curve 1.0 2.6:
(9) The old config A) with Gamma_Curve 1.0 2.625:

Ok, thanks. So clearly, as I said earlier, either yCMS has a bug or madVR, or both. yesgrey, can you investigate?
Definitely there should be something wrong. I will look into it.

yesgrey

23rd July 2011, 21:13

hello yesgrey,the sony is supposed to be wide gamut http://www.neox.fr/Televions-Hi-Fi-Home-cinema/Televisions/TV-LCD/46-pouces/Sony/KDL-46HX700/KDL46HX700AEP/809386.html#_index :confused:
Well, it is wider than other LCD screens, unfortunately it seems to be not enough to fully cover the BT.709 standard...

The only thing that you could do is measuring the primaries for each of the colour modes the display has and see if there is any setting with a wider color gamut. If the gamut is the same in all modes so there is nothing that can be done. :(

alph@

23rd July 2011, 21:35

The only thing that you could do is measuring the primaries for each of the colour modes the display has and see if there is any setting with a wider color gamut. If the gamut is the same in all modes so there is nothing that can be done. :(
all modes give the same gamut,next time I would be careful before purchasing a display,it is very difficult to find the gamut range of a display in the net.

yesgrey

23rd July 2011, 22:32

next time I would be careful before purchasing a display
Don't worry about it, it's pretty close to BT.709. You're only missing a little of red, but those highly saturated reds usually only appear in CGI films, so it shouldn't be a big issue on your daily usage.

salora

24th July 2011, 07:53

madVR 0.66 is not working correctly with the 3DLUT. Try with the last one and let me know if everything is working fine.

Sorry, I've missed your post when you stated the version you were using.

don't worry for that

about madVR 0.67 I read that there are bugs too , and maybe in yCMS also, so it maybe better to wait for others bugfree versions?

and will it make a there a difference if I set the output of ffdshow to RGB32 or others? to my gamut I mean, because as i said earlier my display does have a wide gamut (when it's new, mine is old could be that?)
thank u

alph@

29th July 2011, 18:42

for dvd pal, what color space should I use in Colorhcfr 'Pal/ Secam or sdtv rec 601'.and what are the 'view images(red, green,blue,white) that I should use for dvd pal.

yesgrey

29th July 2011, 23:06

for dvd pal, what color space should I use in Colorhcfr 'Pal/ Secam or sdtv rec 601'.
Pal/Secam

what are the 'view images(red, green,blue,white) that I should use for dvd pal.
Could you be more specific about what are you intending to do?

alph@

30th July 2011, 16:46

thanks for your reply yesgrey

Pal/Secam

Could you be more specific about what are you intending to do?
for play dvd pal and correct gamut ,i use this 'mires' http://www.mediafire.com/?oc8zsn4llgsvyex ,(100% saturation),I found nothing else,is it good.

yesgrey

30th July 2011, 18:06

for play dvd pal and correct gamut ,i use this 'mires'
OK, I think you are trying to calibrate for each of your sources, but you don't need to do that. You only need to calibrate to one of them, and then madVR will automatically adapt each source to look accurate on your display.

nand chan

8th August 2011, 18:46

I must ask again, is there any plan of including the option of creating a 3dLUT from an ICC profile? What about .ti3 (http://www.argyllcms.com/doc/ti3_format.html) files?

I need this because my profiling software (ArgyllCMS) only outputs these two types of file to hold profiling information, from which I want to create a .3dlut to work with madVR.

Mr Alpha

8th August 2011, 21:24

Mark_A_W

8th August 2011, 22:44

Hi madshi/yesgrey

I'm trying to get the new version working.

I have deleted and let madVR re-download yCMS.

- With 3D LUT created with previous version, I get an error that the 3D LUT does not contain primary colours info (yes it did!).

- After deleting the old 3D LUT, madVR is unable to create a new one. I get a "Creating the 3DLUT for the display blah blah failed" error.

The measurements are the same dodgy ones I had before - for testing only (I'm testing the robustness of your system ;) )

Primaries:

red, Yxy, 5.112, 0.628, 0.337
green, Yxy, 9.018, 0.294, 0.595
blue, Yxy, 1.672, 0.156, 0.078
white, Yxy, 10.833, 0.321, 0.342

Greyscale:

20, Yxy, 0.301, 0.338, 0.349
30, Yxy, 0.179, 0.316, 0.333
40, Yxy, 2.705, 0.311, 0.335
50, Yxy, 5.037, 0.311, 0.340
60, Yxy, 7.476, 0.315, 0.340
70, Yxy, 10.364, 0.320, 0.341
80, Yxy, 10.603, 0.320, 0.341
90, Yxy, 10.749, 0.321, 0.342
100, Yxy, 10.850, 0.321, 0.342

Any ideas? Do you want me to activate debug mode.bat? (How do you deactivate it?)

Fixed it.

Should be:

30, Yxy, 1.179, 0.316, 0.333

However I'm still getting the fluro greens happening in white. I will look for another bad value.

nand chan

8th August 2011, 23:14

I found making the 3dLUT from the ti3 file created by ArgyllCMS by hand using madVR's interface relatively trivial. You can open the ti3 file in a texteditor of your choice and then just copy/paste the results.

Oh? Is there something I'm missing here? Where would I insert this information and how?

Afaik madVR's yCMS interface only allows me to insert the primary coordinates as well as a grayscale ramp.

How do I parse a full LUT?

Also, I guess I could find out the structure of madVR's .3dlut files, then write a custom interpolation engine + YUV convertor, but it would probably be nowhere near as clean. I suppose I could use the same libraries yCMS used for interpolation.

cyberbeing

9th August 2011, 00:58

How do I parse a full LUT?

You don't, since measured Primaries + Whitepoint + Grayscale is all yCMS currently uses for creating its LUT. Supporting more measurements has been something on yesgrey's todo list for quite awhile.

As I've stated previously, if anybody with the necessary coding knowledge can hack at ArgyllCMS colorprof to output a 3DLUT using modified ArgyllCMS XYZ LUT AtoB/BtoA tables as a base, that would be optimal from a calibration workflow standpoint. It should be easier now that madVR 3DLUTs are working in RGB->RGB, but that could change back to yRGB at some point. In any case, there is no longer any need for a 3DLUT doing YUV->RGB when using madVR.

yesgrey

9th August 2011, 01:01

However I'm still getting the fluro greens happening in white. I will look for another bad value.
Your primaries measurements are strange... The R,G,B luminances sum should equal the white luminance, but in your case they are very different...

yesgrey

9th August 2011, 01:07

I must ask again, is there any plan of including the option of creating a 3dLUT from an ICC profile?
It's on my todo list, but I don't have any idea when I will have time to do it.

Mark_A_W

9th August 2011, 01:48

Your primaries measurements are strange... The R,G,B luminances sum should equal the white luminance, but in your case they are very different...

Thanks yesgrey, I will check them again. Remeasure if I don't find any mistakes in transposing the numbers.

I have an old CRT projector....it has some quirks. I am a test case for the robustness of your software...

But it still looks fantastic - only in the last year have digitals started to perform better than my 14 year old CRT (and they STILL can't do a full fade to black).

nand chan

9th August 2011, 02:17

You don't, since measured Primaries + Whitepoint + Grayscale is all yCMS currently uses for creating its LUT. Supporting more measurements has been something on yesgrey's todo list for quite awhile.

As I've stated previously, if anybody with the necessary coding knowledge can hack at ArgyllCMS colorprof to output a 3DLUT using modified ArgyllCMS XYZ LUT AtoB/BtoA tables as a base, that would be optimal from a calibration workflow standpoint. It should be easier now that madVR 3DLUTs are working in RGB->RGB, but that could change back to yRGB at some point. In any case, there is no longer any need for a 3DLUT doing YUV->RGB when using madVR.

Ah, right, I see what you mean - yeah, that's what I'm currently doing - measuring the primaries manually and inputting them + the grayscale ramp to yCMS.

Also, what's so hard about using YUV->RGB instead of RGB->RGB? Isn't the YUV color space mathematically identical to the RGB color space? Conversion is relatively straightforward and well-defined (http://en.wikipedia.org/wiki/YUV#Conversion_to.2Ffrom_RGB)

All you need to do is create a regular 3dLUT for sRGB->XYZ (which can be done mathematically) and change each R/G/B entry to Y/U/V using the described formulae (resulting in a YUV->XYZ), then go through each entry and find the closest match to the given XYZ in the monitor's interpolated output profile (as derived from .ti3 as RGB->XYZ), and write that R/G/B value into the final stage of the YUV->RGB 3dlut.

You don't even have to bring the grayscale into the equation, unless I'm mistaken.

I don't quite know how to do the correct interpolation myself, especially not using derived gamma functions.

Finding the nearest match in 3d space would also potentially pose a large performance problem when dealing with 1.07 billion entries, especially if using an O(n²) algorithm and using trigonometric distance functions to sort (though that can be skipped for the vast majority of entries by simply filtering out values which deviate too far in at least one axis).

Though, if you have the memory for it, I suppose you could create a three dimensional BST (that is, a BST containing BSTs containing a BST each) and use a recursive algorithm to find all points that are likely to be matches.

How does ICC do it, either way? If you want an easy way out, you could use argyllCMS's collink.exe utility to link the device profile to the virtual sYUV profile (as calculated from sRGB), then just map each value from 0/0/0 to 1023/1023/1023 through it. This way you can also take care of things like rendering intents (some people would really like perceptual mode instead of absolute colorimetric).

Ps. How deep is the bit-depth of madVR's 3dLUTs either way? 8 bit? 10 bit? 16 bit?

A nice 16 bit YUV -> RGB conversion 3dlut would be the ideal solution, with post-dithering down to the maximum bit-depth supported by the graphics card, which is unfortunately only 10.

It's on my todo list, but I don't have any idea when I will have time to do it.

How about an option to format a .3dlut file from a text list of R/G/B -> R/G/B or Y/U/V -> R/G/B entries? That way I can implement the logic myself by using existing ICC libraries.

nand chan

9th August 2011, 15:45

Hmm, whenever I add the grayscale info from the .ti3, my image looks up very distorted afterwards and I doubt it's supposed to look that way.

For comparison:

Before (just gamut correction) (http://img840.imageshack.us/img840/7815/beforem.jpg)
After (gamut correction + grayscale) (http://img847.imageshack.us/img847/7430/afterm.jpg)

Grayscale info I used (http://pastebin.com/KpwAPGVf)

Also, I left the ICM profile generated by ArgyllCMS as default in the Windows color management - I figured this would be correct since the profiling was done while the profile was active, no?

Edit: Solved this problem already, was using the wrong values

nand chan

12th August 2011, 18:43

Having done some further into research into ICC profiles, I can understand why you aren't supporting them yet - they're *awful* for gamut conversion!

But yeah, I would like an option to generate my own .3dlut files from a list of RGB->RGB or YUV->RGB entries. That way I can take care of gamut conversion out-of-program by creating an abstract link ICC profile and feeding values through it.

I already have a system in place that generates a 4096x4096 .tiff file and applies the gamut conversion / value mapping to it using argyllCMS, so I never have to touch any ICC code myself.

Garma

21st August 2011, 06:02

I've tried calibrating my laptop's monitor with yCMS but I was unable to. My monitor's brand is InnoLux (I think it's a Chinese brand).
My ICC profiles (according to W7) are sRGB IEC61966-2.1 and Adobe RGB (1998) D65 WP 2.2 Gamma. My video card is an ATI Mobility Radeon GD 4500/5100 Series.
I've tried getting those values with ICC Profile Inspector and imputing them in MadVR's yCMS calibration, but ultimately it told me it couldn't work because of my monitor.

yesgrey

21st August 2011, 13:12

it told me it couldn't work because of my monitor.
"It" who? ICC Profile Inspector or yCMS?

Garma

21st August 2011, 14:52

yCMS. Right after I put my data and saved it, MadVR told me it had to download something, then once it downloaded it, it told me it couldn't work.

yesgrey

21st August 2011, 17:02

yCMS. Right after I put my data and saved it, MadVR told me it had to download something, then once it downloaded it, it told me it couldn't work.
Post the data you used with madVR.

nand chan

22nd August 2011, 20:48

Posting this here because it's been suggested:

TI3 Parser toolset (http://forum.doom9.org/showthread.php?t=162285)

The TI3 Parser toolset is a small collection of tools (with a graphical user front-end) that allow easy integration of ArgyllCMS and yCMS, by, amongst other features, generating a .3dlut from a .ti3 profile file.

Garma

23rd August 2011, 01:35

Post the data you used with madVR.
For format, I used XYZ.

As for the values:
For rXYZ
X - 0.43607
Y - 0.22249
Z - 0.01392

For gXYZ
X - 0.38515
Y - 0.71687
Z - 0.09708

For bXYZ
X - 0.14307
Y - 0.06061
Z - 0.71410

For wtpt
X - 0.95045
Y - 1.00000
Z - 1.08905

I took these values from the sRGB IEC61966-2.1 ICC profile.

6233638

29th September 2011, 11:33

I'm wondering, is there any way to create a hand-crafted 3DLUT file?

What I would like to do, is measure my display and set it up to be the very best it can. I'd like to input the exact RGB values from 20-100% grey in 10%, or possibly 5%, steps (I have found that anything below about 20% in madVR causes posterisation/banding) that result in D65 at my desired gamma, and have yCMS fill in the rest.

I was previously doing this with a VideoEQ (http://avfoundry.com/VideoEq/index.php) and got much better results than when I simply input xyY or XYZ values and had it calculate a LUT based on that. Unfortunately while it worked great for greyscale & gamma, I found the CMS to be useless and the lack of inputs to be problematic, so I ended up selling it.

I would like to do this for primary and secondary colours too. Because it uses white LEDs, my display is not the greatest for colour. But what I have tested and confirmed is that if I turn up the colour control enough so that the least saturated colour is now enough (color from 50 to 65 seems to sort out green) I can get almost perfect colour from it by tweaking the RGB values of colour patches—much better results than I seem to be getting from simply inputting xyY values into madVR.

This would probably need RGB values taken from 25/50/75/100% brightness measurements, and probably saturation ones too, to linearise the response.

Does that sound possible at all?

nand chan

29th September 2011, 16:46

alph@

29th September 2011, 20:08

6233638,i try videoequalizer for corrected my gamma curve,how correct the gamma curve without damaging the gray balance?how did you processed.

Portioli

17th October 2011, 23:21

hello to everybody..

which is the best user-friendly colorimeter for measuring primaries for yCMS?

&

one more question,
if i own either a gamut monitor (& standard 709 PJ) and i have colorimeter i have to profiling/calibrating only in sRGB
both displays?

6233638

18th October 2011, 08:02

I find it surprising that a lot of people seem to have displays which are short on gamut. I thought most of today's display would have larger primaries than needed, not smaller. Very weird.Most, if not all white LED backlit displays do not cover the BT.709 gamut.

Higher-end CCFL displays were able to exceed the BT.709 gamut (for example, Sony's WCG-CCFL BRAVIAs) but modern CCFL tends to have an even more limited gamut than white LED.

Is there any way to specify output RGB values in a 3DLUT, or some way of having that feature added?

My current LCD is one of those white LED displays (though it's backlit rather than edge lit, which helps) and if I enable the "Live Colour" mode and turn up saturation to 60, the gamut exceeds spec on Green, almost gets there on Red (<1dE'94) and still falls short on Blue, compared to falling short on all three when set correctly. (50 colour, Live Colour disabled)

Because I have to resort to this in order to almost cover the BT.709 gamut, simply inputting my primaries doesn't quite work for a good calibration.

I really need to be able to tweak my output RGB values for 100% RGBCMY, and it would most likely need 25, 50 and 75% saturation values as well in order to linearise things.

Same goes for greyscale/gamma. The results are good but not perfect with the automatically generated LUT. I know that my display can have a perfect gamma when manually tweaked, but the necessary control just doesn't seem to be there with 3DLUTs right now. (or at least I haven't been able to figure it out)

nand chan

18th October 2011, 15:00

Is there any way to specify output RGB values in a 3DLUT, or some way of having that feature added?

Not in yCMS to my knowledge, but the spec itself is quite capable of it, yes. What I would suggest doing here is crafting a custom .3dlut which specifies BT.709 primaries as input (by default yCMS will use your monitor primaries here and madVR will scale output to those already), which will make madVR not touch the values further.

Then you can just do a mapping of each BT.709 RGB -> your monitor RGB manually (the input gamma is exactly 2.2 PPC, the output will not be further adjusted). Then you also have to make sure to clear your video card's CLUTs during playback (eg. by making sure the ICC profile loaded in Windows does /not/ contain CLUT information).

You can use any software eg. ArgyllCMS to take a large list of measurement patches for your monitor (in the .ti3 format) and generate an ICC profile that will do this mapping for you, then generate a .3DLUT from this ICC profile (eg. using LittleCMS).

6233638

18th October 2011, 23:19

Not in yCMS to my knowledge, but the spec itself is quite capable of it, yes. What I would suggest doing here is crafting a custom .3dlut which specifies BT.709 primaries as input (by default yCMS will use your monitor primaries here and madVR will scale output to those already), which will make madVR not touch the values further.

Then you can just do a mapping of each BT.709 RGB -> your monitor RGB manually (the input gamma is exactly 2.2 PPC, the output will not be further adjusted).I don't understand—how would you do the output mapping manually? That's what I'm trying to do.

You can use any software eg. ArgyllCMS to take a large list of measurement patches for your monitor (in the .ti3 format) and generate an ICC profile that will do this mapping for you, then generate a .3DLUT from this ICC profile (eg. using LittleCMS).I have measurements already, and know exactly what RGB values are required to be sent to my display for perfect colour reproduction. (had photoshop running on one half of the screen, calman on the other, and adjusted color patches to get the exact RGB values needed)

I've yet to find any commercial package that can do as good a job with automated measurements as hand-tuning the RGB values can, I would be surprised if argyllcms does, especially when it does not include functions such as calman's low-light handling (more than simple averaging) for consistently repeatable readings.

I tried ArgyllCMS in the past, before turning to commercial packages (so far the best results I have had, have been with ColorEyes Display Pro) as I did not find its automated calibration to give acceptable results.

The main problem here, is that I don't think the "Live Colour" mode on this TV, which is required to expand the gamut, is a linear saturation/gamut boost. I haven't measured it yet, but I would not be surprised at all if it was non-linear.

Correcting for 100% saturation helps, but the display's colour response would still be non-linear.

It is possible to correct for this with LUTs, and I can get all the required data for it, but I just don't know how to create a 3DLUT file that does this correctly.

I don't know if development for yCMS, or madVR's interface with yCMS has halted or not though, things don't seem to have been updated for a while now.

I just don't understand why it works by giving it your display's primaries and measurements, and then calculating what it thinks is best. That seems like the least accurate way possible to create a LUT.

nand chan

19th October 2011, 17:00

I don't understand—how would you do the output mapping manually? That's what I'm trying to do.

I have measurements already, and know exactly what RGB values are required to be sent to my display for perfect colour reproduction. (had photoshop running on one half of the screen, calman on the other, and adjusted color patches to get the exact RGB values needed)

I've yet to find any commercial package that can do as good a job with automated measurements as hand-tuning the RGB values can, I would be surprised if argyllcms does, especially when it does not include functions such as calman's low-light handling (more than simple averaging) for consistently repeatable readings.

I tried ArgyllCMS in the past, before turning to commercial packages (so far the best results I have had, have been with ColorEyes Display Pro) as I did not find its automated calibration to give acceptable results.

You're probably misunderstanding a bit here. I was talking about just using ArgyllCMS to turn your measurement data into a PCS -> RGB .icc profile. Then you can use whatever proprietary software you want to work with this ICC profile (and create a custom RGB -> RGB mapping). What I'd do is not calibrate your monitor whatsoever (all OS-based calibration uses 3x1DLUTs which often does more damage than it repairs), but just dump the raw measurement data into a .ti3 file (look up the specification, it has a huge list of raw monitor signal (R/G/B) to measured XYZ on the display). Then you can interpolate a giant PCS->RGB table, which shouldn't have an additional errors when performed with ArgyllCMS.

Then, all you have to do is use a theoretical input profile made for BT.709/2.3. How you combine those two tables is left up to your preferred proprietary implementation's algorithms.

Even if you want to skip this step and create the entire RGB table yourself, it's still a rather trivial process of just dumping this table into an ICC profile and using simple software (eg. LittleCMS) to create a 256x256 .3dlut from this (by interpolating, which also shouldn't introduce any errors - but will be bound to your measurement precision).

The other option here is to use whatever proprietary software you like to create then PCS->RGB lut, and then existing software like LittleCMS to use this.

The main problem here, is that I don't think the "Live Colour" mode on this TV, which is required to expand the gamut, is a linear saturation/gamut boost. I haven't measured it yet, but I would not be surprised at all if it was non-linear.

If you want to linearly expand the gamut what I'd recommend doing is a multiplication of the chromaticity in L*Ch space (which is how LittleCMS and all of my chromaticity functions do it). This is, of course, derived from/converted back to XYZ space which is device independent, so you don't have to do any forms of compensation.

Correcting for 100% saturation helps, but the display's colour response would still be non-linear.

It is possible to correct for this with LUTs, and I can get all the required data for it, but I just don't know how to create a 3DLUT file that does this correctly.

This doesn't really matter. Regardless of what your display's characteristics are, nor how ridiculously non-linear they might be, if you want absolute chromaticity, it's a simple mapping:

(1): RGB, 709 primaries, 2.3 gamma
(2): RGB, 709 primaries, linear
(3): XYZ, image relative to D65
(4): L*Ch relative to D65 (expand the gamut here, steps 4 and 5 optional)
(5): XYZ, image relative to D65
(6): RGB, display primaries, display gamma

Basically, in step (5) you have the absolute XYZ value you want to see in the real world, so you just go through the huge table of measurements and find the one RGB value (on the display) that corresponds to the exact XYZ you want to see. No matter how ridiculously contrived your display is, no matter what sort of crazy gamma it has, no matter if it inverts the input or whatever, you'll *always* get the most correct mapping by this way.

You don't have to tune anything manually except for the last step. All of this can be done with perfect precision except for (6), which relies on real world measurement data and physical limitations. But if you can get a perfect .ti3 file that corresponds to your display, you can get a perfect result via this method. And the .ti3 file you can change by hand if you want to.

Limitations of ArgyllCMS or other software should not be a problem at this point, and if you want to do anything else (eg. white point adaption or black point compensation) then you can do this in XYZ space manually using custom transformation filters (eg. LutScript, which can be used to generate a .3dlut).

I don't know if development for yCMS, or madVR's interface with yCMS has halted or not though, things don't seem to have been updated for a while now.

I just don't understand why it works by giving it your display's primaries and measurements, and then calculating what it thinks is best. That seems like the least accurate way possible to create a LUT.

It only works for a perfect display, but you're right, using yCMS is a bit silly/unneeded.

n3w813

19th October 2011, 23:11

I'm currently using a ColorMunki Design to do calibrations on my HTPC/LCD combos. My question is this...since the CM cannot reliably read IRE below 20%, should I include those low readings in the yCMS tab in MadVR? Or just limit the readings from 20%-100%?

Thanks :)

nevcairiel

20th October 2011, 06:55

Its better to just leave out the readings that you know are inaccurate. For my meter, its about the same, the 10 and 20% IREs are rather inaccurate, and letting yCMS figure those out itself is much better.

Fer

28th December 2011, 13:28

Definitely there should be something wrong. I will look into it.

Hello. Sorry, do you have had any success investigating the problem?

Thank you so much.

hhb97b

21st January 2012, 14:35

Hi

I believe I'm having an issue with ycms. My issue can be seen in the picture(capture.txt should be .jpeg but the system wouldn't accept it) where the red circle is.
The gradiation are wrong in this area and you can see a tilted line instead. The video-source are from avsforum and is called
\HDMV MP4-2c\Misc Patterns\A - Additional\1-Grayscale Ramp.mp4. The weird thing is that the error isn't present in the upper right area, only the left bottom error.

It can be difficult to see on a LCD but on plasma it is quite easy.
I have tested the configuration on 2 different computer and 3 different monitors(2 plasma and LCD), however both computers are with nvidia gpu.

I'm trying to use ycms(1.1) inside ffdshow tryout(rev4251) with t3dlut(1.1) and this script are the one used

LoadPlugin("C:\video\util\video\cms\t3dlut-1.1\t3dlut.dll")
ConvertToYUY2()
t3dlut(lutfile="C:\video\util\video\cms\yCMS-1.11\hdpctest.3dlut",threads=2)

I have generated the 3dlut file from the script inside the file template - HD - PC.txt.

The values in gamut are measured and they can be found in the r6g-2b-7.txt(rename to .chc) file. They are measured with a xrite eye one.

The issue isn't preset when

-using a 8 bit output depth
-input colorspace are yRGB, as in madvr setup
-input_range and output_range are he same.

I'm only having this issue if the output bitrate are 16.

Any ideas what I'm doing wrong?

703

20th March 2012, 05:48

would yCMS in the future also be able to take in secondary xyY values to build the 3DLUT? This could allow better correction for non-linear displays.

Yellow_

24th June 2012, 18:08

Is it possible to create a LUT for conversion to ACES IFF, the color primaries are: R x 0.73470 y 0.26530, G x 0.0 y 1.0, B x 0.00010 y -0.07700

Other stuff:

– Negative code values are valid, e.g. {0.14, 1.00, -0.55}

Calculation Neutral Axis

– CIE x = 0 32168 CIE y = 0 33767

– Approximately CIE D60

– ACES {0.1800, 0.1800, 0.1800} = CIE XYZ {0.1715, 0.1800, 0.1816}

The negative blue primary seems to be unusable with yCMS. :-(

PeterTaps

25th June 2012, 21:15

Hello,

While searching for applications that can create 3D LUTs, I came across yCMS. The change log indicates that the last modification (v1.11) was done in Apr 2011. I am wondering if yCMS is still under active development.

Thank you in advance for your help.

Regards,
Peter

madshi

29th July 2012, 18:21

The developer is taking a break for personal reasons. He does plan to work on yCMS again some time in the future. But whether his plans will actually happen is another question.

Yellow_

23rd August 2012, 08:37

madshi thanks for the heads up, quick query partly relating to madVR is it possible to use yCMS to create YCbCr with yRGB primaries rather than RGB output, is this something you use internally with madVR or do you go to RGB only when or if you use yRGB at all.

Do you know if an ICC profile exists for yRGB or a tool that can create one, guess Argyll possibly?

madshi

23rd August 2012, 09:46

Not sure if that answers your question, but madVR always feeds RGB to the GPU.

Yellow_

12th September 2012, 13:28

madshi, thanks.

Is yRGB documented anywhere, such as primaries etc, I'd like to create a OpenColorIO profile and transform but haven't found yRGB details anywhere.

n3w813

19th September 2012, 20:45

Audionut

22nd September 2012, 07:49

How can I specify different saturation points to be corrected? See the color tracking of my TV below. Is there anyway I can manually build a 3DLUT to be used in MadVR to fix the various saturation points?

My first suggestion if your software allows, is to calibrate for 75% saturation. It looks like you have calibrated for 100%, and got them very close, but the gamut tracking is horrible.

ChromaPure (http://www.chromapure.com/) allows for calibrating 75% saturation and then checking the results through 25%, 50%, 75% and 100% saturation.

I like to calibrate for 75% and then adjust as needed to bring all 4 points as close to spec as possible. This results in the 100% results not being as close as they can be, but you end up with much better tracking through the various saturation levels. And overall deltaE results much lower.

Asmodian

24th September 2012, 02:52

@n3w813
In addition to what Audionut suggested you can try turning up the "color" setting on your TV if you have it.

Audionut

24th September 2012, 04:52

@n3w813
In addition to what Audionut suggested you can try turning up the "color" setting on your TV if you have it.

Yeah, a slight boost would bring yellow and magenta closer, help green a little, but would push blue out and wouldn't help with the tint shift problems.

The TV needs CMS to get anywhere near spec. Or something in the video chain that has precise control of color.

Cyan is a worry, there is a massive tint shift between 100% saturation and below. My LG TV suffers the same problem, but not to that extent.

6233638

24th September 2012, 19:10

My first suggestion if your software allows, is to calibrate for 75% saturation. It looks like you have calibrated for 100%, and got them very close, but the gamut tracking is horrible.

ChromaPure (http://www.chromapure.com/) allows for calibrating 75% saturation and then checking the results through 25%, 50%, 75% and 100% saturation.

I like to calibrate for 75% and then adjust as needed to bring all 4 points as close to spec as possible. This results in the 100% results not being as close as they can be, but you end up with much better tracking through the various saturation levels. And overall deltaE results much lower.

He is using CalMAN v5 there, which also takes those measurements. (as you can see from the image he posted)

The issue is that yCMS only allows you to specify primaries and greyscale points, there is no option to create a custom LUT to fix hue/saturation errors below 100%.

Most displays are far from linear below 100%.

yesgrey

9th November 2012, 22:22

Hi,
After a longer absence than I intended, here I am back with a new version, but first, here are the answers to some of the previous questions.

Definitely there should be something wrong. I will look into it.
Hello. Sorry, do you have had any success investigating the problem?
Yes, I found and fixed the problem.
In the beginning of yCMS there was a strange problem which caused severe noise and posterization in the black level region. I added a denoise algorithm that eliminated it at the cost of a slightly lower accuracy in the black level region. Since with the new madVR the noise problem seems to have disappeared, I decided to add a new command to yCMS to make this denoise algorithm optional. This way, people could be able to enable it only when using other applications than madVR, and if the noise shows up.

Unfortunately, it will not be possible for you to get the same image like you were having with the previous version, because for that it would be needed to also incorporate this denoise algorithm inside madVR, which, since it's not needed anymore, will not happen. Furthermore, the image was less accurate, so one less reason for you to miss it... ;)

However, I also made a small mistake when I created the yCMS config file for you to use with the new madVR.
Replace the line:
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
with the line:
Output_Transfer_Function 1
This way you will have the exact equivalent config file.

I believe I'm having an issue with ycms. My issue can be seen in the picture(capture.txt should be .jpeg but the system wouldn't accept it) where the red circle is.
The gradiation are wrong in this area and you can see a tilted line instead. The video-source are from avsforum and is called
\HDMV MP4-2c\Misc Patterns\A - Additional\1-Grayscale Ramp.mp4. The weird thing is that the error isn't present in the upper right area, only the left bottom error.
If the error is present only on the left bottom area, then it cannot be an yCMS problem. The colors in both areas are the same, so the 3DLUT produced by yCMS will output the same color in both cases, so the problem must be somewhere else.

would yCMS in the future also be able to take in secondary xyY values to build the 3DLUT?
Yes, it's planned.

Is it possible to create a LUT for conversion to ACES IFF, the color primaries are: R x 0.73470 y 0.26530, G x 0.0 y 1.0, B x 0.00010 y -0.07700
Yes, with the new version.

I am wondering if yCMS is still under active development.
Yes.

Is yRGB documented anywhere, such as primaries etc
I 'm planning creating a web page for it, but, until then, here are the details:
yRGB color space
Red: 0.6430 0.3310
Green: 0.2920 0.6100
Blue: 0.1490 0.0590
Illuminant (D65): 0.31272661468101209 0.32902313032606195
TF: pure power function with gamma = 2.2

After so many time I only answered the questions that I felt still needed one answer. If I have missed any others, please let me know.