yCMS - Color Management System [Archive] - Page 4

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)