View Full Version : madVR - high quality video renderer (GPU assisted)
leeperry
12th July 2016, 07:17
I have a couple of examples of where anti-bloating removes detail that would be considered valid sharpening. (..)
Guitar (https://drive.google.com/open?id=0B2LAr9InPMjta3NmYTdrSXNaUEE)
Guitar SuperRes (3) (https://drive.google.com/file/d/0B2LAr9InPMjtRkZYLVZVNEM0TU0/view?usp=sharing)
Guitar SuperRes (3) + Anti-Bloating 100% (https://drive.google.com/open?id=0B2LAr9InPMjtVGxNa3IzS2tNcUU)
AB100% is too high of a value IME and I rest my case that there is no such thing as "valid sharpening" to my eyes(especially with sxbr100 which is too sharp to me and so is SR3), for instance I prefer the "Nie" characters written on the left button of the guitar with AB than without. You also didn't mention whether picture was refined after every 2X upscale and what downscaler was used(I ran SSIM 2D 100%).
Anyway, it's not like anyone is forcing you to run AB on SR and I kinda rest my case that the top left corner with sxbr75+SR1 looks better with AB25 than without: http://screenshotcomparison.com/comparison/178293
This is what AB does, it cleans edges for smoother movements. Either way there is no free lunch to be expected from upscaling, it's all about compromises and I find the AB75% compromise more than worth it as picture doesn't look harsh and oversharpened anymore.
ryrynz
12th July 2016, 07:51
T
The rest of the lettering, especially on the lower part of the guitar shows the same improvement and then degradation when anti-bloating is enabled.
Guitar (https://drive.google.com/open?id=0B2LAr9InPMjta3NmYTdrSXNaUEE)
Guitar SuperRes (3) (https://drive.google.com/file/d/0B2LAr9InPMjtRkZYLVZVNEM0TU0/view?usp=sharing)
Guitar SuperRes (3) + Anti-Bloating 100% (https://drive.google.com/open?id=0B2LAr9InPMjtVGxNa3IzS2tNcUU)
Improvement? Anti-bloating is doing wonders here. The SuperRes only pic looks pretty nasty.
Anyway, it's not like anyone is forcing you to run AB on SR and I kinda rest my case that the top left corner with sxbr75+SR1 looks better with AB25 than without: http://screenshotcomparison.com/comparison/178293
The difference there is so subtle I doubt anyone would notice it.. how large is that zoom? :D
burfadel
12th July 2016, 09:18
Maybe try using a lower SuperRes number instead :). The SuperRes by itself is oversharpened, with anti-bloating it's slightly blurred.
ryrynz
12th July 2016, 09:24
Maybe try using a lower SuperRes number instead :). The SuperRes by itself is oversharpened, with anti-bloating it's slightly blurred.
It's not blurred, it just doesn't have crazy amounts of haloing all over the place.
chros
12th July 2016, 11:27
What changes happened between 0.90.20 and 0.90.22 that would hurt performance? As I have said in the past, I like pushing my GPU to the max and my 720p24 profile is right on the edge (so much so that even a chroma superres of just 1 pushes it over the edge). When I tried 0.90.22 the first file I watched at 720p was actually 718 and I thought the performance hit was because of that... however later I watched one that was 720 and I could no longer maintain render queue. I rolled back to 0.90.20 and all is well again. Just curious what could have changed since I didn't see anything is the changelog for either 21 or 22. Something deeper under the hood?
Interesting, I haven't noticed anything like this on my really restricted system (though I haven't tried out all my profiles yet). I'll keep an eye on it and report back.
leeperry
12th July 2016, 12:30
The difference there is so subtle I doubt anyone would notice it.. how large is that zoom? :D
That was with SR1+AB25, difference is a lot more obvious with SR2+AB75. It's called a "proof of concept" :p
Sunset1982
12th July 2016, 13:43
what image/chroma upscaling, and refinement settings would you guys suggest, if you got enough gpu power (GTX 1080)?
s4nder
12th July 2016, 13:53
what image/chroma upscaling, and refinement settings would you guys suggest, if you got enough gpu power (GTX 1080)?
Same question, with a GTX1080 I can easily run NNEDI3 with 256 neurons but with some content it looks painfully sharp. Still looking for the optimal choice.
Shiandow
12th July 2016, 14:25
I have a couple of examples of where anti-bloating removes detail that would be considered valid sharpening.
[...]
Guitar (https://drive.google.com/open?id=0B2LAr9InPMjta3NmYTdrSXNaUEE)
Guitar SuperRes (3) (https://drive.google.com/file/d/0B2LAr9InPMjtRkZYLVZVNEM0TU0/view?usp=sharing)
Guitar SuperRes (3) + Anti-Bloating 100% (https://drive.google.com/open?id=0B2LAr9InPMjtVGxNa3IzS2tNcUU)
Perhaps it's interesting to point out that Anti-Bloating simply seems to make the result closer to what you'd get with the latest version of SuperRes. (http://i.imgur.com/vVRg0L3.png) Not entirely sure what differences there are with MadVR's SuperRes, but among other things this version uses Linear Light, and no anti-ringing of any kind.
Sunset1982
12th July 2016, 14:27
Same question, with a GTX1080 I can easily run NNEDI3 with 256 neurons but with some content it looks painfully sharp. Still looking for the optimal choice.
chroma upscale or luma image doubling?
For chroma I yould suggest NNEDI32, and Luma image doubling at 64 neurons.
But I would like to know is, what settings the other guys here prefer when using NNEDI or superXBR. Are you using SR with both? Any other suggestions?
leeperry
12th July 2016, 15:57
I would like to know is, what settings the other guys here prefer when using NNEDI or superXBR. Are you using SR with both? Any other suggestions?
SR for both, reconstruction soft for chroma & sxbr75/jinc for luma + SSIM 2D 100%.
Perhaps it's interesting to point out that Anti-Bloating simply seems to make the result closer to what you'd get with the latest version of SuperRes. (http://i.imgur.com/vVRg0L3.png) Not entirely sure what differences there are with MadVR's SuperRes, but among other things this version uses Linear Light, and no anti-ringing of any kind.
Ouh, touché!
Iznogūd
12th July 2016, 16:20
madshi,
What changes happened between 0.90.20 and 0.90.22 that would hurt performance? As I have said in the past, I like pushing my GPU to the max and my 720p24 profile is right on the edge (so much so that even a chroma superres of just 1 pushes it over the edge). When I tried 0.90.22 the first file I watched at 720p was actually 718 and I thought the performance hit was because of that... however later I watched one that was 720 and I could no longer maintain render queue. I rolled back to 0.90.20 and all is well again.
QB
I'm experiencing the same issues as well, running a GTX750ti against a 1440x900 display.
jerryleungwh
12th July 2016, 19:02
I'm trying to use the debug mode to find out what's preventing me from using D3D11 exclusive mode but I don't quite understand what the log says. These two lines seem significant though
00006286.019 Window blocking WM_NCACTIVATE
00006289.356 Render prevented Direct3D from setting display mode 0x0, 0 Hz, progressive
Could this be the problem and how can I fix it? If no what should I look for in the log for such problem?
whitestar999
12th July 2016, 19:12
Anyway, it's not like anyone is forcing you to run AB on SR and I kinda rest my case that the top left corner with sxbr75+SR1 looks better with AB25 than without: http://screenshotcomparison.com/comparison/178293
This is what AB does, it cleans edges for smoother movements. Either way there is no free lunch to be expected from upscaling, it's all about compromises and I find the AB75% compromise more than worth it as picture doesn't look harsh and oversharpened anymore.
I have to admit I didn't saw any change in top-left corner but I did saw a black spot diminishing(on mouse over with AB25) & then enlarging on mouse out on bottom right corner of small egg like structure below the antenna/rod at the top of building structure.If only ppl make their voting choices in general elections as diligently.:D
burfadel
12th July 2016, 19:17
The adaptive sharpen shader has been updated, thought I'd mention it since it's used under the upscaling refinement and image enhancements options.
http://forum.doom9.org/showthread.php?t=172131
Changelog:
2016-07-10 - Replaced lerp used for under/overshoot compression with a weighted power mean, reduces some ringing.
- Corrected minor error in the custom smoothstep function.
- Slightly improved weighting for nmax & nmin.
- Tweaked some parameters.
Sunset1982
12th July 2016, 19:45
is there any difference in motion clarity when using NNEDI instead of SuperXBR?
aufkrawall
12th July 2016, 23:28
That's impossible, there can be no difference between scaling one frame seperated or many in a row with the same algorithm.
If you want best motion clarity, let madVR feed a display that supports black frame insertion with the correct refreshrate without smooth motion.
ryrynz
12th July 2016, 23:32
Not entirely sure what differences there are with MadVR's SuperRes, but among other things this version uses Linear Light, and no anti-ringing of any kind.
Looks good, a bit too much sharpness and aliasing but likely you were using a different luma upscaler. I never got the impression SuperRes really helped much at all and have never enabled it. Might actually look at it when this updated version makes it way into madVR.
pirlouy
12th July 2016, 23:38
That's impossible, there can be no difference between scaling one frame seperated or many in a row with the same algorithm.
Well it looks possible to me. I guess lesser quality images might allow a better motion clarity than well defined images.
Anima123
12th July 2016, 23:47
Perhaps it's interesting to point out that Anti-Bloating simply seems to make the result closer to what you'd get with the latest version of SuperRes. (http://i.imgur.com/vVRg0L3.png) Not entirely sure what differences there are with MadVR's SuperRes, but among other things this version uses Linear Light, and no anti-ringing of any kind.
Was this version of SuperRes already available to public?
Shiandow
13th July 2016, 00:17
Was this version of SuperRes already available to public?
It should be the same as the one here (https://github.com/zachsaw/MPDN_Extensions/tree/master/Extensions/RenderScripts/SuperRes).
SpoCk0nd0pe
13th July 2016, 01:13
Hey Madshi,
I've got a rather special request:
Could you implement changing 3d formats, allowing a change from frame packed 3d to frame sequential 3d?
or
Could you implement support for frame sequential 3d input?
digitech
13th July 2016, 01:28
does anyone know if i use the nvidia edge enhancement option with "use nvidia setting" selected on control panel if madvr really apply this setting or just ignore it?
huhn
13th July 2016, 01:59
does anyone know if i use the nvidia edge enhancement option with "use nvidia setting" selected on control panel if madvr really apply this setting or just ignore it?
should be ignored except with DXVA processing. it may work with deinterlancing or DXVA scaling.
Ironclad
13th July 2016, 05:51
Having to copy the image in high-bit-depth from the GPU to system memory and back after processing will take a significant part of the performance, so don't expect too much free magic.
Oh so more so than the GPU needing to process an additional 36 or more frames per second, it's the lag caused by storing in system memory that's slowing everything down. I'm probably oversimplifying it but 640x480 frames->1440x1080 frames should increase the traffic through system memory by like 5 both ways compared to the current method.
Even if the GPU is doing 2.5-6 times as much work, that's not comparable to the difference in speed between RAM and VRAM.
https://en.wikipedia.org/wiki/List_of_device_bit_rates#Dynamic_random-access_memory
Oh of course that's why already high framerate videos are no issue! The only solution would be if the interpolation is done entirely by a GPU. I guess using DDR4 will help somewhat. I'll see what the SVP developers think but I'm guessing it would require completely rewriting the filter.
ShiftyFella
13th July 2016, 20:59
Looks like HDR processing in .22 is kinda broken or maybe it's just me? LG Chess and Sony Camp videos play absolutely fine with hdr processing turned on and picture looks like it should but this (http://demo-uhd3d.com/fiche.php?cat=uhd&id=115) Samsung demo and files from this (http://forum.doom9.org/showthread.php?p=1765307#post1765307) post look totally wrong. HDR processing option turned on produces color shifted image. Playing with any of the options doesn't help and only turning it off helps. Using .20 or older produced no such issues, I skipped .21 and updated straight to .22 from .20 tho
samsung hdr demo:
hdr processing turned on:
http://i.imgur.com/NNGRKOgl.jpg (http://i.imgur.com/NNGRKOg.jpg)
hdr processing off:
http://i.imgur.com/QQ84Tsil.jpg (http://i.imgur.com/QQ84Tsi.jpg)
sony camp:
hdr on:
http://i.imgur.com/LwcofFMl.jpg (http://i.imgur.com/LwcofFM.jpg)
hdr off:
http://i.imgur.com/ijQpbjrl.jpg (http://i.imgur.com/ijQpbjr.jpg)
pose
13th July 2016, 21:35
madshi, i was always curious as of what settings and scaling algorithms you prefer yourself. Can you tell me please? Also thank you for the madVR! My chinese cartoons look amazing! :thanks:
zoyd
13th July 2016, 23:02
Looks like HDR processing in .22 is kinda broken or maybe it's just me?
I'm not seeing any color shifting of that image here. Note that the text and image overlay is encoded with peak white at 255 (10,000 nits).
350 nit display (madVR set to 400 nits HDR on, preserve hue on)
https://dl.dropboxusercontent.com/u/2621383/20160713174711_HDMI1.jpg
mastrboy
13th July 2016, 23:15
Is it possible for MadVR to have more controls than the seek bar in exclusive mode? (like next/previous chapter buttons for example)
ryrynz
13th July 2016, 23:40
HDR processing option turned on produces color shifted image.
sony camp:
hdr on:
http://i.imgur.com/LwcofFMl.jpg (http://i.imgur.com/LwcofFM.jpg)
I've watched this HDR test video quite a lot at work on HDR & non HDR TV's, and that's exactly how it looks.
leeperry
13th July 2016, 23:58
Is it possible for MadVR to have more controls than the seek bar in exclusive mode? (like next/previous chapter buttons for example)
PotPlayer has fully skinnable GUI's and also a mode that doesn't break FSE :)
zoyd
14th July 2016, 00:37
I do think the desaturation of high luminance red/orange is too aggressive when using preserve hue. Take this for example:
hue preserve off
https://dl.dropboxusercontent.com/u/2621383/desat1.jpg
hue preserve on
https://dl.dropboxusercontent.com/u/2621383/desat2.jpg
CalMAN LUT
https://dl.dropboxusercontent.com/u/2621383/desat3.jpg
Without hue preserve the madVR image luminance is too low and appears oversaturated - with hue preserve you lose all of the amber light and a good portion of the red tent.
The CalMAN LUT appears to mildly desaturate and both white and amber headlights look correct. The red tent brightens without loosing too much red definition.
ryrynz
14th July 2016, 01:03
The CalMAN LUT appears to mildly desaturate and both white and amber headlights look correct. The red tent brightens without loosing too much red definition.
That's more than just mild desaturation, but yes the lights do look right to me but the rest if quite off. What are you basing you comparison on for things being accurate/not accurate?
I might be tempted to take a photo of one of the HD sets at work with this scene for comparison although it wouldn't be calibrated.
ShiftyFella
14th July 2016, 01:46
I'm not seeing any color shifting of that image here. Note that the text and image overlay is encoded with peak white at 255 (10,000 nits).
350 nit display (madVR set to 400 nits HDR on, preserve hue on)
https://dl.dropboxusercontent.com/u/2621383/20160713174711_HDMI1.jpg
After resetting my setting and nuking all of my profiles, I figured out the culprit. It was SuperRes turned on for chroma upscaling. When both SuperRes and HDR procesing turned on, it produces weird color shift and it changes depending on the SR level. Turning SR off brings picture back to normal, apparently i had SR on in some profiles but not in others, that's why it was only showing up with different files. I'm not sure what's going on or why it's doing this.
HDR on, SR off:
http://i.imgur.com/LwcofFMl.jpg (http://i.imgur.com/LwcofFM.jpg)
HDR on, SR@1:
http://i.imgur.com/my9I3Zvl.jpg (http://i.imgur.com/my9I3Zv.jpg)
HDR on, SR@4:
http://i.imgur.com/nSZwDBel.jpg (http://i.imgur.com/nSZwDBe.jpg)
HDR off, SR on
http://i.imgur.com/Cw0JOYSl.jpg (http://i.imgur.com/Cw0JOYS.jpg)
zoyd
14th July 2016, 01:55
That's more than just mild desaturation, but yes the lights do look right to me but the rest if quite off.
The point was that the CalMAN LUT generated image is significantly less desaturated than what madVR is doing with preserve hue.
What are you basing you comparison on for things being accurate/not accurate?
The display is calibrated via the LUT so what I am seeing is correct in an absolute sense for in-gamut colors. For the out-of-gamut colors there is no way to assess "correct" because each display needs a different compromise depending on it's peak luminance. All I can say is that the CalMAN LUT mapping of out-of-gamut colors for my display appears to do a better job with these red/orange highlights than the current madVR algorithm.
James Freeman
14th July 2016, 04:43
I do think the desaturation of high luminance red/orange is too aggressive when using preserve hue. Take this for example:
I have to agree, the CalMAN LUT preserve the color gradations more, while in madVR the colors turn to white very fast.
Moreover, when changing the "display calibrated to gamut" to BT.2020 in madVR it should preserve more of the color saturation gradations than BT.709 no?
It looks like it does not even on BT.2020.
StinDaWg
14th July 2016, 08:40
Can anyone else confirm these D3D11 bugs...
When in D3D11 FSE mode, playing back a 30 fps video (not 29.97, but 30 fps), the render queue and present queue drops down to minimum levels, and present stats are abnormally high (15-19ms) when it's normally in the 0 to 1ms range.
This also happens for all videos when the video is paused in D3D11 FSE and Windows screen saver comes on. Once you resume play all the queues drop and they never recover.
This does not happen in D3D11 windowed or D3D9 (either mode). It seems to be a D3D11 FSE only issue. Using AMD card/drivers and Win10.
I would like to use D3D11 FSE as it offers the best performance and 10 bit mode, but these issues make it kind of unusable for me.
wolfman2791
14th July 2016, 09:36
I'm having an issue: I get a OpenCL error on the x64 version of MPC-HC. Causes MPC-HC to crash. I don't get it on the x86 version. Is this a known issue?
I have a AMD R9 390 8GB GPU. So it can't be a memory issue.
zoyd
14th July 2016, 10:42
Moreover, when changing the "display calibrated to gamut" to BT.2020 in madVR it should preserve more of the color saturation gradations than BT.709 no?
It looks like it does not even on BT.2020.
No, BT.2020 just means wide gamut encoding. The colors in that clip do not exceed DCI/P3 gamut and the problem is with high luminance throwing these colors out-of-gamut, not high saturation.
ShiftyFella
14th July 2016, 11:16
Can anyone else confirm these D3D11 bugs...
When in D3D11 FSE mode, playing back a 30 fps video (not 29.97, but 30 fps), the render queue and present queue drops down to minimum levels, and present stats are abnormally high (15-19ms) when it's normally in the 0 to 1ms range.
This does not happen in D3D11 windowed or D3D9 (either mode). It seems to be a D3D11 FSE only issue. Using AMD card/drivers and Win10.
I would like to use D3D11 FSE as it offers the best performance and 10 bit mode, but these issues make it kind of unusable for me.
Do you use hdmi port for your tv\monitor? I can confirm this weird behavior occurs over hdmi but not over display port, everything is like it should there. I have 290x with latest crimson drivers(16.7.2) and win10(64bit). Personally I don't use FSE that much as I don't see any performance gain and it sometimes messes with my multi monitor setup
http://i.imgur.com/DE3ee4dl.jpg http://i.imgur.com/p85gYe7l.jpg http://i.imgur.com/gZRtwj3l.jpg
madshi
14th July 2016, 11:27
OK, here goes
Ok, thanks, will have a look at that when I find some time, maybe next weekend.
What changes happened between 0.90.20 and 0.90.22 that would hurt performance?
Three things:
1) Bilateral chroma upscaling is slower now (when using the new algo).
2) HDR handling is slower now.
3) Fixed a couple of bugs in deciding when image doubling and upscaling refinement becomes activated.
If you don't use Bilateral chroma upscaling, and if we're talking about SDR content, and you still get slower performance, then it might have to do with image doubling and/or upscaling refinement now maybe becoming active when it didn't before?
What does it mean if 1080p/720p MKV movies have present queue 0-2/3 in Windowed Mode but FSE it works fine.
Asus G751JT
Windows 8.1 x64 + Potplayer x64 + Lavfilters 0.61 + DXVA2 CopyBack or CUVID + 970M + 368.69 Drivers + Potplayer Profile set to Maximum Performance - 3 Pre-rendered frames - Gsync Disabled Fixed Refresh
How can I fix it ?
The render queue is the first queue in the list which is nearly empty, so that's the bottleneck. It seems that your GPU can't keep up. Might have to do with the high refresh rate (100Hz). You may have to lower your scaling settings. E.g. use 16 neurons instead of 32 for chroma upscaling.
what image/chroma upscaling, and refinement settings would you guys suggest, if you got enough gpu power (GTX 1080)?
Same question, with a GTX1080 I can easily run NNEDI3 with 256 neurons but with some content it looks painfully sharp. Still looking for the optimal choice.
madshi, i was always curious as of what settings and scaling algorithms you prefer yourself. Can you tell me please? Also thank you for the madVR! My chinese cartoons look amazing! :thanks:
For chroma upscaling I like super-xbr AR or Reconstruction Soft, which are both decent allround algorithms, which work fine for most content. The best quality can be achieved with Bilateral, though. However, although Bilateral looks best in most cases, sometimes it produces artifacts, so at this point I'm not confident recommending it as a general purpose allround algorithm yet.
For luma upscaling I like NNEDI3 + SuperRes. For downscaling I like SSIM1D 100 with some Anti-Bloating.
Just my personal opinion, though. YMMV.
Perhaps it's interesting to point out that Anti-Bloating simply seems to make the result closer to what you'd get with the latest version of SuperRes. (http://i.imgur.com/vVRg0L3.png) Not entirely sure what differences there are with MadVR's SuperRes, but among other things this version uses Linear Light, and no anti-ringing of any kind.
Which settings did you use for your newest SuperRes for this image?
I just compared your latest SuperRes with mine again last weekend, but I'm still not convinced that your latest algo is an improvement over what I already have. The nice thing about yours is that it doesn't need an extra anti-ringing filter. However, depending on the settings, yours still has either aliasing artifacts, or looks somewhat "bloated", or is too soft for my taste.
Generally I don't like having 5 different options which all influence each other. Most users wouldn't have a clue which settings they should use. I'd like to have one algo with just a "strength" option which works decent for all sources. And from what I'm seeing, currently I still think my current implementation is a better allround solution with less bloated look, less aliasing problems and higher detail reconstruction. But I'm very willing to be convinced otherwise!
Which settings would you recommend to use with your new algorithm? Those settings should work well for all sources. I'll gladly retest to see if with those settings I now like yours better than mine.
Thanks!! :)
I'm trying to use the debug mode to find out what's preventing me from using D3D11 exclusive mode but I don't quite understand what the log says. These two lines seem significant though
00006286.019 Window blocking WM_NCACTIVATE
00006289.356 Render prevented Direct3D from setting display mode 0x0, 0 Hz, progressive
Could this be the problem and how can I fix it? If no what should I look for in the log for such problem?
The log is pretty hard to interpret. It's made for my eyes, so I'm not sure if you can find what you need. Those 2 lines you mentioned are "good", they should be there are don't indicate a problem.
If you upload the (zipped) log somewhere I can have a look if I can see something. Please activate the Ctrl+J OSD and keep it active while creating the log, then try to enter exclusive mode. Having the Ctrl+J OSD turned on is important because in this specific case it adds more information to the debug log.
The adaptive sharpen shader has been updated
K, thanks.
Could you implement changing 3d formats, allowing a change from frame packed 3d to frame sequential 3d?
My control over what the GPU outputs is very limited. I can either output frame packed 3D, or conventional 2D. I have no other options. When outputting conventional 2D, I can do some fancy pixel resorting, which allows me to render 3D for those line or column alternate displays (passive IPS LCDs). But I don't see how I could do frame sequential 3D. Neither Windows nor the GPU manufacturers offer any kind of API for that.
Is it possible for MadVR to have more controls than the seek bar in exclusive mode? (like next/previous chapter buttons for example)
This is really what the media player should do. I do know that not all media players provide a nice exclusive mode GUI, though, which is the reason why I implemented the seekbar in the first place. Maybe at some point I'll add more GUI controls for media players that don't have their own in exclusive mode. But it's not a high priority atm.
I've watched this HDR test video quite a lot at work on HDR & non HDR TV's, and that's exactly how it looks.
FWIW, tone+gamut mapping on current HDR TVs is not really high quality, so I'm not sure if that should be used as a reference. I would really like madVR to be better than what HDR TVs do.
I do think the desaturation of high luminance red/orange is too aggressive when using preserve hue. Take this for example:
[..]
Without hue preserve the madVR image luminance is too low and appears oversaturated - with hue preserve you lose all of the amber light and a good portion of the red tent.
The CalMAN LUT appears to mildly desaturate and both white and amber headlights look correct. The red tent brightens without loosing too much red definition.
Agreed. I've talked to Graeme about this. He says priority in gamut mapping should be like this:
1) hue preserversion.
2) luminance preservation.
3) saturation preservation.
Which is *exactly* the priority sorting I use in madVR. However, Graeme makes the excellent point that desaturating a pixel too much doesn't really preserve hue. E.g. an almost white pixel doesn't really preserve any hue at all, although strictly the hue angle might still be perfect.
So I'm going to modify the desaturation logic a bit to avoid pixels getting desaturated too much. This means luminance accuracy will take a hit, though. I'm currently waiting for more feedback from Graeme and SpectraCal about how I should do that in the best possible way.
After resetting my setting and nuking all of my profiles, I figured out the culprit. It was SuperRes turned on for chroma upscaling. When both SuperRes and HDR procesing turned on, it produces weird color shift and it changes depending on the SR level.
Ah, thanks! Will have a look at this ASAP.
Can anyone else confirm these D3D11 bugs...
When in D3D11 FSE mode, playing back a 30 fps video (not 29.97, but 30 fps), the render queue and present queue drops down to minimum levels, and present stats are abnormally high (15-19ms) when it's normally in the 0 to 1ms range.
This can happen with weird refresh rates, especially in 10bit mode, especially with AMD GPU drivers. I don't think I've seen this reported with NVidia drivers yet. One possible fix is to lower the number of prepresented frames to e.g. 4-6. This reportedly has helped for most users in the past. I believe it's a GPU driver issue, which is related to the mixture of using D3D11, weird refresh rates, a high number of prepresented frames, and maybe 10bit output.
I'm having an issue: I get a OpenCL error on the x64 version of MPC-HC. Causes MPC-HC to crash. I don't get it on the x86 version. Is this a known issue?
I have a AMD R9 390 8GB GPU. So it can't be a memory issue.
Probably a GPU driver issue. Have you tried different GPU driver versions?
Do you use hdmi port for your tv\monitor? I can confirm this weird behavior occurs over hdmi but not over display port, everything is like it should there. I have 290x with latest crimson drivers(16.7.2) and win10(64bit). Personally I don't use FSE that much as I don't see any performance gain and it sometimes messes with my multi monitor setup
That's quite interesting! I suppose the left most screenshot is HDMI while the other 2 are display port? So a good workaround would be to use a display port -> HDMI adapter to avoid the presentation queue from getting empty in FSE mode?
MariaX9
14th July 2016, 11:39
Is Luma Upscaling the Image Doubling setting?
chros
14th July 2016, 11:53
No, BT.2020 just means wide gamut encoding. The colors in that clip do not exceed DCI/P3 gamut and the problem is with high luminance throwing these colors out-of-gamut, not high saturation.
Thanks zoyd for the Calman screenshot, it looks the best indeed. So it's clear now (as e-t172 suggested as well) that it's an out of gamut problem.
Agreed. I've talked to Graeme about this. He says priority in gamut mapping should be like this:
1) hue preserversion.
2) luminance preservation.
3) saturation preservation.
Which is *exactly* the priority sorting I use in madVR. However, Graeme makes the excellent point that desaturating a pixel too much doesn't really preserve hue. E.g. an almost white pixel doesn't really preserve any hue at all, although strictly the hue angle might still be perfect.
So I'm going to modify the desaturation logic a bit to avoid pixels getting desaturated too much. This means luminance accuracy will take a hit, though. I'm currently waiting for more feedback from Graeme and SpectraCal about how I should do that in the best possible way.
Amazing, thanks for all your work, madshi!
ShiftyFella
14th July 2016, 12:52
That's quite interesting! I suppose the left most screenshot is HDMI while the other 2 are display port?
No, only one on the right(last one) is display port. left is hdmi with fse, middle one is hdmi in windowed and on the right is display port with fse.
madshi
14th July 2016, 13:09
Is Luma Upscaling the Image Doubling setting?
Yes.
No, only one on the right(last one) is display port. left is hdmi with fse, middle one is hdmi in windowed and on the right is display port with fse.
Ok. To be fair, both the resolution and the refresh rate differs when comparing hdmi and display port in your screenshots. So I'm not sure if it's proof yet that display port doesn't have the issue.
zoyd
14th July 2016, 13:32
.
However, Graeme makes the excellent point that desaturating a pixel too much doesn't really preserve hue. E.g. an almost white pixel doesn't really preserve any hue at all, although strictly the hue angle might still be perfect.
So I'm going to modify the desaturation logic a bit to avoid pixels getting desaturated too much. This means luminance accuracy will take a hit, though. I'm currently waiting for more feedback from Graeme and SpectraCal about how I should do that in the best possible way.
I have trouble visualizing why desaturation would be used to preserve hue in the first place. Assuming the hue angle is correct for a primary color, desaturation along that line increases luminance. And this is a good trade to make in moderation because the overly dark color "appears" too saturated although it really isn't, it's just too dark. That trade is usually evaluated by minimizing one of the modern dE formulas (CIE1994 or CIE2000).
madshi
14th July 2016, 13:42
So basically I'd be using something like dE to calculate the best compromise between saturation loss and luminance loss (while keeping the hue angle constant)?
colinhunt
14th July 2016, 13:42
Apologies for asking something I couldn't find but which has probably already been answered:
- Windows 7 64-bit
- Radeon RX 480 (HDCP 2.2 and HDMI 2.0 with support for HDR), connected via HDMI to an HDR 4K television.
I'm trying to play HDR 4K demo clips on MPC-HC which has been configured to use MadVR but the screen remains black. Audio plays, though.
Should MPC-HC + madVR pass 10-bit video with HDR metadata to the TV or not, i.e. should the TV recognize and display HDR video?
nevcairiel
14th July 2016, 13:47
Should MPC-HC + madVR pass 10-bit video with HDR metadata to the TV or not, i.e. should the TV recognize and display HDR video?
No, it should not. madVR can only convert HDR videos to SDR and display that.
colinhunt
14th July 2016, 13:55
No, it should not. madVR can only convert HDR videos to SDR and display that.
Thanks for the quick reply!
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.