madVR - high quality video renderer (GPU assisted)

[tetsuo55]

madvr does not leave FSE mode in this case, even the task manager stays behind the video window thus leaving rebooting as the only option.

i guess its reclock that crashes then.

[madshi]

Ouch. Yeah, it could be Reclock. Although the crash is in the DSound system dll. It could still be Reclock's fault. At least it's something audio related which madVR has nothing to do with. The only reason why madVR caught this crash is because madVR hooks into the graph "Run" action (that's needed for the "delay playback start until queue is full" feature). As a result madVR catches and reports all crashes which occur during handling of the "Run" action.

[nlnl]

I'm still not really sure about what the problem is exactly. So a few more questions:

Generally your report and your answers to my questions are *very* low on details.



madshi
I will be able to do intensive testing only during weekend :(.

And sorry, I promise to be very very detailed and verbose!

[TheElix]

I can't reproduce this problem on my PC. And to be honest, it makes zero sense, technically. The gamma processing has *nothing* to do whatsoever with whether you're using windowed, overlay or exclusive mode. Are you 100% sure you didn't make an error when testing this?My fault. I had a Disable GPU gamma ramp option enabled and I had a custom GPU ramp. Unticking this option and restarting the player fixed my problem.

[THEAST]

The latest madVR build supports a new subtitle interface which has several benefits, one of them is that it should allow to render subtitles correctly in final movie output resolution while still allowing madVR to do the video scaling. Unfortunately there's no subtitle renderer available yet which makes use of the new interface. xy-vsfilter is supposed to support this interface sooner or later, but the xy-vsfilter developer is taking a break, so it could take some time (maybe a loooong time) for this to happen.
Hmm, that sounds nice!

What is this "advanced typesetting" that the MPC-HC renderer cannot handle properly? A year or so ago it couldn't handle alpha-blending but that has been resolved for awhile.

If you haven't tried the renderer on the current-release MPC-HC I suggest you give it a shot. I personally would very much like the know the filename/see the subtitle script of a file that does not render its subs correctly.

Strange, I just tested a specific sign I had previously used many times to see if MPC-HC's subtitle renderer has been fixed or not, with the latest build of MPC-HC and it seems it is now being drawn correctly, although I think it is still slightly misaligned but it is still far much better than before that MPC-HC drew the whole sign as a single dot in full screen mode. Unfortunately the image host I uploaded the screenshots from the time the sign was still being drawn incorrectly, is down atm or else I could show you the screens but that doesn't matter anymore because the issue seems to have been fixed and I don't need to use Directvobsub anymore. Funny thing is, now directvobsub is drawing that sign completely misaligned. :confused:

P.S. I'm talking about Elfen Lied by AKH-Anisubs, EP09, around 11:21 (including OP/ED), the translation on the zoo map billboard.

[clsid]

Subtitle positioning will work better in MPC-HC if you change this option:
Subtitles > Default Style > Position subtitles relative to the video frame

[THX-UltraII]

Am I correct that if I want to get the least change for dropped frames I can:

1. raise the CPU queue size from 12 to 32 (max)
2. raise the GPU queue size from 8 to 24 (max)
3. change 'how many frames shall be presented in advanvce' from 4 to 16

Is this correct?

[mark0077]

madshi, I have an issue highlighting some DVD menus. My issue is the highlightable / selectable area with the mouse seems to be off in the vertical axis by perhaps 100px, hard to know exactly by how much.

Basically I need to move the mouse significantly higher than the actual menu position, to get it to highlight. It only happens with both madVR and LAV Video decoder as far as I can tell. Is there some combination of the two thats causing it? I saw you mentioned some aspect ratio changes were needed to get DVD's to work correctly, not sure if its related.

I can only reproduce on some DVD's which is weird, some are perfectly fine. Is there any information I could give, if you wanted to check it out at any point. Heres the pin IN info into madVR, thats definitely badly off when highlighting.

Filter : madVR - CLSID : {E1A8B82A-32CE-4B0D-BE0D-AA68C772E423}

- Connected to:

CLSID: {0B390488-D80F-4A68-8408-48DC199F0E97}
Filter: ffdshow raw video filter
Pin: Out

- Connection media type:

Video: YV12 1024x576 (4:3) 25fps

AM_MEDIA_TYPE:
majortype: MEDIATYPE_Video {73646976-0000-0010-8000-00AA00389B71}
subtype: MEDIASUBTYPE_YV12 {32315659-0000-0010-8000-00AA00389B71}
formattype: FORMAT_VideoInfo2 {F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA}
bFixedSizeSamples: 1
bTemporalCompression: 0
lSampleSize: 884736
cbFormat: 112

VIDEOINFOHEADER:
rcSource: (0,0)-(720,576)
rcTarget: (0,0)-(720,576)
dwBitRate: 0
dwBitErrorRate: 0
AvgTimePerFrame: 400000

VIDEOINFOHEADER2:
dwInterlaceFlags: 0x00000000
dwCopyProtectFlags: 0x00000000
dwPictAspectRatioX: 4
dwPictAspectRatioY: 3
dwControlFlags: 0x00000000
dwReserved2: 0x00000000

BITMAPINFOHEADER:
biSize: 40
biWidth: 1024
biHeight: 576
biPlanes: 1
biBitCount: 12
biCompression: YV12
biSizeImage: 884736
biXPelsPerMeter: 0
biYPelsPerMeter: 0
biClrUsed: 0
biClrImportant: 0

pbFormat:
0000: 00 00 00 00 00 00 00 00 d0 02 00 00 40 02 00 00 ........Ð...@...
0010: 00 00 00 00 00 00 00 00 d0 02 00 00 40 02 00 00 ........Ð...@...
0020: 00 00 00 00 00 00 00 00 80 1a 06 00 00 00 00 00 ........€.......
0030: 00 00 00 00 00 00 00 00 04 00 00 00 03 00 00 00 ................
0040: 00 00 00 00 00 00 00 00 28 00 00 00 00 04 00 00 ........(.......
0050: 40 02 00 00 01 00 0c 00 59 56 31 32 00 80 0d 00 @.......YV12.€..
0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

[turbojet]

Thanks for fixing dvd playback, the few encrypted dvd's I've tried so far have played without issue.

Has anyone else messed around with spline100 and spline144 resizers from splineresize.dll (http://www.wilbertdijkhof.com/)?

Cyberbeing suggested them back in August. (http://forum.doom9.org/showthread.php?p=1586987&highlight=spline144#post1586987) I've been using them lately through ffdshow and it looks promising, very sharp with minimal artifacts, cpu load is between lanczos4 and lanczos8, here's a parking meter comparison to some other madvr resizers. (http://megaload.it/g7colcw3obbt) It was made with windowed fullscreen print screen with bicubic75 chroma. Is this interesting enough to consider for a future release?

I notice quite a difference between lanczos3 in madvr and ffdshow, specifically more artifacts in the latter. Could this be caused by chroma being upsampled twice? MadVR is definitely upsizing chroma, load changes when resizer change but what's ffdshow doing with it?

Also what are the avisynth equivalent to madvr's spline resizing? Is it splineresize(taps=3-4) or spline36/64?

[leeperry]

The "disable GPU gamma ramps" feature currently seems to only affect exclusive mode. Maybe that's what you're seeing?
I just double-checked and just as I thought, it was really the resizing that made the picture slightly lighter in FSE as compared to a previous tiny windowed downscale....I guess a huge downscale might slightly oversaturate the red or something, but if I resize the window to almost FS-size and then switch between windowed/FSE, colors are identical.

I should have my 660 tomorrow, so I'll get back to you on that CLUT stuff later this week...and also on whether the new rendering path works as reliably as the old one with the latest nvidia drivers on XP.

[khanmein]

newbie here, how come my composition rate from 60hz change to 30hz after updated madvr 0.84.7? thanks..

[nx6]

Strange, I just tested a specific sign I had previously used many times to see if MPC-HC's subtitle renderer has been fixed or not, with the latest build of MPC-HC and it seems it is now being drawn correctly, although I think it is still slightly misaligned but it is still far much better than before that MPC-HC drew the whole sign as a single dot in full screen mode.

This is odd. If you had paid more attention to the subtitle dialog text you would have noticed it was slightly "scrunched" horizontally in the MPC-HC version compared to the VobSub version.

Anyway, here's your sign:
http://screenshotcomparison.com/comparison/156523

I believe the issue here stems from your DVD encoding. This is an anamorphic encoding. Source resolution is 704x480. But this is a 16:9 feature. So the picture is rendered as 853x480 on playback.

I think MPC-HC is rendering the subs using the source aspect ratio in some weird way, perhaps assuming that will be the final aspect ratio and not adjusting. If they were rendered before the adjustment for PAR, we would see dialog text elongated (kinda like what you see on VOBSub on it's default settings, I have mine set for "accurate size" to correct for widescreen video). The sign you're referring to is a vector sub on an angle, so the length of one axis is changing between the SAR and PAR. Because of this, the line is not angled correctly to align with the sign text when MPC-HC's subtitle renderer does it.

This is only an issue you're going to see on anamorphic encodings I believe. I have an encoding of Elfen Lied here, an upconvert in this case, and the sign text renders at the correct angle regardless of whichever subtitle filter is used. But the SAR and PAR are the same in my files (16:9, 1280x720).

Edit:

@clsid: I have that "Position subtitles relative to video frame" checked. But saw no difference whether it was on or off or sorta-on? What are the three values? Checked and unchecked I understand. But what does it do when you have a dot in the box? O_o

[Pulstar]

Could you please tell me where the config is stored? I tried writing a batch file to replace settings.bin but it doesn't affect the options. I have a switchable graphics system so Intel HD can't handle Lanczos resizing (maybe Ivy Bridge can)

[kasper93]

People even write blog post about ISR and bug with resizing. http://afternoonnapsempire.org/subtitle-renderer-matters/ As long as video frame is not resized everything is fine. This file http://www.mediafire.com/?301dtzr51lflvj2 show the problem nicely. Anyway this was fixed long time ago in JanWillem's build, but sadly this won't be port to mpc-hc :(

BTW. This is wrong thread to discuss such things :)

[6233638]

Am I correct that if I want to get the least change for dropped frames I can:

1. raise the CPU queue size from 12 to 32 (max)
2. raise the GPU queue size from 8 to 24 (max)
3. change 'how many frames shall be presented in advanvce' from 4 to 16

Is this correct?You should only change these values if you are experiencing problems, otherwise leave them at the defaults.

I just double-checked and just as I thought, it was really the resizing that made the picture slightly lighter in FSE as compared to a previous tiny windowed downscale....I guess a huge downscale might slightly oversaturate the red or something, but if I resize the window to almost FS-size and then switch between windowed/FSE, colors are identical.Are you resizing in linear light?

[NicolasRobidoux]

The choice of colorspace has a huge impact on the result, esp. with filters with negative lobes (like Lanczos or "Jinc"), and especially when downsampling.

[Mangix]

exciting, I discovered a bug.

On nVidia hardware(GTS 450) with Windows 8, I'm having issues switching between windowed and exclusive mode.

My scenario is this. I have a 1680x1050 monitor with refresh rates of 60Hz, 72Hz, and 75Hz(the last two are custom resolutions. CVT-RB). I am using madVR's refresh rate switcher. I am also using Windowed Overlay mode.

What happens is this: The video will start playing. Then I go fullscreen using Alt+Enter(MPC-HC) and when it switches, it errors. The error is "8876086c".

My guess as to what is happening is Overlay doesn't like it when something(in this case madVR) tries to take over. I say that because I could not take a screenshot of the error(overlay). I'm guessing the simple fix is disable overlay mode and then switch. Dunno.

This does not happen with regular Windowed mode. Also if the refresh rate switcher is disabled, this issue does not happen either. I am using the latest 310.33 drivers from nVidia.

edit: I spoke too soon. Even regular windowed mode fails. The difference is, it fails well and doesn't show the error. What happens is it will go to exclusive mode but it freezes the image and then continues playing at 60Hz instead of what it's supposed to switch to. When I set switch refresh rate to when player goes fullscreen, the refresh rate doesn't switch at all.

The only solution right now seems to be to disable exclusive mode. A damn shame though since I lose that awesome seekbar.

edit2: I think I figured it out. Windows considers 72Hz as well as 75Hz as unsupported resolutions based on the monitor's EDID. The stupid thing about this is that I've already modified the EDID file through the .inf trick to tell Windows that the monitor actually supports 120Hz as a maximum resolution(not really. 75Hz is the actual max). Either I might need to re-do the .inf trick or it's a driver issue. Meaning this whole post was useless. Sorry.

edit3: redoing the .inf trick worked. The switch between windowed and exclusive mode works perfectly now, even with overlay.

[aduwind]

Hi madshi,

first of all: thank you for your fantastic job:thanks:

I discovered an issue.

If 3d vision is activated, madshi crashes.
When 3d vision is deactivated, madshi works.

Please, let me know how send the crash report, as it's too long (52955 characters), so I can't report here.

http://pastebin.com/W2AyMJnF

[pirlouy]

Zip it, upload it and post the link here.

Just to be clear, madVR can't render 3D for now.

[Mangix]

Hi madshi,
Please, let me know how send the crash report, as it's too long (52955 characters), so I can't report here.

http://pastebin.com

[leeperry]

Are you resizing in linear light?
nope, just Jinc3 AR for luma and softcubic50 AR for chroma.

and anyway, I don't mean to threadcrap but I've come to realize that cheap CCFL LCD TV's(such as my previous Hitachi) come at a price: a frigging annoying buzzing noise when their backlit is dimmed, but more importantly banding (https://www.google.com/search?q=lcd+tv+banding&tbm=isch)(the reason why I returned the Hitachi) :mad:

the latter is fairly easy to spot in the shop if you disable color all the way and stare at a black and white picture looking for the bands, I'm learnin fast ^^

Apparently, it could due to poor quality AR layers/adhesive and/or poor thermal management...meaning that it could be fine OOTB and crap out 6 months later, google is full of ppl whining about that.

Cheap LCD TV's come back with a vengeance (http://translate.google.com/translate?hl=en&sl=fr&tl=en&u=http%3A%2F%2Fwww.lesnumeriques.com%2Ftv-televiseur%2Fhaier-let46z18-p14738%2Ftest.html)(5K:1 CR) but you can't disable the frame interpolation feature on this one, huh...and it suffers from 99ms input lag(but I don't think we care too much about that for video playback).

The Edge LED Sammy's got the killer feature of providing a 1cm only black shell around the picture, so it looks like it's floating in the air! On the >6100 series they provide all the colorimetry options we crave(custom gamut, 10 points gamma/color temperature adjustment) but the user manual clearly states that these are disabled when you connect a PC via a DVI/HDMI cable, well done geniuses(but it's still junk even when it works apparently (http://www.avsforum.com/t/1428521/ue46es6300-color-calibration-questions/0_100))....but maybe it'd work with an HDMI/HDMI cable, huh :rolleyes:

So anyway, the 40ES5500 was recently tested to have a Sharp UV²A panel (http://translate.google.com/translate?sl=fr&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwww.lesnumeriques.com%2Ftv-televiseur%2Fsamsung-ue40es5500-p13193%2Ftest.html)(so poorly driven than it can't achieve 5K:1 CR, though) so I'll just get a 46ES5500 and pray that it doesn't run a CMI/AUO panel and doesn't suffer from any clouding/banding, luckily for us we can fix the colorimetry on the PC now. I'm even willing to pay an extra benji to buy it in a brick and mortar shop with a good return policy at this point :o

I've seen the 46ES5500 in the shop with HD DVB, and I can only imagine how mVR would kill on this thing! It's even got an option for xvYCC, maybe madshi would be OK to add it to his gamut rolling presets if I were to ask nicely :p

[aduwind]

Zip it, upload it and post the link here.

Just to be clear, madVR can't render 3D for now.


Issue happens when a dvd/blu ray starts.
Viewing 3D iso disc, I'm using Arcsoft TMT

http://pastebin.com/W2AyMJnF

[Blight]

Pulstar:
Did you try the registry?
HKEY_CURRENT_USER\Software\Madshi

[MSL_DK]

I have serious problems with madvr> calibration > ycms.

What could be wrong?

Setup
GFX full rgb
TV 0-255
madVR 0-255 > disable gpu gamma ramps

red, XYZ, 37.398489, 20.237959, 0.723647
green, XYZ, 26.563456, 57.456555, 4.313266
blue, XYZ, 11.150031, 3.637511, 59.522139
white, XYZ, 69.184206, 72.368390, 78.614891

20, XYZ, 4.373911, 4.628296, 5.313616
40, XYZ, 17.691000, 18.432128, 21.119084
60, XYZ, 41.823960, 43.907140, 48.948928
80, XYZ, 80.563753, 84.372412, 91.640175
100, XYZ, 138.180825, 145.422189, 154.262064

https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/madVR/Capture.JPG

https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/madVR/1.jpg

[6233638]

I have serious problems with madvr> calibration > ycms.

What could be wrong?

Setup
GFX full rgb
TV 0-255
madVR 0-255 > disable gpu gamma rampsWhat does your display gamut look like without madVR? (and xyY, or Yxy as yCMS uses for some reason, is much more readable than XYZ data)

If I had to guess, your display is undersaturated, which is not something any CMS can fix.

[MSL_DK]

What does your display gamut look like without madVR? (and xyY, or Yxy as yCMS uses for some reason, is much more readable than XYZ data)

If I had to guess, your display is undersaturated, which is not something any CMS can fix.

I'll try with xyY

It looks like this

https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/madVR/Capture1.jpg

https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/madVR/2.jpg

[cyberbeing]

@MSL_DK

Why is your measurement for "White" (Y 72.368390, x 0.3142344355322546, y 0.3286969887611062) not identical to "IRE 100" (Y 145.422189, x 0.3155785467778273, y 0.3321164356477865) when both are measurements of the same thing? Your primary and white point measurements have half the brightness of your grayscale measurements, which doesn't make sense.

If you create a 3DLUT without the grayscale measurements do things improve?

[MSL_DK]

@MSL_DK

Why is your measurement for "White" (Y 72.368390, x 0.3142344355322546, y 0.3286969887611062) not identical to "IRE 100" (Y 145.422189, x 0.3155785467778273, y 0.3321164356477865) when both are measurements of the same thing? Your primary and white point measurements have half the brightness of your grayscale measurements, which doesn't make sense.

I had taken measurements of 75 IRE. I edited it.


If you create a 3DLUT without the grayscale measurements do things improve?

No, it makes no difference.

[MSL_DK]

I do not understand why I see blue and red 219-251 Green 219-233. flashing
gray 219-233.

I have tried with this

GFX full rgb
TV 0-255
madvr 0-255

EDIT
Primaries and secondaries results delta E

4.9 10.6 3.9 8.1 10.0 9.1

Input_Primaries 0.693 0.304 0.299 0.692 0.140 0.053 0.31272661468101209 0.32902313032606195
Output_Primaries 0.635339 0.344059 0.298578 0.648101 0.149984 0.048691 0.315575 0.332529

Input_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0
Output_Transfer_Function 1.0 0.0 0.45454545454545454545454545454545 0.0

Input_Matrix_Coefficients 0
Output_Matrix_Coefficients 0

Input_Range 16 235
Output_Range 16 235

Input_Bit_Depth 8
Output_Bit_Depth 16


Gamut_Measurements 1
21.327677 0.635339 0.344059
61.166471 0.298578 0.648101
4.025139 0.149984 0.048691
148.806663 0.315575 0.332529

# Grayscale IRE Measurements
Grayscale_Measurements
20 1 5.897468 0.304441 0.322701
30 1 12.527427 0.306711 0.323847
40 1 21.866929 0.308687 0.323669
50 1 34.077722 0.309168 0.325264
60 1 48.753964 0.311103 0.325064
70 1 67.190588 0.313064 0.326819
80 1 90.109418 0.314161 0.330048
90 1 117.156346 0.315154 0.331625
100 1 148.806663 0.315575 0.332529

https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/madVR/Capture2.JPG

[6233638]

I do not understand why I see blue and red 219-251 Green 219-233. flashing
gray 219-233.Video is encoded to only use 16-235, so you probably shouldn't see anything outside that range. Color management systems also have a tendency to clip anything outside the display's gamut.

https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/madVR/Capture1.jpg
https://dl.dropbox.com/u/111324524/Images%20for%20Sharing/madVR/Capture2.JPGThis looks like what I would expect from yCMS, though green could perhaps be better. You now have secondaries completely on target, and Red/Blue hue is now correct. (yCMS seems to prioritise hue) Green saturation seems a lot better. (though it should be possible to have "perfect" green on your display as the target is well within your display's gamut)

Ultimately, until we get better controls for yCMS (e.g. setting custom points) that's probably the best result you are going to get. For example, if I'm just adjusting RGB values in Photoshop, I am able to create RGBCMY patches on my display that measure perfect BT.709 values, but I have yet to find a CMS that actually lets me set specific output values at various points to achieve that. Because my display is already very accurate without the use of yCMS (dE2000 <1.0) I actually prefer to just enter the BT.709 values into yCMS so that it's only used for colorspace transformations. (SMPTE-C content)

I do use yCMS to achieve a perfect 2.40 gamma on my display though, which requires tweaking the Y value, as the "calculated" gamma from entering the measured values from my display is not perfect. I don't use it for greyscale calibration though, I only input Y values and set xy to 0.312713, 0.329016. (D65)

Your DeltaE numbers are probably meaningless, as I think HCFR is still using dE76 for everything, and you should really be using at least dE94 if not dE2000 for color.

I would also suggest switching your charts to CIE uv rather than CIE xy charts, as they are much more perceptually uniform. Errors can look much larger than they really are on a CIE xy chart.

[dansrfe]

I wish there was a file generated by hcfr that we could just load into yCMS in madVR.

[6233638]

I wish there was a file generated by hcfr that we could just load into yCMS in madVR.Honestly, most auto-generated LUTs aren't that good in my experience.

I would much rather spend the time to tune a LUT to be optimal at specific points by hand - say 25/50/75/100% RGBCMY saturation, and 20-100% Greyscale in 10% steps (going below 20% in yCMS won't be usable until we get >8-bit output from madVR) and have interpolation take care of the rest.

You would think that programs would be best at doing this algorithmically rather than taking the time to hand-tune things, but most of the time tolerances just aren't strict enough or the emphasis is on speed and making a "good enough" profile. It isn't worthwhile if your display drifts a lot, but if your display is good enough, it's definitely worth putting the effort in. (please, no-one suggest ArgyllCMS...)

[MSL_DK]

Video is encoded to only use 16-235, so you probably shouldn't see anything outside that range. Color management systems also have a tendency to clip anything outside the display's gamut.

I do not understand why I get the flashing bars above 235 on red and blue after using ycms. The two colors also looks washed out compared to blue

[leeperry]

I do not understand why I get the flashing bars above 235 on red and blue after using ycms. The two colors also looks washed out compared to blue
Yeah, has anyone really put the current yRGB based CMS of mVR through test patterns and so? I haven't read about any real world testing tbh. I've only read ppl complaining and the author replying that he had better things to do than working on yCMS. That's mostly the reason why I asked madshi why he wouldn't allow custom RGBW coordinates to be input into his PS based gamut mapping magic....it looks so beautiful as is :cool:

And BTW, yesterday I played around with a UE46ES6100: the 10 points color temp correction works like a charm(and 10bit correction kills PQ-wise, 3800:1 native CR yeah baby!) but the custom primaries/secondaries are a major hit and miss because they work in R/G/B instead of XYZ, huh? Maybe I really missed something but from my limited testing, that was a major hit and miss. And anyway, it exhibited outrageous clouding right in the center of the bottom 2.35 bar so it had to go back and I didn't bother testing it any further...not dropping 900€ for this :scared:

[6233638]

Yeah, has anyone really put the current yRGB based CMS of mVR through test patterns and so? I haven't read about any real world testing tbh. I've only read ppl complaining and the author replying that he had better things to do than working on yCMS. That's mostly the reason why I asked madshi why he wouldn't allow custom RGBW coordinates to be input into his PS based gamut mapping magic....it looks so beautiful as is :cool:Unfortunately the yCMS controls are very basic right now, which probably puts its correction on a similar level to these gamut mapping pixel shaders. However, LUT correction can be significantly more powerful. The problem is that the LUT creation tools for yCMS are very basic right now, not the LUT system itself.

the custom primaries/secondaries are a major hit and miss because they work in R/G/B instead of XYZ, huh?Most color management systems work with RGBCMY HSL controls.

XYZ is a pain to work with. There are some very high end displays which let you just dial in some XYZ co-ordinates and the display shows them accurately, but most displays are not capable of this.

xyY is preferable to XYZ because it's easily readable - xy are your horizontal and vertical axes, and Y is luminance. (brightness)

[leeperry]

Well for each primary/secondary I was able to play around with -50/+50 for R/G/B....how the hell do you get those spot-on REC.709? HCFR talks in xy/ΔE and the green primary of that sammy was drifting like hell :devil:

A friend of mine told me that his high-end SONY TV also provides custom gamut capabilities, I've asked him for more informations.

Well yeah, I am well aware that 3DLUT's are the top of the crop in the movie industry(and that each movie goes through a truckload of them, some of them being proprietary and encrypted), but right here right now with yCMS it doesn't do anything (much) better than the PS script (AFAIK), it hasn't been thoroughly tested(I haven't seen a single real world measurement of the results of yRGB based corrections through mVR, only complains) and the author has been AWOL for a while. But anyway, I know it annoys madshi when I raise this matter, so I'll just put my hands where my mouth is :p

[leeperry]

All this said, I just bought a UE50EH5300(so cheap that it was hard to resist :D) that can only do D70 or D59...it's got gain/offset settings for R/G/B though, so I would need a 3DLUT to convert it to D65 and map its gamut.

I guess I'll try my luck with the current yCMS helper in mVR, get it through HCFR test patterns and report back....IIRC it claims to be able to convert both gamut and white point so we'll see about that :cool:

[MSL_DK]

^^ I think I'm having a little break with ycms. Whatever I do, the result is weird. But looking forward to hearing about your results :-)

[madshi]

FWIW, a new yCMS build with an important bugfix is expected very soon.

[Xaurus]

madshi, is there any way a donation can help speed up the 3D support? :)

[leeperry]

FWIW, a new yCMS build with an important bugfix is expected very soon.
OK, thanks for the heads-up!

In the meantime I could always use a 8bit Argyll CLUT in order to convert D70 to D65, but there's no point in going through very time consuming and annoying HCFR-based manual tests of yRGB based corrections if there's a bugfix bound to be released soon.....which still raises my question as to whether it would be a lot of trouble for you to allow custom coordinates for PS based gamut mapping in mVR. As we say in french "never put all of your eggs in one basket", and that would do the interim nicely until yCMS corrections will have been proven to be reliable. I haven't checked your gamut rolling stuff in HCFR, but it looks great to me and I'd be glad to oblige with a whole bunch of test results.

:thanks:

[dansrfe]

Is there a guide or book I can read to get better knowledge of calibration and 3DLUTs?

[leeperry]

I like this one (http://www.color.org/ICC_Chiba_07-06-19_PM_DMP_Float.pdf).

[pirlouy]

Leeperry, your determination to search always for better quality is really funny and enjoyable to read ! :D
Even if it's off topic, I hope you'll continue to tell us about your research. :)

[dansrfe]

This issue has existed for a while for me but I never raised an issue about this before. I actually don't know what it is attributed to. Either MPC-HC, madVR, or LAV Filters.

The issue is that when I have subtitles on (in windowed mode) and I drag the playing MPC-HC window across to my other monitor, the subtitles become horizontally stretched and I have to resize the window (just trigger a resize basically so even +- 1 pixel does it) to correct the subtitles width. This happens with SRT or SSA embedded in MKV files.

[6233638]

Well for each primary/secondary I was able to play around with -50/+50 for R/G/B....how the hell do you get those spot-on REC.709?It doesn't sound like that set has a proper CMS and only offers RGBCMY chroma adjustments. (saturation and brightness combined)A friend of mine told me that his high-end SONY TV also provides custom gamut capabilities, I've asked him for more informations.I don't think this is correct.right here right now with yCMS it doesn't do anything (much) better than the PS script (AFAIK), it hasn't been thoroughly tested(I haven't seen a single real world measurement of the results of yRGB based corrections through mVR, only complains)I'll try and get measurements off a display this weekend.All this said, I just bought a UE50EH5300(so cheap that it was hard to resist :D) that can only do D70 or D59...it's got gain/offset settings for R/G/B though, so I would need a 3DLUT to convert it to D65 and map its gamut.There is no such thing as D70 or D59, only D50, D55, D65 and D75.

If you have white balance controls, you should be able to calibrate it to D65 however. I would suggest starting at the 7000K preset as you are generally best to use subtractive adjustments when calibrating.

I guess I'll try my luck with the current yCMS helper in mVR, get it through HCFR test patterns and report back....IIRC it claims to be able to convert both gamut and white point so we'll see about that :cool:Unless your display is really bad after calibration with its own controls, I would suggest only using the RGBW gamut section, and using the "greyscale/gamma" section to only make gamma corrections from 20% up, until we get 10-bit output from madVR and/or better controls for yCMS LUT creation.

To do this, set xy to 0.312713, 0.329016 for all points (preferably 20-100% in 10% steps) and enter your measured Y values, then adjust each point as necessary to hit your desired gamma target, working from 90% downwards. (the calculated LUT will probably only be accurate to within ±0.10 for each point) As your display contrast is <10,000:1, I would suggest that you use the BT.1886 curve adjusted for your contrast ratio. (this spreadsheet (http://www.avsforum.com/t/1409045/how-power-law-gamma-calibration-can-lead-to-crushed-blacks/0_100#post_22208270) should help)

I would also suggest using the display's controls (if it has any) to calibrate gamma as much as possible, prioritizing 0-20%, and yCMS for fine-tuning gamma from 20-100%. yCMS corrections below 20% can introduce visible errors, which is why I would recommend using the display controls for that. (I suspect this is the result of madVR's 8-bit output)

As display gamma controls tend to be relatively coarse, if you can't get a point at the specific brightness required (some controls might jump from 2.35 to 2.45 on a point for example) you are better to calibrate it to the brighter of the two (lower gamma - in this case, 2.35) and correct that via the 3DLUT, than be too dark and brighten it with the LUT.

[leeperry]

If you have white balance controls, you should be able to calibrate it to D65 however. I would suggest starting at the 7000K preset as you are generally best to use subtractive adjustments when calibrating.

Yup thanks for the tips, you nailed it! A few hours after writing this, I fired up my i1d2 and managed to get the D70 preset to reach D65 without the help of Argyll so all is well :)

I'm not too OCD'ed about gamma tbh, but I'm quite sure that I should be able to get it to behave because I can play around with the backlight brighness, picture brightness, contrast and it's got a gamma setting that goes from -3 to +3 so that should get the job done. Either way, I like a darkish 2.4 cinema-like gamma.

The "10p white balance" feature that Sammy provide in their mid/high range TV's seems pretty pointless because the gain/offset settings for R/G/B can easily reach D65 anyway. Many old Mitsu DLP's only had those settings and that had never been a problem before.

xvYCC also seems utterly pointless at this point as far as I can tell, and concerning the gamut stuff their user manual says "Colour Space: Adjusts the range and variety of colours (the colour space) available to create images"(engrish at work ^^)....I tried to set extreme settings and it did move the primaries drastically in HCFR, but as I said it seemed to be too much of a hit and miss to bother with it. Either you implement it well or you don't, providing sloppy features to look good in the datasheet is not a good business practice.

I dunno what's your take on this, but when I fired up the 46" Hitachi, its sujective "pop effect" really struck me! Everything looked like it was literally popping out of the screen, and that Sammy UE46ES6100 looked even more 3D and made all the other TV's in the shop look flat and dull. The salesman understood that I was a video nutcase so he let me set them all to cinema modes and disable all their noise reduction/dynamic contrast features so I wasn't comparing apples Vs oranges.

And strangely enough, the "pop effect" of those 3/4K'ish:1 CR Hitachi/Sammy TV's is much more striking than on a 20K:1 flat screen CRT.....that same salesman told me that a good TV is not just a panel, it's also a DSP! And I think he nailed it because when playing noisy SD videos, the 6100 was literally cleaning the picture(even though all its NR settings were disabled :scared: ) and after watching it for several hours, I came to the conclusion that Sammy being well aware that there's only so much CR you can squeeze off a LCD panel, they had to "cheat" in order to increase the subjective "pop effect". But strangely, it's not silly halo-based EE nor agressive gamma so I don't really know how the hell they do it :(

But the 46ES6100 looked very very "colored" to me, in the sense that everything kinda looked like a cellshade cartoon and very "digital" when OTOH the 50ES5300 looks far more natural and doesn't try to impress you with unrealistic pictures :confused:

I guess they must be doing some smart NR + playing around with the contrast of edges or something, hard to tell..but there sure is something on.

I'll try and get measurements off a display this weekend.
Sounds like a plan http://forum-images.hardware.fr/images/perso/kimouss.gif

Leeperry, your determination to search always for better quality is really funny
Well, I'm a proud member of team "enough is never enough" :p

Anyway, I think I finally won the panel/clouding lottery because this 800€ 50" Sammy really seems to hit the spot: it can reach D65 in 10bit using its internal processing(w/o resorting to a sloppy dynamics-killing 8bit CLUT on the PC), its clouding is very reasonable(only a slight stain in the middle of the left edge), its picture is very sharp and quite contrasty and it's got that killer looking 1cm thick only shell around the picture.....I have to admit that most other TV's look kinda dated to me now.

I couldn't care less about cellphones and tablets, but I can see why Apple are so afraid of Sammy.....and I guess the latter learned their lesson quite well when they commissioned Joe Kane for some of their videoprojectors because even their low-end TV's provide offset/gain settings for R/G/B & 24Hz support, when getting this kind of features from their competition usually raises prices drastically(x2/x3) and forces you to pay for all kinds of features you might very well never use(wifi, artifacts feast frame interpolation, video recorder, smart TV, anaglyph 3D, etc).

At this point, all I need is 1) gamut mapping(but we'll see what 6233638's test results with yCMS will look like) 2) mirroring(which should be possible when mVR will support PS scripts) 3) levels conversion, because I've got many HD videos that went through failtastic processing and end up being 24-210 or stuff like that....I can't use the 8bit ffdshow processing anymore so I'm really SOL on this one....hopefully madshi will pity me/us and allow custom levels filename tags such as [levels=24-210]http://forum-images.hardware.fr/images/perso/2/goldos.gif

Sitting 2 meters away from a 50" TV(with 10bit colorimetry correction) should really allow Jinc3 AR luma upscaling to shine! It's about time I'd fire up the 660 that's been sitting in its box for the past 2 days now :devil:

[MSL_DK]

Yup thanks for the tips, you nailed it! A few hours after writing this, I fired up my i1d2 and managed to get the D70 preset to reach D65 without the help of Argyll so all is well :)

The same here ... but with color clipping (Samsung UE40D5005 /5000/5520)

[vomanci]

Got 2 crashes one after the other, using PotPlayer, trying to right-click in widowed screen. After that it worked finehttp://www.sendspace.com/file/c8wvle.

[MSL_DK]

FWIW, a new yCMS build with an important bugfix is expected very soon.

Thanks for the info :)