madVR - high quality video renderer (GPU assisted) [Archive] - Page 468

James Freeman

17th February 2014, 14:19

That isn't just a tad brighter, but rather multiple levels brighter. I'd question your special brightening method for causing this discrepancy. You must have brightened A1 & A4 more than A2 & A3 because of noise level differences. In untouched form, all these adaptive routines should have identical overall brightness with 1/100th of a level step accuracy.

EDIT:

You are correct.
There is one step error with the last zip file, I'll fix that right away!

Fixed: This post. (http://forum.doom9.org/showpost.php?p=1668855&postcount=23356)

Instead of changing the Input Levels, I just move the middle slider of the Output Levels closer to 255 to give that result.

Ver Greeneyes

17th February 2014, 15:07

NicolasRobidoux

17th February 2014, 16:07

Honestly, pixel art does not look good when you use video-style filters on it. It's just not how it was intended to look...
Yes: What I pointed to was a general purpose image resampling method... that does reasonably well with pixel art.
Really (and I believe madshi has pointed that out already, and you are basically reiterating here) pixel art calls for specialized methods.
This being said, if you are willing to use NNEDI on pixel art, you may as well give a try to a tuned Jinc.

James Freeman

17th February 2014, 16:08

Okay, link in my signature.

I still need to update the colored version.

Edit: 8-bit version re-encoded in "bgr0" color space (should be the same result as rgb24), and updated the colored versions.

Thank you very much.

iSunrise

17th February 2014, 17:33

@Ver Greeneyes

Can you please make an, 8-bit yuv444p video of Color & Grey, to compare the dithered 16-bit vs undithered 8-bit at the same frame?
True 8-bit video should not be dithered at all, right?
The purpose of this is to test the Gamma or any other deviations between the builds.

Thanks.
This can be confusing at first, but even 8bit needs to be dithered, because madVR upsamples at the very beginning and the dithering we are testing atm is the dithering that is applied at the very end, before madVR sends it to the display itself.

Of course it is very valid to test with 8bit sources though, because that´s what most of the current content comes in. That´s why I asked some pages ago if someone had access to some real world high-bitdepth footage (like TimeScapes), since we could (I know leeperry would be able to, his display is also well equipped, because he has a way higher dynamic range to begin with) more effectively see the differences, because our eyes are trained to perceive nature and compare it at the same time with reality, instead of artificial patterns.

Ver Greeneyes

17th February 2014, 18:15

This can be confusing at first, but even 8bit needs to be dithered, because madVR upsamples at the very beginning and the dithering we are testing atm is the dithering that is applied at the very end, before madVR sends it to the display itself.There shouldn't need to be any upsampling if you test this at 100% zoom on a monitor that's big enough (that's one reason I used 1920 for the width - I could make the height smaller for 1920x1080 monitors though, so you can open it in a maximized window instead of being forced to use full screen). The 8-bit video is encoded with 24-bit RGB, so there's no need for conversion, and the 16-bit video is encoded with YUV444, which also doesn't require chroma upscaling (but does require conversion into RGB). Of course, any other processing that madVR applies (such as a 3DLUT) is going to require dithering.

MistahBonzai

17th February 2014, 18:24

MistahBonzai,

Everything is fine, ED is changing.
The difference is so refined between the latest builds, that its almost invisible with the naked eye (without software intervention)..

Thanks..it's just that leeperry seems to be able to make subjective impressions quite easily. I have an accurately calibrated 10bit 40" display which serves as my desktop monitor, along with a practiced eye, and figured I could define differences by viewing actual content in a normal viewing environment. Apparently not..and lord knows I tried...

leeperry

17th February 2014, 18:32

I have an accurately calibrated 10bit 40" display which serves as my desktop monitor, along with a practiced eye, and figured I could define differences by viewing actual content in a normal viewing environment. Apparently not..and lord knows I tried...
When you compare NL6 and A4, don't you see the major decrease in noise? Are you running Reclock in 24/60Hz?

What's the calibrated contrast figure on that monitor? Because I guess things would get tough with IPS/TN and a thick antiglare pearly/grainy layer, possibly with PWM on top of it.

Also, are you wearing glasses? Are they made of organic glass? Mineral glass is the way to go when you need optical resolution, nothing matches their constringence AFAIK. Ages ago I bought some super light polycarbonate glasses but they only offered like 20 Abbe, I was sitting 3 meters away from a 2m large projection screen and it was so frigging blurry......I finally went for 59 Abbe mineral glass et voilà ))

iSunrise

17th February 2014, 19:15

There shouldn't need to be any upsampling if you test this at 100% zoom on a monitor that's big enough (that's one reason I used 1920 for the width - I could make the height smaller for 1920x1080 monitors though, so you can open it in a maximized window instead of being forced to use full screen). The 8-bit video is encoded with 24-bit RGB, so there's no need for conversion, and the 16-bit video is encoded with YUV444, which also doesn't require chroma upscaling (but does require conversion into RGB). Of course, any other processing that madVR applies (such as a 3DLUT) is going to require dithering.
My understanding is that madshi implemented the "don´t use dithering" option in the "trade quality for performance" tab, because otherwise, there would always be dithering, even if you wouldn´t need upsampling/scaling at all. Is that a wrong assumption from my side? Otherwise why would he implement the "don´t use dithering" option? Only for lower bit-depth sources?

Also, it would require to always select "8bit (or higher)" under the "devices - properties" tab.

When you compare NL6 and A4, don't you see the major decrease in noise? Are you running Reclock in 24/60Hz?
You mean in actually movie watching or with our level-reduced dithering comparisons? Because it depends where the noise is and what it is. Is it "hidden" encoding-noise (could mean bad calibration) or is it the camera´s source-noise and if it´s the camera source-noise, does that just get more visible or does it get less visible? Could also be artificially added noise, which got added in post, to make the image appear more lifelike (or an artistic choice, in the case of Michael Mann movies). That´s where the difficulties begin.

Do you have a sample where you see this noise, because I´m interested to compare it on my hardware-calibrated Eizo (that only has about 700:1 left after calibration to REC709).

Now that we have A4, I can see a lot more noise in general. And it think that´s a good thing, because that doesn´t seem to be the cause of the new dithering-algorithms at all, but it finally shows us a higher effective bit-depth of the original source, whereas the smearing/extreme noise of random dithering made that less visible. With random dithering, there was just so much noise all around, it added a whole layer of unnecessary thick noise, that even was colored noise, so that there was no breathing room for fine details at all. Now, with the newer algorithms, actual source noise has more room to breathe. And especially the blacks became a lot more refined and differentiation seems to have improved. At least for higher dynamic range display, this will probably make a world of a difference and I am sure that´s why some also see differences than others.

I´m still not entirely sure about the differences between the adaptive variants on my display, it takes so much concentration in actual movies/clips that it´s very time consuming and cannot be done at day times, because my eyes (all senses) work better at night time (more sensitive). All I can say is that, with A4, we seem to have arrived at a level that satisfies me a lot. Even though I´m not sure what 6233638 and cyberbeing think about it and I want to hear their opinions.

Shiandow

17th February 2014, 19:57

My understanding is that madshi implemented the "don´t use dithering" option in the "trade quality for performance" tab, because otherwise, there would always be dithering, even if you wouldn´t need upsampling/scaling at all. Is that a wrong assumption from my side? Otherwise why would he implement the "don´t use dithering" option? Only for lower bit-depth sources?

FWIW if all pixel values are whole numbers between 0 and 255 then even if you perform dithering this won't change the output. So in a sense not performing any dithering doesn't ever make the result better. Maybe we should check that the way error diffusion is currently implemented also doesn't change the output, but at the very least the limited builds should be 'safe' since they always output the value rounded down or rounded up which leaves whole numbers unchanged.

Ver Greeneyes

17th February 2014, 20:14

My understanding is that madshi implemented the "don´t use dithering" option in the "trade quality for performance" tab, because otherwise, there would always be dithering, even if you wouldn´t need upsampling/scaling at all. Is that a wrong assumption from my side? Otherwise why would he implement the "don´t use dithering" option? Only for lower bit-depth sources?

Also, it would require to always select "8bit (or higher)" under the "devices - properties" tab. I believe what madshi implemented was to only do random dithering on pixels that aren't an integer multiple of 1/255. But with error diffusion I don't think that's relevant, since such pixels wouldn't have any error to diffuse (and if they're diffusing error from another pixel then you can't disable dithering for them anyway).

"don't use dithering", on the other hand, completely disables dithering, regardless of what you have your display's bit depth set to. Note that other things can still introduce dithering though, such as the decoder.

iSunrise

17th February 2014, 20:24

I believe what madshi implemented was to only do random dithering on pixels that aren't an integer multiple of 1/255. But with error diffusion I don't think that's relevant, since such pixels wouldn't have any error to diffuse (and if they're diffusing error from another pixel then you can't disable dithering for them anyway).

"don't use dithering", on the other hand, completely disables dithering, regardless of what you have your display's bit depth set to. Note that other things can still introduce dithering though, such as the decoder.
I just saw that he originally spoke about 8-bit yuv444p and then he mentioned only "True 8-bit video should not be dithered at all, right?" in the second sentence, that confused the hell out of me for some reason. Should have read this more clearly.

Yes, the decoder may be another reason for dithering, however, LAV will pass-through the decoded result untouched (same that happens with the levels) to madVR if I remember correctly, so this thing is of the past for most people, which is actually another great accomplishment.

Ver Greeneyes

17th February 2014, 20:43

I just saw that he originally spoke about 8-bit yuv444p and then he mentioned only "True 8-bit video should not be dithered at all, right?" in the second sentence, that confused the hell out of me for some reason. Should have read this more clearly.Yeah, I made this mistake initially. YUV anything will still require conversion, but the 8-bit 'bgr0' encodes I made shouldn't.

Also a heads up to anyone using my test patterns: v2.1 is the same as before, but with the height reduced to 960 pixels to make getting a screenshot easier (now people with 1920x1080 monitors should be able to get a screenshot while running MPC-HC as a maximized window, for instance).

James Freeman

17th February 2014, 20:52

An Image(s) worth a thousand words:

Original (http://www.mediafire.com/convkey/3f23/mb4zhja4rtjdd45fg.jpg) (Untouched).

No Dithering (http://www.mediafire.com/convkey/bdc4/x2tl54os1gzrqoafg.jpg) (Low bitrate).

Random Dithering (http://www.mediafire.com/convkey/29b8/li091s04o02mlzrfg.jpg) (Low bitrate dithered with MadVR Random Dithering).

ED Adaptive 4 (http://www.mediafire.com/convkey/4094/w2s9d5tqzzraq3rfg.jpg) (Low bitrate dithered with MadVR Adaptive 4).

Here's how:

1. In MPC-HC turn Brightness to -100, Contrast to +80 (its 16-bit through MadVR).
This to make the image dark.

2. In you favorite editor:
Input Level, to about 100 (from white 255) or leave it untouched.
Output Level Center, raise towards 255 till you think is enough (this is the important step).
Play with these till the image looks close to the Original.

I wish MadVR Brightness would go lower than -100, so that I would not need to raise that contrast too.

The 8472

17th February 2014, 20:57

Honestly, pixel art does not look good when you use video-style filters on it. It's just not how it was intended to look.

There are specialized pixel art scalers anyway: http://en.wikipedia.org/wiki/Image_scaling#Pixel_art_scaling_algorithms

Ver Greeneyes

17th February 2014, 21:11

An Image(s) worth a thousand words: [...]That's a pretty nice comparison :)

leeperry

17th February 2014, 21:16

Do you have a sample where you see this noise, because I´m interested to compare it on my hardware-calibrated Eizo (that only has about 700:1 left after calibration to REC709).
Dunno, take a very clear HD movie such as Oblivion for instance, the sequence from 13'49 to 14'45 is one of my favorites when it comes to rolling ED's. Gosh, it looks so sharp and high contrast with ED4, too good :)

With NL6, it looks a hell more grainy and far less focused and even ED1 is a big downgrade when it comes to clarity and transparency.

I guess 700:1 is your bottleneck especially if there's a thick pearly anti-glare layer on your monitor. I'm always dubious when I see computer geeks raving about 1440p 24/27" monitors that use IPS panels and come with a very blurry anti-glare layer (http://www.overclockers.ru/images/lab/2013/03/07/1/61_kristaleffect_big.jpg)....they are not getting 1440p by a long shot IMO due to the blurriness.

Now that we have A4, I can see a lot more noise in general. And it think that´s a good thing, because that doesn´t seem to be the cause of the new dithering-algorithms at all, but it finally shows us a higher effective bit-depth of the original source, whereas the smearing/extreme noise of random dithering made that less visible.
Oh definitely, the A builds really get you to see the ugliness of your sources......64x NNEDI or else :scared:

James Freeman

17th February 2014, 21:28

That's a pretty nice comparison :)

Thanks.

I think it is a nice method to test future builds.
AND, I gave my method for free !!! ;)

madshi,
Any way to go lower than -100 on the Brightness?

iSunrise

17th February 2014, 22:04

That's a pretty nice comparison :)
Indeed, good job James Freeman.

When looking at this, I have at least two questions, though.

Since in James Freeman's original untouched screenshot, the black borders are as black as black gets (0) (I checked it), why is there dithering? Is that a rounding error?

Also, look at Bilbo´s jacket around the high of his right hand, why is there no dithering applied at all (I also checked it, this is definitely not black)? There are several places where the really dark black areas don´t get any dithering applied to them. Is that an error of the algorithm?

Can someone else instead of madshi explains this to me?

nevcairiel

17th February 2014, 22:07

Since in James Freeman's original untouched screenshot, the black borders are as black as black gets (0), why is there dithering? Is that a rounding error?

My guess is that this is an artifact from the brightness/contrast modification inside madVR.

It would be better to do any enhancements *after* madVR, so that they do not influence the dithering behaviour.

iSunrise

17th February 2014, 22:09

My guess is that this is an artifact from the brightness/contrast modification inside madVR.

It would be better to do any enhancements *after* madVR, so that they do not influence the dithering behaviour.
Yes, that´s what I thought about, too. But why would it show like random dots? Doesn´t brightness or contrast increase/decrease everything (every pixel) by a certain level instead of just single pixels? Kinda odd or?

nevcairiel

17th February 2014, 22:11

Yes, that´s what I thought about, too. But why would it show like random dots? Doesn´t brightness or contrast increase everything (every pixel) by a certain level instead of just single pixels? Kinda odd or?

Thats the error diffusion artifacts. It probably increased the value to something like 0.1 instead of 0, and the dithering accumulates the "error" and once it has enough, it'll draw a pixel with 1 instead of 0.

iSunrise

17th February 2014, 22:13

Thats the error diffusion artifacts. It probably increased the value to something like 0.1 instead of 0, and the dithering accumulates the "error" and once it has enough, it'll draw a pixel with 1 instead of 0.
Ok, that makes sense, thanks nevcairiel.

James Freeman

17th February 2014, 22:13

My guess is that this is an artifact from the brightness/contrast modification inside madVR.

Correct.
No error of the algorithm.

Its because of the raised Contrast, it clips the darkest and brightest shades.

That's why I asked if there is more than -100 on Brightness.
So the all the information will still be there (16-bit).

EDIT:
The resulting non black bars are because of the elevated Contrast.
Even value of +1 or -1 creates colorful blacks.

It would be better to do any enhancements *after* madVR, so that they do not influence the dithering behaviour.

That's will not do, that will defy the purpose of this experiment.
Just the contrary, we need to use MadVR's Brightness because its 16-bit (to preserve all the information), then let it dither the resulting image.

sneaker_ger

17th February 2014, 22:13

An Image(s) worth a thousand words

Are the black bars encoded as 100% black?

iSunrise

17th February 2014, 22:21

Are the black bars encoded as 100% black?
Yes, at least when you look at the original png, they are.

James Freeman

17th February 2014, 22:25

The answer to the non black borders is in my last post.

XMonarchY

17th February 2014, 22:37

Would enabling my i7 3770K HD4000 CPU graphics to work along with my GeForce GTX 770 improve madVR rendering performance? Would I need to get the Lucid Logix software to make it happen?

Also, LAV Video Decoder has can be set to use either random or ordered dithering. There is no way to disable it AFAIK. Does that mean that I also get dithering on top of error diffusion? Is that of benefit to me or not? If not, then is there a way to turn it off?

Finally, I set LAV Video to use nVidia CUVID acceleration for decoding. I know decoding is not the same as rendering, but since CUVID uses GPU, could it be reducing madVR rendering that also needs GPU power?

madshi

17th February 2014, 22:38

Any way to go lower than -100 on the Brightness?
The brightness algorithm in madVR practically changes the gamma value, as simple as that. The way the current formula works, more than -100 is not possible, I'd have to change the formula for that. But you can further darken the image by enabling gamma processing and selecting a higher gamma value, e.g. 2.60.

nevcairiel

17th February 2014, 22:38

Also, LAV Video Decoder has can be set to use either random or ordered dithering. There is no way to disable it AFAIK. Does that mean that I also get dithering on top of error diffusion? Is that of benefit to me or not? If not, then is there a way to turn it off?

Dithering in LAV Video is only used when it needs to be used, and if you use madVR and didn't disable any output formats in LAV, then it will never be needed.

turbojet

18th February 2014, 00:54

Would enabling my i7 3770K HD4000 CPU graphics to work along with my GeForce GTX 770 improve madVR rendering performance? Would I need to get the Lucid Logix software to make it happen?

I'm pretty sure madvr must render on the gpu used for display.

Finally, I set LAV Video to use nVidia CUVID acceleration for decoding. I know decoding is not the same as rendering, but since CUVID uses GPU, could it be reducing madVR rendering that also needs GPU power?

Absolutely. You could use software decoding or I think setting up a fake display on the igp and using quicksync decode also works.

cyberbeing

18th February 2014, 00:58

MistahBonzai

18th February 2014, 01:07

When you compare NL6 and A4, don't you see the major decrease in noise? Are you running Reclock in 24/60Hz?
.
.
.

Right up front I almost never watch actual content unless it is to judge image quality. I'm a confirmed 'pixel peeper'.

I utilize reclock with 23/24/25/30P for image calibration Otherwise, in the real world, I use AVIsynth plugins to image double (interframe2) or other smoothing techniques. yeah I know they destroy the image from a purest perspective but that's part of the challenge :sly:.

So far I have limited my comparisons to adaptive4 versus linearlight. I figured there should be a significant difference between them - no? Update; I have fallen back to the basic approach of capturing, cropping, zooming and eyeballing. It consists of controlled print-screen image captures of the gradient-perceptual-v2.mkv video off loaded to Paintshop pro. Croping a suitable sample of the lower right-hand corner and vieweing it zoomed 400%. The differences are readily apparent - no contest the ED capture created with adaptive4 wins hands down based on smoothness and constancy.

Agree with your corrective lens observations. My 'distance glasses' are adaptive photo grey. I don't wear corrective lenses while performing critical viewing cuz of the undesirable image shifting they introduce. I assume you do and they were created to minimize light diffraction and tinting. Or are they a special tool used to control the light environment associated with emissive light source image calibration?

In any-case very useful info cuz the cataract in my right eye ain't getting better :D.

I have misplaced (lost) my contrast meter - it was a pro model utilized to produce display service procedure for Kodac imaging systems (KIMS) - so no-longer able to measure post calibration peak light output or calculate contrast.

I have constructed my own 'white balance' calibration tool - a black shoe box partitioned lengthwise. Equipped with a 6500K light source and a photo grey card on the left and a view port on the right. I can attach ND filter(s) to balance the brightness of calibration source versus the display image when needed. Crude yes, but it works very well. Well back to pixel peeping ;)

The 8472

18th February 2014, 01:31

Finally, I set LAV Video to use nVidia CUVID acceleration for decoding. I know decoding is not the same as rendering, but since CUVID uses GPU, could it be reducing madVR rendering that also needs GPU power?

I think the video decoders use ASICs and not the shader cores, so they shouldn't affect compute performance itself. But they might consume some memory or PCIe bandwidth, especially with copyback.

huhn

18th February 2014, 01:43

madshi, I noticed today that madVR produces diagonal distortion with uncompressed 4096x2304 v210 in AVI saved from VirtualDub. Uncompressed v210 in AVI below 4K has no issue. 4096x2304 v210 from LAV Video also has no problem, so the issue is specifically when madVR opens the raw video directly. If you don't believe this is a trivial fix, I'll stick it up on your bug tracker.

there is a problem with 4096 16 bit png too i was wait for the final 87.x version to see if it's still there but it is most likely related

just try this png http://media.xiph.org/sintel/sintel-4k-png16/00000162.png i get a red screen
the sd 16 bit version works fine http://media.xiph.org/sintel/sintel-1k-png16/00000162.png

Would enabling my i7 3770K HD4000 CPU graphics to work along with my GeForce GTX 770 improve madVR rendering performance? Would I need to get the Lucid Logix software to make it happen?

i tried it out a year or longer ago of cause this doesn't work and yeah you need lucid logix software to to use it. and the software is not free anymore... ignore it. it mostly for tearing free playback but there is no real tearing problems with madvr.

Finally, I set LAV Video to use nVidia CUVID acceleration for decoding. I know decoding is not the same as rendering, but since CUVID uses GPU, could it be reducing madVR rendering that also needs GPU power?

why should it decreases render times it increases them very little. what you see is very easy CUVID is cuda based (at least the upload....) and cuda forces your gpu in the highest possible power state possible which is just a waste of power.

because the gpu is now "faster" render times are lower. render times are pretty unreliable anyway they depend on the gpu power states.

just use dxva it uses the same decoder in the gpu and doesn't force your gpu in the highest powerstate which is just better at least with newer card with dxva2 support vp4+.

didn't i tell you the same in avsforum where you stated CUVID looks a lot better than dxva or software decoding... ?

Mfusick

18th February 2014, 02:00

madVR does not use SLI. Actually simply enabling SLI has a huge negative performance hit, at least on my system.

For example at my 720p settings:
If I disable SLI I get 38ms rendering times, 84% GPU0 (1071Mhz), 0% GPU1 (324Mhz).
If I enable SLI I get 84ms rendering times, 79% GPU0 (1071Mhz), 30% GPU1 (836Mhz).

Oddly while in SLI mode the memory usage of both cards is identical but the memory controller for GPU1 is idle.

If I force a SLI rendering mode (AFR1 or AFR2) I get similar performance and horrible flickering (the second GPU's frames are black?). This flickering has happened with all versions of madVR I have ever used when forced into a SLI rendering mode.

I am using Titans and running drivers 327.23.

I have a 2560x1440 monitor, if you are using a lower resolution you might be able to get away with higher settings.

I needed to setup profiles but for <720p I use:
32 neuron NNEDI3 chroma 4:2:0 -> 4:4:4
128 neuron NNEDI3 luma doubling if scaling is >= 2.0
32 neuron NNEDI3 luma quadrupling if scaling is >= 4.0
Jinc3AR image upsampling (very small performance hit relative to lanczos so might as well) ;)
Catmul-Rom AR+LL image downscaling

For >= 720p I use:
Same as above except 64 neuron NNEDI3 luma doubling if scaling is >= 2.0

No trade quality for performance options. Smooth motion on when watching 24fps on a 60Hz display.

Is this really true you can't use dual GPU cards with MadVR ?

Asmodian

18th February 2014, 03:23

Well you can use madVR on SLI systems, it is just much slower than if you disable SLI. I updated my drivers again so I do not use NNEDI3 (I usually watch blurays and 1080p->1440p with NNEDI3 isn't much better) so I do not notice or care that rendering is slower. EDIT: I will probably switch back soon though, NNEDI3 chroma upsampling is nice all the time. :o

It is probably only an issue when using NNEDI3 or if you have SLI'ed two low end cards.

I would love to hear reports from other SLI and Crossfire users as to rendering times with and without SLI/Crossfire. Use NNEDI3 to put a real load on the GPU, otherwise the cards sit in a lower power state and ramp up their clock speeds more in SLI instead of taking longer to render.

Stereodude

18th February 2014, 04:35

I guess 700:1 is your bottleneck especially if there's a thick pearly anti-glare layer on your monitor. I'm always dubious when I see computer geeks raving about 1440p 24/27" monitors that use IPS panels and come with a very blurry anti-glare layer (http://www.overclockers.ru/images/lab/2013/03/07/1/61_kristaleffect_big.jpg)....they are not getting 1440p by a long shot IMO due to the blurriness.
Only if he doesn't use an oxygen free cable that's at least 24 gauge not longer than 42cm. The skin effect and jitter really bloom out of control once it gets longer than that. Oh yeah, you've got to use an isolation transformer too. If you don't it totally ruins the immersive quality.

MistahBonzai

18th February 2014, 04:51

GREG1292

18th February 2014, 05:12

A4 works for me and my 799.00 Mitsubishi HC7900. I am an end user and this build
seems to have it all. Just when I think I am happy the bar is raised even higher.
Since last week I have tested all the builds to date and put 36 hours on my projector
testing. Job well done!!!!!!!!!!!!!!

James Freeman

18th February 2014, 08:58

Only if he doesn't use an oxygen free cable that's at least 24 gauge not longer than 42cm. The skin effect and jitter really bloom out of control once it gets longer than that. Oh yeah, you've got to use an isolation transformer too. If you don't it totally ruins the immersive quality.

:D

leeperry,

That goes to show that you are way overboard with your eagle eye theory. ;)
You are probably the only one who can actually see super clearly the difference with your own eyes, and use terms like "pop", "looks like 3D", "looking through a dirty window", etc...
The difference is not THAT drastic between the builds (without enhancements).

I wonder if you would see the difference in a real blind test with the current builds without enhancements. :rolleyes:

Moreover,
If you are testing the builds with uncompressed (Original or Remux) BluRay content,
Dare I say, MadVR Dithering does absolutely nothing in terms of visible banding/error correction, so that so you can disable it and not see the difference.
This for the simple reason that the video is already heavily dithered from the original high-bit master to 16-235 bluray (about 7.8-bit).
Now, compressed "internet content" that destroys/blends this native dithering to a solid color, or anime, is a whole different story.

huhn

18th February 2014, 09:30

:D

leeperry,

That goes to show that you are way overboard with your eagle eye theory. ;)
You are probably the only one who can actually see super clearly the difference with your own eyes, and use terms like "pop", "looks like 3D", "looking through a dirty window", etc...
The difference is not THAT drastic between the builds (without enhancements).

I wonder if you would see the difference in a real blind test with the current builds without enhancements. :rolleyes:

Moreover,
If you are testing the builds with uncompressed (Original or Remux) BluRay content,
Dare I say, MadVR Dithering does absolutely nothing in terms of visible banding/error correction, so that so you can disable it and not see the difference.
This for the simple reason that the video is already heavily dithered from the original high-bit master to 16-235 bluray (about 7.8-bit).
Now, compressed "internet content" that destroys/blends this native dithering to a solid color, or anime, is a whole different story.

you should take this back...

madvr upscales the chroma in 16 bit so there are now 16 bit informations in the chroma then the 16-235 -> 0-255 correction is done in 16 it and this can create banding but now the bt 709 to srgb or 3d lut correction... this creates even more information in the 16 bit and now just clip it away ? and you really think this is lossless/invisible?

about leeperry i can't take him serious i mean good 1440 displays are 10 bit professional displays they are at the top... if not the best of the best...

ryrynz

18th February 2014, 09:30

iSunrise

18th February 2014, 09:36

Incredible, but how come there's dithering on the black bars? Can you add an untouched screenshot of Adaptive 4 please?
Read the last 2 pages please, already been answered.

James Freeman

18th February 2014, 10:00

you should take this back...

madvr upscales the chroma in 16 bit so there are now 16 bit informations in the chroma then the 16-235 -> 0-255
correction is done in 16 it and this can create banding but now the bt 709 to srgb or 3d lut correction...
this creates even more information in the 16 bit and now just clip it away ? and you really think this is lossless/invisible?

Don't get me wrong, I'm very thankful for madshi and MadVR.
That's why I specifically said Visible Difference & see the difference.

Yeah, I am completely aware of the 16-bit processing chain.
What you explain in your example is a smooth and undithered 16-235 video (a test pattern for example),
WILL have very visible errors when stretching it to 0-255 after all the the 16-bit processing (lut, gamma, etc...) or without.
BUT, native dithered to 16-235 content, will have almost no visible errors when stretched to 0-255.
See?

What I meant was "You can't make sand look different after adding more sand".
Hmm... maybe that's a bad analogy.

I'll try to explain it again,
By dithering again (to 0-255) the already randomly dithered 16-235 pixels, you are fixing a random noise "pixel by pixel" errors, which is almost imperceivable.

Another try,
Where do you encounter banding caused by bit conversion errors?
In a smooth gradient (Skies for example) un-dithered content, that does not match the bit depth of the display device you have (8-bit), be it 6-bit, 7.8-bit or 16-bit.

In the future madVR will be a very big thing when the native bit depth of BluRay (v2.0) will be 10/12 bit, for people who would still be using 8-bit panels.

Incredible, but how come there's dithering on the black bars? Can you add an untouched screenshot of Adaptive 4 please?

Backing up what I already written, you will not see the difference with or without dithering.
The Hobbit is already heavily dithered bluray (Its my reference bluray disc), as most properly converted blurays.

Yeah, I'll post some untouched images anyway (No Dithering, Random, Adaptive 4).

leeperry

18th February 2014, 10:06

I use AVIsynth plugins [..] I know they destroy the image
8bit processing a big no-no, it will increase both banding and noise-floor. You are throwing away quite a lot of useful data that mVR could put to good use.

The differences are readily apparent - no contest the ED capture created with adaptive4 wins hands down based on smoothness and constancy.
Yup hard to deny, even Stevie Wonder can see that ;)

I don't wear corrective lenses while performing critical viewing cuz of the undesirable image shifting they introduce. I assume you do and they were created to minimize light diffraction and tinting. Or are they a special tool used to control the light environment associated with emissive light source image calibration?
I either use 59 Abbe mineral glass lenses with a pretty sharp sprayed multi-coated anti-glare layer or better, Focus Dailies Aquacomfort contact lenses that provide the best sharpness but are hard to bear in a pitch black room.

I have misplaced (lost) my contrast meter[..] no-longer able to measure post calibration peak light output or calculate contrast.
Argyll can very easily measure the color temperature and native contrast using:
dispcal -P 1,1,5.5,5.5 -r -yl -v -Y p

Black level = 0.0386 cd/m^2
50% level = 30.18 cd/m^2
White level = 134.78 cd/m^2
Aprox. gamma = 2.26
Contrast ratio = 3488:1
White chromaticity coordinates 0.3104, 0.3265
White Correlated Color Temperature = 6651K, DE 2K to locus = 4.5
White Correlated Daylight Temperature = 6651K, DE 2K to locus = 0.1
White Visual Color Temperature = 6481K, DE 2K to locus = 4.3
White Visual Daylight Temperature = 6656K, DE 2K to locus = 0.1

I can attach ND filter(s) to balance the brightness of calibration source versus the display image when needed. Crude yes, but it works very well.
Every optical filter in the light path will temper with sharpness, even the TOTL multi-coated ones AFAIK.

A4 works for me and my 799.00 Mitsubishi HC7900. I am an end user and this build seems to have it all. Just when I think I am happy the bar is raised even higher.
Yaah, kinda makes you wonder if that's ever gonna end ^^

I wonder if you would see the difference in a real blind test with the current builds without enhancements.
Again, make it interesting and I'll happily prove you wrong.

BTW I see that you've literally become a screnshots scrutinizing self-made prime expert overnight, I'm impressed. Keep up the good work.

1440 displays are 10 bit professional displays they are at the top... if not the best of the best
Who gives a damn about 10bit if it's 600:1 IPS huh(n).

James Freeman

18th February 2014, 11:45

To back this argument:
By dithering again (to 0-255) the already randomly dithered 16-235 pixels, you are fixing a random noise "pixel by pixel" errors, which is almost imperceivable.

007 Bond:
No Dithering (http://www.mediafire.com/convkey/23bd/btkbge83oxx7nf0fg.jpg)

Frodo:
No Dithering (http://www.mediafire.com/convkey/5bce/tzq1y35yl13m93lfg.jpg)
Random Dithering (http://www.mediafire.com/convkey/af08/y7yymo65xyjo6p8fg.jpg)
Adaptive 4 (http://www.mediafire.com/convkey/282b/f66g8mzidfuqhv3fg.jpg)

Bilbo:
No Dithering (http://www.mediafire.com/convkey/2828/z0z45dc14zev1uufg.jpg)
Random Dithering (http://www.mediafire.com/convkey/2281/rhh2y3aoxqxjwwgfg.jpg)
Adaptive 4 (http://www.mediafire.com/convkey/e2c7/ziwlpf38hlztccpfg.jpg)

Moon:
No Dithering (http://www.mediafire.com/convkey/2767/uuz8jye725vx16dfg.jpg)
Random Dithering (http://www.mediafire.com/convkey/c714/7xil8p5lf4kl575fg.jpg)
Adaptive 4 (http://www.mediafire.com/convkey/c992/i6uqipsrp5wba91fg.jpg)

Bilbo (Clipped Whites to level 30):
No Dithering (http://www.mediafire.com/convkey/a408/4yuw417iabbbyqtfg.jpg)
Random Dithering (http://www.mediafire.com/convkey/dcca/15ski2xho71hhx8fg.jpg)
Adaptive 4 (http://www.mediafire.com/convkey/7ec0/ut46imb4tttk9irfg.jpg)

Bilbo (MadVR Brightness + Photoshop Treatment):
No Dithering (http://www.mediafire.com/convkey/f6d5/edkb281uutn8y2ffg.jpg)
Random Dithering (http://www.mediafire.com/convkey/7303/3jy8195910bzvpufg.jpg)
Adaptive 4 (http://www.mediafire.com/convkey/86b4/t07z95sikfd0975fg.jpg)

Moon (MadVR Brightness + Photoshop Treatment):
No Dithering (http://www.mediafire.com/convkey/afcd/pasnrhxf9ua0f4wfg.jpg)
Random Dithering (http://www.mediafire.com/convkey/a128/5c820g4i4bp9oc2fg.jpg)
Adaptive 4 (http://www.mediafire.com/convkey/7a08/r3a3yfskwge3cl6fg.jpg)

Hopefully you can see that dithering already dithered content will yield almost no visible difference (Moon & 007 shows it the best).
You can clearly see the heavy dithering that the original blurays have.
Note that this Moon shot is completely CGI (Not camera noise, unlike the other shots), so why the ugly dithering? Maybe its the AVC-1 compression (unlikely, because it does just the opposite)?

Even after enhancements (Bilbo Clipped Whites), there is (almost) no visible MadVR dithering, but the native colorful rgb dithering (or camera noise?) is becoming visible on the walls & fireplace.

The last two sets of images is with lowered brightness in MadVR to -100 & Gamma to 2.60 (no Contrast change = no clipped/dithered blacks), then lifted Output Level middles in Photoshop.
Here you can clearly see MadVR Dithering at work (Which is effing perfect I might add :D).

I Just wanted to say that whoever actually can discern the differences between the DC, NL, Adaptive, or any other ED test builds with real bluray content (leeperry ;)), I take my hat off for you.