View Full Version : yCMS - Color Management System
Pages :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[
16]
17
nand chan
22nd August 2011, 20:48
Posting this here because it's been suggested:
TI3 Parser toolset (http://forum.doom9.org/showthread.php?t=162285)
The TI3 Parser toolset is a small collection of tools (with a graphical user front-end) that allow easy integration of ArgyllCMS and yCMS, by, amongst other features, generating a .3dlut from a .ti3 profile file.
Garma
23rd August 2011, 01:35
Post the data you used with madVR.
For format, I used XYZ.
As for the values:
For rXYZ
X - 0.43607
Y - 0.22249
Z - 0.01392
For gXYZ
X - 0.38515
Y - 0.71687
Z - 0.09708
For bXYZ
X - 0.14307
Y - 0.06061
Z - 0.71410
For wtpt
X - 0.95045
Y - 1.00000
Z - 1.08905
I took these values from the sRGB IEC61966-2.1 ICC profile.
6233638
29th September 2011, 11:33
I'm wondering, is there any way to create a hand-crafted 3DLUT file?
What I would like to do, is measure my display and set it up to be the very best it can. I'd like to input the exact RGB values from 20-100% grey in 10%, or possibly 5%, steps (I have found that anything below about 20% in madVR causes posterisation/banding) that result in D65 at my desired gamma, and have yCMS fill in the rest.
I was previously doing this with a VideoEQ (http://avfoundry.com/VideoEq/index.php) and got much better results than when I simply input xyY or XYZ values and had it calculate a LUT based on that. Unfortunately while it worked great for greyscale & gamma, I found the CMS to be useless and the lack of inputs to be problematic, so I ended up selling it.
I would like to do this for primary and secondary colours too. Because it uses white LEDs, my display is not the greatest for colour. But what I have tested and confirmed is that if I turn up the colour control enough so that the least saturated colour is now enough (color from 50 to 65 seems to sort out green) I can get almost perfect colour from it by tweaking the RGB values of colour patches—much better results than I seem to be getting from simply inputting xyY values into madVR.
This would probably need RGB values taken from 25/50/75/100% brightness measurements, and probably saturation ones too, to linearise the response.
Does that sound possible at all?
nand chan
29th September 2011, 16:46
I'm wondering, is there any way to create a hand-crafted 3DLUT file?
What I would like to do, is measure my display and set it up to be the very best it can. I'd like to input the exact RGB values from 20-100% grey in 10%, or possibly 5%, steps (I have found that anything below about 20% in madVR causes posterisation/banding) that result in D65 at my desired gamma, and have yCMS fill in the rest.
I was previously doing this with a VideoEQ (http://avfoundry.com/VideoEq/index.php) and got much better results than when I simply input xyY or XYZ values and had it calculate a LUT based on that. Unfortunately while it worked great for greyscale & gamma, I found the CMS to be useless and the lack of inputs to be problematic, so I ended up selling it.
I would like to do this for primary and secondary colours too. Because it uses white LEDs, my display is not the greatest for colour. But what I have tested and confirmed is that if I turn up the colour control enough so that the least saturated colour is now enough (color from 50 to 65 seems to sort out green) I can get almost perfect colour from it by tweaking the RGB values of colour patches—much better results than I seem to be getting from simply inputting xyY values into madVR.
This would probably need RGB values taken from 25/50/75/100% brightness measurements, and probably saturation ones too, to linearise the response.
Does that sound possible at all?
You can do all/most of that using ArgyllCMS (http://www.argyllcms.com/), and having it output an ICC profile. Just set it to use a LUT-based profile and it will generate a 3d LUT for you.
alph@
29th September 2011, 20:08
6233638,i try videoequalizer for corrected my gamma curve,how correct the gamma curve without damaging the gray balance?how did you processed.
Portioli
17th October 2011, 23:21
hello to everybody..
which is the best user-friendly colorimeter for measuring primaries for yCMS?
&
one more question,
if i own either a gamut monitor (& standard 709 PJ) and i have colorimeter i have to profiling/calibrating only in sRGB
both displays?
6233638
18th October 2011, 08:02
I find it surprising that a lot of people seem to have displays which are short on gamut. I thought most of today's display would have larger primaries than needed, not smaller. Very weird.Most, if not all white LED backlit displays do not cover the BT.709 gamut.
Higher-end CCFL displays were able to exceed the BT.709 gamut (for example, Sony's WCG-CCFL BRAVIAs) but modern CCFL tends to have an even more limited gamut than white LED.
Is there any way to specify output RGB values in a 3DLUT, or some way of having that feature added?
My current LCD is one of those white LED displays (though it's backlit rather than edge lit, which helps) and if I enable the "Live Colour" mode and turn up saturation to 60, the gamut exceeds spec on Green, almost gets there on Red (<1dE'94) and still falls short on Blue, compared to falling short on all three when set correctly. (50 colour, Live Colour disabled)
Because I have to resort to this in order to almost cover the BT.709 gamut, simply inputting my primaries doesn't quite work for a good calibration.
I really need to be able to tweak my output RGB values for 100% RGBCMY, and it would most likely need 25, 50 and 75% saturation values as well in order to linearise things.
Same goes for greyscale/gamma. The results are good but not perfect with the automatically generated LUT. I know that my display can have a perfect gamma when manually tweaked, but the necessary control just doesn't seem to be there with 3DLUTs right now. (or at least I haven't been able to figure it out)
nand chan
18th October 2011, 15:00
Is there any way to specify output RGB values in a 3DLUT, or some way of having that feature added?
Not in yCMS to my knowledge, but the spec itself is quite capable of it, yes. What I would suggest doing here is crafting a custom .3dlut which specifies BT.709 primaries as input (by default yCMS will use your monitor primaries here and madVR will scale output to those already), which will make madVR not touch the values further.
Then you can just do a mapping of each BT.709 RGB -> your monitor RGB manually (the input gamma is exactly 2.2 PPC, the output will not be further adjusted). Then you also have to make sure to clear your video card's CLUTs during playback (eg. by making sure the ICC profile loaded in Windows does /not/ contain CLUT information).
You can use any software eg. ArgyllCMS to take a large list of measurement patches for your monitor (in the .ti3 format) and generate an ICC profile that will do this mapping for you, then generate a .3DLUT from this ICC profile (eg. using LittleCMS).
6233638
18th October 2011, 23:19
Not in yCMS to my knowledge, but the spec itself is quite capable of it, yes. What I would suggest doing here is crafting a custom .3dlut which specifies BT.709 primaries as input (by default yCMS will use your monitor primaries here and madVR will scale output to those already), which will make madVR not touch the values further.
Then you can just do a mapping of each BT.709 RGB -> your monitor RGB manually (the input gamma is exactly 2.2 PPC, the output will not be further adjusted).I don't understand—how would you do the output mapping manually? That's what I'm trying to do.
You can use any software eg. ArgyllCMS to take a large list of measurement patches for your monitor (in the .ti3 format) and generate an ICC profile that will do this mapping for you, then generate a .3DLUT from this ICC profile (eg. using LittleCMS).I have measurements already, and know exactly what RGB values are required to be sent to my display for perfect colour reproduction. (had photoshop running on one half of the screen, calman on the other, and adjusted color patches to get the exact RGB values needed)
I've yet to find any commercial package that can do as good a job with automated measurements as hand-tuning the RGB values can, I would be surprised if argyllcms does, especially when it does not include functions such as calman's low-light handling (more than simple averaging) for consistently repeatable readings.
I tried ArgyllCMS in the past, before turning to commercial packages (so far the best results I have had, have been with ColorEyes Display Pro) as I did not find its automated calibration to give acceptable results.
The main problem here, is that I don't think the "Live Colour" mode on this TV, which is required to expand the gamut, is a linear saturation/gamut boost. I haven't measured it yet, but I would not be surprised at all if it was non-linear.
Correcting for 100% saturation helps, but the display's colour response would still be non-linear.
It is possible to correct for this with LUTs, and I can get all the required data for it, but I just don't know how to create a 3DLUT file that does this correctly.
I don't know if development for yCMS, or madVR's interface with yCMS has halted or not though, things don't seem to have been updated for a while now.
I just don't understand why it works by giving it your display's primaries and measurements, and then calculating what it thinks is best. That seems like the least accurate way possible to create a LUT.
nand chan
19th October 2011, 17:00
I don't understand—how would you do the output mapping manually? That's what I'm trying to do.
I have measurements already, and know exactly what RGB values are required to be sent to my display for perfect colour reproduction. (had photoshop running on one half of the screen, calman on the other, and adjusted color patches to get the exact RGB values needed)
I've yet to find any commercial package that can do as good a job with automated measurements as hand-tuning the RGB values can, I would be surprised if argyllcms does, especially when it does not include functions such as calman's low-light handling (more than simple averaging) for consistently repeatable readings.
I tried ArgyllCMS in the past, before turning to commercial packages (so far the best results I have had, have been with ColorEyes Display Pro) as I did not find its automated calibration to give acceptable results.
You're probably misunderstanding a bit here. I was talking about just using ArgyllCMS to turn your measurement data into a PCS -> RGB .icc profile. Then you can use whatever proprietary software you want to work with this ICC profile (and create a custom RGB -> RGB mapping). What I'd do is not calibrate your monitor whatsoever (all OS-based calibration uses 3x1DLUTs which often does more damage than it repairs), but just dump the raw measurement data into a .ti3 file (look up the specification, it has a huge list of raw monitor signal (R/G/B) to measured XYZ on the display). Then you can interpolate a giant PCS->RGB table, which shouldn't have an additional errors when performed with ArgyllCMS.
Then, all you have to do is use a theoretical input profile made for BT.709/2.3. How you combine those two tables is left up to your preferred proprietary implementation's algorithms.
Even if you want to skip this step and create the entire RGB table yourself, it's still a rather trivial process of just dumping this table into an ICC profile and using simple software (eg. LittleCMS) to create a 256x256 .3dlut from this (by interpolating, which also shouldn't introduce any errors - but will be bound to your measurement precision).
The other option here is to use whatever proprietary software you like to create then PCS->RGB lut, and then existing software like LittleCMS to use this.
The main problem here, is that I don't think the "Live Colour" mode on this TV, which is required to expand the gamut, is a linear saturation/gamut boost. I haven't measured it yet, but I would not be surprised at all if it was non-linear.
If you want to linearly expand the gamut what I'd recommend doing is a multiplication of the chromaticity in L*Ch space (which is how LittleCMS and all of my chromaticity functions do it). This is, of course, derived from/converted back to XYZ space which is device independent, so you don't have to do any forms of compensation.
Correcting for 100% saturation helps, but the display's colour response would still be non-linear.
It is possible to correct for this with LUTs, and I can get all the required data for it, but I just don't know how to create a 3DLUT file that does this correctly.
This doesn't really matter. Regardless of what your display's characteristics are, nor how ridiculously non-linear they might be, if you want absolute chromaticity, it's a simple mapping:
(1): RGB, 709 primaries, 2.3 gamma
(2): RGB, 709 primaries, linear
(3): XYZ, image relative to D65
(4): L*Ch relative to D65 (expand the gamut here, steps 4 and 5 optional)
(5): XYZ, image relative to D65
(6): RGB, display primaries, display gamma
Basically, in step (5) you have the absolute XYZ value you want to see in the real world, so you just go through the huge table of measurements and find the one RGB value (on the display) that corresponds to the exact XYZ you want to see. No matter how ridiculously contrived your display is, no matter what sort of crazy gamma it has, no matter if it inverts the input or whatever, you'll *always* get the most correct mapping by this way.
You don't have to tune anything manually except for the last step. All of this can be done with perfect precision except for (6), which relies on real world measurement data and physical limitations. But if you can get a perfect .ti3 file that corresponds to your display, you can get a perfect result via this method. And the .ti3 file you can change by hand if you want to.
Limitations of ArgyllCMS or other software should not be a problem at this point, and if you want to do anything else (eg. white point adaption or black point compensation) then you can do this in XYZ space manually using custom transformation filters (eg. LutScript, which can be used to generate a .3dlut).
I don't know if development for yCMS, or madVR's interface with yCMS has halted or not though, things don't seem to have been updated for a while now.
I just don't understand why it works by giving it your display's primaries and measurements, and then calculating what it thinks is best. That seems like the least accurate way possible to create a LUT.
It only works for a perfect display, but you're right, using yCMS is a bit silly/unneeded.
n3w813
19th October 2011, 23:11
I'm currently using a ColorMunki Design to do calibrations on my HTPC/LCD combos. My question is this...since the CM cannot reliably read IRE below 20%, should I include those low readings in the yCMS tab in MadVR? Or just limit the readings from 20%-100%?
Thanks :)
nevcairiel
20th October 2011, 06:55
Its better to just leave out the readings that you know are inaccurate. For my meter, its about the same, the 10 and 20% IREs are rather inaccurate, and letting yCMS figure those out itself is much better.
Fer
28th December 2011, 13:28
Definitely there should be something wrong. I will look into it.
Hello. Sorry, do you have had any success investigating the problem?
Thank you so much.
hhb97b
21st January 2012, 14:35
Hi
I believe I'm having an issue with ycms. My issue can be seen in the picture(capture.txt should be .jpeg but the system wouldn't accept it) where the red circle is.
The gradiation are wrong in this area and you can see a tilted line instead. The video-source are from avsforum and is called
\HDMV MP4-2c\Misc Patterns\A - Additional\1-Grayscale Ramp.mp4. The weird thing is that the error isn't present in the upper right area, only the left bottom error.
It can be difficult to see on a LCD but on plasma it is quite easy.
I have tested the configuration on 2 different computer and 3 different monitors(2 plasma and LCD), however both computers are with nvidia gpu.
I'm trying to use ycms(1.1) inside ffdshow tryout(rev4251) with t3dlut(1.1) and this script are the one used
LoadPlugin("C:\video\util\video\cms\t3dlut-1.1\t3dlut.dll")
ConvertToYUY2()
t3dlut(lutfile="C:\video\util\video\cms\yCMS-1.11\hdpctest.3dlut",threads=2)
I have generated the 3dlut file from the script inside the file template - HD - PC.txt.
The values in gamut are measured and they can be found in the r6g-2b-7.txt(rename to .chc) file. They are measured with a xrite eye one.
The issue isn't preset when
-using a 8 bit output depth
-input colorspace are yRGB, as in madvr setup
-input_range and output_range are he same.
I'm only having this issue if the output bitrate are 16.
Any ideas what I'm doing wrong?
703
20th March 2012, 05:48
would yCMS in the future also be able to take in secondary xyY values to build the 3DLUT? This could allow better correction for non-linear displays.
Yellow_
24th June 2012, 18:08
Is it possible to create a LUT for conversion to ACES IFF, the color primaries are: R x 0.73470 y 0.26530, G x 0.0 y 1.0, B x 0.00010 y -0.07700
Other stuff:
– Negative code values are valid, e.g. {0.14, 1.00, -0.55}
Calculation Neutral Axis
– CIE x = 0 32168 CIE y = 0 33767
– Approximately CIE D60
– ACES {0.1800, 0.1800, 0.1800} = CIE XYZ {0.1715, 0.1800, 0.1816}
The negative blue primary seems to be unusable with yCMS. :-(
PeterTaps
25th June 2012, 21:15
Hello,
While searching for applications that can create 3D LUTs, I came across yCMS. The change log indicates that the last modification (v1.11) was done in Apr 2011. I am wondering if yCMS is still under active development.
Thank you in advance for your help.
Regards,
Peter
madshi
29th July 2012, 18:21
The developer is taking a break for personal reasons. He does plan to work on yCMS again some time in the future. But whether his plans will actually happen is another question.
Yellow_
23rd August 2012, 08:37
madshi thanks for the heads up, quick query partly relating to madVR is it possible to use yCMS to create YCbCr with yRGB primaries rather than RGB output, is this something you use internally with madVR or do you go to RGB only when or if you use yRGB at all.
Do you know if an ICC profile exists for yRGB or a tool that can create one, guess Argyll possibly?
madshi
23rd August 2012, 09:46
Not sure if that answers your question, but madVR always feeds RGB to the GPU.
Yellow_
12th September 2012, 13:28
madshi, thanks.
Is yRGB documented anywhere, such as primaries etc, I'd like to create a OpenColorIO profile and transform but haven't found yRGB details anywhere.
n3w813
19th September 2012, 20:45
How can I specify different saturation points to be corrected? See the color tracking of my TV below. Is there anyway I can manually build a 3DLUT to be used in MadVR to fix the various saturation points?
http://www.avsforum.com/content/type/61/id/67453/
Audionut
22nd September 2012, 07:49
How can I specify different saturation points to be corrected? See the color tracking of my TV below. Is there anyway I can manually build a 3DLUT to be used in MadVR to fix the various saturation points?
My first suggestion if your software allows, is to calibrate for 75% saturation. It looks like you have calibrated for 100%, and got them very close, but the gamut tracking is horrible.
ChromaPure (http://www.chromapure.com/) allows for calibrating 75% saturation and then checking the results through 25%, 50%, 75% and 100% saturation.
I like to calibrate for 75% and then adjust as needed to bring all 4 points as close to spec as possible. This results in the 100% results not being as close as they can be, but you end up with much better tracking through the various saturation levels. And overall deltaE results much lower.
Asmodian
24th September 2012, 02:52
@n3w813
In addition to what Audionut suggested you can try turning up the "color" setting on your TV if you have it.
Audionut
24th September 2012, 04:52
@n3w813
In addition to what Audionut suggested you can try turning up the "color" setting on your TV if you have it.
Yeah, a slight boost would bring yellow and magenta closer, help green a little, but would push blue out and wouldn't help with the tint shift problems.
The TV needs CMS to get anywhere near spec. Or something in the video chain that has precise control of color.
Cyan is a worry, there is a massive tint shift between 100% saturation and below. My LG TV suffers the same problem, but not to that extent.
6233638
24th September 2012, 19:10
My first suggestion if your software allows, is to calibrate for 75% saturation. It looks like you have calibrated for 100%, and got them very close, but the gamut tracking is horrible.
ChromaPure (http://www.chromapure.com/) allows for calibrating 75% saturation and then checking the results through 25%, 50%, 75% and 100% saturation.
I like to calibrate for 75% and then adjust as needed to bring all 4 points as close to spec as possible. This results in the 100% results not being as close as they can be, but you end up with much better tracking through the various saturation levels. And overall deltaE results much lower.
He is using CalMAN v5 there, which also takes those measurements. (as you can see from the image he posted)
The issue is that yCMS only allows you to specify primaries and greyscale points, there is no option to create a custom LUT to fix hue/saturation errors below 100%.
Most displays are far from linear below 100%.
yesgrey
9th November 2012, 22:22
Hi,
After a longer absence than I intended, here I am back with a new version, but first, here are the answers to some of the previous questions.
Definitely there should be something wrong. I will look into it.
Hello. Sorry, do you have had any success investigating the problem?
Yes, I found and fixed the problem.
In the beginning of yCMS there was a strange problem which caused severe noise and posterization in the black level region. I added a denoise algorithm that eliminated it at the cost of a slightly lower accuracy in the black level region. Since with the new madVR the noise problem seems to have disappeared, I decided to add a new command to yCMS to make this denoise algorithm optional. This way, people could be able to enable it only when using other applications than madVR, and if the noise shows up.
Unfortunately, it will not be possible for you to get the same image like you were having with the previous version, because for that it would be needed to also incorporate this denoise algorithm inside madVR, which, since it's not needed anymore, will not happen. Furthermore, the image was less accurate, so one less reason for you to miss it... ;)
However, I also made a small mistake when I created the yCMS config file for you to use with the new madVR.
Replace the line:
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
with the line:
Output_Transfer_Function 1
This way you will have the exact equivalent config file.
I believe I'm having an issue with ycms. My issue can be seen in the picture(capture.txt should be .jpeg but the system wouldn't accept it) where the red circle is.
The gradiation are wrong in this area and you can see a tilted line instead. The video-source are from avsforum and is called
\HDMV MP4-2c\Misc Patterns\A - Additional\1-Grayscale Ramp.mp4. The weird thing is that the error isn't present in the upper right area, only the left bottom error.
If the error is present only on the left bottom area, then it cannot be an yCMS problem. The colors in both areas are the same, so the 3DLUT produced by yCMS will output the same color in both cases, so the problem must be somewhere else.
would yCMS in the future also be able to take in secondary xyY values to build the 3DLUT?
Yes, it's planned.
Is it possible to create a LUT for conversion to ACES IFF, the color primaries are: R x 0.73470 y 0.26530, G x 0.0 y 1.0, B x 0.00010 y -0.07700
Yes, with the new version.
I am wondering if yCMS is still under active development.
Yes.
Is yRGB documented anywhere, such as primaries etc
I 'm planning creating a web page for it, but, until then, here are the details:
yRGB color space
Red: 0.6430 0.3310
Green: 0.2920 0.6100
Blue: 0.1490 0.0590
Illuminant (D65): 0.31272661468101209 0.32902313032606195
TF: pure power function with gamma = 2.2
After so many time I only answered the questions that I felt still needed one answer. If I have missed any others, please let me know.
yesgrey
9th November 2012, 22:47
yCMS v1.12 released
http://yesgrey.com/ycms.html
- New command Denoise_Black_Level to denoise black level range
- Changed Input/Output_Primaries range to allow negative numbers in R,G,B
The new command Denoise_Black_Level is disabled by default.
It should be enabled only if severe noise and posterization are found in the black level range.
Now it is possible to use primaries with negative coordinates. Other than crashing, it was not performed any validation
of the operation with primaries with negative coordinates, so use it at your own risk.
Unless there are any critical bugs, this will be the last release of yCMS 1.x.
I will now start working on the development of yCMS 2.x. Even though I have returned, I still don't have much free time, so I will focus my time mainly on the development of yCMS 2.x instead of answering questions here in the forum. I will appreciate your patience and comprehension if the questions are not answered as fast as you would like, but if I don't do it then yCMS2.x will take much longer to show up...
madshi
9th November 2012, 22:53
Thanks. :)
cyberbeing
9th November 2012, 23:26
What kind of enhancements do you currently have planned for yCMS 2.x?
6233638
10th November 2012, 00:03
I will now start working on the development of yCMS 2.x. Even though I have returned, I still don't have much free time, so I will focus my time mainly on the development of yCMS 2.x instead of answering questions here in the forum. I will appreciate your patience and comprehension if the questions are not answered as fast as you would like, but if I don't do it then yCMS2.x will take much longer to show up...Please allow us to tweak the LUT in yCMS2. My display can hit the BT.709 gamut perfectly if I create custom patches in Photoshop by adjusting RGB values for example, but because yCMS only allows you to set input values, rather than output values for the LUT, I can't get close.
Similarly for gamma, I have to "cheat" and set xy to D65, and adjust Y for each point to have gamma actually hit my specified target. (calculated values are off by ±0.10 for each point)
yRGB color space
Red: 0.6430 0.3310
Green: 0.2920 0.6100
Blue: 0.1490 0.0590
Illuminant (D65): 0.31272661468101209 0.32902313032606195
TF: pure power function with gamma = 2.2Is there a reason you aren't just using the BT.709 gamut? (this seems really close)
I'm also curious about your D65 numbers, as I have: 0.312713, 0.329016 from SpectraCAL. (6504K)
hhb97b
10th November 2012, 11:51
If the error is present only on the left bottom area, then it cannot be an yCMS problem. The colors in both areas are the same, so the 3DLUT produced by yCMS will output the same color in both cases, so the problem must be somewhere else.
You are correct. I found out later that there was an error in the dithering algorithm for avs scripts. As I recall the problem was dividering in the dithering. It was done by swifting 0, but one place in the code the number of switching 0 was wrong. I belive it was 8 instead of 4, but I'm not completly sure
Thanks for you answer
MSL_DK
6th December 2012, 12:41
Hello yesgrey and others. I'm having trouble ycms + madvr. I do not know if it's my TV that limits or whether it is ycms which fails. I'm posting my results before and after ycms
Measurements are made using i1pro and HCFR
GFX: RGB Full Range
madVR: 0-255
TV: PC Levels
Red and blue are washed out and as you can see is the completely wrong with red
Before ycms
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/before/7.JPG
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/before/8.JPG
red, Yxy, 26.277639, 0.640307, 0.340035
green, Yxy, 96.551832, 0.308219, 0.640425
blue, Yxy, 4.673627, 0.153171, 0.048816
white, Yxy, 109.649715, 0.316380, 0.329259
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/before/1.JPG
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/before/2.JPG
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/before/3.JPG
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/before/4.JPG
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/before/5.jpg
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/before/6.jpg
After ycms
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/after/7.JPG
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/after/8.JPG
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/after/9.JPG
red, Yxy, 25.961723, 0.612202, 0.324843
green, Yxy, 85.567025, 0.310051, 0.606321
blue, Yxy, 10.082963, 0.159330, 0.074489
white, Yxy, 110.846549, 0.316352, 0.329157
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/after/1.JPG
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/after/2.JPG
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/after/3.JPG
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/after/4.JPG
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/after/5.jpg
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/after/6.jpg
MSL_DK
6th December 2012, 20:01
I added a few screenshots from Digital Video Essentials
Before ycms
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/before/dve.JPG
After ycms
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/after/dve.JPG
MSL_DK
7th December 2012, 10:07
As I see it, is red and blue undersaturated, particularly red? I do not understand as the original gamut is not undersaturated?
6233638
7th December 2012, 15:58
As I see it, is red and blue undersaturated, particularly red? I do not understand as the original gamut is not undersaturated?While red and blue are oversaturated on your display, its gamut does not cover the BT.709 spec.
If I overlay your two images, we see that red and blue are as saturated as they can be, and yCMS is just moving the primaries to have accurate hue:
http://www.abload.de/img/gamut6xpya.png
I don't know what is happening with the test-patterns though, yCMS must be clipping or something. I have experienced the same thing recently, and I am not even using a custom gamut (I just put in the numbers for the BT.709 spec) so I don't know what is happening there.
madshi
7th December 2012, 16:13
FWIW, I'm probably going to create my own calibration solution for madVR next year, because it seems that yesgrey simply doesn't have enough development resources for yCMS these days...
MSL_DK
8th December 2012, 19:40
While red and blue are oversaturated on your display, its gamut does not cover the BT.709 spec.
If I overlay your two images, we see that red and blue are as saturated as they can be, and yCMS is just moving the primaries to have accurate hue:
http://www.abload.de/img/gamut6xpya.png
I don't know what is happening with the test-patterns though, yCMS must be clipping or something. I have experienced the same thing recently, and I am not even using a custom gamut (I just put in the numbers for the BT.709 spec) so I don't know what is happening there.
Many thanks for your help and explanations, they are useful for such a newbie like me :-)
MSL_DK
8th December 2012, 19:47
FWIW, I'm probably going to create my own calibration solution for madVR next year, because it seems that yesgrey simply doesn't have enough development resources for yCMS these days...
I am pleased :thanks: Not to disparage yesgrey work. I am very grateful for all the time you spend on it.
MSL_DK
9th December 2012, 11:19
Is there someone who can upload v1.11
madshi
9th December 2012, 11:42
I think this one should be v1.11:
http://madshi.net/yCMS111.rar
yesgrey
9th December 2012, 14:15
I added a few screenshots from Digital Video Essentials
I don't know what is happening with the test-patterns though, yCMS must be clipping or something. I have experienced the same thing recently, and I am not even using a custom gamut (I just put in the numbers for the BT.709 spec) so I don't know what is happening there.
The test pattern results are really strange. I will take a look to see if I can find the problem. Maybe I have added any bug with the recent changes...
cyberbeing
9th December 2012, 16:12
I had strange test pattern results similar to MSL_DK with yCMS v1.11 & v1.12, which I sent to madshi last month.
http://www.mediafire.com/?zhzp03vlm65cx5q
When I force TV range input on that PC range TIFF, I seem to get incorrect results when using a yCMS 3DLUT.
240 & 255 levels do not match for Red, when they should be clipped.
240 & 255 levels do not match for Green, when they should be clipped.
240 & 255 levels match for Blue.
15 & 30 levels for Red & Blue match each other.
15 & 30 level for Green is much too bright.
15 level for Green measures as 6 in Photoshop, when it should be clipped to 0.
MSL_DK
9th December 2012, 17:13
I tested with version 1.11 as madshi links to (thanks) with the same result as version 1.12
yesgrey
9th December 2012, 19:28
I had strange test pattern results similar to MSL_DK with yCMS v1.11 & v1.12, which I sent to madshi last month.
I tested with version 1.11 as madshi links to (thanks) with the same result as version 1.12
OK, that would help. Might be any problem introduced with 1.11, then. I will investigate...
yesgrey
9th December 2012, 19:33
@MSL_DK,
Are you using madVR to create the 3DLUT files or are you using yCMS? If the latter, could you please post the configuration file you are using to create the 3DLUT?
MSL_DK
9th December 2012, 21:29
I am somewhat confused and not sure I am able to explain to me technically. I have just a few questions. My gfx is set to full rgb madvr to 0-255 and my TV is set to (EDIT) PC levels. Before ycms will rgb clip 235 and after ycms at 251, why?
To eliminate madvr as source of error, I installed version 0.60 and get this result I have attached settings and images ycms 1.11 + madvr 0.60 (https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/0.60.zip) Note the green.
I get the same result whether I use madvr to generate my 3dlut
With ycms 1.11 + madvr 0.85.2 giving me this result (http://forum.doom9.org/showpost.php?p=1604286&postcount=783)
Input_Primaries 0.612202 0.324843 0.310051 0.606321 0.159330 0.074489 0.31272661468101209 0.32902313032606195
Output_Primaries 0.612202 0.324843 0.310051 0.606321 0.159330 0.074489 0.316352 0.329157
Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0
Input_Range 16 235
Output_Range 16 235
Input_Bit_Depth 8
Output_Bit_Depth 16
Gamut_Measurements 1
1.0 0.612202 0.324843
1.0 0.310051 0.606321
1.0 0.159330 0.074489
1.0 0.316352 0.329157
# Grayscale IRE Measurements
Grayscale_Measurements
20 0 2.720541
40 0 13.086288
60 0 32.660640
80 0 62.491302
100 0 107.281296
MSL_DK
9th December 2012, 21:36
I try later to use hcfr patterns to collect rgb values, as you can see they are not the same between version 0.60 and 0.85.2
MSL_DK
9th December 2012, 22:31
STOP PLEASE. If I collect values via hcfr patterns I get this result. As I see it, there is still something wrong with blue but it's a completely different result
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/ycms/HCFR/1.JPG
madshi
10th December 2012, 00:34
Are you taking the measurements by running color test patterns through madVR? Or are you using some other software to display the test patterns? The ideal solution should be to let madVR display the color test patterns, but I'm not sure if that's easily possible. When using other software, there could be issues like different RGB output levels or lack of dithering. If you use madVR, you should set madVR to "this display is not calibrated" when you display the color test patterns.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.