madVR - high quality video renderer (GPU assisted)

[James Freeman]

Meh, I'd vote to leave Random Dither as-is. I have a feeling that oppositeColor with the noise level of 'random dither' would be horrible to my eyes. If there is anything which random dither has in its favor, it's that people have gotten used to it over the years. No need to blur the difference between dither algorithms even more.

Don't have this feeling...
There is no reason people will have to use it ever again, if they got Ordered Dithering with almost the same CPU requirements.
The result does look better as with the ED builds:
and I've already tested, it very noticeably lowers luma noise once more.


If there are unforseen problems for some, there should be a safe base to go back to.
Nothing will be changed in Random Dithering except it will look better.
I have an old laptop which Random Dithering is the only option, and I like it to be OppositeColor.

[leeperry]

w00t, new build :)
It worked fine with the default settings but once I enabled vanilla A4 it instantly gave: http://thumbnails112.imagebam.com/31075/a6c944310742572.jpg (http://www.imagebam.com/image/a6c944310742572)

I restarted PotP, it worked fine, I set vanilla ED11 and now it won't load videos anymore, all I get is the same OCL error msg :o

I'm on W7SP1 with the latest WHQL HD7850 drivers.

[iSunrise]

Don't have this feeling...
There is no reason people will have to use it ever again, if they got Ordered Dithering with almost the same CPU requirements.
The result does look better as with the ED builds:




Nothing will be changed in Random Dithering except it will look better.


I have an old laptop which Random Dithering is the only option, and I like it to have OppositeColor option.
Please stop trying to overrule our opinion. And please stop posting things about "looking better".

You´re not the judge here. You´re once again completely missing the point of madshi´s question.

[aufkrawall]

Even with the latest testbuild, debanding doesn't work right for me when upscaling this 1080p video to 1440p in FSE, I am getting dropped frames:
http://www.ausgamers.com/files/download/67564/cryengine-3-crysis-3-realtime-tech-demo-video

It does happen both on a Radeon r9 290 and a GTX 670 OC, so it definitely shouldn't be a performance issue. It doesn't happen when e.g. downscaling 4k to 1440p with CR AR + LL.
This particular video file seems to be like a stress test for madVR's debanding.
Even with just bilinear upscaling (chroma & luma) I'm still getting dropped frames (smooth motion on). This is happening since the debanding feature exists in madVR.

Will post an entry at the bugtracker later if needed.

[James Freeman]

Please stop trying to overrule our opinion. And please stop posting things about "looking better".
You´re not the judge here. You´re once again completely missing the point.

Just to make it clear,
My opinion is part of OUR opinion.
Judging is EXACTLY what beta testing and voting is.
We are all "The Judge".

The point is making Random Dithering be just as compatible as before, but slightly better.
madshi clearly stated: OppositeColor does make Random Dithering look better too.

Lay back and relax,
I can voice my opinion even if I may appear a little pushy.
You can ignore me if you like, but you can't take my voting or influencing power, That's how democracy rolls baby. ;)

EDIT:
I suggest you delete your post and I'll delete mine.

[cyberbeing]

Don't have this feeling...
There is no reason people will have to use it ever again, if they got Ordered Dithering with almost the same CPU requirements.
...
Nothing will be changed in Random Dithering except it will look better.
My subjective view disagrees. :devil:

I was serious when I mentioned in a previous post that I preferred 'random dither' over any of the 'oppositeColor' error diffusion builds. Similar to how I preferred 'multiColor' error diffusion over 'oppositeColor' error diffusion. I also actually still see myself using 'random dither' as a fallback as well, if by chance the behavior of ordered dither become problematic on certain content or displays in the future. There has been almost 5 years of madVR legacy, and up until now when madshi introduce error-diffusion, there have never been any strong complaints about the use of 'random dithering'. It was accepted and ignored, even if it was bad. Keeping something familiar which is not unlike adding random color noise in other applications for dithering or otherwise, I think is beneficial. In terms of madVR itself, it also allows people to do easy before/after comparisons.

[James Freeman]

My subjective view disagrees.


No problem at all,
I don't care that much for Random Dithering so I'll rest my case here.
If there are some people who want it the way it is, then let it be.

Thanks for not being offensive...

[iSunrise]

iSunrise,
Sorry for getting you angry. :o
I´m not angry, but some people actually liked the multiColor noise on random dithering and I absolutely see no reason to rush things right now.

Everyone basically used random dithering, before we did our in-depth tests and everyone is a pretty broad user base to ignore. Another reason being, that LAV also offers random dithering and if someone wants to use it in madVR, the option of random dithering still makes sense in that case.

But that´s all up to madshi, anyway, he needs valid arguments though, which we provided.

[cyberbeing]

http://madshi.net/madVRfinalDither2.rar
This build appears to have fixed the NNEDI3 bug.

[madshi]

Can you please write a small list of what build are are what setting.
Rounding, Random Dithering, OD32, A4, ED11.

Did you have to rewrite a lot of code for that change?
"a lot of" is relative. It did require changing 3 files (mvrSettings.dll, madHcCtrl.exe, madVR.ax).

Also, I´m curious, why did you stop at 3bit instead of 1bit?
Tried 2bit, it was more than useless. Absolutely terrible, no use for testing. Ok, 1bit might have been interesting.

Quick Bug report 2:
When switching from "None" to any Dithering mode, the checkbox options do not appear till the settings window is closed, or switched to another branch and back.
Ok, noted for the build after the next build.

Mathematically it is justified since doing so does not change the average colour. But it does mean that instead of interpolating between 8 different combinations (with varying probability) it will only interpolate between 4 different combinations. It's hard to say what kind of an effect this has.

One specific problem I can think of is the following, consider the colour: (0.4,1.2,0.7). If we want to do random dithering with oppositeColor noise then we should add something of the form (x,-x,x) with x a random number between -0.5 and 0.5, and then round the result to nearest integer, this gives us:

(0,2,0) if x<-0.3
(0,1,0) if -0.3<x<-0.2
(0,1,1) if -0.2<x<0.1
(1,1,1) if 0.1<x

But if we change the colour slightly to (0.4,1.3,0.8) then we get:

(0,2,0) if x<-0.3
(0,2,1) if -0.3<x<-0.2
(0,1,1) if -0.2<x<0.1
(1,1,1) if 0.1<x

So now dithering uses a different set of colours. I'm not sure how noticeable this would be on gradients etc. but it could look quite odd. In both of the above cases the multiColor version just picks randomly between:

(0,1,0), (0,1,1), (0,2,0), (0,2,1), (1,1,0), (1,1,1), (1,2,0), (1,2,1)

This might make the transition smoother.

Edit: A similar problem happens with multiColor when one of the values is almost 'whole' but this happens less frequently.
Hmmmm... I'm having headaches, and I'm tired of dithering algorithms, so please forgive me for not trying to think this through. FWIW, in practical tests oppositeColor does appear smoother/less noisy, though. So I'm feeling safe with sticking to oppositeColor instead of multiColor.

Meh, I'd vote to leave Random Dither as-is.
I also would say that it makes sense to leave some backwards compatibility in-place right now. If there are unforseen problems for some, there should be a safe base to go back to.
Ok.

Even with the latest testbuild, debanding doesn't work right for me when upscaling this 1080p video to 1440p in FSE, I am getting dropped frames:
http://www.ausgamers.com/files/download/67564/cryengine-3-crysis-3-realtime-tech-demo-video

It does happen both on a Radeon r9 290 and a GTX 670 OC, so it definitely shouldn't be a performance issue. It doesn't happen when e.g. downscaling 4k to 1440p with CR AR + LL.
This particular video file seems to be like a stress test for madVR's debanding.
Even with just bilinear upscaling (chroma & luma) I'm still getting dropped frames (smooth motion on). This is happening since the debanding feature exists in madVR.

Will post an entry at the bugtracker later if needed.
What do the queues say (see madVR debug OSD, Ctrl+J)? Are they getting empty? Which one first?

-------

Here's a fixed build:

http://madshi.net/madVRfinalDither2.rar

Ordered dithering should hopefully work ok now, and NNEDI should be back to working.

[madshi]

http://madshi.net/madVRfinalDither2.rar
This build appears to have fixed the NNEDI3 bug.
Haha! First time somebody guessed a new build before I announced it... :D

[*Touche*]

Do you guys really see differences between the last couple of builds in 8bit mode watching real video content or do you go to 4bit/sample images to choose favourites? I find it hard to impossible, after multiple blind tests, to consistently differentiate between them in 8bit mode while watching movies. My plasma's native dithering could be a factor here.

[Soukyuu]

The new build dies on me - black screen with mpc-hc 1.7.3 crashing the moment I close it. I didn't change any settings (not using NNEDI), driver version still the 327.23

edit: to clarify: that's with both the finalDither and the newest finalDither2 build.
If its using the same CPU power, go for the better looking option and leave the nostalgia behind.
Besides, if anyone is still using Random Dithering instead of Ordered Dithering, he probably couldn't care less "what's inside". ;)I sure care about "what's inside", not having a DX11 capable GPU leaves me out in the rain though.

[iSunrise]

Tried 2bit, it was more than useless. Absolutely terrible, no use for testing. Ok, 1bit might have been interesting.
Yes, that´s why I asked. I also think 1bit would be interesting and nice for testing especially.

Thanks for the quick fixes.

Haha! First time somebody guessed a new build before I announced it... :D
LOL, that´s actually quite funny. :D

[Damien147]

With an hd 4850(ati) all I get is black screen and mpc crash on exit.I reseted madvr settings but no luck.No support because of old card or something else I need in mind?(Of course I haven't put error diffusion)


@Soukyuu got me,same thing.

[seiyafan]

I maybe not in the right forum but is this a place to ask questions regarding functionality of MadVR? I've been lurking for some time and from what I read it seems mostly are about development.

[leeperry]

wow, dynamic ED11 looks stunning on anime :cool:
not really in the mood for serious evaluation atm but ED11's noise is so low that the wavey changes might end up being (far) less problematic to my eyes, I'll give it a serious shot tomorrow morning. :thanks:

[Shiandow]

Hmmmm... I'm having headaches, and I'm tired of dithering algorithms, so please forgive me for not trying to think this through. FWIW, in practical tests oppositeColor does appear smoother/less noisy, though. So I'm feeling safe with sticking to oppositeColor instead of multiColor.

It should only be a problem when you use oppositColor with random dithering. And even then using oppositeColor is probably fine, but as others pointed out it might be a bad idea to change the 'good old' random dithering to something which may introduce new problems. I was just trying to point out possible new problems.

[aufkrawall]

What do the queues say (see madVR debug OSD, Ctrl+J)? Are they getting empty? Which one first?

Render queue is falling to 2-8 / 8 when the drops occur. Upload queue goes down to 6-8 / 8 at the same time. Without debanding, both queues stay at 7-8 / 8 all the time.

[cyberbeing]

dynamic ED11

Almost forgot about that, madshi had mentioned I should re-test with dynamic ED11 for that reason. I'll check it out later.

I maybe not in the right forum but is this a place to ask questions regarding functionality of MadVR? I've been lurking for some time and from what I read it seems mostly are about development.

Yes, this is the right forum and thread to ask such questions (this thread on Doom9 is the official home of madVR). madshi is just in extremely active development mode at the moment (which rarely occurs), so a lot of recent discussions are about test build releases. During development lulls, discussion in this thread usually goes back to general questions about functionality and other topics related to use of madVR. But feel free to ask such questions at any time.

If I enable NNEDI3 doubling, since it only works with powers of 2, it would first double it to 2160, then downscale it (I think Catmull-Rom is the most popular algorithm for downscaling) to 1440. Would this still yield visually better results than just a one step upscaling using (Jinc-3/4 AR) without the doubling? Is Catmull-Rom a good algorithm to use here?

Use of NNEDI3 doubling will potentially improve quality even when viewing at scale ratios less than 2, but performance is prohibitive. With at least 2.0x scale, NNEDI3 should always yield superior results, but the closer you get to 1.0x scale it may or may not be worth it. madVR has "only if scaling factor" settings for exactly this reason. In general NNEDI3 will result in lower aliasing and ringing, and possibility a slightly sharper image. Catmull-Rom + Anti-Ringing + Linear Light is a popular choice for image downscaling, assuming your GPU is powerful enough.


My second question is: for 1080 --> 1440, is image upscaling algorithm used at all if NNEDI3 doubling is enabled?
Yes, assuming you only have NNEDI3 'luma doubling' enabled, 'image upscaling' will be used to scale the chroma from video resolution to output resolution.

My third question is: how is NNEDI3 under chroma upscaling related to NNEDI3 chroma doubling? Since both consume a lot of resources, which one yields a better result if I can only choose one or the other? Sorry I am still technically challenged in this area.

'Chroma upscaling' is always used to convert 4:2:0 or 4:2:2 YCbCr (almost all videos are 4:2:0) to RGB at native video resolution. If you have a 1920x1080 4:2:0 YCbCr video, the chroma is encoded at a half resolution of 960x540. 'Chroma upscaling' is used to resize this 960x540 chroma to match the video resolution of 1920x1080.

"Chroma doubling" is a separate operation performed after "Chroma upscaling".

[madshi]

The new build dies on me - black screen with mpc-hc 1.7.3 crashing the moment I close it. I didn't change any settings (not using NNEDI), driver version still the 327.23

edit: to clarify: that's with both the finalDither and the newest finalDither2 build.
I sure care about "what's inside", not having a DX11 capable GPU leaves me out in the rain though.
With an hd 4850(ati) all I get is black screen and mpc crash on exit.I reseted madvr settings but no luck.No support because of old card or something else I need in mind?(Of course I haven't put error diffusion)

@Soukyuu got me,same thing.
The OpenCL kernel code changed, which means madVR has to recompile OpenCL. Give it a couple of seconds. Don't close mpc too quickly. Does that help? Or still black screen? Did this also occur with the previous dither test builds?

It should only be a problem when you use oppositColor with random dithering. And even then using oppositeColor is probably fine, but as others pointed out it might be a bad idea to change the 'good old' random dithering to something which may introduce new problems. I was just trying to point out possible new problems.
Ok. I'll stick to multiColor for random dithering for now.

Render queue is falling to 2-8 / 8 when the drops occur. Upload queue goes down to 6-8 / 8 at the same time. Without debanding, both queues stay at 7-8 / 8 all the time.
Does activating the trade for quality option "don't rerender frames when fade in/out is detected" help?

-------

@Everybody: Are you happy with the new default dithering settings (ordered dither with both colored / dynamic checked)?

[iSunrise]

@madshi:
The improvement ED11 dynamic brings over static is just mind-blowingly awesome. Even in 3bit mode it´s only barely visible at all. I think we not only reached our goal to provide a fairly transparent dithering algorithm, but we clearly surpassed it. I just cannot believe how good this looks. And it´s a 5bit difference, which is huge. This should leave a lot of headroom for further madVR processing without degrading the quality.

My expectations for a dynamic ED11 build are clearly surpassed with this.

Now I´m extremely interested how this looks in 1bit (if it´s not too much to ask). Would also be helpful for various display-specific tests.

[seiyafan]

Yes, assuming you only have NNEDI3 'luma doubling' enabled, 'image upscaling' will be used to scaling the chroma from video resolution to output resolution.



Thanks for your help, I still don't quite understand this one. If luma doubling is enabled, then chroma upscaling is still used but image upscaling will or will not? Because you said image upscaling will be used to scale chroma but there is already a chroma upscaling.

[madshi]

seiyafan, I already answered all your questions two pages ago.

[turbojet]

Same black screen issue as Soukyuu and Damien147 on GTX250. Happens with madVRfinal5 builds too, waited at least a minute for a picture.

[Damien147]

The OpenCL kernel code changed, which means madVR has to recompile OpenCL. Give it a couple of seconds. Don't close mpc too quickly. Does that help? Or still black screen? Did this also occur with the previous dither test builds?


Tried 2-3 different videos for 2-3 minutes and had the same result,also after ~30 seconds I lose sound(by skipping sound comes back).Expect those two builds I've tried adaptive4 build and had the same black screen.
[(gpu-z has opencl ticked just to confirm if it matters,catalyst 13.9(last supported)]

[Soukyuu]

The OpenCL kernel code changed, which means madVR has to recompile OpenCL. Give it a couple of seconds. Don't close mpc too quickly. Does that help? Or still black screen? Did this also occur with the previous dither test builds?I gave it a minute, no change. I didn't test the previous dither builds because I don't have a DX11 card...

edit: i tried the final 5 cylo- err, builds, but same thing. Latest working version for me is 87.4

[cyberbeing]

Thanks for your help, I still don't quite understand this one. If luma doubling is enabled, then chroma upscaling is still used but image upscaling will or will not? Because you said image upscaling will be used to scale chroma but there is already a chroma upscaling.

1920x1080 4:2:0 YCbCr video (Luma Resolution = 1920x1080, Chroma Resolution = 960x540)

->

'Chroma upscaling' upsamples the chroma from 4:2:0 to 4:4:4 RGB
1920x1080 4:4:4 RGB video (Luma Resolution = 1920x1080, Chroma Resolution = 1920x1080)

->

madVR converts back to YCbCr
1920x1080 4:4:4 YCbCr video (Luma Resolution = 1920x1080, Chroma Resolution = 1920x1080)

->

NNEDI3 Luma doubling, doubles luma resolution.
(Luma Resolution = 3840x2160)

->

'Image downscaling' performed on luma to match output resolution (let's assume 2560x1440 display)
(Luma Resolution = 2560x1440)

->

'Image upscaling' performed on chroma to match output resolution (let's assume 2560x1440 display).
(Chroma Resolution = 2560x1440)

->

Luma & Chroma re-combined
2560x1440 4:4:4 YCbCr video (Luma Resolution = 2560x1440, Chroma Resolution = 2560x1440)

->

madVR converts back to RGB
2560x1440 4:4:4 RGB video (Luma Resolution = 2560x1440, Chroma Resolution = 2560x1440)

[seiyafan]

seiyafan, I already answered all your questions two pages ago.

Ha, I really need to sharpen my reading skills.

Thanks a ton!

[seiyafan]

So it seems to me NNEDI3 works the best for doubling the resolution. Will it make 720 video look just as good on 1440 monitor compared with 1080 video (need one more downscale step)? My hunch is no because 1080 video still contains more information. Do you think so too?

[DarkSpace]

Thanks for the new build! I'm just curious (I'm always curious, in fact), did you change Error Diffusion to use linear light or not? You said that for 8 bit, it wouldn't matter because the distance between values is small enough, but since you now allow us to diffuse error down to 8-3 bit instead of only 8 bit, I thought I'd ask again.

[iSunrise]

So it seems to me NNEDI3 works the best for doubling the resolution. Will it make 720 video look just as good on 1440 monitor compared with 1080 video (need one more downscale step)? My hunch is no because 1080 video still contains more information. Do you think so too?
Both of this is correct.

Yes, because NNEDI3 works only with powers of 2 (double/quadruple and so forth).

Yes, because everything that comes in native higher resolution or bitrate will always have more image data compared to an already downscaled alternative if both were transfered directly from the master tape itself. With compressed content your milage may vary a lot, because you also upscale image artifacts / compression artifacts too, which the higher resolution (native) version won´t have.

However, NNEDI3 does an extremely impressive job of keeping the differences as small as possible and depending on the content, will work wonders if you have a really well-handled and well-compressed 720p source.

[madshi]

The improvement ED11 dynamic brings over static is just mind-blowingly awesome. Even in 3bit mode it´s only barely visible at all. I think we not only reached our goal to provide a fairly transparent dithering algorithm, but we clearly surpassed it. I just cannot believe how good this looks. And it´s a 5bit difference, which is huge. This should leave a lot of headroom for further madVR processing without degrading the quality.

My expectations for a dynamic ED11 build are clearly surpassed with this.
Good to hear! :)

Same black screen issue as Soukyuu and Damien147 on GTX250. Happens with madVRfinal5 builds too, waited at least a minute for a picture.
Tried 2-3 different videos for 2-3 minutes and had the same result,also after ~30 seconds I lose sound(by skipping sound comes back).Expect those two builds I've tried adaptive4 build and had the same black screen.
[(gpu-z has opencl ticked just to confirm if it matters,catalyst 13.9(last supported)]
I gave it a minute, no change. I didn't test the previous dither builds because I don't have a DX11 card...

edit: i tried the final 5 cylo- err, builds, but same thing. Latest working version for me is 87.4
Ok, was a bug with handling DirectCompute failure. Should be fixed in this build:

http://madshi.net/madVRfinalDither3.rar

Maybe I should stop calling these "final"... :D

[turbojet]

Works fine now, thanks.

[Damien147]

All good here too,thanks.

[Soukyuu]

Same here, works fine now.

A (probably already asked) question about dithering: when is it actually applied?
I just tried watching a few anime episodes with dithering _off_ and I don't really see a difference...

[iSunrise]

Same here, works fine now.

A (probably already asked) question about dithering: when is it actually applied?
I just tried watching a few anime episodes with dithering _off_ and I don't really see a difference...
Since madshi has now introduced lower native bit-selections for your display, just select a lower one from the devices - properties tab, until you can see the dithering pixels. Then you can select which one´s you prefer on your display and dial that up again to where it was.

Dithering is applied always, unless you select "None" in the dithering tab (and then you will actually see, how good the new dithering algorithms really are).

[Soukyuu]

Well the thing is, with my panel set to 8Bit, I can disable dithering and not see a difference. I remember madshi saying one should not disable dithering because it would show banding etc, but I'm not seeing it... or not looking at the right things.

Sure, if I go down to 5Bit and below, I start to see the dithering (and I prefer ordered dithering (color noise, static pattern) over old random dithering in that case).
What I'm trying to figure out is, why would I need to spend resources on dithering in the first place...

[Shiandow]

Sure, if I go down to 5Bit and below, I start to see the dithering (and I prefer ordered dithering (color noise, static pattern) over old random dithering in that case).
What I'm trying to figure out is, why would I need to spend resources on dithering in the first place...

No-one is forcing you to, but using ordered dithering shouldn't use a significant amount of resources and it does prevent banding and improves colour accuracy. You may want to make sure that your screen is actually capable of displaying more than 6bit and doesn't use dithering to increase this to 8bit, because that would also explain why you don't see much difference between 6bit and 8bit.

[Damien147]

I don't know if it's placebo but everything seems to run smoother:)

[cyberbeing]

@Everybody: Are you happy with the new default dithering settings (ordered dither with both colored / dynamic checked)?

Ack, I just checked again and realized ordered dither has very strong patterns on certain shades. I didn't notice this until seeing 'colored' in the latest build, but on close examination it also exists on luma when using 'mono'. Originally I thought I preferred ordered dither as mono / static, but after noticing the patterns with colored / dynamic, I think I'd settle on mono / dynamic instead. I'm torn now though... and unsure if ordered dither makes a good default over random dither.

Though I guess defaults don't really matter, as long as configuration options for dithering don't start disappearing at some later date. If you are not already doing so, please allow each dither algorithm choice to have separate saved/restored 'options' checkboxes instead of being a global setting.

[iSunrise]

madshi, another bug that may be related to the bug that James Freeman already reported, is that when you go into the madVR dithering settings and select "None" and apply it, then you close the madVR settings completely and open them up again, in the dithering settings there suddenly is no selection at all. So it seems madVR doesn´t remember the "None" dithering selection.

To be clear, every other dithering option works, only the "None" option doesn´t stick.

This is with madVRfinalDither3.

[Shiandow]

I don't know if it's placebo but everything seems to run smoother:)

I have the same impression, but maybe we shouldn't rule out the placebo effect too quickly. A plausible explanation would be that the lack of 'temporal' noise lessens the strain on the 'motion sensing' neurons which makes things seem smoother, if this is true then using a static algorithm would make things seem even smoother. But this is just speculation on my part.

[noee]

Well, something got "smoother", because now I can just barely run A4 with SmoothMotion On with 1080p 10-bit encodes. Before I could not, a drop fest. Not so with ED11 and SM. Without SM, like a champ.

[seiyafan]

Earlier I have been looking for benchmarks of MadVR, especially with the newer NNEDI3, I didn't find any. So I decide to make my own and share with this community. This is for a 1920x1080 video upscaled to 2560x1440 (monitor res)

Enjoy:

http://s28.postimg.org/tgq6gkq1n/madvr.png

[XMonarchY]

So decreasing dithering bits is there to improve performance but decrease quality, correct?

[cyberbeing]

So decreasing dithering bits is there to improve performance but decrease quality, correct?

No, that is not intended to be a performance vs quality setting. If you don't set it to your display's bitdepth, you'll just have an incorrect dithering result. It was originally added by madshi long ago if someone had a 6bit display which does not internally dither to 8bit. Upon adding unrealistic display bitdepths below 6bit, it's now more of a dithering test mode or similar, not something for general use.

[James Freeman]

@Everybody: Are you happy with the new default dithering settings (ordered dither with both colored / dynamic checked)?

I my opinion, Yes.
Its OD32, which to me looks as good as ED11.

I think, OD32 will be an excellent choice for madTPG.
Whether Mono/Color/Static/Dynamic, (probably Mono Dynamic will be best for greyscale).
Graeme should decide based on what would "look" better for the hardware sensors (should probably look good to our eyes too).


madshi,
Thank you for a your effort, I really appreciated and admire your work.
We are lucky to be on the edge of HTP video experience in this time (and be part of it).

Upon adding unrealistic display bitdepths below 6bit, it's now more of a dithering test mode or similar, not something for general use.
Yes, probably to save a lot of questions, and let people actually SEE the difference for themselves.
Although with the new dithering methods, 5-bit is quite enough to enjoy the movie completely. :D

[pie1394]

Well, something got "smoother", because now I can just barely run A4 with SmoothMotion On with 1080p 10-bit encodes. Before I could not, a drop fest. Not so with ED11 and SM. Without SM, like a champ.

I bought a new NB for my new job recently -- Sony Fit 11A, which the CPU is Pentium N3520 with redesigned out-of-ordered Atom CPU core * 4 + HD4000-downgraded GPU of 4 units.

Basically I don't expect it to be as powerful as Core i5-4200U(+HD4400). Yet its performance is indeed very impressive to me since its maxTDP is just 8w and SDP is 4.5w. It allows SmoothMotion on H.264 720p24, 1080p24 contents and half-frame-rated deinterlacing on 1080i60 ones. LavFilter is set to use QuickSync decoder. ASS is handled by XySubFilter. madVR Chroma upscaling is set to SoftCubic100, Image Up/Down-scaling is DXVA. If I don't remember it wrong, madshi ever mentioned that HD4000 GPU contains HW Lanczos4 scaler...

About the CPU part, it can handle the regular bit-rate of H.264 Hi10p 1080p contents -- maybe up to 10Mbps.

[Anima123]

Just for testing purpose I guess. It's harder for human eyes to distinguish delicate differences in 8 bit between various dithering algorithms Madshi used.