yCMS - Color Management System

[yesgrey]

About what?

[janos666]

About using lcms2 (http://www.littlecms.com/index.html) to calculate gamut and gamma corrections for 3DLUTs.
I think an ICC profile based CMS can theoretically give us better result than the current yCMS engine. (But I can't compare it, so I am not sure.)

[yesgrey]

About using lcms2 (http://www.littlecms.com/index.html) to calculate gamut and gamma corrections for 3DLUTs.
That's out of question. I will not use any code from other people on yCMS. The only exception is ALGLIB project, but that's only for the interpolation of the grayscale measurements. However, as soon as I find the time for it, I will write my own code for it and drop ALGLIB.

[madshi]

Would it be difficult/useful to implement ICC profile import functionality to yCMS? Don't really know, just a thought...

[janos666]

Well, I think he can read out some informations from an ICC file for basic yCMS processing easily (matrix tag for gamut and average gamma for gamma correction). But this is not what I want to see. I am not sure about a real, ICC LUT based processing.
But why do you resist to use other's work when it's done and available for free? Yes, it's nice to write your own code and you should continue it but why won't you implement an existing code until you don't have any better solution?
(Yes, it's another question if lcms2 is better or worse but it is theoretically better.)

[And I can't understand your statement about ALGLIB. I would never hesitate to use something which is already done and available for free. May be I would improve it for my needs and share the improved version with others, etc/aso. But re-create something which is already exists? In my eyes, it's the absolute waste of time. You can do something much more useful instead...)

I am not talented enough to do it but I would do it for myself if I know the structure of the 3DLUT files.

yCMS 1.8 uses 2D primary color and white point coordinates with a single 3D gamma curve. This is something what an ICC file would call "matrix+shaper profile". It is nice for high-end displays which behaves close to a perfectly additive/linear display. But the usual LCD and plasma displays often lay far from that.
A LUT based ICC file can be constructed from theoretically infinite number of measurement data. You can measure single channels and secondary colors at various luminance levels to make a much better guess about the effects of the corrections.
As you can see it on my graphs above, yCMS isn't really able to correct the white balance. I think it's because it knows the current state (color luminance levels and chroma coordinates) of the grays but it doesn't know anything else about the display. It can't make any real guess what can happen when it tries to correct the white balance. If the display is not a perfectly additive/linear device, it can produce even worst results.

That's why I decided to make a high quality VGA LUT calibration to D65 and gamma 2.35 targets and 3DLUT processing like this:
Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Input_Transfer_Function 1.0 0.0 0.425531915 0
Gamut_Measurements 0.6817928 0.307676391 0.204774561 0.696317393 0.150704032 0.055593849 0.310563576 0.326995079
Output_Transfer_Function 1.0 0.0 0.425531915 0
The calibration pushes my display closer to an additive display, so a matrix calculation for gamut emulation can be successful.
But my other display works with 8 bit/color only, so I shouldn't calibrate it with the VGA LUT for targets like these. But it would be nice with dithering. (I am using MPC-HC with EVR-CP + ICC based CMS for this display right now. But it has other drawbacks. For example, I think they forgot to use black offset. But it is not that bad, colors looks good. And I hope they fix the black crush soon.)

[madshi]

A 3dlut can theoretically map any possible color to any other possible color. So basically there's almost no limit to what you can (theoretically) do with a 3dlut. The only question is how to calculate the 3dlut to make it work perfectly. I don't think that an ICC profile is theoretically better than using a 3dlut. Actually I think it's the other way round - provided that the 3dlut is calculated in a good way. yesgrey is constantly working on improving yCMS, so you can't just take the current version as the ceiling of image quality you can potentially get by 3dlut processing.

Suggesting to us to simply use lcms2 doesn't really make much sense, because it's a totally different concept. yesgrey would basically have to throw away all his work. And that for a solution which IMHO is not actually any better at all? Furthermore, lcms2 does not really fit the madVR + yCMS approach. yCMS does the calculations offline and madVR simply uses them. This way yesgrey and I can split the work. When using an ICC type of solution, splitting the work would be very difficult. Probably I would have to do all the work alone. And again: All that for a solution which is IMHO not any better?

Please note that when I'm talking about whether ICC profiles or the 3dlut approach is better or worse, I'm talking about potential, and not necessarily about the current state of things.

A LUT based ICC file can be constructed from theoretically infinite number of measurement data.
The same is true for 3dluts.

You can measure single channels and secondary colors at various luminance levels to make a much better guess about the effects of the corrections.
The same is true for 3dluts.

As you can see it on my graphs above, yCMS isn't really able to correct the white balance.
Not the current version, maybe (yesgrey?). But that's not a shortcoming of the general 3dlut concept, but just something yCMS does not appear to do correctly just yet.

[janos666]

I think I didn't drew it correctly. I know that the problem is not the 3DLUT itself but the calculation of the corrections. So, yes, you can keep the 3DLUT concept.
And yes, I know that a different (and external) solution would make the current engine useless. But this doesn't mean that we shouldn't try if it can be theoretically better.

I wanted to suggest that may be yesgray should try to use an existing ICC based CMS software to create the corrected 3DLUT files. It doesn't sound like a big job. He only need to send through every possible RGB colors and save the results into a 3DLUT.
And if it works significantly better, than he should work on his own solution which works even better. But it can show the path if yCMS should work with measurement data from single channel and secondary color measurements, like the engines of the compilers of the LUT based ICC profiles. (It would prove that 2D primary color coordinates and 3D gray coordinates are not always enough and you need more samples from other colors as well. - at least for average LCDs)

[memmerson]

Hi,
I am getting the following error when attempting to generate a 3dlut:

Error! Line 6 - Previous measurement was higher. All measurements must be specified in increasing order.
My input file is as follows:
Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16

Grayscale_Measurements 1
33 0.926286 0.29594 0.324745
37 1.18544 0.293792 0.322481
41 1.44325 0.292435 0.321269
45 1.75784 0.290731 0.318757
50 2.11293 0.291182 0.319109
54 2.45289 0.290722 0.317749
58 2.85725 0.290821 0.318597
62 3.25171 0.291342 0.318807
66 3.69734 0.291563 0.318772
70 4.17525 0.292272 0.319191
74 4.63349 0.291336 0.319286
79 5.15526 0.292582 0.319647
83 5.65992 0.292276 0.319268
87 6.17528 0.29152 0.319866
91 6.75987 0.291674 0.318983
95 7.29939 0.291294 0.31888
100 7.90411 0.291128 0.318659

Gamut_Measurements 0.666 0.326 0.284 0.707 0.135 0.052 0.291 0.318
I guess it is referring to the ire 37 measurement, but I am unsure what to do about it. Any suggestions?

Thanks

[yesgrey]

I guess it is referring to the ire 37 measurement, but I am unsure what to do about it. Any suggestions?
That's a bug. Previously I was expecting the user to enter the Luminance values for each color channel, so I always tested all color channels when looking for lower values. Now, I should test only the Luminance channel, and not the others. I will try to correct it soon and release a new version - hopefully today.

Thanks for reporting.

[yesgrey]

But why do you resist to use other's work when it's done and available for free?
And why shouldn't I? I do this for fun, because I want to learn more about it, and the only way of really understand and know something is doing it.

Yes, it's nice to write your own code and you should continue it but why won't you implement an existing code until you don't have any better solution?
Because the time I would "waste" on that is time I can use on doing what I want to do.

But re-create something which is already exists? In my eyes, it's the absolute waste of time. You can do something much more useful instead...)
Everything that people do in their life is simply wasting time. We only chose how we want to waste ours. ;)

I am not talented enough to do it but I would do it for myself if I know the structure of the 3DLUT files.
That's public: http://thr3dlut.sourceforge.net/

yCMS 1.8 uses 2D primary color and white point coordinates with a single 3D gamma curve. This is something what an ICC file would call "matrix+shaper profile". It is nice for high-end displays which behaves close to a perfectly additive/linear display. But the usual LCD and plasma displays often lay far from that.
I'm perfectly aware that yCMS has several shortcomings, even though the current results are already very good. I plan to improve yCMS by correcting them, but that would only happen in yCMS v2.x. I want to make v1.x stable before starting working on the next major version, and I think it's almost there.

[madshi]

I think I didn't drew it correctly. I know that the problem is not the 3DLUT itself but the calculation of the corrections. So, yes, you can keep the 3DLUT concept.
And yes, I know that a different (and external) solution would make the current engine useless. But this doesn't mean that we shouldn't try if it can be theoretically better.

I wanted to suggest that may be yesgray should try to use an existing ICC based CMS software to create the corrected 3DLUT files. It doesn't sound like a big job. He only need to send through every possible RGB colors and save the results into a 3DLUT.
And if it works significantly better, than he should work on his own solution which works even better. But it can show the path if yCMS should work with measurement data from single channel and secondary color measurements, like the engines of the compilers of the LUT based ICC profiles. (It would prove that 2D primary color coordinates and 3D gray coordinates are not always enough and you need more samples from other colors as well. - at least for average LCDs)
Ok, that makes more sense. If you want, you can ask the lcms2 programmer if he would be willing to add a madVR+yCMS compatible 3dlut output option. That might make for a nice alternative for people who already have a good ICC profile. However, if you want to do that, I'd wait a bit before asking him, because the 3dlut input/output formats used by madVR are going to change soon (currently: 8bit YCbCr -> 16bit RGB, soon: 8bit RGB -> 16bit RGB).

Personally, my bets are on yCMS, because there are some things yesgrey and I have not told anybody yet.

[madshi]

P.S:

Yes, it's nice to write your own code and you should continue it but why won't you implement an existing code until you don't have any better solution?
You argue as if yesgrey would have unlimited time. That is not the case. His time is limited. He has to decide how to spend his available programming time. He can either implement existing code, or he can work on his own solution. If he implements existing code, that costs time which is lost for working on his own solution. So your suggestion wastes a lot of precious time by first spending time to implement some code written by someone else, and then afterwards trying to develop a better solution. yesgrey doesn't have any time to waste. So he directly tries to develop a solution which is better than anything else out there. And in that he has my full support.

But re-create something which is already exists? In my eyes, it's the absolute waste of time.
Re-creating something (madVR) which is already exists (EVR)? In your eyes, it's the absolute waste of time.

If everybody would think like that ("there already exists a solution which is good enough"), there would not *ever* be any progress, because nobody would ever try to develop something better than already exists.

[yesgrey]

any idea of what I could try about the gamma correction of that movie of mine yet? ;)
Add this line at the end of your files:
Output_Transfer_Function 4.5 0.099 0.45 0.018
This will specify the output gamma of the file. You should change the bold value to your taste. The standard value is 0.45 (1/2.2222). If you want to make the image brighter decrease the value (for example 0.40 (1/2.5)), if you want to make it darker increase it. However, I think you would not want that in this case... Don't forget to lower the black level with the Input Range command.

I have tried Input_Range 30 235 with 0.40 as the gamma and the results looked good. Give it a try... remember you could create different 3DLUT files using different values and compare.

[Thunderbolt8]

thanks. is there any way here again as with the input range to get a mathematical 'correct ' result how the original gamma is supposed to be (assuming we found the correct lowest black level values)? or is it just 'try what suits you best' here?

[janos666]

Re-creating something (madVR) which is already exists (EVR)? In your eyes, it's the absolute waste of time.

If everybody would think like that ("there already exists a solution which is good enough"), there would not *ever* be any progress, because nobody would ever try to develop something better than already exists.

You know, I talked about the usage of the ALGLIB here (as an example). I don't do any programming (but I know the very basics of C++ programming) but this ALGLIB looks like a cool stuff for me. If I would write an own program which requires some of these functions, I would be happy that I can use it instead of creating an own solution with hard work.
The ignoring of the ALGLIB sounds something like the ignoring of the stdio.h for me. But ok, I don't want to argue about that. I can understand the other motivations behind these kind of thinking (even if I would never behave like this).

You argue as if yesgrey would have unlimited time.
I would agree if I asked for a complete ICC cLUT based engine from scratch, just for fun. I thought it's not a big deal to use an existing CMS software to send through the RGB numbers and save the corrected results.
I think I will be able to do it for myself after you switch to RGB->R'G'B' 3DLUTs because the only missing part is the YCrCb->RGB conversion which I don't want to re-create for myself (and I think I am simply not talented enough to do it...). I have the tools for an easy RGB->R'G'B' implementation right now. (That's why I thought that it would be easy for yesgrey if he accept to use other's work.)

It's easy to create the input (every possible RGB combinations in given order) and send it through ArgyllCMS/icclu (http://www.argyllcms.com/doc/icclu.html) to get the corrected colors. Now, I can see that the 3DLUT specifications is public, so the only missing part is the YCbCr->RGB conversion. But yesgrey already has it, so it sounds like "one hour of programming" for somebody who is already familiar with these things.


But OK, it was only an idea. I accept the "NO" answer. :o


Personally, my bets are on yCMS, because there are some things yesgrey and I have not told anybody yet.
I'm perfectly aware that yCMS has several shortcomings, even though the current results are already very good.
Ok, don't blame me if I can't see into your brains. I can't wait to see it. :rolleyes:

[yesgrey]

is there any way here again as with the input range to get a mathematical 'correct ' result how the original gamma is supposed to be (assuming we found the correct lowest black level values)?
Unfortunately no. It might be possible with a more complex processing chain, but considering that we would only be guessing what it might be I think it's not worthy. Furthermore, the benefit might be very small, because the gamma in a movie is supposed to be more robust than the black level, so a slight difference from the ideal is not so critical.

Just try some values and go for the one that pleases you more. Either way, it's an old movie with not a very big quality, so you would never be able to make it look much better...;)

Let me know how it ended up, and if you enjoyed a good movie experience after applying all these corrections...

[janos666]

I know, the XYZ support is still young but I already have a new feature request: support for the CIE 1964 (FOV10) observer based XYZ color space.
EIZO (and others) thinks (http://www.eizo.com/global/support/wp/pdf/wp_08-002.pdf) that this observer produces much better results in certain real-life situations than the usual 1931 (FOV2) observer.

I tried to calibrate my display with this observer setting and the result is promising. But I can't use these XYZ.10 values with yCMS. And there are certain problems:
- If I take XYZ.2 measures on the XYZ.10 calibrated display, the white point won't looks like D65, so the gamut will be drifted around the offset white point.
- There is still some gamut drift when I use the XYZ.2 measurements with a "fake" D65 white point. (This observer differs in the luminance tracking as well, so my output_transfer_function is a false number now, even if I calibrated my display to the same targets...)

I think that the usage of this observer may be able to provide better results but it should be supported by the CMS application too. (It doesn't work when you try to use your XYZ.10 values in a software which is supposed to work with XYZ.2 values.)

(The EIZO document talks about wide gamut displays. But this is not limited to WCG displays. It is a general thing. But you can see the limitations of the XYZ.2 color space based calibration when you try to compare different displays, and WCG differs from sRGB...)

Is it even possible? (I mean I know that the world is built to the XYZ.2 color space. New standardized observers are exist but if nobody really use them, then it can be hard to find the formulas for your calculations. And we need to find the reference points/curves of the Rec709 standard in this color space which sounds hard.)

And I am sorry if this is a bad idea (I think I had some in the near past). :o

[madshi]

You know, I talked about the usage of the ALGLIB here (as an example).
Ok, I see your point about ALGLIB. I thought you were talking about lcms2, mainly.

I think I will be able to do it for myself after you switch to RGB->R'G'B' 3DLUTs because the only missing part is the YCrCb->RGB conversion which I don't want to re-create for myself
Well, if you do manage to create an ICC -> 3dlut "conversion" tool, you're very welcome to publish it, of course, so everybody can use it and compare it to yCMS.

[Thunderbolt8]

Let me know how it ended up, and if you enjoyed a good movie experience after applying all these corrections...
I think I will go with input 32 235 and then gamma either 0.40 or 0.41. both look a tiny bit better in one scene or another, cant take the middle I guess :D

but the movie looks much better now than before, thank you very much for your help! ;)

[yesgrey]

I think I will go with input 32 235 and then gamma either 0.40 or 0.41. both look a tiny bit better in one scene or another, cant take the middle I guess :D
In fact you can. That's a double number, so you can use up to 14 decimal places, so you could go with 0.405.;)

the movie looks much better now than before, thank you very much for your help! ;)
Great.:)

[madshi]

That's a double number
For the non-programmers out there "double" is a high precision floating point data type, allowing up to 14 decimals. When I first read that sentence I thought "it's a double=twice number"? :)

[yesgrey]

thanks madshi, I should have been more clear...

[Thunderbolt8]

I think I will go with input 32 235 and then gamma either 0.40 or 0.41. both look a tiny bit better in one scene or another, cant take the middle I guess :D

but the movie looks much better now than before, thank you very much for your help! ;)aww, forgot about the subs.
you said the colour of the subs changes as well with all these changes being made, so I'd have to adjust them.

the colours I usually use for my .ass subs are 246 245 222 for primary, 255 0 0 for secondary and 0 0 0 for outline and shadow.
what would I have to do here with input 32 235 and gamma 0.405? im not very good at maths :S

[darkbasic]

Hi, I can't achieve decent color correction with yCMS, can you help me?
Here is the thread: http://forum.doom9.org/showthread.php?t=157722

Thank you

[yesgrey]

Hi, I can't achieve decent color correction with yCMS, can you help me?
Until 4th November I'm a little busy, but after that I will read the thread.

I've missed your thread because I usually only follow this one, so it's always a good idea to drop a note here in case anyone decide to create a new thread.

[darkbasic]

Until 4th November I'm a little busy, but after that I will read the thread.

I know, madshi told me. Thank you.

[sepheas]

sorry for that, but I don't know since when, I cannot create any 3dlut file.

I run the command prompt. Then, chdir with the right repertory.

Then, "yCMS HD_PC.txt HD_PC"

And nothing happens !

I've got Eset smart security on my computer. I tried to disable real time protection but I've got the same problem.

Any idea ?

edit: the only that I did was changing my cpu. From a E2180 to a pentium E6600

edit2 : In fact Ycms.exe is using 50% of my cpu continually

[yesgrey]

That's odd...
Have you tried deleting the entire yCMS directory, download it again and replace it?

Another possibility could be your securuty software, because since yCMS it's an exe file those programs usually consider all exe files as possible threats... Whenever I create a new yCMS version on my computer I have to give permission for it...

You could also post your input file so I could test it.

[sepheas]

I just reinstalled win 7. ( because of the new cpu ).

I run yCMS with nod32 with the same results. Then, I run yCMS without nod32 and I've got the same thing.

What the hell ? My new pentium E6600 is broken ? I've just got a sensor failure on core1. But it's not a big problem generally. I ran loooots of test on my cpu to be sure ! ( sandra lite, occt, etc...) ( I still think it's odd to have 6.4 with the windows perf. test but with sandra it's ok ).
DO you think it's the integrity of this cpu ? What can I do to test it in depth ?

The input I use for testing is the standard :

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

[yesgrey]

DO you think it's the integrity of this cpu ? What can I do to test it in depth ?
I don't know... have you tried using prime95 for stress testing your cpu? If you haven't, try it in conjunction with RealTemp, so you could be able to control your cpu temperature.

Furthermore, yCMS only requires SSE support, nothing more, to guaranty a broader compatibility range, so, unless your cpu's SSE unit is flawed it should work OK.

The standard script is safe, so the problem should be in any other place...

The only time I had a behavior like what you are describing was when I had selected a wrong option on my firewall settings (Comodo) for yCMS access. I needed to clear all custom settings for all files to make it work again, but it solved the problem.

You could try running yCMS under "safe mode" to be sure that it's not the ESET or the firewall that are blocking it.

[sepheas]

ok... I know it's "hors sujet" but it's strange no ?

I run ycms in "safe mode" with the same results. 50% of cpu occupation continually.

Second, I run a prime95 1 hour test. ( in-large large fft ). With no error.

Furthermore, yCMS only requires SSE support, nothing more, to guaranty a broader compatibility range, so, unless your cpu's SSE unit is flawed it should work OK.

well, is it possible that my E6600 have a problem with SSE unit ?
How can I test it ? ( wich soft ? )

I also used this Intel-Processor-Diagnostic-Tool (http://www.softpedia.com/get/System/System-Info/Intel-Processor-Diagnostic-Tool.shtml) and it's ok

I submit the results

MMX - Intel MMX Technology Feature Supported --> Yes---> PASS
SSE - Streaming SIMD Extensions Feature Supported --> Yes---> PASS
SSE2 - Streaming SIMD Extensions 2 Feature Supported --> Yes---> PASS
SSE3 - Streaming SIMD Extensions 3 Feature Supported --> Yes---> PASS
SSSE3 - Supplemented SSE 3 Feature Supported --> Yes---> PASS

Would you like more information ?

[gorgeousjorge]

Hi.

I´ve been reading over the last several days this subjects about madvr and now ycms.

I have some questions namely about the last,ycms.
My "probe" is an huey "pro" and from looking at the calibration report file i can see the gamut values,but with the gamma i only have the rgb data; so my question is how do i find the IRE values based on this.

The software i use is their own,huey is not supported by hfcr.
If i don`t enter any gamma correction i´ll my picture suffice any "degradaction"?

Another thing i´m confusing is the fact that i have a profile in windows icm wich is affecting all the desktop,this also affects the videos wich i play on that same desktop?
So if i run ycms on top of this,i´ll i have a "double" color correction?

Tx for any help you can provide.
Best regards.

[janos666]

No, you won't have "double correction".
The Windows ICM works with CMS softwares. It isn't effective for the whole desktop! Windows loads the VGA LUT from the ICC/ICM files but it doesn't apply any "fullscreen correction".

If you calibrated you display, you know your calibration target. Set this curve with the output_transfer_function command!
And be careful, the ICC/ICM files contain the gamut coordinates relatively to D50, so you need to do a chromatic adaptation to get those coordinates relatively to D65.

[gorgeousjorge]

Tx for the clarifications.

So windows doesn`t apply the profile i`ve created to the video playing in mpc-hc for example in fullscreen mode?
It will apply it for any window that pops up when a software is fired up,sorry for the noobish but i think i`m confusing all this things a bit.

When i calibrated with the pantone software it asked me to wich color temperature to set and i have choosed d65; so i guess it`s all good?

Best regards.

[janos666]

No, no and no. :)

MPC-HC may use it when you enable the color management module which works with the EVR-CP renderer only. It won't work with madVR but madVR+yCMS is better than EVR+lcms (lcms is integrated to MPC-HC but it's not enabled by default).

Windows won't do any color corrections. It fills the VGA LUT with your calibration LUT during the startup process, but it won't do any ICC based color corrections. The color correction (mostly the gamut correction if you already calibrated your display to proper target gamma and WP...) has to be done by the softwares. (For example, Photoshop, Windows Image Viewer, IrFanView, MPC-HC, etc. And OK, there is CMS engine in Windows, but it won't work until the software calls it, so...)

You can calibrate your display to any target WP, it won't change the gamut. The ICC standard demands from the software to save the XYZ coordinates relatively to D50. (So, if you calibrate your display to D65, your ICC file will store XYZ gamut coordinates which are relative to D50, but you need to convert them again to find the XYZ values which are relative to D65, because Rec709 is based on D65 and I think yCMS 1.8 is not able do this conversion properly. - Is it?)

[gorgeousjorge]

Thanks again for your thoughts on the subject,yesterday i finally understood how this thing works,i was confusing things a lot.
It was here that i`ve had clarified my doubts:

http://photo.net/digital-darkroom-forum/00FYil

And thanks to you too janos.

Now i wasn`t aware of the gamut thing,you say my icc profile as information of the gamut relative to d50 and not d65.
Is this true with the colormeters,namely mine the huey?
How do i convert them?

Best regards.

[sepheas]

I'm confused about that. Seriously, I don't know if I must call and Intel tech support to tell him about this malfunction. I'm thinking of that because I'm the apparently the only one who have this problem !

hey, someone can help me to know if my cpu is broken ? I really need to know :confused:

I made a clearcmos, I reinstall windows 7, I tested my cpu with stress software. I don't know what to do now...

And sorry for this alternative subject.

[janos666]

It won't help you (this is why I didn't tell it earlier ; and I don't have a solution) but I had this problem with and older version of yCMS.
I calibrated one of my friend's display and I wanted to set up MPC-HC+madVR+yCMS for him (he had relatively good hardwares but he used them on a stupid way :D).
When I wanted to create the 3DLUT files, the yCMS.exe used the CPU cores but it never finished it's work. It was a Q9650 and I installed the Win7 x64 OS for him. (It was a fresh installation from my DVD with my usual settings, like a real administrator account, etc...)
I didn't search for a solution because I could use an other PC to create the 3DLUT files for him (it was a cheap, old laptop with XP x86).
It was a stable hardware. He can work (AutoCAD, MathCAD, MS Office, etc.) and play (recent "up-to-DX11" games) on his machine without any problems. (But I wasn't able to run yCMS.)

[gorgeousjorge]

After reserch the net and trying to understand this later issue about the d50-d65 conversion.

From reading the manual i guess it was to be done manually because ycms doesn`t do it automatically.

I am right here?

Best regards.

[yesgrey]

Would you like more information ?
Zip your yCMS.exe file and send it to me (yesgrey (at) gmx (dot) com).

This is a very strange thing, and without reproducing it would be very hard to fix...

[janos666]

Could you please give me a 1.8b version where you remove this stupid limitation that every X, Y and Z column should have increasing numbers? (Yes, I know the reason of this leftover. But I think it would be better to disable this check than leave it here for months, until you fix it...)
I didn't ask it earlier because I thought it's useless anyway (the last version with R G B values didn't seem to touch the white balance and I didn't test this because it refused a lot of lines) but I did a quick test with some random XYZ values and it seems that it works with 1.8, so I think I would use it.

[cyberbeing]

While this feedback is months late, I just want to give thanks to yesgrey for listening to my request and adding the Gamma_Curve parameter. It works well, but it's not particularly intuitive in naming and description.

It's worth noting for those unaware that the Gamma_Curve parameter is for specifying Camera Gamma and not Display Gamma (this probably should be specified in a future Manual.txt). If you've calibrated your display with the likes of Argyll, ProfileMaker, basICColor, etc, which use Display Gamma, you need to be careful with what you enter for this value. By default, ycms defaults to a Camera Gamma of 2.2 (If you've calibrated your display to a Display Gamma of 2.2 this will result in your video being displayed with a Display Gamma of ~1.9). In other words this messes with the gamma you targeted when you calibrated your display.

In order to get ycms to match a calibrated Display Gamma of 2.2 with curveType 1.0, you seem to need to specify a Gamma_Curve of 2.6 in ycms.

Gamma_Curve 1.0 2.6
Measured Display Gamma of 2.2 + ycms Camera Gamma 2.6 = Measured Display Gamma 2.2 (no change)

Or alternatively

Gamma_Curve 1.0 2.2
Measured Display Gamma of 2.6 + ycms Default Camera Gamma 2.2 = Measured Display Gamma 2.2 should also be true, but this could mess up your video since such a large modification is very destructive.

Unless your display can't for whatever reason reach your desired gamma, or you want your videos displayed at a different gamma then your desktop, always use
the Camera Gamma which is equal to your Display Gamma so your original targeted gamma is maintained. It's always preferable to let your Display take the lead when attempting to reach a calibration target, and only modifying the source material when you're fine-tuning areas where your display is lacking.

Below are the settings I'm using, and they seem to give good results with only very subtle gamma changes (as expected) on my CRT which was already calibrated to sRGB Gamma of 2.2 before using ycms:
# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

# IRE Grayscale Measurements
Grayscale_Measurements 2
15 1.439 1.517 1.735
20 2.391 2.519 2.856
25 3.808 4.014 4.587
30 5.728 6.050 6.865
35 8.031 8.502 9.388
40 10.688 11.310 12.419
45 13.873 14.658 15.825
50 17.312 18.125 20.105
55 21.545 22.653 24.873
60 25.738 27.011 29.991
65 31.257 32.778 35.980
70 36.832 38.914 42.454
75 43.403 45.642 49.700
80 49.823 52.544 56.810
85 57.344 60.309 65.975
90 65.348 68.943 75.033
95 73.944 77.909 84.853
100 82.131 86.449 94.321

# Target Camera Gamma
Gamma_Curve 1.0 2.6

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

[Peekstra]

I'm confused about that. Seriously, I don't know if I must call and Intel tech support to tell him about this malfunction. I'm thinking of that because I'm the apparently the only one who have this problem !

hey, someone can help me to know if my cpu is broken ? I really need to know :confused:

I made a clearcmos, I reinstall windows 7, I tested my cpu with stress software. I don't know what to do now...

And sorry for this alternative subject.

I think that I'm experiencing the same problem on my quad core Q8400 based PC. yCMS works fine on my dual core E5200 system though.

Both computers run Windows 7 x86.

[janos666]

Never mind, my latest practice accidentally solved this problem.
I set D65 WP with the OSD Gains and this slight adjustment fixed the near-white-crash (for a cost of a slight contrast ratio reduction), so every column has increasing numbers now. I am happy with the current result.
I tested MPC-HC with lcms and HQ cLUT profiles (constructed from numerous multidimensional patch measurements) in floating point and dithered 10-bit mode (real 10-bit doesn't work) and I am not sure if it is more precise on colorimetric side but my overall subjective result is much better with madVR+yCMS. I think the difference in the YCC 4:2:0 -> RGB conversion is much more noticeable than the difference between matrix+shaper style <-> cLUT based color correction.

@cyberbeing
I vote for this kind of corrections/assumptions:
Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Input_Transfer_Function 1.0 0.0 0.425531915 0.0
Gamut_Measurements 0.682317569 0.307322062 0.205227114 0.696319629 0.15098312 0.056274784 0.312179044 0.32865249
Grayscale_Measurements 2
0 0.106242 0.111464 0.17869
0.39216 0.107896667 0.112873333 0.18019
0.78431 0.1102 0.1153475 0.18288
1.1765 0.11629 0.1215175 0.18927
1.5686 0.123358 0.129064 0.196224
1.9608 0.137176 0.143006 0.20708
2.3529 0.15885 0.16535 0.22914
2.7451 0.17961 0.18768 0.25096
3.1373 0.2085 0.21843 0.28034
3.5294 0.24306 0.25241 0.31307
3.9216 0.28933 0.30282 0.3584
4.3137 0.33707 0.35266 0.41374
4.7059 0.38994 0.40797 0.46775
5.098 0.44489 0.46658 0.52788
5.4902 0.51609 0.53755 0.59943
5.8824 0.59657 0.62356 0.68813
6.2745 0.67403 0.70667 0.78272
6.6667 0.75296 0.78951 0.87302
7.0588 0.83687 0.87731 0.96406
7.451 0.93631 0.97449 1.0657
7.8431 1.0459 1.0951 1.1932
8.2353 1.1469 1.2052 1.3153
8.6275 1.2521 1.3133 1.431
9.0196 1.3556 1.4248 1.5558
9.4118 1.4709 1.5436 1.682
9.8039 1.604 1.6781 1.8352
10.196 1.7355 1.8208 1.9889
10.588 1.8593 1.9527 2.1353
10.98 1.9858 2.0864 2.278
11.373 2.1107 2.2239 2.4252
11.765 2.2466 2.3601 2.5791
12.157 2.402 2.5163 2.7564
12.549 2.5651 2.6928 2.9477
12.941 2.7043 2.8406 3.1184
13.333 2.849 2.9938 3.2856
13.725 2.9993 3.1488 3.4604
14.118 3.1432 3.3081 3.6327
14.51 3.3139 3.4799 3.8195
14.902 3.4913 3.6581 4.0364
15.294 3.6603 3.8453 4.2355
15.686 3.8237 4.0206 4.4167
16.078 4.0004 4.2044 4.623
16.471 4.1656 4.3876 4.8197
16.863 4.3362 4.5611 5.0108
17.255 4.5167 4.7448 5.2248
17.647 4.714 4.9446 5.4662
18.039 4.902 5.1469 5.6704
18.431 5.1 5.3548 5.9009
18.824 5.2996 5.5738 6.1265
19.216 5.5019 5.7772 6.3674
19.608 5.6977 5.9885 6.5811
20 5.8822 6.1764 6.8209
20.392 6.0915 6.3868 7.0668
20.784 6.3187 6.622 7.3178
21.176 6.533 6.8462 7.5561
21.569 6.7385 7.072 7.8024
21.961 6.9653 7.3148 8.0559
22.353 7.1826 7.5342 8.296
22.745 7.3923 7.7659 8.5596
23.137 7.6064 7.9861 8.7965
23.529 7.8459 8.223 9.0687
23.922 8.0888 8.4757 9.3648
24.314 8.3252 8.7271 9.6165
24.706 8.559 8.9722 9.91
25.098 8.8475 9.2712 10.228
25.49 9.0857 9.5205 10.507
25.882 9.33 9.7834 10.802
26.275 9.5712 10.035 11.072
26.667 9.8258 10.293 11.353
27.059 10.098 10.567 11.653
27.451 10.337 10.812 11.921
27.843 10.6 11.104 12.239
28.235 10.844 11.347 12.554
28.627 11.111 11.632 12.883
29.02 11.352 11.888 13.1
29.412 11.619 12.167 13.408
29.804 11.889 12.441 13.7
30.196 12.169 12.74 14.041
30.588 12.442 13.009 14.348
30.98 12.719 13.306 14.614
31.373 13.013 13.615 15.04
31.765 13.299 13.914 15.345
32.157 13.587 14.218 15.694
32.549 13.842 14.482 15.941
32.941 14.132 14.796 16.273
33.333 14.446 15.102 16.635
33.725 14.734 15.392 16.966
34.118 15.021 15.696 17.283
34.51 15.311 16 17.678
34.902 15.606 16.315 17.95
35.294 15.896 16.629 18.276
35.686 16.193 16.929 18.655
36.078 16.477 17.231 18.949
36.471 16.798 17.577 19.255
36.863 17.099 17.865 19.676
37.255 17.408 18.186 20.028
37.647 17.694 18.487 20.364
38.039 18.007 18.825 20.695
38.431 18.323 19.153 21.054
38.824 18.615 19.46 21.372
39.216 18.916 19.766 21.749
39.608 19.242 20.122 22.154
40 19.556 20.442 22.479
40.392 19.877 20.779 22.791
40.784 20.199 21.1 23.112
41.176 20.516 21.446 23.514
41.569 20.854 21.814 23.953
41.961 21.158 22.124 24.309
42.353 21.478 22.455 24.657
42.745 21.796 22.797 25.008
43.137 22.125 23.134 25.383
43.529 22.461 23.479 25.717
43.922 22.793 23.815 26.125
44.314 23.156 24.17 26.507
44.706 23.528 24.538 26.894
45.098 23.905 24.91 27.316
45.49 24.289 25.282 27.784
45.882 24.692 25.721 28.23
46.275 25.092 26.119 28.659
46.667 25.495 26.554 29.07
47.059 25.887 26.951 29.564
47.451 26.309 27.384 30.001
47.843 26.705 27.806 30.567
48.235 27.1 28.216 31.02
48.627 27.523 28.675 31.463
49.02 27.935 29.122 31.932
49.412 28.346 29.552 32.411
49.804 28.767 29.983 32.847
50.196 29.278 30.506 33.493
50.588 29.682 30.94 34.002
50.98 30.104 31.386 34.463
51.373 30.517 31.816 34.992
51.765 30.962 32.3 35.513
52.157 31.362 32.723 35.952
52.549 31.769 33.16 36.441
52.941 32.211 33.628 36.961
53.333 32.636 34.06 37.411
53.725 33.066 34.511 37.827
54.118 33.462 34.939 38.304
54.51 33.873 35.37 38.804
54.902 34.323 35.839 39.338
55.294 34.729 36.293 39.789
55.686 35.161 36.745 40.353
56.078 35.564 37.183 40.85
56.471 35.992 37.628 41.279
56.863 36.447 38.103 41.73
57.255 36.887 38.564 42.27
57.647 37.278 38.965 42.801
58.039 37.715 39.427 43.345
58.431 38.177 39.918 43.868
58.824 38.607 40.39 44.28
59.216 39.039 40.846 44.783
59.608 39.462 41.296 45.331
60 39.894 41.742 45.935
60.392 40.366 42.248 46.379
60.784 40.793 42.707 46.909
61.176 41.21 43.128 47.35
61.569 41.667 43.608 47.812
61.961 42.133 44.11 48.35
62.353 42.566 44.568 48.896
62.745 42.989 45.032 49.471
63.137 43.418 45.473 50.066
63.529 43.86 45.942 50.558
63.922 44.334 46.444 51.084
64.314 44.802 46.95 51.434
64.706 45.222 47.344 52.047
65.098 45.7 47.868 52.593
65.49 46.154 48.353 53.107
65.882 46.611 48.822 53.462
66.275 47.048 49.285 54.034
66.667 47.5 49.796 54.744
67.059 47.953 50.257 55.149
67.451 48.43 50.76 55.497
67.843 48.913 51.253 56.136
68.235 49.376 51.736 56.83
68.627 49.853 52.232 57.197
69.02 50.349 52.758 57.817
69.412 50.809 53.235 58.383
69.804 51.295 53.733 58.935
70.196 51.739 54.219 59.586
70.588 52.232 54.738 59.89
70.98 52.724 55.23 60.43
71.373 53.211 55.76 60.913
71.765 53.733 56.309 61.559
72.157 54.222 56.815 62.018
72.549 54.686 57.292 62.479
72.941 55.204 57.863 63.127
73.333 55.726 58.417 63.77
73.725 56.2 58.93 64.346
74.118 56.66 59.405 64.934
74.51 57.181 59.966 65.229
74.902 57.677 60.448 65.935
75.294 58.361 61.159 66.633
75.686 58.835 61.651 67.327
76.078 59.354 62.198 67.856
76.471 59.849 62.722 68.399
76.863 60.372 63.289 69.105
77.255 60.862 63.761 69.745
77.647 61.413 64.381 70.159
78.039 61.947 64.947 70.534
78.431 62.543 65.525 71.491
78.824 63.064 66.08 72.178
79.216 63.614 66.634 72.726
79.608 64.139 67.183 73.253
80 64.714 67.779 73.94
80.392 65.273 68.362 74.629
80.784 65.862 68.999 75.202
81.176 66.404 69.546 75.82
81.569 66.93 70.094 76.628
81.961 67.494 70.682 77.32
82.353 68.08 71.283 77.97
82.745 68.656 71.909 78.589
83.137 69.236 72.482 79.267
83.529 69.828 73.118 79.853
83.922 70.423 73.751 80.612
84.314 71.002 74.374 81.434
84.706 71.623 75.019 82.03
85.098 72.225 75.639 82.478
85.49 72.782 76.234 83.258
85.882 73.391 76.862 84.147
86.275 74.027 77.535 84.807
86.667 74.639 78.178 85.453
87.059 75.224 78.72 86.159
87.451 75.887 79.446 86.885
87.843 76.49 80.1 87.558
88.235 77.072 80.769 88.232
88.627 77.714 81.439 89.019
89.02 78.288 82.026 89.712
89.412 78.83 82.603 90.655
89.804 79.427 83.226 91.225
90.196 80.06 83.951 91.944
90.588 80.721 84.597 92.455
90.98 81.329 85.235 93.11
91.373 81.896 85.848 93.825
91.765 82.525 86.522 94.557
92.157 83.108 87.167 95.354
92.549 83.764 87.79 96.04
92.941 84.399 88.463 96.815
93.333 84.96 89.103 97.756
93.725 85.576 89.812 98.324
94.118 86.162 90.405 99.084
94.51 86.704 91.026 99.682
94.902 87.301 91.661 100.05
95.294 87.796 92.131 101.2
95.686 88.389 92.796 101.96
96.078 88.948 93.342 102.4
96.471 89.585 94.024 102.97
96.863 90.209 94.781 103.89
97.255 90.711 95.319 104.75
97.647 91.2514 95.888 105.264
98.039 91.9506 96.5128 106.274
98.431 92.659 97.2676 107.168
98.824 93.35 98.0552 107.96
99.216 93.7922 98.5518 108.894
99.608 94.2948 99.1406 109.254
100 94.9796 99.9916 109.276

[yesgrey]

Could you please give me a 1.8b version where you remove this stupid limitation that every X, Y and Z column should have increasing numbers?
That's not a stupid limitation, it's a bug. It would be fixed on next version.

I think that I'm experiencing the same problem on my quad core Q8400 based PC. yCMS works fine on my dual core E5200 system though.
It seems to be a compiler bug. The next version should fix it.

[cyberbeing]

yesgrey, while using Grayscale_Measurements 2 or Grayscale_Measurements 1 if you list only the Y value, does ycms realize this and automatically use CIE Y on just those values?

For example:

Grayscale_Measurements 2
15 1.439 1.517 1.735
20 2.391 2.519 2.856
25 3.808 4.014 4.587
30 5.728 6.050 6.865
35 8.031 8.502 9.388
40 10.688 11.310 12.419
45 13.873 14.658 15.825
50 17.312 18.125 20.105
55 21.545 22.653 24.873
60 25.738 27.011 29.991
65 31.257 32.778 35.980
70 36.832 38.914 42.454
75 43.403 45.642 49.700
80 49.823 52.544 56.810
85 57.344 60.309 65.975
90 65.348 68.943 75.033
95 73.944 77.909 84.853
100 82.131 86.449 94.321
to
Grayscale_Measurements 2
15 1.517
20 2.519
25 4.014
30 5.728 6.050 6.865
35 8.031 8.502 9.388
40 10.688 11.310 12.419
45 13.873 14.658 15.825
50 17.312 18.125 20.105
55 21.545 22.653 24.873
60 25.738 27.011 29.991
65 31.257 32.778 35.980
70 36.832 38.914 42.454
75 43.403 45.642 49.700
80 49.823 52.544 56.810
85 57.344 60.309 65.975
90 65.348 68.943 75.033
95 73.944 77.909 84.853
100 82.131 86.449 94.321

If this no longer works, can you re-add the ability to do so in the next version? This is useful for when you your sensor can get accurate luminance values near-black but not accurate colorimetry.

If you don't want to make it automatic again, would something like the following make more sense, where ycms would combine multiple Grayscale_Measurements modes specified in a settings file, if no IRE values overlapped?

Grayscale_Measurements 0
15 1.517
20 2.519
25 4.014

Grayscale_Measurements 2
30 5.728 6.050 6.865
35 8.031 8.502 9.388
40 10.688 11.310 12.419
45 13.873 14.658 15.825
50 17.312 18.125 20.105
55 21.545 22.653 24.873
60 25.738 27.011 29.991
65 31.257 32.778 35.980
70 36.832 38.914 42.454
75 43.403 45.642 49.700
80 49.823 52.544 56.810
85 57.344 60.309 65.975
90 65.348 68.943 75.033
95 73.944 77.909 84.853
100 82.131 86.449 94.321

[yesgrey]

yesgrey, while using Grayscale_Measurements 2 or Grayscale_Measurements 1 if you list only the Y value, does ycms realize this and automatically use CIE Y on just those values?
No, it will consider those as invalid lines.

This is useful for when you your sensor can get accurate luminance values near-black but not accurate colorimetry.
Agreed. I will add it to the next version.

If you don't want to make it automatic again, would something like the following make more sense, where ycms would combine multiple Grayscale_Measurements modes specified in a settings file
I don't want to make it automatic, because when using format XYZ the first column is 'X', not 'Y', and that would be confusing. I have considered the possibility of entering the values on XYZ format as YXZ, but I didn't like the idea.

I like your suggestion of accepting the Grayscale_Measurements command more than once, so probably it would be like that.

[yesgrey]

yCMS v1.9 released

http://yesgrey.com/ycms.html

- Fixed bug on Grayscale_Measurements order verification.
- Changed Grayscale_Measurements: 'format' is set for each measurement.
- Added new parameter 'format' to Gamut_Measurements.
- Added Yxy and XYZ support on Gamut_Measurements.
- Changed Gamma_Curve algorithm to improve its accuracy.

[yesgrey]

I think I will go with input 32 235 and then gamma either 0.40 or 0.41. both look a tiny bit better in one scene or another, cant take the middle I guess :D
Do you still need this?

In fact Ycms.exe is using 50% of my cpu continually
I think that I'm experiencing the same problem on my quad core Q8400 based PC.
Please let me know if the new version fixes it.

[Thunderbolt8]

Do you still need this?Im not sure how to understand this, as I cannot really tell what the listed changes of 1.9 mean.
does it mean that now all greyscale adjustment is done automatically and it should be enough, only to do the colour adjustment as in that case of mine?