Can't achieve a decent color correction with Madvr + yCMS 3dlut

[darkbasic]

Here is a comparative screenshot:
http://darkbasic.homelinux.com/images/yCMS-vs-Photoshop.png

Here is my monitor's profile:
http://darkbasic.homelinux.com/monitor_140_f2000.icm

Monitor is a 30" Nec Spectraview 3090, HW calibrated with an Eye-One Colormunky spectrophotometer (Gamma 2.2, D65 and 140 cd/m^2) and profiled with argyll 1.3.1 with a 2000 patches chart.

Here is a dump of the wtpt, rXYZ, gXYZ and bXYZ tags from my minotor's profile:
C:\Users\Niko\Documents\monitor>iccdump.exe -v3 -t wtpt -t rXYZ -t gXYZ -t bXYZ monitor_140_f2000.icm
XYZArray:
No. elements = 1
0: 0.944122, 1.000000, 1.136963 [Lab 100.000000, -3.494897, -22.575995]
XYZArray:
No. elements = 1
0: 0.595306, 0.266281, -0.000214 [Lab 58.628512, 104.081738, 101.486962]
XYZArray:
No. elements = 1
0: 0.225998, 0.679947, 0.078293 [Lab 86.003793, -131.388852, 84.638767]
XYZArray:
No. elements = 1
0: 0.142899, 0.053772, 0.746811 [Lab 27.783450, 75.878480, -117.989972]

I converted them to xyY and I chromatic adaptated the rxyY, gxyY and bxyY values to find the primaries.

Here is the resulting HD - PC - Config.txt:
# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_PC 16

Gamut_Measurements 0.688384 0.308513 0.204128 0.697998 0.146249 0.052579 0.306425 0.324561

Gamma_Curve 0.0 2.2

- The frame without color correction has been made disabling 3dlut, pressing 'Stamp', pasting the frame into photoshop and assigning the 'monitor_140_f2000.icm' profile.
- The frame color corrected with yCMS has been made in the same way but with 3dlut enabled.
- The frame color corrected with Photoshop has been made disabling 3dlut, pressing 'Stamp', pasting the frame into photoshop and assigning the 'HDTV (Rec. 709)' profile.
All frames have been finally converted to ProPhoto with relative colorimetric w/ black point compensation.


Observations:
the frame color corrected with yCMS is much more contrasted than the one color corrected with Photoshop, giving less detailed dark zones. Is there any way to avoid it? Photoshop's color corrected frame is MUCH better.

Thank you,
Darkbasic

[dansrfe]

you need to make sure you're running ycms + madvr in exclusive mode to get rid of any windows stuff happening in the mix.

[leeperry]

you could always try this script (http://www.avsforum.com/avs-vb/showthread.php?t=912720) for comparisons sake's, as it's been fully tested by hundreds ppl.

here's a good test pattern: rec709.mkv (http://www.mediafire.com/download.php?gjau13ct5x8ry4g)

[darkbasic]

you need to make sure you're running ycms + madvr in exclusive mode to get rid of any windows stuff happening in the mix.

Can you tell me something more? What's exclusive mode? How can I check if I already use it?

you could always try this script (http://www.avsforum.com/avs-vb/showthread.php?t=912720) for comparisons sake's, as it's been fully tested by hundreds ppl.

I already tried the shader editor solution, but again the result wasn't similar to the photoshop one. Please see this thread: http://forum.doom9.org/showthread.php?t=157700

[madshi]

Ultimately yesgrey needs to comment on this, but let me try:

You did not provide yCMS with grayscale measurements. But you asked yCMS to modify the gamma curve of the source to a 2.2 pure power curve. Doing that does make the image more "contrasty" which eats shadow detail.

Let me ask you: What exactly do you want yCMS to do? Do you want it to:

- do gamut correction?
- do gamma correction?
- modify the gamma curve of the movie?

Of course the yCMS configuration must be set according to what you want to achieve. Your current yCMS configuration corrects the gamut, and makes the gamma more contrasty. So I'd say you get what you asked yCMS to do. If you want something else, let me know what and we can adjust your yCMS configuration accordingly.

[darkbasic]

I want to do gamut and gamma correction. Best way should be providing grayscale measurements, but unfortunately HCFR does not support my spectrophotometer and I still didn't try to do the measurements with argyll because I will have to make a chart with the very same patches.
So I tried to specify the display's gamma response. The manual says:
Gamma_Curve curveType gammaValu - If curveType is set to 0.0, the display will be calibrated to a pure power curve.

Doesn't it allow me to specify my monitor's gamma response?

Thank you

[madshi]

As long as you don't provide grayscale measurements I'd recommend to remove the "gamut_curve" command from the yCMS configuration. I'm pretty sure that your problems with contrast and shadow detail will go away then. Put the "gamut_curve" command back in once you're able to provide gamma measurements.

To be honest, I think yCMS should be modified. The current behaviour of the "gamut_curve" command, when no gamma measurements are given, is not intuitive. At least it's different to what you expected. But that's something yesgrey and I will have to discuss. For now my recommendation is (as said above) to use "gamut_curve" only if you also provide grayscale measurements.

[madshi]

Doesn't it allow me to specify my monitor's gamma response?
I think you're misunderstand the purpose of the gamma_curve command. You seem to think that you can use it to tell yCMS how your display is currently calibrated. But that's not what gamma_curve is for. If you want to tell yCMS how your display is currently calibrated, you should provide grayscale measurements. The documentation says: "gamma_curve specifies the desired gamma curve to get after display calibration". In other words: gamma_curve tells yCMS how you want your display to behave after yCMS calibration. The problem is that without grayscale measurements yCMS doesn't have all the information it needs to properly realize your gamma_curve wishes. I think gamma_curve should not be used without grayscale measurements.

[darkbasic]

Maybe I found a way to do IRE measurements with argyll:
The -g parameter sets the number of patches in a set of combined (nominally gray) wedges. This will typically be equal RGB or CMY values, and by default will be equally spaced steps in device space.

If I understood correctly black equals to 0 IRE and white to 100 IRE (but from wikipedia white seems to be 140 IRE). So I can use targen with the -g parameter set to x while x is:

x - (x/100)*30 = 256 ==> x = 366

This gives me 256 useable measurements: 366 minus the measurements below 30 IRE [(366/100)*30=110]

Then I can find the corresponding IRE with:
IRE = measurement_number/3,66


Am I right? Is this what I need?

[madshi]

I've no idea. This is not my area of expertize.

[darkbasic]

In the meantime I did one more test removing Gamma_Curve:
http://darkbasic.homelinux.com/images/test_pattern1.png

Even without Gamma_Curve the differences are really big (probably dE 6 or even greater) and I can clearly see a differece in ALL test patterns expect the darkest one :(

[madshi]

These are very different tests than before. Is the contrast/shadow detail problem still there or is that gone? It doesn't make sense to analyze multiple errors at the same time. One problem at a time, that's the only proper way. So first: Is the contrast/shadow detail problem still there?

[darkbasic]

So first: Is the contrast/shadow detail problem still there?

Not completely, yCMS still gives a slightly more contrasted image, but it may not be a gamma related problem.

Here is another screenshot (unfortunately it's quite impossibile to find the same frame, so do not compare it with the previous one):
http://darkbasic.homelinux.com/images/yCMS-vs-Photoshop2.png

[madshi]

I'm not sure but I think something is wrong with your screenshots or with the way you create them. In the original shot there is banding in the face and the face is slightly green. The photoshop shot shows no banding and no green tint. I doubt that the original really has a green tint to it. Furthermore it's practically impossible that the original has banding in it and the photoshop image somehow gets rid of the banding.

> The frame without color correction has been made
> disabling 3dlut, pressing 'Stamp', pasting the frame
> into photoshop and assigning the 'monitor_140_f2000.icm'
> profile.

Why the heck did you assign the icm profile and then name the image "original"? My understanding of "original" would be "untouched" which means you should not apply the icm profile.

> The frame color corrected with yCMS has been made in
> the same way but with 3dlut enabled.

So for the yCMS corrected frame you applied the icm profile another time on top??? Why would you do that? Makes no sense to me whatsoever. You should use either the icm profile or the 3dlut but not both at the same time.

Furthermore your "photoshop" image does not have the icm profile applied? So the reason why the "photoshop" image looks better than the others is that you applied the icm profile to the others, but not to the photoshop image.

[darkbasic]

In the original shot there is banding in the face and the face is slightly green. The photoshop shot shows no banding and no green tint. I doubt that the original really has a green tint to it. Furthermore it's practically impossible that the original has banding in it and the photoshop image somehow gets rid of the banding.

Are you using firefox to see it? Unfortunately firefox no longer uses LCMS and so now it sucks hard. If you view it with photoshop there is no banding in the 'Original' frame (but there is some banding in the photoshop frame instead :D)
Even Photoshop sucks a bit when dealing with complex color management (like rec709-->prophoto-->monitor_140_f2000.icm in my instance). If you use LUT profiles instead of shaper+matrix ones, photoshop is even worse, sometimes terrible :scared:

So if you do not want to see banding at all I will have to use Cinepaint which is actually the only one which has decent color management, but I will have to boot linux every time...

Why the heck did you assign the icm profile and then name the image "original"? My understanding of "original" would be "untouched" which means you should not apply the icm profile.

With original I mean "as I see on my monitor without any color correction". Assigning my monitor's profile is like doing no color management at all, in fact the 'Original' frame is exactly as I see it in MPC-HC with 3dlut disabled.


So for the yCMS corrected frame you applied the icm profile another time on top??? Why would you do that? Makes no sense to me whatsoever. You should use either the icm profile or the 3dlut but not both at the same time.

Again, assigning my monitor's profile is like doing no color management at all: if source profile is A and monitor profile is again A, color management is a 1:1 transform, so no color management is done and you only see the color management done by 3dlut. In fact, the 'Photoshop' frame is exactly as I see it in MPC-HC with 3dlut enabled.

Furthermore your "photoshop" image does not have the icm profile applied? So the reason why the "photoshop" image looks better than the others is that you applied the icm profile to the others, but not to the photoshop image.

It has, as I said previously I applied the "HDTV (Rec. 709)" profile. This time Photoshop's monitor compensation converts from the source profile (Rec. 709) to the monitor profile (monitor_140_f2000.icm). If my assumption that the movie color space is Rec. 709 is right, then the resulting image will look nice (and this is the case).

[madshi]

This is all too complicated for me. If we have to use specific image apps to view your screenshots properly then there are so many variables at play that I can not judge, anymore, what's going on. I don't really understand which profiles are applied in which order, on which monitor with which app the screenshots are supposed to be watched etc etc. Maybe yesgrey can help out, but I've heard he's very busy at the moment.

[darkbasic]

It's quite simple:

Original/No color correction:
No color management at all, as I see it in MPC-HC with 3dlut off. To achieve it I have to disable 3dlut and assign my monitor's profile, you will see it as I see it on my monitor. If I don't apply any profile at all, I will still see it in the same way, but *YOU* will see it in a different manner, like if you are actually playing the same movie with MPC-HC and 3dlut off!

Photoshop Color Correction:
I assing the Rec. 709 profile. 3dlut is obviously disabled because I want Photshop to do the color correction, not yCMS. I called it 'Photoshop' because the Rec. 709 profile is in bundle with Photoshop, but Photoshop actually did nothing, I just applied a profile to the image and I did no conversion at all! (well, except for the ProPhoto conversion, but I had to do it just because I put images with different color spaces into one single image). Is the image viewer you use which really does the color management!

yCMS:
As I see it in MPC-HC with 3dlut on. 3dlut is enabled and I assign my monitor's profile, you will see it as I see it on my monitor. If I don't apply any profile at all, I will still see it in the same way, but *YOU* will see it in a different manner, like if you are actually playing the same movie with MPC-HC and 3dlut on using the same "HD - PC.3dlut" file I use!

To judge the images your monitor has to be profiled, but you can use whatever image viewer which supports color managemet! Even firefox is right, but be aware that you may see some banding because it sucks. Just ignore them :sly:

[madshi]

Neither my monitor nor projector are profiled. And I don't have Photoshop.

[darkbasic]

You definitively need a profiled monitor. I will wait for yesgrey, thank you very much.

[darkbasic]

For comparison here is what I obtain with MPC-HC embedded color management:
http://darkbasic.homelinux.com/images/mpchc1.png
http://darkbasic.homelinux.com/images/mpchc2.png

The result is stunning, I just can't see any difference, except for the dark patches of course (I filed a bug: https://sourceforge.net/apps/trac/mpc-hc/ticket/881)
The difference may be huge in dark scenes: http://darkbasic.homelinux.com/images/mpchc-photoshop.png

Here are the .psd files, if someone wants to play enabling/disabling layers or layer masks:
http://darkbasic.homelinux.com/images/mpchc1.psd
http://darkbasic.homelinux.com/images/mpchc2.psd

Unfortunately it doesn't support madVR renderer :-(

[janos666]

I filed a bug: https://sourceforge.net/apps/trac/mpc-hc/ticket/881)
The difference may be huge in dark scenes: http://darkbasic.homelinux.com/images/mpchc-photoshop.png(

I have a ticket too: https://sourceforge.net/apps/trac/mpc-hc/ticket/862

First of all:
- MPC-HC's lcms implementation is broken. You can't achieve a proper color correction because the working rendering intents won't correct the white point.
And it didn't use black offset. (I think it works with the latest SVN builds. You should check.)
- But this is also true for yCMS, it won't correct the white point. (It looks like it would correct it as well, but the current version doesn't do it!)
- On the other hand, Photoshop corrects the white point and it also uses black offset.
It can make a huge difference when you don't calibrate your display (for example: you don't have any instruments but an ICM file from your display's manufacturer).

But this white point issue is not a real problem when you calibrate your display to D65 white (not 6500k blackbody, but daylight filtered 6500K...).
And yes, MPC-HC shouldn't touch the gamma when you already calibrated your display to the same target gamma. (I think there was a problem with the black offset.)

So, your best choice is to
- Calibrate your display to D65 white and gamma ~2.35 (select your target gamma according to your current faith/belief/random choice...)
- Use an yCMS command file, like this:

Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Input_Transfer_Function 1.0 0.0 0.425531914893617 0
Output_Transfer_Function 1.0 0.0 0.425531914893617 0
Gamut_Measurements 0.682537479 0.307457486 0.204105114 0.697129708 0.150903096 0.055930001 0.311976618 0.32839644

You can't achieve any better results yet.


By the way, I would use MPC-HC for a notebook where I need DXVA for HD contents (a notebook with 1920x1200 display). And this is a notebook display with a relatively old VGA, so the VGA LUT works with 8 bit/color effective precision. That's why I don't want to calibrate it but profile it only. In this situation, I need Absolute colorimetric rendering intent which is broken in MPC-HC. So, it's not a working solution yet.


And a little side note: You should use ArgyllCMS 1.3.2 for calibration and profiling. You can't find any better software but bundled softwares may let you down!

[darkbasic]

- MPC-HC's lcms implementation is broken. You can't achieve a proper color correction because the working rendering intents won't correct the white point.
And it didn't use black offset. (I think it works with the latest SVN builds. You should check.)

Uhm... isn't white point correction the "Paper Color Simulation" in photoshop? If yes, it isn't effective for a shaper+matrix profile, you can check it yourself using softproof.
And what about black offset? Again, it isn't effective if monitor's profile is a shaper+matrix one.



I did one more test: I applied "dark environment" output viewing condition for the perceptual B2A table embedded in the profile.

colprof -v -qh -ni -no -np -as -tp -S sRGB.icm -cmt -dmd monitor_140_f2000_dmd

Now using photoshop's softproof I can clearly see the difference between releative and perceptual intent, but in MPC-HC there is no difference, perceptual gives the same output of relative intent :scared: Why?

You can't achieve any better results yet.
Did you test Yue Shi Lai mplayer's color management patch? It uses LCMS too, maybe it's better...


And a little side note: You should use ArgyllCMS 1.3.2 for calibration and profiling. You can't find any better software but bundled softwares may let you down!

I do, I'm an argyll fan too :sly:
Is use it for profiling but not for calibration becuase I have a professional monitor which I hardware calibrate.

[janos666]

Uhm... isn't white point correction the "Paper Color Simulation" in photoshop? If yes, it isn't effective for a shaper+matrix profile, you can check it yourself using softproof.

Sorry, I haven't read the full thread. I thought you created an XYZ LUT profile, not a shaper+matrix one.
But yes, I think it can be better when you can calibrate your display properly, through the hardware LUT. (Or when your softwares don't support XYZ-LUT profiles.)
And I am not sure if the lcms in MPC-HC uses the cLUT anyway. I didn't tested it with the cLUT+swapped matrix option.

It's not always that simple. In some situations, PS corrects the WP in any rendering intent modes. (For example, when you would attach your ICM file, which you mentioned.)

And what about black offset? Again, it isn't effective if monitor's profile is a shaper+matrix one.

I though the gamma settings in MPC-HC mess with the gamma (when you already calibrated your display to the same gamma) because it doesn't use black offset.
By the way, there is a black colorant tag in matrix profiles too.


I did one more test: I applied "dark environment" output viewing condition for the perceptual B2A table embedded in the profile.

colprof -v -qh -ni -no -np -as -tp -S sRGB.icm -cmt -dmd monitor_140_f2000_dmd

Now using photoshop's softproof I can clearly see the difference between releative and perceptual intent, but in MPC-HC there is no difference, perceptual gives the same output of relative intent :scared: Why?

Yes, I already noticed it. Every rendering intent modes in MPC-HC produces the same result, except the Absolute colorimetric which is clearly broken (because it always produces bluish white point).


Did you test Yue Shi Lai mplayer's color management patch? It uses LCMS too, maybe it's better...

No, I didn't. I don't know the software but I doubt they implemented the FP16 processing and 10 bit input modes for EVR and color management is useless without these things.

I do, I'm an argyll fan too :sly:
Is use it for profiling but not for calibration becuase I have a professional monitor which I hardware calibrate.

Well, maybe it's not the best idea. I think you should let your calibration software to construct the profile for you.
And maybe I would construct an ICM file manually when I can trust in the calibration: I would write my calibration targets (simple gamma value and target white point coordinates) manually into the ICM file, with the additional RGB coordinates.

When your display is properly calibrated through the hardware LUT, you don't really need any additional corrections but gamut emulation only.
This gamut emulation requires the 2D coordinates of the primaries and a single gamma value, because you already smoothed out your gamma curve and the white balance with the hardware calibration.

But this is what I suggested you to try with yCMS.


A tip for ArgyllCMS: You should use the XYZ coordinates from your *.ti3 files. They are absolute values, you don't need chromatic adaptation (which isn't exact). :o

[darkbasic]

I don't know the software but I doubt they implemented the FP16 processing and 10 bit input modes for EVR and color management is useless without these things.

I don't know the details, but it seems he did a good job.
Here is a description of his implementation:
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2008-August/058341.html

And here is latest patch:
http://archives.free.net.ph/message/20100119.155927.ed7fa4ae.ca.html

Let me know what do you think about it.


Well, maybe it's not the best idea. I think you should let your calibration software to construct the profile for you.

I tried, but it does some things I don't like, like putting chromatic adapted primaries in the profile instead of D50. I trust argyll much more.

A tip for ArgyllCMS: You should use the XYZ coordinates from your *.ti3 files. They are absolute values, you don't need chromatic adaptation (which isn't exact). :o

Are you *really* sure? Because I already asked it and yesgrey (yCMS's author) told me to use the the chromatic adapted values:
http://forum.doom9.org/showpost.php?p=1340017&postcount=512
http://forum.doom9.org/showpost.php?p=1340053&postcount=516
:confused:

[janos666]

I don't know the details, but it seems he did a good job.
Let me know what do you think about it.

The quality of the lcms implementation means nothing until the video renderer is unable to properly present the result (corrected or untouched images...).
But ok, I can take a look at this player (without any hope).



I tried, but it does some things I don't like, like putting chromatic adapted primaries in the profile instead of D50. I trust argyll much more.

Strange, but it doesn't mean that it's broken. The v4 version of the ICC standard defined this thing better. So, it can work if it's a v4 profile. (ArgyllCMS/colorprof creates v2 profiles.)

And it also depends on the chromatic adaptation method. Different algorithms creates different outputs, that's why they exists (I mean: more than one...).

Are you *really* sure? Because I already asked it and yesgrey (yCMS's author) told me to use the the chromatic adapted values:
http://forum.doom9.org/showpost.php?p=1340017&postcount=512
http://forum.doom9.org/showpost.php?p=1340053&postcount=516
:confused:

Yes, I am sure.

ArgyllCMS stores the measurement data in the *.ti3 files. Your actual instrument output is spectral data and ArgyllCMS saves the converted CIE 1932 XYZ coordinates in the *.ti3 files. They are absolute values.
But yes, a chromatic adaptation is necessary when you have a WP different from D65. That's why yCMS asks for the white xy coordinates (gamut_measurements R, G, B W - xy coordinates...). I am not sure if yCMS handles it correctly (I mean, the current public version...) but this is not a problem when you calibrate your display to D65 white first (as Rec709 is based on D65 as well).

The ICM files has chromatic adapted coordinates which are relative to D50 because this is the reference illuminant of the ICC standard.

So, you can pick up the original data from the *.ti3 files and do a simple XYZ->xyz calculation (simple and exact linear transformation) or you can let ArgyllCMS/colorprof (or whatever) to save the chromatic adapted XYZ coordinates in an ICM file and do a revers chromatic adaptation (by yourself or by yCMS -> because yCMS can theoretically do that when you insert your R, G, B, W coordinates) and you can hope that both processes used the same algorithm and the error is negligible. It's risky and redundant, a waste of time and quality...

[janos666]

May be it's my fault (I didn't find the "magic switch") but I couldn't achieve a good result with this player.
I tried to use direct3d and opengl renderers (with different switches) but it always looks like the EVR without the FP16P and 10 bit input switches. (The grayscale was not smooth.)

[darkbasic]

I will ask Yue Shi Lai about FP16P and 10 bit, can you point me to a good test video?

[janos666]

http://www.avsforum.com/avs-vb/showthread.php?t=948496
I use the mp4 files. A good one: Calman fields, Brightness, contrast.

The floating point processing is a renderer thing. For example, madshi wrote his own D3D renderer with 32+ bit pipeline. The Mplayer has a lot of renderers but none of them looks "good" (at least under windows 7).

[darkbasic]

- Use an yCMS command file, like this:
Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Input_Transfer_Function 1.0 0.0 0.425531914893617 0
Output_Transfer_Function 1.0 0.0 0.425531914893617 0
Gamut_Measurements 0.682537479 0.307457486 0.204105114 0.697129708 0.150903096 0.055930001 0.311976618 0.32839644

I tried it but I still get terrible results :(
yCMS is the lower one:
http://darkbasic.homelinux.com/images/yCMS.png

Here is the psd if someone wants to play with levels:
http://darkbasic.homelinux.com/images/yCMS.psd

[cbw.lava]

For comparison here is what I obtain with MPC-HC embedded color management:
http://darkbasic.homelinux.com/images/mpchc1.png
http://darkbasic.homelinux.com/images/mpchc2.png

The result is stunning, I just can't see any difference, except for the dark patches of course (I filed a bug: https://sourceforge.net/apps/trac/mpc-hc/ticket/881)
The difference may be huge in dark scenes: http://darkbasic.homelinux.com/images/mpchc-photoshop.png

This is not a bug. The Rec. 709 profile from Adobe is a ICC v4 LUT profile with a different TRC (it looks like the sRGB TRC which has a straight segment at the dark end), so of course the results are different from a pure gamma curve. If you want same results, you have to use a profile with the same gamma as selected in MPC-HC.

[darkbasic]

I did one final test doing Grayscale_Measurements with argyll:
targen -v -d3 -f0 -g 101 -e0 gray
dispread -v -H -yl gray

Here is the ti3 file: http://darkbasic.homelinux.com/images/gray.ti3

And here is yCMS config:
Input_Format HD YCbCr 8

Output_Format HD RGB_PC 16

Grayscale_Measurements 2
30 6.9079 7.3366 8.1785
31 7.2734 7.7528 8.6289
32 7.9362 8.4506 9.4189
33 8.3416 8.8640 9.8735
34 9.0097 9.5840 10.674
35 9.5043 10.110 11.189
36 10.187 10.827 12.019
37 10.667 11.356 12.561
38 11.415 12.128 13.471
39 11.966 12.704 14.085
40 12.728 13.530 14.979
41 13.520 14.394 15.906
42 14.025 14.901 16.503
43 14.943 15.867 17.553
44 15.566 16.553 18.309
45 16.482 17.518 19.305
46 17.142 18.202 20.096
47 18.090 19.223 21.208
48 18.755 19.922 21.933
49 19.817 21.055 23.183
50 20.934 22.245 24.449
51 21.601 22.975 25.175
52 22.669 24.080 26.459
53 23.429 24.933 27.307
54 24.574 26.083 28.626
55 25.378 26.950 29.597
56 26.556 28.214 30.845
57 27.349 29.076 31.831
58 28.713 30.513 33.402
59 29.493 31.345 34.194
60 30.786 32.744 35.705
61 32.086 34.142 37.253
62 33.070 35.175 38.418
63 34.343 36.529 39.851
64 35.327 37.541 40.992
65 36.758 39.060 42.626
66 37.753 40.104 43.842
67 39.287 41.737 45.528
68 40.220 42.730 46.647
69 41.861 44.480 48.522
70 43.430 46.165 50.288
71 44.469 47.285 51.545
72 46.094 48.988 53.401
73 47.210 50.201 54.758
74 48.734 51.805 56.405
75 49.887 53.046 57.819
76 51.775 55.033 59.929
77 52.852 56.181 61.201
78 54.733 58.172 63.448
79 56.020 59.559 64.999
80 57.802 61.445 66.966
81 59.636 63.339 69.109
82 60.964 64.778 70.671
83 62.842 66.752 72.771
84 64.110 68.128 74.213
85 66.203 70.319 76.682
86 67.407 71.598 78.033
87 69.607 73.955 80.548
88 71.010 75.425 82.166
89 73.040 77.564 84.580
90 75.259 79.938 86.998
91 76.677 81.375 88.767
92 78.807 83.635 91.275
93 80.420 85.356 93.168
94 82.516 87.637 95.686
95 84.018 89.270 97.406
96 86.442 91.762 100.20
97 87.964 93.425 101.88
98 90.283 95.862 104.61
99 92.184 97.895 106.70
100 94.176 100.00 109.09

Gamut_Measurements 0.691113 0.309136 0.229617 0.690836 0.151459 0.056993 0.306425 0.324561

But the resulting image is still very bad :mad:

yCMS is the lower one:
http://darkbasic.homelinux.com/images/yCMS_grayscale.png

The psd if someone wants to play with levels/layer masks:
http://darkbasic.homelinux.com/images/yCMS_grayscale.psd

[cbw.lava]

- MPC-HC's lcms implementation is broken. You can't achieve a proper color correction because the working rendering intents won't correct the white point.

Yes, the absolute colorimetric intent is broken badly.

And it didn't use black offset. (I think it works with the latest SVN builds. You should check.)

There is no such thing as 'black offset' in ICC terms. Did you mean the (originally Adobe proprietary, but also supported by LCMS) black point compensation? I think this is already used by MPC-HC, but I'd need to re-check.
If by 'black offset' you mean the 'bkpt' mediaBlackPointTag that may be present in display profiles: Afaik this tag is not used by any recent CMM out there (not Adobe ACE, not LCMS) because it's redundant (behavior at the blackpoint is already recorded in the TRCs of matrix profiles or the LUTs of LUT profiles). It has for this and other reasons been deleted from the current ICC spec (see http://color.org/ICCSpecRevision_07_11_07_BlackPointTag_Deletion.pdf).

And yes, MPC-HC shouldn't touch the gamma when you already calibrated your display to the same target gamma. (I think there was a problem with the black offset.)

Usually when you calibrate to a certain gamma, this means (atleast with Argyll) that it will match the 50% output of the requested gamma value. So, the actual response (especially at and near the blackpoint) will still be different from a pure power curve (and it has to be, as the pure power curve assumes zero output at zero input, which no real display can reproduce).

[darkbasic]

This is not a bug. The Rec. 709 profile from Adobe is a ICC v4 LUT profile with a different TRC (it looks like the sRGB TRC which has a straight segment at the dark end)
WTF? :eek:
Shouldn't Rec. 709 be a standard? Not only the still use SMPTE-C monitors for mastering but there isn't a general accepted Rec. 709 definition too? :(

so of course the results are different from a pure gamma curve. If you want same results, you have to use a profile with the same gamma as selected in MPC-HC.
Can you point me to one?
Also, being able to specify the input profile in MPC-HC would be wonderful...

[cbw.lava]

Uhm... isn't white point correction the "Paper Color Simulation" in photoshop? If yes, it isn't effective for a shaper+matrix profile, you can check it yourself using softproof.
And what about black offset? Again, it isn't effective if monitor's profile is a shaper+matrix one.

Just because Photoshop doesn't support it doesn't mean it's not possible :) Of course you can have WP correction with matrix profiles. Also here is a very good post (on the Argyll CMS list) about how the PS softproof settings work:

http://www.freelists.org/post/argyllcms/Confused-with-PS-softproofing-and-monitor-profile-intents

I did one more test: I applied "dark environment" output viewing condition for the perceptual B2A table embedded in the profile.

colprof -v -qh -ni -no -np -as -tp -S sRGB.icm -cmt -dmd monitor_140_f2000_dmd

Now using photoshop's softproof I can clearly see the difference between releative and perceptual intent, but in MPC-HC there is no difference, perceptual gives the same output of relative intent :scared: Why?

colprof -as requests a shaper+matrix profile, this can't incorporate gamut mapping. So the -ni, -no, -np, -tp, -S, -cmt and -dmd parameters are ignored.

[cbw.lava]

WTF? :eek:
Shouldn't Rec. 709 be a standard? Not only the still use SMPTE-C monitors for mastering but there isn't a general accepted Rec. 709 definition too? :(

I can just talk about the profile that Adobe delivered, and it doesn't have a pure power curve TRC.

Can you point me to one?

Attached is a profile with sRGB primaries (= Rec. 709) and pure power gamma 2.2

Also, being able to specify the input profile in MPC-HC would be wonderful...

Agreed.

[darkbasic]

Can you upload it to Mediafire (http://www.mediafire.com/)? Otherwise we need moderator's approval.

Also, what's "Ambient Light" option in MPC-HC? I've never seen anything similar in any color aware application...

[janos666]

I tried it but I still get terrible results :(
yCMS is the lower one:
http://darkbasic.homelinux.com/images/yCMS.png

Here is the psd if someone wants to play with levels:
http://darkbasic.homelinux.com/images/yCMS.psd

When I saw these images, I wanted to say the same what cbw.lava told.

It's a problem with the tonal response curves.
If you want to match with the Adobe profile, try to use the Rec709 inverse-encode curve as a decoding curve in yCMS (there is a Rec709 "preset" for the in/output_transfer_function commands).

I already said: You should set the TRC according to your current faith/belief/random guess. There is no standard decoding curve for Rec709 contents. It defines an encoding curve but the common opinion is that you shouldn't use the inverse-encode curve as a decode curve but you should use a pure power gamma curve for decoding (and you should set the exponent according to your environment light conditions -> darker room requires higher exponent)


And be careful with the
Output_Transfer_Function 1.0 0.0 0.425531914893617 0
command: 1/2.35=0.425
So, you should calibrate your display to gamma 2.35 or change these numbers.

If you store your LUT in the device's internal memory and you can store one LUT only, and you want to use your display as a PC monitor, then you should calibrate it to gamma 2.2, and use something like this:
Input_Transfer_Function 1.0 0.0 0.425531914893617 0
Output_Transfer_Function 1.0 0.0 0.45 0
If you can store more than one LUTs (or you want to use this display for video playback/editing only) then you should make a device LUT with gamma 2.35 and use something like this:
Input_Transfer_Function 1.0 0.0 0.425531914893617 0
Output_Transfer_Function 1.0 0.0 0.425531914893617 0
Or, if you wish to match with PS, you can use the inverse-Rec709-encode curve...

@cbw.lava
Yes, black point compensation (instead of black offset)...
The curve scaling also depends on your settings, you can choose relative or absolute scaling, with or without black offset.
Of course, you should choose the relative with black offset for LCDs.

And yes, it's never perfect. But you shouldn't try to refine your 10+ bit hardware-LUT/VGA-LUT calibration with a software based CMS which works with 8 (or even 10) bit framebuffers. It can't help but it can hurt...

[cbw.lava]

Can you upload it to Mediafire (http://www.mediafire.com/)? Otherwise we need moderator's approval.

Done :) http://www.mediafire.com/?hu9p9djqqe6secy

Also, what's "Ambient Light" option in MPC-HC? I've never seen anything similar in any color aware application...

The 'ambient light' option just chooses the source TRC. So, to get matching results in MPC-HC and Photoshop, use HDTV material with ambient set to 'Bright (Gamma 2.2)' and the above profile in PS.

[cbw.lava]

It's not always that simple. In some situations, PS corrects the WP in any rendering intent modes. (For example, when you would attach your ICM file, which you mentioned.)

That's interesting. I have never experienced such behavior in recent Photoshop versions. In fact, white point correction seems to be not working for me when converting between matrix profiles with different whitepoints (ICCv2, no ICCv4 'chad' chromatic adaption tags) in Photoshop using absolute colorimetric and Adobe Ace (interestingly, it works when switching to Microsoft ICM as engine, which uses Heidelberg code, but has other drawbacks). (Sorry I know the PS stuff is a bit OT :))

[janos666]

I can't explain it. I played with PS and different profiles (constructed from the same measurement data - 2386 points - with different colorprof settings).
I wasn't able to achieve the WP correction for any images (with any intent modes).
But I created a new document, and it worked. The blank white background was white. I saved and reopened it in other non-CMS viewers and it wasn't white. I reopened it in PS and it was white.
The working space was set to sRGB and the intent modes didn't change anything on this blank white image.

(It was easy to decide because I used an uncalibrated notebook display. But I also took some readings with spotread.)

And I think it always works when you open and image, convert it to your display profile and save it as sRGB (or whatever) again. (You can see it when you open it in non-CMS software: the white will be white...)

I used PS CS5 x64 with the advanced OpenGL renderer.


But... hmm... May be I also tried to set the engine to MS. I can't remember.

[darkbasic]

I can store more than one LUT and I can even calibrate locking the primaries into sRGB gamut instead of the native one (but I have to calibrate to gammma 2.2 if I want sRGB emulation). If I remember correctly Rec. 709 primaries are the sRGB ones, so I don't need gamut correction at all for HD material.
If I'm going to do a separate calibration to watch films, maybe I should choose a better contrast ratio too: actually I calibrated to a 300:1 contrast ratio (because printers have a similar contrast). What's the best contrast calibration target for watching films? Lowest black and maximum possible intensity (meaning maximum possible contrast)?

If I calibrate for sRGB emulation and 2.2 gamma, is this config right?

Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16
Input_Transfer_Function 1.0 0.0 0.425531914893617 0
Output_Transfer_Function 1.0 0.0 0.45 0

Or doing Grayscale_Measurements is better than using a 0,45 Output_Transfer_Function?

Thank you

[darkbasic]

Done :) http://www.mediafire.com/?hu9p9djqqe6secy

Thank you very much! Now MPC-HC gives coherent results! Do you have a profile with Gamma 2,35 too?

When I saw these images, I wanted to say the same what cbw.lava told.

It's a problem with the tonal response curves.

It was the problem with MPC-HC's color correction, but I can't still achieve coherent results with yCMS.

Here is the psd file with 4 layers: http://darkbasic.homelinux.com/images/madvr_tests.psd


[A] madvr, 3dlut OFF, sRGB primaries w/ Gamma 2.2
The output renderer is madvr, 3dlut was disabled and I assigned cbw.lava's profile.

[ B] madvr, 0.45 input transfer function, grayscale measurements
I used 0,45 input transfer function because cbw.lava's profile has a 2.2 gamma. This is the config:
Input_Format HD YCbCr 8

Output_Format HD RGB_PC 16

Grayscale_Measurements 2
30 6.9079 7.3366 8.1785
31 7.2734 7.7528 8.6289
32 7.9362 8.4506 9.4189
33 8.3416 8.8640 9.8735
34 9.0097 9.5840 10.674
35 9.5043 10.110 11.189
36 10.187 10.827 12.019
37 10.667 11.356 12.561
38 11.415 12.128 13.471
39 11.966 12.704 14.085
40 12.728 13.530 14.979
41 13.520 14.394 15.906
42 14.025 14.901 16.503
43 14.943 15.867 17.553
44 15.566 16.553 18.309
45 16.482 17.518 19.305
46 17.142 18.202 20.096
47 18.090 19.223 21.208
48 18.755 19.922 21.933
49 19.817 21.055 23.183
50 20.934 22.245 24.449
51 21.601 22.975 25.175
52 22.669 24.080 26.459
53 23.429 24.933 27.307
54 24.574 26.083 28.626
55 25.378 26.950 29.597
56 26.556 28.214 30.845
57 27.349 29.076 31.831
58 28.713 30.513 33.402
59 29.493 31.345 34.194
60 30.786 32.744 35.705
61 32.086 34.142 37.253
62 33.070 35.175 38.418
63 34.343 36.529 39.851
64 35.327 37.541 40.992
65 36.758 39.060 42.626
66 37.753 40.104 43.842
67 39.287 41.737 45.528
68 40.220 42.730 46.647
69 41.861 44.480 48.522
70 43.430 46.165 50.288
71 44.469 47.285 51.545
72 46.094 48.988 53.401
73 47.210 50.201 54.758
74 48.734 51.805 56.405
75 49.887 53.046 57.819
76 51.775 55.033 59.929
77 52.852 56.181 61.201
78 54.733 58.172 63.448
79 56.020 59.559 64.999
80 57.802 61.445 66.966
81 59.636 63.339 69.109
82 60.964 64.778 70.671
83 62.842 66.752 72.771
84 64.110 68.128 74.213
85 66.203 70.319 76.682
86 67.407 71.598 78.033
87 69.607 73.955 80.548
88 71.010 75.425 82.166
89 73.040 77.564 84.580
90 75.259 79.938 86.998
91 76.677 81.375 88.767
92 78.807 83.635 91.275
93 80.420 85.356 93.168
94 82.516 87.637 95.686
95 84.018 89.270 97.406
96 86.442 91.762 100.20
97 87.964 93.425 101.88
98 90.283 95.862 104.61
99 92.184 97.895 106.70
100 94.176 100.00 109.09

Input_Transfer_Function 1.0 0.0 0.45 0

Gamut_Measurements 0.691113 0.309136 0.229617 0.690836 0.151459 0.056993 0.306425 0.324561

[C] madvr, 0.45 input/output transfer function
I used a 0,45 output tranfer function instead of the grayscale measurements. This is the config:
Input_Format HD YCbCr 8

Output_Format HD RGB_PC 16

Input_Transfer_Function 1.0 0.0 0.45 0
Output_Transfer_Function 1.0 0.0 0.45 0

Gamut_Measurements 0.691113 0.309136 0.229617 0.690836 0.151459 0.056993 0.306425 0.324561

[D] madvr, 0.425 input transfer func, 0,45 output transfer func
I used a 0,425 input transfer function (gamma 2,35). I put it just to see the differences because cbw.lava's profile has a 2.2 gamma and I don't have a profile with 2.35 gamma. This is the config:
Input_Format HD YCbCr 8

Output_Format HD RGB_PC 16

Input_Transfer_Function 1.0 0.0 0.425531914893617 0
Output_Transfer_Function 1.0 0.0 0.45 0

Gamut_Measurements 0.691113 0.309136 0.229617 0.690836 0.151459 0.056993 0.306425 0.324561



Considerations:
- I can't see any significant difference between B and C, I think it means my monitor's calibration is good.
- There are a lot of differences between C and A and I don't know how to explain it :confused:

[janos666]

I can store more than one LUT and I can even calibrate locking the primaries into sRGB gamut instead of the native one
So, you have a display like mine (12 bit internal gamut emulation ; and maybe yours have a 16 bit LUT for the "simple" gamma and WP correction) with the addition that you can fully rewrite your internal LUTs and matrices (mines are locked to the factory calibrated settings which are far from perfect - according to my ColorMunki).

(but I have to calibrate to gammma 2.2 if I want sRGB emulation)
What kind of limitation is that?
Can't you set the primaries (with their xy coordinates) and a custom gamma value manually instead of an "sRGB preset"?
(I saw a CG243w where the colornavigator software worked like this. That CG is my "I will buy it if I win 1000$ on online poker" display. :D)

If you have this freedom, I suggest you to set the primaries to sRGB/Rec709 primaries and gamma to 2.35, and watch/edit movies/videos in "dim" environment.
If you are limited to gamma 2.2, you can try to fine-tune it through the VGA LUT (if you have a 10 bit/color DisplayPort connection). In my experience, the VGA LUT calibration won't hurt the internal gamut emulation. (But my sRGB preset needs very small changes when I calibrate it to gamma 2.2 and I don't use it for movies.)
Or you can apply gamma correction with yCMS (I would do so).

I found it better to use a VGA-LUT calibrated sRGB emulation mode (factory calibrated, locked LUT and matrix) for PC Games, web browsing, etc, but to use the VGA-LUT corrected native gamut mode with a gamut emulation with yCM, because I could achieve a higher contrast ratio and better gamut coverage. -> I think it answers your question: Movies requires the highest achievable contrast ratio.

But again, I can't fine-tune the internal LUTs and matrices, otherwise, I would be very happy with them and I could forget this whole software color management story for once and all. -> The display emulation works with 12 bit, and you can output max 10 bit from a VGA (max 8 when you don't have a Quadro/FirePro). And yes, yes, dithering... it has other drawbacks and you can't use it everywhere...

[janos666]

- I can't see any significant difference between B and C, I think it means my monitor's calibration is good.
- There are a lot of differences between C and A and I don't know how to explain it :confused:[/color]

I wouldn't use Grayscale_Measurements when I can trust in my calibration (and we can).

What is your subjective opinion about the D version?

But... wait...
Why did you assigned a profile when you already had a theoretically good result?
You had a "theoretically perfect display" and you tried to correct the untouched image with a profile?
I can't see the point. It can't be good if anything is changed after you applied this profile!

You should compare C with A, but without any ICC based conversions.

[darkbasic]

What kind of limitation is that?
A stupid one, I know... :(

Can't you set the primaries (with their xy coordinates) and a custom gamma value manually instead of an "sRGB preset"?
Not from the GUI: if I select the "sRGB emulation" target I can only select the target contrast ratio.
It's possible to load a custom calibration target, but I don't know how to make one.
This is the "sRGB emulation" target, you may know how to edit it, but I don't:
http://darkbasic.homelinux.com/images/sRGB_Emulation.tgt


If you are limited to gamma 2.2, you can try to fine-tune it through the VGA LUT (if you have a 10 bit/color DisplayPort connection).

I already tried to fine tune the hardware calibration with argyll in the past (you can find a thread in the argyll mailing list), but I obtained worst results.

I wouldn't use Grayscale_Measurements when I can trust in my calibration (and we can).
Perfect, I agree.


What is your subjective opinion about the D version?
It is the best one (so "dim" environment is the best choice in MPC-HC), but I can't compare it to A because A has a 2.2 gamma ("bright" environment). Do you agree?


But... wait...
Why did you assigned a profile when you already had a theoretically good result?
You had a "theoretically perfect display" and you tried to correct the untouched image with a profile?
I can't see the point. It can't be good if anything is changed after you applied this profile!
I assigned "sRGB primaries, Gamma 2.2, D50.icc" to A because I wanted it to be the "reference" image (since I trust photoshop's color correction).
I assigned my monitor's profile to C because I didn't want any color correction. It's like not assigning a profile (no color management), but if I want *you* to look at this image or if I want to convert it to prophoto (layers have to be in the same color space) I _have_ to assign it a profile (my monitor's one).

You should compare C with A, but without any ICC based conversions.
It's what I did, assigning my monitor's profile to C is like not assigning an ICC profile. In fact the results I obtained with MPC-HC's color correction are EXCATLY the same I obtained disabling MPC-HC's color correction and assigning "sRGB primaries, Gamma 2.2, D50.icc".

[janos666]

It is the best one (so "dim" environment is the best choice in MPC-HC), but I can't compare it to A because A has a 2.2 gamma ("bright" environment). Do you agree?

There is no standard, so you should choose the one which looks the best for you. If your subjective opinion is that D is the best, then you should choose this. (I recommended it for you because this was my winner.)
The common opinion is that you should watch Rec709 contents on a display with Rec709(/sRGB) primaries and a pure power TRC where you can set the exponent according to your view conditions. The "recommanded" view condition is a "dim D65 environment", and you should set an exponent about 2.35 for this view condition.

You should forget about MPC-HC's lcms implementation. It works with EVR but madVR is MUCH better in many things.

It's what I did, assigning my monitor's profile to C is like not assigning an ICC profile. In fact the results I obtained with MPC-HC's color correction are EXCATLY the same I obtained disabling MPC-HC's color correction and assigning "sRGB primaries, Gamma 2.2, D50.icc".

Ok, it was my misunderstanding. I thought you always used the downloaded ICC file (you didn't mentioned that you assigned your display profile in the second case. Or I missed that part...)

[darkbasic]

You should forget about MPC-HC's lcms implementation. It works with EVR but madVR is MUCH better in many things.

Unfortunately it is the only viable option for high bitrate full HD sources: my poor old Athlon64 3800+X2@2,7GHz just can't decode them with madVR and so I have to use EVR + libavcodec MT or XVDA. I use madVR only for SD and 720p movies. Anyway I still didn't test madVR with CoreAVC, maybe... :)

Ok, it was my misunderstanding. I thought you always used the downloaded ICC file (you didn't mentioned that you assigned your display profile in the second case. Or I missed that part...)
So the question remains: why isn't C similar to A? :confused:

[janos666]

This is the "sRGB emulation" target, you may know how to edit it, but I don't:
http://darkbasic.homelinux.com/images/sRGB_Emulation.tgt

Unfortunately, I can't.
I would write an email to the manufacturer and ask for an editor or a file with my custom targets. And ask them to use a simple text file with xy coordinates and a gamma value (or something like that) in the next software version (if they don't want to make a GUI for this).

[janos666]

Unfortunately it is the only viable option for high bitrate full HD sources: my poor old Athlon64 3800+X2@2,7GHz just can't decode them with madVR and so I have to use EVR + libavcodec MT or XVDA. I use madVR only for SD and 720p movies. Anyway I still didn't test madVR with CoreAVC, maybe... :)

I thought we talk about your desktop PC. Do you use your NEC display with this notebook?
If not, use FFDshow+madVR on your desktop PC and DXVA+EVR on your notebook (that's what I am doing -> but it's far from perfect until they fix the absolute colorimetric rendering intent...).

You should try to set the resizers to bilinear in madvr (if you didn't try it already). It can save a lot of GPU power.


So the question remains: why isn't C similar to A? :confused:

I don't know.
Is that profile correct? His description says:
sRGB primaries, Gamma 2.2, D50
But Rec709 defines a D65 WP. (But the ICC file should contain primaries relatively to D50, so it can mean anything here. It's only a guess.)


I would see that PS file but I can't download it.

[darkbasic]

I thought we talk about your desktop PC. Do you use your NEC display with this notebook?

It isn't my notebook, it's my desktop pc :)

You should try to set the resizers to bilinear in madvr (if you didn't try it already). It can save a lot of GPU power.
GPU is quite powerful, it's an Ati Radeon HD3870.


I would see that PS file but I can't download it.
Try again, probably my adsl was down when you tried.