yCMS - Color Management System

[janos666]

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

[yesgrey]

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.

[xv]

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]

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]

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.

[xv]

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]

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]

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]

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.)

[xv]

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]

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]

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]

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]

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...

[xv]

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]

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]

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?

[xv]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

I won't say that. I say we told it at the beginning and x.v. did it already.

[Damien147]

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_]

yesgrey, are you looking at adding support for Log space at all, for Log to Rec709 for example?

[yesgrey]

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_]

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]

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]

Great!!!!

@yesgrey
http://www.tftcentral.co.uk/articles/icc_profiles.htm

[yesgrey]

Thanks.:)

[janos666]

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_]

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_]

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]

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_]

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]

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]

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]

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_]

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]

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]

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_]

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.