madVR - high quality video renderer (GPU assisted)

[aufkrawall]

New de-ringing options looks great and should always be enabled (if performance isn't an issue). It's really noticeable with the lighthouse image, and does wonders.

Unfortunately, it looks kinda weird after upscaling the American Dad cartoon example, the leftovers are much more obvious than the ringing in general.

However, ofc thanks a lot for the new build.

[madshi]

APPLY is greyed out so you cant activate the new feature.

Im not the only one to report this now.
I've not seen anybody else reporting this yet.

Do you have one madVR installation or multiple? Have you updated *all* the files on all PCs involved?

Well, the application doesn’t require installation. You can just run the standalone exe file. Anyway, please see the screenshots in the below link:

http://www.mediafire.com/view/pd8924882kj99vt/Comparison.png

The application doesn’t resize so I am unable to show the complete table. But, I guess with the screenshots you will get a fair idea of the problem.
Yes, as expected. The application doesn't seem to understand that there are 2 different ways to create a linear lut. IIRC it can even vary depending on OS and GPU. In any case, madVR supports both and from where I'm standing there's nothing wrong with what madVR does.

Nevcairiel was willing to output XYZ directly to madVR, when I made that request. He also said that it wouldn’t be too much work on his side. Maybe you can speak to him.

For testing, you may download the trial version of JPEG2000 Video Decoder (http://www.3dtv.at/Downloads/JPEG2000VideoDecoder122_en.msi). More information here (http://www.3dtv.at/Products/Jpeg2000Decoder/Index_en.aspx).

By default it outputs XYZ (disguised as RGB). You can enable the XYZ to RGB conversion through the decoder settings. It’s output is limited to 8 bits only. Honestly, the ideal solution would be that LAV outputs XYZ to madVR.
Still waiting for RenderGuy2 to send me whatever he wanted to send me. I've put this on my to do list, but as I said, it'll be low priority.

By the way, the file name tag “deringing=full|half” would enable/disable “reduce dark halos around bright edges, too” option, right?
Yes.

The dehaloing is nice, but what are the chances of it being a little less soft/smudgy, I'd like to see it hopefully retain or "create" some kind of detail if possible. Can you add some grain and or
allow the algo to be a little more flexible in it's choices of color?
I suppose I could add grain. Color is not modified, only the luma channel is.

New anti-ringing algo looks really great, but sometime needs even more strength. Sample: AR (http://i1376.photobucket.com/albums/ah1/Ivan_Nemow/WWa_zpsn6xbsnlf.png) / noAR (http://i1376.photobucket.com/albums/ah1/Ivan_Nemow/WWb_zpsbfj6eu4n.png).
Well, the algo is tweaked for "normal" halos, not for extreme halos. I'm not sure if I could remove those. I don't plan any strength settings in the near future.

Unfortunately, it looks kinda weird after upscaling the American Dad cartoon example, the leftovers are much more obvious than the ringing in general.
Really? In the American Dad example, I didn't really notice any noticeable leftovers. It looks very clean to me, and noticeably better than without deringing. Can you show an upscaled American Dad screenshot with/without deringing which shows that deringing makes it look weird?

[regiregi22]

This was discussed AT LENGTH just a couple of pages ago.
I know, I have read those pages. But it has some cases where there was limitations I don't have. Like output devices that don't support extended ranges or dedicated HTPCs that don't care about messing up colors on desktop applications. There were shown quite some alternatives, each one with each drawbacks.

So that's why I am asking, I can assure you I have read them paying attention.

Thank you for your input anyway :-)

[aufkrawall]

Really? In the American Dad example, I didn't really notice any noticeable leftovers. It looks very clean to me, and noticeably better than without deringing. Can you show an upscaled American Dad screenshot with/without deringing which shows that deringing makes it look weird?
NNEDI3 32 chroma scaling, NNEDI3 64 doubling, super-xbr AB 25% quadrupling, bicubic 150 AR GL downscaling, SuperRes 4 GL AB 25%

off:
http://abload.de/thumb/1hds8l.png (http://abload.de/image.php?img=1hds8l.png)

on (recommended setting for Anime):
http://abload.de/thumb/27jsx9.png (http://abload.de/image.php?img=27jsx9.png)

[madshi]

I know, I have read those pages. But it has some cases where there was limitations I don't have. Like output devices that don't support extended ranges or dedicated HTPCs that don't care about messing up colors on desktop applications. There were shown quite some alternatives, each one with each drawbacks.

So that's why I am asking, I can assure you I have read them paying attention.
This is the most asked question ever, and really going on my nerves because of that. Here's a quote of my sum up, which I've posted ages ago:

http://forum.doom9.org/showpost.php?p=1766328&postcount=37690

I won't say any more about it.

NNEDI3 32 chroma scaling, NNEDI3 64 doubling, super-xbr AB 25% quadrupling, bicubic 150 AR GL downscaling, SuperRes 4 GL AB 25%
Oh well, yes there are some leftovers... :( I still prefer the deringed image, but I suppose it's a matter of taste/preferences...

[aufkrawall]

Oh well, yes there are some leftovers... :( I still prefer the deringed image, but I suppose it's a matter of taste/preferences...
I think the deringing filter works fine, but SuperRes introduces some of the ringing again in a nasty way.
Could it be that SuperRes doesn't compare the upscaled image with the source image which is already processed by deringing?

[madshi]

Nah, SuperRes properly compares the image after deringing and before upscaling, that's not it, unfortunately.

[James Freeman]

madshi, is there a way to ignore wrong ST.2086 metadata and use peak white was selected by user?
The official test video from Sony has completely useless metadata and madVR simply shows all white picture (0.5 nit peak white):

* The video plays perfectly fine on a Samsung HDR TV as reported by users.
It ignores the 2086 metadata completely, and just maps the bit values to luminance.

http://demo-uhd3d.com/fiche.php?cat=uhd&id=144

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 2mn 7s
Bit rate : 75.6 Mbps
Maximum bit rate : 123 Mbps
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 59.940 (60000/1001) fps
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.152
Stream size : 1.12 GiB (100%)
Encoded date : UTC 2016-02-03 07:59:49
Tagged date : UTC 2016-02-03 08:01:32
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primar : R: x=1.000000 y=1.000000, G: x=1.000000 y=1.000000, B: x=1.000000 y=1.000000, White point: x=1.000000 y=1.000000
Mastering display luminance : min: 0.1000 cd/m2, max: 0.5000 cd/m2


Let the user select 1200nit as peak white ignoring the wrong 0.5nit 2086 metadata.

[aufkrawall]

Nah, SuperRes properly compares the image after deringing and before upscaling, that's not it, unfortunately.

Too bad, your deringing filter seems to work wonders in general. :)
Especially with super-xbr, the difference in the cartoon example without SuperRes is enormous.

[har3inger]

Didn't Superres at 4 with AB introduce a bit of ringing anyway? Maybe try at superres 2 no AB or superres off to see if it's still bad. The sample aufkrawall posted seems noticeably worse than the one posted by madshi in his release post.

[aufkrawall]

SuperRes introduces ringing when it is in the source, especially with higher strength. You are right that it's not a problem with a strength of 1.

[huhn]

@aufkrawall

can you try super XBR without anti bloat?

the artefects kind of look like the same issue i have with super XBR AB with crisp edges.

[aufkrawall]

It seems to happen totally independent from the chosen upscaling algorithm, also with super-xbr or Jinc the ringing looks "aliased" with deringing + high SuperRes strength.

[YxP]

What a remarkable addition this deringing is. Ringing is my number one annoyance, much more so than mild banding or aliasing. Whatever leftovers you guys are talking about, they definitely are not as bad as ringing itself :P Great work!

[aufkrawall]

Did you see my comparison above? The ringing in some areas of the image gets more distinct than without deringing because SuperRes with high strength reintroduces it in an aliased shape. Which is of course not the fault the deringing filter, but an unfortunate coincidence.

[XMonarchY]

Why don't you try and find out?
If you can't judge the quality for yourself, then you might as well not bother, because you won't see a difference then either. :)

I don't see much difference, but I also don't see that much of a difference between most of madVR settings. The image quality improvement that I obviously see only comes when all high-quality settings are selected and utilized. Hell, we both know that most image/chrome upscaling/downscaling method comparisons shown here require zooming in on particular specific parts of images because its very hard, if not impossible, to see the difference at native resolution / "with a naked eye" so-to-speak.

I know there was a general consensus that Scale in Linear Light provided the best results for Catmull-Rom Image Downscaling method, but I do not know if the same applies to the SSIM 2D 100% Image Downscaling method. What is the general consensus - should I use Scale in Linear Light for SSIM 2D 100% downscaling.

[YxP]

Did you see my comparison above? The ringing in some areas of the image gets more distinct than without deringing because SuperRes with high strength reintroduces it in an aliased shape. Which is of course not the fault the deringing filter, but an unfortunate coincidence.

Yes I did see it and you are correct of course. I'm just so impressed at the moment that maybe I need some time to start paying attention to the leftovers, as you call them. Personally I only use SR@1 or 2 because more will make my GPU fan go nuts.

[omarank]

Yes, as expected. The application doesn't seem to understand that there are 2 different ways to create a linear lut. IIRC it can even vary depending on OS and GPU. In any case, madVR supports both and from where I'm standing there's nothing wrong with what madVR does.
Ok. I have this basic understanding that all output from the OS is passed through the GPU LUT. If the LUT is linearized to unity, then all video data will be multiplied by 1 and the output will be unchanged by the LUT. In any other case, there will be floating point/ high bit depth values which the GPU will have to dither to the output bit depth.

Now it is interesting to learn that LUT can be set in two different ways and still remain linear. Could you please explain a bit how that works, if you don’t mind?


Still waiting for RenderGuy2 to send me whatever he wanted to send me. I've put this on my to do list, but as I said, it'll be low priority.
Sure, thanks!

While we are at it, I will share some thoughts:

1. 3D DCP video is a frame sequential 48fps stream with alternate left eye and right eye frames for 24 fps content. If LAV video decoder just flags and sends the stereo frames in the same way as it does for MVC content, no special handling of 3D would be required in madVR (I believe).

2. Currently, the black bar detection algorithm doesn’t work for RGB content (and also YUV content, IIRC), so it wouldn’t work for XYZ as well without extra work on your side. However, you can use the “Y” of XYZ for black bar detection as you do for YCbCr content because “Y” in XYZ and YCbCr are very similar as both have lightness information.

[aufkrawall]

I know there was a general consensus that Scale in Linear Light provided the best results for Catmull-Rom Image Downscaling method, but I do not know if the same applies to the SSIM 2D 100% Image Downscaling method. What is the general consensus - should I use Scale in Linear Light for SSIM 2D 100% downscaling.
I don't think there is a difference in "quality". LL downscaling should maintain the original brightness of the unscaled image while gamma light is darker. So imho it makes sense to use LL when there is just downscaling happening (imho it doesn't even matter which downscaling algorithm is used, LL is always brighter and GL a bit less aliased).

However, SuperRes also makes the image even brighter (in GL more than in LL, that's a little confusing since it's the opposite way around compared to image scaling) and must be fed with image in GL when SuperRes itself also works in GL to avoid aliasing introduction (and fed with LL when it works in LL).
So, it should be best to define script profiles to achieve LL downscaling when there is no upscaling with SuperRes and to use GL downscaling when SuperRes in GL is used (it should be used in GL since probably most content is that way).

[AngelGraves13]

SuperRes at 1 is the best option in my opinion. Anything more than 1 starts causing its own issues with the image. 4 usually looks bad unless you have a super clean image, and even then I'd say 3 should be the limit on SuperRes.

[aufkrawall]

Really depends on the source and target device.
I hardly see any artifacts with 1080p -> WQHD Jinc AR SL + SR 4, except with broken sources or small or bad fonts (which would also look pixelated on a 24" 1080p display with 1080p source).

[kalston]

Can confirm the bug where image doubling triggers when reducing the window (my doubling is set to "only if scaling factor is 2.0 or higher").

[cork_OS]

Can confirm the bug where image doubling triggers when reducing the window (my doubling is set to "only if scaling factor is 2.0 or higher").
Same here.

[har3inger]

SuperRes at 1 is the best option in my opinion. Anything more than 1 starts causing its own issues with the image. 4 usually looks bad unless you have a super clean image, and even then I'd say 3 should be the limit on SuperRes.

Have you tried SR 2? Don't use any of the checkboxes on SR, since those introduce artifacts.

I find 1 is subtle and almost universally good, but 2 is often better unless image is covered in compression artifacts. 3 is the same thing as 2, but with greater strength per pass (thus stronger effect, but also more haloing without more detail resolution) and should only be reserved for good quality sources of 720p or higher resolution. However, it's great for 720p->1080p. 4 starts costing an arm and a leg, so I don't run it and cannot comment on its qualities.

[70MM]

I've not seen anybody else reporting this yet.

Do you have one madVR installation or multiple? Have you updated *all* the files on all PCs involved?


?

Sorry I thought someone reported the same problem of the new anti ring feature greyed oy for them also.. But when I went back to check I see they are talking about something else:o

My installer updated madvr so I really don't know how he did it sorry. Maybe my installation for the latest version hasn't been installed correctly.

Can someone give me the correct procedure for installing new updates please?

You mention is the installation multiple/updated *all* files, etc etc but Im not sure about how its done correctly. Can someone help with the correct procedure please so I can pass this onto the installer?

Thanks in advance...

[CarlosCaco]

Sorry I thought someone reported the same problem of the new anti ring feature greyed oy for them also.. But when I went back to check I see they are talking about something else:o

My installer updated madvr so I really don't know how he did it sorry. Maybe my installation for the latest version hasn't been installed correctly.

Can someone give me the correct procedure for installing new updates please?

You mention is the installation multiple/updated *all* files, etc etc but Im not sure about how its done correctly. Can someone help with the correct procedure please so I can pass this onto the installer?

Thanks in advance...

As you use JRIVER you need to find were JRIVER instaled madvr folder...
When you find download the rar from first page of this thread and extract all files to this folder...

[Manni]

Madshi, thanks for the reply re my crash report.
I have no idea why I have the issue and not others. It could be a combo of settings.
I'll try your suggestion, I'll also try to reset the settings to default and see if it makes a difference.

Re your question about why no HDR content in 10000nits, it's because there is no monitor able to grade HDR content in 10000nits. The max today is the Dolby Vision Pulsar, which does 4000nits in 1080p. Their 4K model can't do 4000nits. The other often used grading monitor for HDR is the Sony which does around 1000-1200nits.

[jkauff]

As you use JRIVER you need to find were JRIVER instaled madvr folder...
When you find download the rar from first page of this thread and extract all files to this folder...
JRiver installed madVR here for me:

c:\Users\Jkauff\AppData\Roaming\J River\Media Center 21\Plugins\madvr\

[SamuriHL]

Another positive vote for the new deringing. Very impressive results I must say! I only had limited time to check it out, but, I tried it on some Family Guy episodes and I'm quite impressed. Nicely done!

[ryrynz]

Another positive vote for the new deringing. Very impressive results I must say! I only had limited time to check it out, but, I tried it on some Family Guy episodes and I'm quite impressed. Nicely done!

Yeah I'm using it on Naruto Shippuden ATM, and I'm happy with the results. Dehalo Alpha was one filter I used a little quite some years back, in the end I think it destroyed the image too much so I stopped using it.

Next up, deblocking! :D

[Warner306]

I tried some live action video (720p -> 1080p). I'm not sure if I like deringing or not. It kind of kills the look of image sharpening. I'm only interested if it can be left on for all content, as I can't see myself selectively enabling it for certain content. Debanding manages to work this way, so I was hoping deringing would as well.

[iSunrise]

madVR v0.90.18 released

http://madshi.net/madVR.zip

[code]* added new deringing algorithm

light house:
no deringing (http://madVR.com/doom9/dering/lightHouseNoDering.png) - - | - - DeHalo_alpha (http://madVR.com/doom9/dering/lightHouseDeHaloAlpha.png) - - | - - madVR (http://madVR.com/doom9/dering/lightHouseMadVR.png)
:eek::eek::eek::eek:

OMG, is this for real? The difference is unbelievable!

All the details still intact, while it only removes the ringing COMPLETELY.

Wow, I am speechless. This one feature alone is probably the best proof that madVR is so much better than anything else out in the market for video playback rendering by far.

Great work madshi!

[cork_OS]

Next up, deblocking! :D
Antialiasing! :D

[70MM]

As you use JRIVER you need to find were JRIVER instaled madvr folder...
When you find download the rar from first page of this thread and extract all files to this folder...

Ok so doing it this way I will retain the latest version of madvr wont I?

I don't want to run with the version of madvr that JR uses as all the sharpening features plus many others are deleted from their version. At the moment Im not using the madvr version recommended by JR.

[CarlosCaco]

Ok so doing it this way I will retain the latest version of madvr wont I?

I don't want to run with the version of madvr that JR uses as all the sharpening features plus many others are deleted from their version. At the moment Im not using the madvr version recommended by JR.

I think so... But i don t know exactly because i don t use JRIVER, used a couple of times only...

[70MM]

Guys Ive just checked with my installer and he says we are installing madvr correctly in conjunction with JRiver. He said the madVR install he did was using the Program Files/madVR folder, not the one in the user folder so he updated the folder under users and will see how it goes....

He made this video showing how the APPLY is greyed out. Can you check and see what we are doing wrong please?
https://www.youtube.com/watch?v=TGHoKtttvcQ&feature=youtu.be

[huhn]

I tried some live action video (720p -> 1080p). I'm not sure if I like deringing or not. It kind of kills the look of image sharpening. I'm only interested if it can be left on for all content, as I can't see myself selectively enabling it for certain content. Debanding manages to work this way, so I was hoping deringing would as well.

why don't you post an example?

[SamuriHL]

Ok so doing it this way I will retain the latest version of madvr wont I?

I don't want to run with the version of madvr that JR uses as all the sharpening features plus many others are deleted from their version. At the moment Im not using the madvr version recommended by JR.

I think so... But i don t know exactly because i don t use JRIVER, used a couple of times only...

I do it all the time. Eventually JRiver will update madvr and lav filters, but, I routinely replace the ones in the appdata directory with new versions and they "stick" until a new version is released by JRiver to update them. Works fine to do it this way.

[XMonarchY]

Where's the option for the new Anti-Ringing algorithm? Is it better than the old one? I can't find it anywhere in the settings...

[fhoech]

Now it is interesting to learn that LUT can be set in two different ways and still remain linear. Could you please explain a bit how that works, if you don’t mind?
Under Windows, there's SetDeviceGammaRamp for the desktop (which always takes a 3x256 entries table with 16-bit precision integers) and equivalent functionality for D3D fullscreen.

Btw, don't use the prehistoric X-Rite (or rather LOGO/GretagMacbeth) Calibration Tester to test video card gamma ramp linearity - it doesn't work right and from what I know, never did (you can even see it in your screenshot, the end value for a linear ramp should be 65535, but LUT tester thinks it should be 65280, which probably means the developers made the mistake that they assumed each step above zero increases by 256 instead of the correct 257). There's other tools to check video card gamma ramp linearity (e.g. either Argyll's dispcal -V when used with a linear cal file which will show the discrepancy if any in percent, or DisplayCAL's curve viewer which will show "linear" in the status area if you hover the graph of a linear gamma ramp when "show calibration from video card" is checked).

[Asmodian]

Where's the option for the new Anti-Ringing algorithm? Is it better than the old one? I can't find it anywhere in the settings...

It is under processing -> artifact removal. On the same page as debanding. :)

[Ver Greeneyes]

Under Windows, there's SetDeviceGammaRamp for the desktop (which always takes a 3x256 entries table with 16-bit precision integers) and equivalent functionality for D3D fullscreen.

But I think what madshi was talking about was how to calculate the values. madVR uses 257 * x (with x from 0 to 255) to generate 16-bit values that go from 0 to 65535, whereas the program assumes that a linear ramp will use 256 * x (generating 16-bit values from 0 to 65280). Personally I think madVR's way makes more sense - it's correctly rounded, and the high bits are the same regardless.

Incidentally, I found it interesting that such a simple algorithm produces correct rounding: (x / 255.0) * 65535.0 reduces to 257.0 * x since 65535 / 255 = 257. I think it's easier to see why this must be true if you think of it as 256 * x + 1 * x, or 0x100 * x + 0x1 * x in hexadecimal. Since the maximum value of x is 0xff, the maximum value is 0x100 * 0xff + 0xff = 0xffff - there's no overlap between the two. The same goes for 8-bit to 24-bit: 0x10000 * x + 0x100 * x + 0x1 * x produces no overlap for values of x between 0 and 0xff, and the maximum value is 0xffffff - therefore 2^24 - 1 must be divisible by 2^8 - 1 - and indeed it is: 16777215 / 255 = 65793. That's probably not the most mathematically rigorous, but I found it enlightening. But I digress :)

[har3inger]

Where's the option for the new Anti-Ringing algorithm? Is it better than the old one? I can't find it anywhere in the settings...

New setting works different from the upscale/downscale antiring filter.

Dering removes source ringing before any sizing is done. Antiring removes ringing that is introduced by most scaling algorithms but shouldn't affect source ringing at all.

[Stereodude]

Can I ask for further improvements in the 6:4 film mode used for p60 video? I don't know if you use it all that often which is why it's in the state it's in or if it's extremely hard to detect the pattern accurately, but it's not very polished from my use of it. It's probably the least polished feature I've found in madVR, by far. It sometimes takes several seconds to detect a pattern change resulting in the slow-mo playback look, it sometimes seems to displays frames out of order, or it flashes a random frame it shouldn't after a pattern change. It feels like an experimental / alpha feature. The 3:2 mode for i60 content works much, much, much, much better.

[Uoppi]

I don't think there is a difference in "quality". LL downscaling should maintain the original brightness of the unscaled image while gamma light is darker. So imho it makes sense to use LL when there is just downscaling happening (imho it doesn't even matter which downscaling algorithm is used, LL is always brighter and GL a bit less aliased).

However, SuperRes also makes the image even brighter (in GL more than in LL, that's a little confusing since it's the opposite way around compared to image scaling) and must be fed with image in GL when SuperRes itself also works in GL to avoid aliasing introduction (and fed with LL when it works in LL).
So, it should be best to define script profiles to achieve LL downscaling when there is no upscaling with SuperRes and to use GL downscaling when SuperRes in GL is used (it should be used in GL since probably most content is that way).

1. Does this also apply when using SuperRes only for chroma?

2. Just to make sure I understood right: when downscaling UHD -> 1080p (no SuperRes), it would be best to UNtick the linear light option?

3. And in even simpler terms: when no SuperRes = UNtick linear light, when SuperRes involved = tick linear light box?

[Warner306]

why don't you post an example?

I tried to quickly capture some images and could not find any good examples. I'll leave the AR filter on for a while to see if anything jumps out as offensive. It seemed to flatten the edges of objects but I can't see it in still frames.

[aufkrawall]

Uoppi, you got it exactly the wrong way around. :o

Just image downscaling: downscale in LL to preserve original brightness (LL checkbox for downscaling ticked)
When there is downscaling because of image doubling and SuperRes is used: downscale in GL (LL checkbox for downscaling unticked) and use SuperRes in GL (LL checkbox for SuperRes unticked as well)

However, the effect for SuperRes of LL/GL used for image downscaling after image doubling probably is very small in most cases. It's much more important how the image of the video (untouched by madVR) has been downscaled before.
We can't say this for sure and can only assume that downscaling in GL by content creators/providers is most common. The results with SuperRes seem to confirm this assumption, but I don't think anyone tested lots of material with this.

[Asmodian]

1. Does this also apply when using SuperRes only for chroma?

2. Just to make sure I understood right: when downscaling UHD -> 1080p (no SuperRes), it would be best to UNtick the linear light option?

3. And in even simpler terms: when no SuperRes = UNtick linear light, when SuperRes involved = tick linear light box?

1. Ignore all gamma/linear talk for chroma, chroma does not have gamma and linear light, those are luma concepts.

2. It is the other way around, downscale in linear light if downscaling the source directly but downscale in gamma light when downscaling after image doubling.

3. Again, it is the other way around. no SuperRes = tick linear light, when SuperRes involved (ignoring chroma) = UNtick linear light box.

[QBhd]

madshi,

It seems mixed upscaling (target 1024x768) is broken again... First pic is latest madVR (no settings changed), second pic is madVR v0.90.17

http://i.imgur.com/ESTSiOQ.png

http://i.imgur.com/OgHHOi2.png

I really wanted to try the new De-Ringing...

QB

[fhoech]

Personally I think madVR's way makes more sense

Not only that, it's the only correct way - a linear 16-bit ramp with the goal to not alter the input in any way has to start at 0 and end at 65535, not 65280, so the CalibrationTester is simply wrong :-)

Btw, I think of the math in a slightly different way: The increment step is 65535 / <number of entries per channel - 1>, i.e. 65535 / (256 - 1) or 65535 / 255.
Why subtract 1 from the number of entries per channel? Because the first entry is zero, and so we have (256 - 1) = 255 entries left to increment up to the maximum channel value of 65535. Sorry for the OT :-)