yCMS - Color Management System

[yesgrey]

sounds like this curve may work on gamma encoded data rather than linear off the sensor? Or not necessarily?
It's hard to believe that consumer level equipment would use linear on any step... the bit depths used are too low for that and it would result in high quantization errors.

do you think it possible to distribute the chroma / luma across full range in the h264?
It would be possible but not with a transfer function. A transfer function always keeps the same highest and lowest values (1.0 and 0.0). For what you want you would need to perform a range conversion, but I don't think it would be worth it...

[Yellow_]

It's hard to believe that consumer level equipment would use linear on any step... the bit depths used are too low for that and it would result in high quantization errors.

Ok, so HSL adjustments on gamma encoded source then encoding.
With regard to quantization errors, I've read a little about it following your last mention but where you commented that luma and chroma ranges should be in same range.

I assume this is at input into the encoder as many vidcams provide full luma in the encoded output and assume it is technically ok to use the full luma when converting to RGB even at 8 bit? Just a brighter more desaturated image? Or am I setting myself up for artifacts and anomolies. For example very common for NLEs to squeeze the full luma to 16 - 235 for conversion to RGB for a reason?

It would be possible but not with a transfer function. A transfer function always keeps the same highest and lowest values (1.0 and 0.0). For what you want you would need to perform a range conversion, but I don't think it would be worth it...

Would this be done by a HSL curve in camera, would a 1 - 254 LOG output be a posibility then?

[fairchild]

I got around to measure my display after applying 2.22 gamma boost with yCMS and this is what it looks like now (it was sitting at 1.76 average gamma without yCMS)

http://img228.imageshack.us/img228/7687/222gammaboost.jpg (http://imageshack.us/photo/my-images/228/222gammaboost.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

And this is the CIE chart

http://img828.imageshack.us/img828/764/cieycms.jpg (http://imageshack.us/photo/my-images/828/cieycms.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

And finally my RGB, the dE's got a bit worse, but I think ultimately the increased gamma and color's should make the picture look better overall. (my de's went from 0.3 to 2.7 from 30-100 IRE and now with yCMS they are 0.6 to 4.1)

http://img17.imageshack.us/img17/1153/rgbycms.jpg (http://imageshack.us/photo/my-images/17/rgbycms.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

[yesgrey]

I assume this is at input into the encoder as many vidcams provide full luma in the encoded output and assume it is technically ok to use the full luma when converting to RGB even at 8 bit?
Yes, it would be OK, but only if it is really full luma.

For example very common for NLEs to squeeze the full luma to 16 - 235 for conversion to RGB for a reason?
I guess the reason is simply to follow the most used standard.

Would this be done by a HSL curve in camera, would a 1 - 254 LOG output be a posibility then?
Yes.

[yesgrey]

I got around to measure my display after applying 2.22 gamma boost with yCMS and this is what it looks like now
If you could send me your hcfr result files for me to take a look I would appreciate that. My e-mail is in the manual, at the bottom.

the dE's got a bit worse
That's how it's supposed to be. The current yCMS version does not allow white point correction. It only allows chromatic adaptation to display's white point. Even though the perception of the colors would be right, the measurements would always be off.

I'm currently developing the white point correction so that it could measure well too, but I cannot give an ETA for it.

[Yellow_]

Yes, it would be OK, but only if it is really full luma.


I guess the reason is simply to follow the most used standard.


Yes.

Ok, thanks I'll try and find information on how to do a 'range conversion' with HSL curves and a suitable editor to make that as easy possible.

I guess it's not as simple as a basic calculation to generate the curves to go from HD camera source ie: BT709 primaries, BT601 matrix, full luma, to 1 - 254 LOG as a 'proof of concept' and test camera h264 encoding.

Then tweak the curves in an editor after for certain ranges like skin tone, high / low contrast scenes etc.

Thank for your time again. :-)

[fairchild]

If you could send me your hcfr result files for me to take a look I would appreciate that. My e-mail is in the manual, at the bottom.


That's how it's supposed to be. The current yCMS version does not allow white point correction. It only allows chromatic adaptation to display's white point. Even though the perception of the colors would be right, the measurements would always be off.

I'm currently developing the white point correction so that it could measure well too, but I cannot give an ETA for it.

Alright, sent you the hcfr files from the original calibration + 2.22 and 2.35 gamma boost.

Thanks for clarification on the increased dE's.

[yesgrey]

Alright, sent you the hcfr files from the original calibration + 2.22 and 2.35 gamma boost.
Thanks. I will take a look and then will let you know.

[yesgrey]

I'm using the 2.22 gamma boost as the 2.35 is a tad too dark to my eyes and in dark scenes I'm getting a bit too much black crush. (2.22 gamma boost also has a tiny bit of black crush but I think this is expected when you are going from a 1.76 gamma to 2.22ish)
The black crush could also be related with you being using a pure power curve. Try Using Gamma_Curve 1.0 2.22 instead, it will decrease the black crush.
If you feel it's too much then try other values for curveType, maybe 0.5, or any other value between 0.0-1.0.

P.S.: Sorry for quoting part of your e-mail here, but I felt that your question and my answer would be helpful for other people.

[fairchild]

Roger that. I tried a smaller curveType, currently using a 0.5 with a 2.22 gamma boost and indeed you get a bit more shadow detail. I'll have to do a measurement with the different curveType to see if I'm still getting the benefit of improved gamma over my crappy 1.76

Changing the curveType should still give a decent gamma boost I'm assuming? My main reason for using yCMS at the moment is to improve my gamma as my set's gamma is poor and has no adjustment in the user menu or service menu.

[yesgrey]

I'll have to do a measurement with the different curveType to see if I'm still getting the benefit of improved gamma over my crappy 1.76
You will. However, you should be aware that HCFR gamma graphs are accurate only for power curves or BT.709 curves, so with a curve in-between the results might look less good that you would expect, but that doesn't mean that yCMS is not working correctly.

Changing the curveType should still give a decent gamma boost I'm assuming?
You can change two parameters of a gamma curve: the curveType, and the gammaValue.

Changing the curveType affects the shadow detail amount. 0.0 will give you the least, and 1.0 the most. Select the value that gives you the most natural look.

Changing the gammaValue affects the image "punch". A lower value gives a flatter image, and a higher one a punchier one. Select the value that gives you the most pleasant image. There is no "gold standard" for the gammaValue. Some claim a value of 2.35 (the one I use), but in the end it would depend on the display...

[Yellow_]

yesgrey, I wonder if you could elaborate on range conversion via HSL curve re discussion on this thread a few days ago I'm struggling to find info on how to go about this.

[yesgrey]

I wonder if you could elaborate on range conversion via HSL curve re discussion on this thread a few days ago I'm struggling to find info on how to go about this.
I'm not working with HSL color space, and probably never will, so I cannot help you with that. When I referred the range conversion I was thinking in doing it in YCbCr or RGB, not in HSL.

I found this (http://lodev.org/cgtutor/color.html) link on google, maybe it could help you...

[janos666]

Yah, the gamma value is a strange question. I always preferred 2.35 on every LCDs (doesn't matter if it was a 800:1 WCG-CCFL H-IPS, 900:1 <sRGB WLED-LCD or 2500:1 ~sRGB CCFL c-PVA) but I am happy with the default gamma 2.20 response of my current PDP (~3800:1 at 50 or 60Hz and ~2300:1 at 96Hz).
I don't know why but the picture on this PDP just looks better for me even if it's less colorimetrically accurate. I don't even use any color corrections, I only set the correct contrast/brightness and white point but that's all. (I don't feel the "itch" to correct anything, even if I know it's not that accurate if I ask my spectrophotometer to tell me the truth...)

[Thunderbolt8]

how can I now make my custom input file for japanese HD movies with messed up black levels with the new madVR version of 0.62 and above?

# Example input file for yCMS v1.0 and up
#
# Settings for creating a 3DLUT file for watching the following Video formats:
# Blu-ray, HD DVD, ATSC HD Broadcast, DVB HD Broadcast
# without any Display correction
# Includes YCbCr->RGB conversion using PC Levels (Black: 0 and White: 255)

# Set input format
Input_Format HD YCbCr 8
Input_Range 32 235

# Set output format
Output_Format HD RGB_PC 16

Output_Transfer_Function 4.5 0.099 0.405 0.018

[madshi]

Try this one:

Input_Format yRGB RGB_Video 8
Input_Range 32 235
Output_Format HD RGB_Video 16
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Not sure about the "Output_Transfer_Function", though, cause I don't know why yours is the way it is.

[Carpo]

Okay, i am totaly lost with yCMS, can someone explain how i would go about finding the primary/gamut measurements for an LG Electronics RZ-37LZ55, its connected to PC via DVI to HDMI connection, I play all types of files, HD, SD, DVD, NTSC, PAL

I will admit i am about as n00b as n00b can get on this :confused: Finally decided i should tweak the hell out of the HTPC, and after reading all i have and getting the migraine i got i wish i never started :mad:

Any help would be greatly appricated

[madshi]

@Carpo, ideally you need to have a meter, so you can measure your display. If you don't have a meter you can try googling if somebody else has ever posted measurements for your display. But even if you do find measurements from somebody else, it's questionable if you should use them because you don't know if the other guy's display is really 100% identical, has the same factory settings etc. IMHO, if you don't have your own meter (and don't plan to get one - it costs money) then simply use madVR as it is, without yCMS. The main purpose of yCMS is to correct any faults your display may have, but you do need a meter, ideally a good one, to achieve that aim.

On the other hand: If you can find a good review of your display with gamut & gamma measurements, maybe that review will give you advice how to configure the LG to achieve good Blu-Ray playback quality. If you can do that, that would benefit madVR playback, too.

[Thunderbolt8]

Try this one:

Input_Format yRGB RGB_Video 8
Input_Range 32 235
Output_Format HD RGB_Video 16
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Not sure about the "Output_Transfer_Function", though, cause I don't know why yours is the way it is.afaik the output transfer thing is for gamma correction and also should be used, because now after the colour change the gamma is too dark. 0.405 is the value for gamma here, default was afaik 0.45 according to yesgrey.

[janos666]

Output_Transfer_Function could be used to describe the actual TRC of your display, not the desired one.
You can assume that your display already has a power-like TRC and guess the exponent (more likely 2.2) but unless you previously calibrated your display to that TRC (through your VGA LUT or an internal hardware LUT, etc) you should use the Grayscale_Measurements instead.

[madshi]

I don't think he has a meter. He's using the 3dlut only to "fix" crappy encodes, as fasr as I understand.

@Thunderbolt8, try using your special Output_Transfer_Function and use the other 3 lines from my suggestion. Does that give you the same image with v0.62 than you got with older versions?

[Carpo]

I don't think he has a meter. He's using the 3dlut only to "fix" crappy encodes, as fasr as I understand.


wouldn't say 1080p encodes using -crf19 were crappy madshi ;)

[Thunderbolt8]

I don't think he has a meter. He's using the 3dlut only to "fix" crappy encodes, as fasr as I understand.

@Thunderbolt8, try using your special Output_Transfer_Function and use the other 3 lines from my suggestion. Does that give you the same image with v0.62 than you got with older versions?
need to check on that with a sample. but wont have time to do so before next weekend :S

but it would only be a rough estimation anyway, because I cannot lay comparison pics from an older madvr version and of the current one next to each other. a screenshot function in madvr would be very handy now (if it was included in a pre 0.62 version just for purposes of comparison as well) :D

[janos666]

I think PrintScreen always works with windowed mode and D3DFS shouldn't change anything with the current versions (may be later with 10-bit output).

---

I still don't understand why do you need to change the output transfer function, it always has to match with the display TRC. If the source is encoded with an unusual TRC then you should change the input transfer function parameter which describes the TRC of the source. (And if you don't know the actual TRC of the display then you should assume a pure-power TRC with gamma 2.2)

[Thunderbolt8]

dont ask me technically about it...all I know is that this line includes changes to gamma which are also adviceable to apply after correction the black levels (and it looks indeed better or "more correct" with these gamma changes)

the printscreen thing is a good idea though, Ill try that at the weekend (I assume there are no flaws when comparing the PQ of screenshots from two different madvr versions that way?)

[janos666]

Just save them in a lossless format, preferably in 8-bit/channel (usually labeled as 24-bit without and 32-bit with the Alpha channel which is irrelevant now) RGB bitmap or PNG (if you plan to upload it to web).

[lych_necross]

Okay, reading this thread has makes me want to get a meter and try yCMS for myself. Can someone recommend a good meter that doesn't cost too much?

[janos666]

Okay, reading this thread has makes me want to get a meter and try yCMS for myself. Can someone recommend a good meter that doesn't cost too much?

Spyder Pro (http://www.datacolor.eu/en/products/monitor-calibration/spyder3pro/index.html) -> They say the new (2010 and later) models can work on WCG displays and they are fairly accurate on low IREs too. (So they are equally good or may be slightly better than i1LT or i1d2. They say that there are some freshly re-certificated/calibrated i1d2s with WCG compatible matrices but they are hard to find, may be from second hand...)

[cyberlolo]

Hi yesgrey.

Until now, I've been using this command for color correction:

Gamut_Measurements 0.6350 0.3321 0.2890 0.6007 0.1528 0.0647 0.3127 0.3294

just as it was intended to be:

Gamut_Measurements redx redy greenx greeny bluex bluey whitex whitey

But now, with the new builds (and the new madvr version), this is not possible, and the procedure seems to be as in this example:

Gamut_Measurements 1
21.26 0.676 0.321
71.52 0.308 0.685
7.22 0.144 0.045
100.00 0.3127 0.3290

You told me that the first column (bold) was the Luminance, but when the calibrator did his job on my TV, he gave me the xy coordinates and they were 2 numbers for each component, not 3!! So I don't have that info. Is there any way to generate 3Dluts without luminance? How can I solve this?

Thanks in advance.

[yesgrey]

Gamut_Measurements 1
21.26 0.676 0.321
71.52 0.308 0.685
7.22 0.144 0.045
100.00 0.3127 0.3290

You told me that the first column (bold) was the Luminance, but when the calibrator did his job on my TV, he gave me the xy coordinates and they were 2 numbers for each component, not 3!! So I don't have that info. Is there any way to generate 3Dluts without luminance? How can I solve this?
You can always continue to use the previous method by creating the 3DLUT yourself. However, if you want to use the new madVR GUI, just use the Luminance values that are in bold, followed by your x,y coordinates. Like this:
Gamut_Measurements 1
21.26 redx redy
71.52 greenx greeny
7.22 bluex bluey
100.00 whitex whitey

yCMS is not yet using the luminance values, so the values on the first column are not important.;)

[cyberlolo]

You can always continue to use the previous method by creating the 3DLUT yourself.

I don't know how to do it with the new version, so I think you mean using an old yCMS version, don't you?

However, if you want to use the new madVR GUI, just use the Luminance values that are in bold, followed by your x,y coordinates. Like this:
Gamut_Measurements 1
21.26 redx redy
71.52 greenx greeny
7.22 bluex bluey
100.00 whitex whitey

yCMS is not yet using the luminance values, so the values on the first column are not important.;)

So can I enter any value (because they're ignored) or do I have to use those exact values?

[yesgrey]

I don't know how to do it with the new version, so I think you mean using an old yCMS version, don't you?
No. The new version works pretty much the same. I think you should be asking about how to create a 3DLUT file compatible with the new madVR. For that, you can still use your old configuration file but using yRGB as the input color space in video levels, like:
Input_Format yRGB RGB_Video 8

For output, you can use whatever RGB color space you want as long as you use video levels, like:
Output_Format whatever RGB_Video 16

So can I enter any value (because they're ignored)
Yes.

[Thunderbolt8]

so can how would I have to change my input file?

Input_Format HD YCbCr 8
Input_Range 32 235

Output_Format HD RGB_PC 16

Output_Transfer_Function 4.5 0.099 0.405 0.018

to something like this?

Input_Format HD yRGB RGB_PC 8
Input_Range 32 235

Output_Format HD RGB_PC 16

Output_Transfer_Function 4.5 0.099 0.405 0.018

and how do I have to name the 3dlut file, afaik theres now only 1 file for all 4 former PC/Video/HD/SD 3dlut files?

[tschi]

Hi Yesgrey,
I have some big issue using madVR (test 0.62 and 0.64) : the gamut correction is very bad, the red is almost pink and blue & green are quite bad
here madVR config :
http://imageshack.us/photo/my-images/24/sansregt.png/
w/o ycms in madVR :
http://imageshack.us/photo/my-images/577/capturedcran20110607233.png/
using ycms in madVR :
http://imageshack.us/photo/my-images/84/capturedcran20110607233.png/

my chc files:
http://www.mediafire.com/?315317y1t7f9127

I calibrated and recalibrated several times, check everything, deleted everything, test with grayscale and not, but I can not find where I mistake :(

Thank you very much for your help

[yesgrey]

so can how would I have to change my input file?
Like this:

Input_Format yRGB RGB_Video 8
Input_Range 32 235
Output_Format HD RGB_Video 16
Output_Transfer_Function 4.5 0.099 0.405 0.018

and how do I have to name the 3dlut file, afaik theres now only 1 file for all 4 former PC/Video/HD/SD 3dlut files?
You can use any name, and you can put it in any dir you want. You just need to select external 3DLUT in madVR settings and point it to the file.

The 4 former options can now be executed within madVR's GUI. There is no more need for 4 3DLUTs.;)

[yesgrey]

Hi Yesgrey,
I have some big issue using madVR (test 0.62 and 0.64) : the gamut correction is very bad, the red is almost pink and blue & green are quite bad
Was the calibration working OK with previous madVR versions?

[tschi]

I use ycms v1.8 before:o and all madVR version since 0.12 it was ok
I was happy with that :)
Ok, I think you means to test last ycms with madvr < 0.62 ;) ..
I will check that

[yesgrey]

OK. First I will measure the new madVR with my own display just to be sure that everything is fine on madVR's side. Until then, I would suggest you to keep using the old one...

[madshi]

@tschi, can you try the latest yCMS version with madVR v0.61? Do you get proper results that way?

[fairchild]

I also was experiencing weird color issues as well with the latest MadVR + the yCMS feature in the new version. I tried entering in Yxy as well as XYZ, tried entering just the gamuts and gamuts+greyscale, but still am seeing a red tinge in my test patterns as well as some weirdness in my color clipping pattern with blue.

I haven't been able to measure with my meter but I guess I could try when I get some time. These are the measurements I entered into the new yCMS integrated into madVR. I can provide an HCFR chc file if requested:

Gamut_Measurements 1
10.081485 0.660916 0.332686
29.748291 0.296783 0.609976
3.789106 0.149306 0.065182
48.580326 0.311850 0.326137

Grayscale_Measurements
30 1 8.235306 0.312919 0.327159
40 1 14.348957 0.311858 0.326344
50 1 22.056358 0.311059 0.327702
60 1 32.212700 0.310529 0.325851
70 1 43.527546 0.311982 0.327575
80 1 55.227596 0.311502 0.325526
90 1 70.423340 0.311393 0.328095
100 1 83.712715 0.312210 0.326144

[tschi]

@tschi, can you try the latest yCMS version with madVR v0.61? Do you get proper results that way?
I try with madVR 0.60 (I didn't see your post) and generated 3dlut with last ycms (with txt file), the result is OK. I didn't take mesures but red is red, not like with the new madVR (red is pink)

[fairchild]

I just tested as was suggest to tschi, I installed madVR 0.61 and created an HD 3dlut file, no glitching on blue with my test pattern. Basically blue gets clipped at 235 and has some flickering of the blue bars below 235, and red gets clipped at 241 with the newer MadVR and it's GUI generated yCMS 3dlut. Where as when I'm using the older version 0.61 with the generated ycms 3dlut using the command line and the below script, I get no clipping on any color.

# Example input file for yCMS v1.0 and up
#
# Settings for creating a 3DLUT file for watching the following Video formats:
# Blu-ray, HD DVD, ATSC HD Broadcast, DVB HD Broadcast
# without any Display correction
# Includes YCbCr->RGB conversion using Video Levels (Black: 16 and White: 235)

# Set input format
Input_Format HD YCbCr 8

# Set output format
Output_Format HD RGB_Video 16

# Gamut correction
Gamut_Measurements 1
10.081485 0.660916 0.332686
29.748291 0.296783 0.609976
3.789106 0.149306 0.065182
48.580326 0.311850 0.326137

# Grayscale correction
Grayscale_Measurements
30 1 8.235306 0.312919 0.327159
40 1 14.348957 0.311858 0.326344
50 1 22.056358 0.311059 0.327702
60 1 32.212700 0.310529 0.325851
70 1 43.527546 0.311982 0.327575
80 1 55.227596 0.311502 0.325526
90 1 70.423340 0.311393 0.328095
100 1 83.712715 0.312210 0.326144

# Gamma correction Gamma_Curve 0.0 2.22 (has the most black crush 1.0 curve has almost no black crush)
Gamma_Curve 0.0 2.22

[cyberlolo]

No. The new version works pretty much the same. I think you should be asking about how to create a 3DLUT file compatible with the new madVR. For that, you can still use your old configuration file but using yRGB as the input color space in video levels, like:
Input_Format yRGB RGB_Video 8

For output, you can use whatever RGB color space you want as long as you use video levels, like:
Output_Format whatever RGB_Video 16


Yes.

Ok. :thanks:

[madshi]

Here's a madVR v0.65 test build with higher internal precision:

http://madshi.net/madVRprecision.rar

Does that improve anything?

[fairchild]

Here's a madVR v0.65 test build with higher internal precision:

http://madshi.net/madVRprecision.rar

Does that improve anything?

I downloaded and installed that build but the same issue. Here is a screenshot so you can get an idea of the glitch (not optimal but at least you can see I entered things correct and can kind of see the glitch).

http://img405.imageshack.us/img405/1704/madvrycmsbug.th.jpg (http://imageshack.us/photo/my-images/405/madvrycmsbug.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

[madshi]

Is this one better?

http://madshi.net/madVRprecision2.rar

[fairchild]

Is this one better?

http://madshi.net/madVRprecision2.rar

That one fixed the glitching on the blue level! :)

But it broke something with the video levels/black levels. It's now clipping white levels/colors and the black levels are borked.

http://img819.imageshack.us/img819/8238/madvrycmsblacklevels.th.jpg (http://imageshack.us/photo/my-images/819/madvrycmsblacklevels.jpg/)

Uploaded with ImageShack.us (http://imageshack.us)

I'd love to keep helping you try to figure this out, but I have to go now, I'll be back later on. But maybe some others can get to the bottom of this. :thanks:

[Mark_A_W]

Yesgrey

I've had a go, based on this workflow:

1. Set PC gamma back to "flat".

2. Calibrate projector as best as I can with the internal controls, using colorimeter (I use HCFR software as the source and HCFR sensor).

3. The final calibration result is the input to yCMS/madVR. Generated by measuring the primary colours, and greyscale.

4. Input the values into madVR. Make sure the formats match.

5. Set my desired gamma in madVR (if it's not 2.2). 2.0 looks much better on my CRT.

I didn't bother Calibrating the projector with it's internal controls, it's a bit out, I changed some boards without re-calibrating. However it looks ok, perhaps a touch too much red down low, but not bad.

But the results are awful. The colours are wrong. White below 235 is completely purple and black below 16 is green.


I did get confused by the formats. You want Yxy. HCFR has xyY. Are they the same?

These are my results, I think I have transcribed them properly:

red, Yxy, 5.112, 0.628, 0.337
green, Yxy, 9.018, 0.294, 0.595
blue, Yxy, 1.672, 0.156, 0.078
white, Yxy, 10.833, 0.321, 0.342

20, Yxy, 0.301, 0.338, 0.349
30, Yxy, 0.179, 0.316, 0.333
40, Yxy, 2.705, 0.311, 0.335
50, Yxy, 5.037, 0.311, 0.340
60, Yxy, 7.476, 0.315, 0.340
70, Yxy, 10.364, 0.320, 0.341
80, Yxy, 10.603, 0.320, 0.341
90, Yxy, 10.749, 0.321, 0.342
100, Yxy, 10.850, 0.321, 0.342

Here is the result

http://dl.dropbox.com/u/1372034/purple.jpg

http://dl.dropbox.com/u/1372034/purple3.jpg
RGB levels before correction

http://dl.dropbox.com/u/1372034/purple2.jpg
Final Result

I think I'm doing something wrong....:eek:

Cheers

Mark

[madshi]

@Mark, the official madVR version has a bug resulting in quite serious problems. This one is an improvement:

http://madshi.net/madVRprecision2.rar

It does not handle BTB and WTW correct yet, but the rest should be fine. A fully fixed version should be available soon. Not sure if this is the cause of your problem, though. Maybe there's another problem added on top of the madVR bugs. I'll let yesgrey comment on that.

[madshi]

Here's comes the next try. I think this one should work pretty well:

http://madshi.net/madVRprecision3.rar