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

6233638

10th October 2013, 19:44

Ouch. I suppose Jinc3AR doesn't work for image upscaling? (Something cheap for chroma.)I was actually just doing some similar testing last night; not specifically about GPU load, but power consumption (which is related to GPU load) when I noticed that it seemed excessively high with 720p60 playback.
Luma Chroma Power
Jinc 3 AR Jinc 3 AR 270W
Jinc 3 AR Bicubic 75 AR 256W
Jinc 3 Bicubic 75 AR 222W
Jinc 3 Bicubic 75 221W
Lanczos 3 AR Bicubic 75 AR 150W

Idle 125W
I've said in the past that there's very little benefit to using Jinc 3 AR for chroma, and if your display processes in less than 4:4:4 it's absolutely pointless, but considering it's eating ~15W for little-to-no practical benefit, I would now recommend everyone use Bicubic 75 AR, unless anyone can produce samples where Jinc 3 AR chroma is better.

And while there are certainly examples where Jinc 3 AR is better than Lanczos 3 AR for luma scaling, it's less apparent when starting with an HD source, and I wonder if it's worth the additional 70-120W power consumption.

When scaling DVDs, the results are quite different. There's only 10W between Jinc 3 AR luma, and anything else.
I have suggested it before, but I really think we could do with resolution specific scaling options, though I know that would require a lot of UI changes.

I also found that hardware accelerated decoding (DXVA2 copy-back) was a bit hit-and-miss. When the GPU was being taxed and in a high power state, it saved me 10W, so the top number dropped to 260W. But when playing back DVDs, power consumption varied a lot, fluctuating between 145-170W. With CPU decoding, it was fixed around 150-155W. I should probably have checked DXVA2 Native, which I'm sure would have produced lower numbers, but I would never use that for quality reasons.
And the "trade quality for performance" options may help for low power GPUs, but barely made a dent in power consumption.

I must say though, if Intel brings the power consumption improvements they made with the mobile Haswell chips over to the desktop next year, that alone is probably going to be enough for me to upgrade. 125W at idle is rather high these days.

I m thinking about getting the AMD 7950. Will this card give me perfect playback with madVR?Aren't you better off with one of the new GPUs? I know they're mostly "rebranded" but there are often smaller changes that people overlook. (possibly upgraded hardware decoders, for example)

What is THE best PQ algorithm to use for 1080p when sending out 1080p to my projector? (I ll stay with 1080p outputting for now and let my vw1000 do the 4k upscaling)The reviewer David Mackenzie posted here a while back that Jinc 3 AR looked a lot better than Sony's "digital reality creation" scaling which incorporates image sharpening in its upscaling algorithms. You might be better outputting 4K and scaling in madVR.

Asmodian

10th October 2013, 21:03

Ouch. I suppose Jinc3AR doesn't work for image upscaling? (Something cheap for chroma.)

Well Jin3AR might work for upscaling but I am actually downscaling the image (2160p->1440p), hence my confusion. ;)

Zachs

10th October 2013, 23:39

Works fine here with both LAV Video Decoder and the internal madVR video decoder. Which decoder are you testing with? Probably a bug with that decoder.

I'm running MPC-HC x86 v1.7.0 from mpc-hc.org.
It has LAV Video Decoder / Audio and Splitter built-in, *not* using any external filters.
Only setting I changed was to make it use MadVR as renderer. MadVR settings untouched. This is on a newly installed Win7 x64.

Switching between the different renderers, only MadVR exhibits this odd behaviour -- the whole green colour plane was shifted down vertically by some pixels. Doesn't happen with all sources, just some.

EDIT: The plane shift results in thick green line appearing at the top of the video.
I tested the same config on a different computer (different hardware but still NVidia GPU) but I can't replicate the problem.

mzso

11th October 2013, 00:08

I get a crash with potplayer when I try to make a bookmark, if the video is zoomed enough so that the height is at least as tall as the screen. If I change to EVR there's no crash. Can madVR be somehow responsible for the crash?
(Contacting the potplayer dev didn't lead to anything useful...)

StephaneM

11th October 2013, 01:01

I'm not sure why you would have problems with bilinear but not with SoftCubic. Usually it's the other way round. Bilinear is ultra-cheap, SoftCubic consumes quite a bit more resources. So something is weird here.Yep indeed, after further testing it does this only on a specific content (here is a sample of this content (https://skydrive.live.com/redir?resid=801E6E4E512A1A8F!408&authkey=!AEhckCtgUnZeiik)), and the more I see it the more I think it's a bug related to this particular content regarding deinterlacing (It looks a lot like when you have a bad packet on the DVB stream and the decoder is really confused and doesn't recover)

Could it be possible that you changed the scaling settings to bilinear in the wrong section? E.g. you changed it for upscaling instead of downscaling or something like that? A stupid question
I triple checked and it's when I change the downscaling to bilinear or nearest neighbor.

But it isn't a big deal really.

Soukyuu

11th October 2013, 01:19

Well Jin3AR might work for upscaling but I am actually downscaling the image (2160p->1440p), hence my confusion. ;)For some reason, downscaling eats a lot more resources than upscaling. I remember not having any problems upscaling DVD to 1080p but downscaling 1080p to DVD size totally killed my 8600m GT back then (EVR renderer). Maybe it's the same thing here.

6233638

11th October 2013, 02:20

For some reason, downscaling eats a lot more resources than upscaling. I remember not having any problems upscaling DVD to 1080p but downscaling 1080p to DVD size totally killed my 8600m GT back then (EVR renderer). Maybe it's the same thing here.Linear light downscaling is very demanding, and it only looks good when you are using the anti-ringing filter as well.

Try downscaling using catmull-rom without those options, and it should drastically reduce the GPU load.

James Freeman

11th October 2013, 05:11

I have been trying for weeks now to makes MadVR & 3DLUT to look anything simmilar to MPC-HC native Color Management.

I have registered to AVSForum to participate in the "MadVR - ArgyllCMS" thread and tried EVERYTHING (believe me).

Still... no matter what settings or teaks I use, nothing looks or behaves like MPC-HC native Color Management (It loads itself from Windows Profile ICM).

I have given-up on 3dlut with ArgyllCMS (collink), because no matter what setting I try, I can't use my calibrated gamma from my .ICM profile.
I am forced to use BT.1886 setting (which I don't like), otherwise the gamma curve is off.

I found a simple solution for my Wide Gammut monitor:
Read the Primaries with HCFR and put them into the yCMS tab in MadVR.
This did the trick perfectly (correcting the Colors & letting windows handle the Gamma).
One step closer to what MPC-HC does natively.

But, I have encountered a problem.

Loading a 3DLUT into Madvr (yCMS) fixes the colors, but something goes wrong with the contrast.

Moreover, playing with the Contrast slider in Madvr disables the 3DLUT altogether.

@Madshi
I have asked for it already in the past,
Is there any way to implement a simple (automatic) Color Management code like in MPC?

I really wish it would be easy and accurate as just "turning a button on" like in MPC.
Without the need for Conversions, Compilations, Command prompts, Multiple Software (not to mention weeks of tweaking).
Simple does it.
Something like "Use OS Profile" in the Calibration tab will be nice.

http://i557.photobucket.com/albums/ss18/ilya-v/Other/4-ColorClippingmp4_snapshot_0129_20131011_064130_zpsff8fd3c2.jpg~original

ryrynz

11th October 2013, 06:45

The blocks or Miley?:)

It's almost a tie. Almost.

turbojet

11th October 2013, 07:24

I'm surprised palladia looks that bad, usually one of the better looking channels here. Is that during a very complex scene or is the significant amount of red causing a blocky frame? NBC is notorious for the latter and AMC used to be.

If pics of the red block issue would help madshi I could keep a look out for it.

THX-UltraII

11th October 2013, 07:34

The reviewer David Mackenzie posted here a while back that Jinc 3 AR looked a lot better than Sony's "digital reality creation" scaling which incorporates image sharpening in its upscaling algorithms. You might be better outputting 4K and scaling in madVR.

This may sound interesting to do some testing with for me. But first I would like to know something else. Let s say I m just going to put out 1080p from my HTPC with madVR. If I let ANY algorithm do it s work in madVR won t this cause any serious artifact? I mean, first madVR will do something with the picture because of it s algorithm and after this my Sony VW1000 projector does the 2K=>4K upscaling with Reality Creation. This sounds bad to me but maybe it s just me :)

IF i m right. Is it also possible that madVR does not do ANY algorithm adaption to the picture? If so, how? I just looked in the madVR settings and I have to choose SOMETHING for Chroma and Luma upscaling? (what is the difference anyway between Chroma and Luma upscaling?)

THX-UltraII

11th October 2013, 08:10

madvr outputs rgb and your intel card transforms this to ycbcr with is bad...huhn, you have any idea how to check if this is true? Not that I don t believe you but I have reasons to think that my Sony VPL-VW1000ES projector DOES get feed with rgb from my HTPC.

if i remenber correct there was a way to output ycbcr with madvr but don't ask me how.IF my intel card outputs ycbcr to my projector, it might be interesting to know how to-do this exactly.

I ask this because I m still in doubt whether I m going to use the 7950 I just bought.

madshi

11th October 2013, 08:30

I'm running MPC-HC x86 v1.7.0 from mpc-hc.org.
It has LAV Video Decoder / Audio and Splitter built-in, *not* using any external filters.
Only setting I changed was to make it use MadVR as renderer. MadVR settings untouched. This is on a newly installed Win7 x64.

Switching between the different renderers, only MadVR exhibits this odd behaviour -- the whole green colour plane was shifted down vertically by some pixels. Doesn't happen with all sources, just some.

EDIT: The plane shift results in thick green line appearing at the top of the video.
I tested the same config on a different computer (different hardware but still NVidia GPU) but I can't replicate the problem.
Are you using DXVA decoding? Or CUDA decoding? I can only guess that this is related to hardware decoding somehow.

I get a crash with potplayer when I try to make a bookmark, if the video is zoomed enough so that the height is at least as tall as the screen. If I change to EVR there's no crash. Can madVR be somehow responsible for the crash?
(Contacting the potplayer dev didn't lead to anything useful...)
Is the crash inside of PotPlayer.exe or inside of madVR? Usually if it's inside of madVR you should get a madVR crash report box and should have the option to send a bug report to me. If the crash is in PotPlayer then chances are it's their problem to fix and not mine. It could still be my fault, but I can't do much without a proper crash report.

I have given-up on 3dlut with ArgyllCMS (collink), because no matter what setting I try, I can't use my calibrated gamma from my .ICM profile.
I am forced to use BT.1886 setting (which I don't like), otherwise the gamma curve is off.
You could try using LightSpace or Calman to create an eeColor 3dlut and then import that in madVR. Those two tools are not free, though.

Loading a 3DLUT into Madvr (yCMS) fixes the colors, but something goes wrong with the contrast.

Moreover, playing with the Contrast slider in Madvr disables the 3DLUT altogether.
Can you define "something goes wrong" a bit better?

Playing with the contrast slider should *not* disable the 3dlut. Are you totally sure on that? What about the other sliders, like brightness, saturation and hue? Do they also disable the 3dlut for you?

I have asked for it already in the past,
Is there any way to implement a simple (automatic) Color Management code like in MPC?

I really wish it would be easy and accurate as just "turning a button on" like in MPC.
Without the need for Conversions, Compilations, Command prompts, Multiple Software (not to mention weeks of tweaking).
Simple does it.
Something like "Use OS Profile" in the Calibration tab will be nice.
I'm not an expert in calibration or profiles. If you have installed an OS Profile, shouldn't it automatically be applied to everything, including video rendering? Why would madVR have to do some extra processing? Isn't it the OS' job to apply the Profile that is installed in the OS?

What kind of profile is that, anyway? A simple matrix profile? Or is some sort of 3dlut contained? Or 3 separate 1dluts for the GPU VideoLUTs?

Yep indeed, after further testing it does this only on a specific content (here is a sample of this content (https://skydrive.live.com/redir?resid=801E6E4E512A1A8F!408&authkey=!AEhckCtgUnZeiik)), and the more I see it the more I think it's a bug related to this particular content regarding deinterlacing (It looks a lot like when you have a bad packet on the DVB stream and the decoder is really confused and doesn't recover)
This is a simple telecined movie broadcast. You can force madVR into film mode to get perfect progressive playback. Playback also works perfectly fine with DXVA deinterlacing and bilinear scaling here on my Intel HD4000, though. However, when using DXVA deinterlacing, if you step through the frames, you'll notice that every frame is shown exactly twice. With madVR's film mode, every frame is only shown once (decimation).

e-t172

11th October 2013, 08:52

I'm not an expert in calibration or profiles. If you have installed an OS Profile, shouldn't it automatically be applied to everything, including video rendering? Why would madVR have to do some extra processing? Isn't it the OS' job to apply the Profile that is installed in the OS?

When using a system-wide ICC profile (and assuming it is loaded correctly), the only thing that's being changed system-wide are the GPU gamma ramps, which are RGB 1D-LUTs. Besides, this method of calibration cannot really do much because it is not aware of the source colorspace.

To achieve full (i.e. 3DLUT) calibration, it's not enough to have the ICC profile configured in the Windows color options, the software needs to be ICC-aware as well (e.g. Gimp, Photoshop, Chrome, etc.). madVR isn't, but the (madVR + Argyll + 3DLUT) combination is.

Ideally, the way it's supposed to work is that madVR is supposed to automatically pick up the ICC profile configured in the Windows color options (using the Windows color API) and use a CMS (e.g. LittleCMS, Argyll) to generate a device link transform (i.e. a 3DLUT) between the source colorspace (e.g. BT.709) and the destination colorspace (the monitor's configured ICC profile). That's how most ICC-aware applications (Photoshop, etc.) work. Unfortunately, madVR doesn't have this feature yet - for now you have to generate the 3DLUT by hand.

What kind of profile is that, anyway? A simple matrix profile? Or is some sort of 3dlut contained? Or 3 separate 1dluts for the GPU VideoLUTs?

Profiles contain either a matrix or a 3DLUT. They can additionally contain calibration 3x1DLUTs (vcgt tag, "Video Card Gamma Tables") - most monitor profiles do. The matrix/3DLUT part of the profile is only valid if the vcgt tag is applied beforehand (usually system-wide as I descrived above). It doesn't really matter if the profile contains a matrix or a 3DLUT: ICC-aware software should be able to correctly handle both. It does make a difference in terms of quality, though.

I can't really comment on the MPC-HC color management feature since I have no idea how it works internally.

madshi

11th October 2013, 09:45

That's all much too complicated for my taste, to be honest. I prefer leaving all the calibration work to external tools and just apply the 3dlut in madVR.

e-t172

11th October 2013, 10:01

StephaneM

11th October 2013, 11:17

This is a simple telecined movie broadcast .../... Playback also works perfectly fine with DXVA deinterlacing and bilinear scaling here on my Intel HD4000 .../... when using DXVA deinterlacing, if you step through the frames, you'll notice that every frame is shown exactly twice.If it works fine on the Intel GPU then it's a bug within the AMD HD 4600 GPU (they are used to have bugs in their deinterlacing process for PAL content : I remember the infamous temporal denoise issue on 1800 XT, or the half picture issue : only the top part was deinterlaced, this was fun :D)

Anyway everything is crystal clear now : madVR does allow hardware deinterlacing to work fine with AMD GPU (despite LAV Filters making you think it's not possible)

Zachs

11th October 2013, 11:57

Are you using DXVA decoding? Or CUDA decoding? I can only guess that this is related to hardware decoding somehow.

I managed to root cause the problem. It was due to an old NVidia GeForce driver that I've been using for my HTPC -- v258.96. This was the version recommended for HTPC as it doesn't stutter with EVR+DXVA (my TV tuner app uses this). Apparently all problems have been fixed with the latest driver, so all is good! :thanks:

James Freeman

11th October 2013, 14:33

@Madshi

MPC-HC uses "Little CMS" which is an opensource color management code to implement in other Software like MadVR. :D

http://www.littlecms.com/
There is even a well written Tutorial PDF on the homepage.
The short FAQ answers important questions a new developer/user may have.

Here is the original short article form the coder (Attila Áfra) on his blog:
http://voxelium.wordpress.com/2010/09/20/icc-color-management-in-media-player-classic-home-cinema/

Quote from the Article:
The ideal solution would be to write a GPU-optimized CMS from scratch, but that’s a lot of work and I’m too busy right now with my ray tracing stuff. A much easier way is to build a 3D LUT with an existing CMS (I’ve opted for Little CMS), which you can sample in a little pixel shader to transform the pixels. 3D LUTs are frequently used in the film industry and are starting to get serious attention in the gaming industry too.

I’m using a 64x64x64 LUT with 16-bit per channel floating point entries, which provides results virtually indistinguishable from those obtained directly with Little CMS. Trilinear interpolation is crucial, and it’s natively supported for this texture format by most (if not all) GPUs released in the past few years. I’ve also added dithering as a final pass to avoid introducing banding artifacts.

Madshi,
Please implement "Little CMS" into MadVR, this will be the best solution for Color Management.

Thanks

James Freeman

11th October 2013, 14:52

I got a mail form the official coder of MPC-HC Color Management System (Attila Áfra):

Hi James,

Thanks for the positive feedback! The full source code for the color management is available in the mpc-hc repository:

The renderer code is here (see DX9RenderingEngine.*):
https://github.com/mpc-hc/mpc-hc/tree/master/src/filters/renderer/VideoRenderers

And the shaders (see final.psh):
https://github.com/mpc-hc/mpc-hc/tree/master/src/mpc-hc/res/shaders

It uses the LittleCMS library to generate the 3D LUT.

I'm quite surprised (and disappointed) that MadVR still supports only explicit LUTs. Implementing an ICC-based solution would be quite easy, and it would be very convenient for the users. I don't use MadVR at all because I simply don't want to bother with LUTs. ICC just works, and I think it's the proper way to do color management in a consumer video application. If it's good enough for professional image editing, then why not use in a video player as well?

Regards,
Attila

@Madshi
Its time. :sly:
It can't be easier now.

James.

DragonQ

11th October 2013, 16:47

Surely making sure your display is calibrated properly avoids the use of these 3DLUTs anyway?

James Freeman

11th October 2013, 16:54

Surely making sure your display is calibrated properly avoids the use of these 3DLUTs anyway?

Sure, if your display supports Gamut mapping and internal LUT loading or calibration.
Like high end TV's and professional PC monitors.

Most TV's and PC monitors don't even cover the whole sRGB gamut, nor let you play with the Gamut points, Gamma Curve or Color Temperature (I mean in a complete custom way).

Or, You have a wide gamut display.
In which no matter how you calibrate your display, MadVR has to know where the Colors (primaries) are to generate correct Rec709 gamut.

6233638

11th October 2013, 17:40

ICC profiles look terrible though. They do not perform complex gamut mapping, and perform their calculations with limited precision.
If madVR can load the data from an external ICC profile and process the image through its internal pipeline, that would be fine, but ICC via the OS gives poor results.
Ideally you would be adjusting the display's internal LUT during calibration instead.

This may sound interesting to do some testing with for me. But first I would like to know something else. Let s say I m just going to put out 1080p from my HTPC with madVR. If I let ANY algorithm do it s work in madVR won t this cause any serious artifact? I mean, first madVR will do something with the picture because of it s algorithm and after this my Sony VW1000 projector does the 2K=>4K upscaling with Reality Creation. This sounds bad to me but maybe it s just me :)

IF i m right. Is it also possible that madVR does not do ANY algorithm adaption to the picture? If so, how?This is not possible. Prior to HDMI 2.0, the 4:2:0 signal format was not supported via HDMI, so chroma upsampling must take place. It should be possible to output otherwise unscaled video by adding 480p, 576p, 720p, 1080p, and 2160p to the madVR output format list, but I don't recommend it.

I just looked in the madVR settings and I have to choose SOMETHING for Chroma and Luma upscaling? (what is the difference anyway between Chroma and Luma upscaling?)Luma can be sent out without any processing, but chroma must be upscaled because video is stored as a 4:2:0 signal, and the minimum format HDMI supports is 4:2:2. I don't understand why you would send it a 1080p signal and not use madVR to upscale to 4K to bypass the projector's internal scaling though.

As I mentioned in my previous post, Jinc 3 AR should look better than Sony's DRC.

James Freeman

11th October 2013, 17:59

ICC profiles look terrible though. They do not perform complex gamut mapping, and perform their calculations with limited precision.

This is ridiculous.

Please take a look at these pages (very short reading):

http://www.color.org/abouticc.xalter
http://www.littlecms.com/

ICC is a world wide known Standard ( ISO 15076-1:2005.) and used in many professional studios in the TV, Cinema and Advertisement industries.

Maybe you did not have a successful results with calibration?
Please don't trash talk up on a world wide Industrial Standard for not getting your way. :angry:

I get perfect results with MPC-HC (built in renderer) and HCFR readings.

3DLUT's on the other hand, are a messy mess for me.
I had to use no less than 3 software (not counting the ArgyllCMS small ones) and weeks of tinkering to generate barely adequate 3dlut.
BARELY.

Try it for yourself:
Calibrate & Profile your monitor (ArgyllCMS or any other Software), generate an ICM file and load it into Color Management in your OS.
Take some measurements with HCFR (or any other soft) & AVS709HD test patterns, play with MPC-HC with built-in color management (EVR).

P.S.
Monitor Calibrated and Profiled in wide gamut mode to capture 100% of Rec709 color space.

"4-Color Clipping.mp4" test pattern from AVS-709-HD disc looks whacked with MadVR & 3DLUT no matter what (BT.1886, -ila -ir, -iaw I tried'em all).
But with MPC-HC with built-in color management (LittleCMS) it looks perfect.

MadVR + 3DLUT (should be cut 235 on):
http://i557.photobucket.com/albums/ss18/ilya-v/Other/4-ColorClippingmp4_snapshot_0129_20131011_064130_zpsff8fd3c2.jpg

e-t172

11th October 2013, 19:47

ICC profiles look terrible though. They do not perform complex gamut mapping, and perform their calculations with limited precision.

I don't think so. Please say more. Besides, CMSes are perfectly capable of doing "complex gamut mapping" using ICC profiles: that's exactly what Argyll does.

If madVR can load the data from an external ICC profile and process the image through its internal pipeline, that would be fine, but ICC via the OS gives poor results.

There is no such thing as "ICC via the OS". There are in-profile 3x1D-LUTs (vcgt) which are typically applied by the OS or a loader, but that's not the main purpose of a ICC profile. Ideally madVR would fetch the currently configured ICC profile for the current monitor using the standard Windows color APIs and then load the profile and use it for rendering. Note that the OS doesn't actually do anything in this scenario apart from providing madVR with a path to a ICC file. That's how it's done in image editing applications.

Ideally you would be adjusting the display's internal LUT during calibration instead.

That's assuming you have a display with a programmable 3DLUT, and that it is of acceptable precision.

"4-Color Clipping.mp4" test pattern from AVS-709-HD disc looks whacked with MadVR & 3DLUT no matter what (BT.1886, -ila -ir, -iaw I tried'em all).
But with MPC-HC with built-in color management (LittleCMS) it looks perfect.

MadVR + 3DLUT (should be cut 235 on):

I don't think you can draw this conclusion so quickly based on your picture. There could be reasonable explanations as to why Argyll doesn't clip all channels at 235, one of which could be that the target luminance allow some of the primaries to overshoot, which is perfectly acceptable and is actually a good thing. You should probably ask Graeme Gill (Argyll's author), who would probably be more able than me at explaining the flaws in your reasoning.

6233638

12th October 2013, 04:53

To expand on my original comment, in my experience with ICC calibration, the corrections are being done in 8-bit, so you always end up with banding.
As for gamut calibration, I've only ever seen it correct gamut at the 100% points and assume that the display is completely linear in its behavior, which is very rarely the case with actual displays. Perhaps I need to investigate profile creation in CalMAN to see if it differs there, but none of the other software I've used includes much more than RGBCMY measurements at 100% saturation for gamut mapping. (if that) Perhaps ArgyllCMS did, but the results I got with it were so poor (severe banding) I did not spent any more time with it.

At least the 3DLUT calibration in madVR is performed in 16-bit and dithered to at least try and avoid banding and posterization, though it's only partially successful at the latter, due to its 8-bit final output.

While calibration is technically more accurate when using ICC or 3DLUT calibration, I have been using my display's own controls for calibration and avoiding ICC/3DLUT for a while now, as it produces much more tolerable results (no posterization/banding) while sacrificing a small amount of technical accuracy.

On a display which has no hardware controls (e.g. a notebook) I would absolutely use an ICC profile for calibration, or if I'm doing content creation where it's more important that every grayscale step is exactly correct and distinct, and image quality (e.g. banding) is not the main concern - as it is with video playback.

THX-UltraII

12th October 2013, 08:25

This may sound interesting to do some testing with for me. But first I would like to know something else. Let s say I m just going to put out 1080p from my HTPC with madVR. If I let ANY algorithm do it s work in madVR won t this cause any serious artifact? I mean, first madVR will do something with the picture because of it s algorithm and after this my Sony VW1000 projector does the 2K=>4K upscaling with Reality Creation. This sounds bad to me but maybe it s just me :)

IF i m right. Is it also possible that madVR does not do ANY algorithm adaption to the picture? If so, how? I just looked in the madVR settings and I have to choose SOMETHING for Chroma and Luma upscaling? (what is the difference anyway between Chroma and Luma upscaling?)any thoughts on this Madshi?

e-t172

12th October 2013, 08:29

To expand on my original comment, in my experience with ICC calibration, the corrections are being done in 8-bit, so you always end up with banding.

That's not a limitation of ICC. That being said, I'm not sure which CMSes support floating point I/O. Argyll probably does, not sure about LittleCMS.

As for gamut calibration, I've only ever seen it correct gamut at the 100% points and assume that the display is completely linear in its behavior, which is very rarely the case with actual displays.

That's not normal. That's probably because you're using a low-quality matrix shaper profile. You should generate a 3DLUT-based profile instead.

tp4tissue

12th October 2013, 14:16

I was actually just doing some similar testing last night; not specifically about GPU load, but power consumption (which is related to GPU load) when I noticed that it seemed excessively high with 720p60 playback.
Luma Chroma Power
Jinc 3 AR Jinc 3 AR 270W
Jinc 3 AR Bicubic 75 AR 256W
Jinc 3 Bicubic 75 AR 222W
Jinc 3 Bicubic 75 221W
Lanczos 3 AR Bicubic 75 AR 150W

Idle 125W
I've said in the past that there's very little benefit to using Jinc 3 AR for chroma, and if your display processes in less than 4:4:4 it's absolutely pointless, but considering it's eating ~15W for little-to-no practical benefit, I would now recommend everyone use Bicubic 75 AR, unless anyone can produce samples where Jinc 3 AR chroma is better.

And while there are certainly examples where Jinc 3 AR is better than Lanczos 3 AR for luma scaling, it's less apparent when starting with an HD source, and I wonder if it's worth the additional 70-120W power consumption.

When scaling DVDs, the results are quite different. There's only 10W between Jinc 3 AR luma, and anything else.
I have suggested it before, but I really think we could do with resolution specific scaling options, though I know that would require a lot of UI changes.

I also found that hardware accelerated decoding (DXVA2 copy-back) was a bit hit-and-miss. When the GPU was being taxed and in a high power state, it saved me 10W, so the top number dropped to 260W. But when playing back DVDs, power consumption varied a lot, fluctuating between 145-170W. With CPU decoding, it was fixed around 150-155W. I should probably have checked DXVA2 Native, which I'm sure would have produced lower numbers, but I would never use that for quality reasons.
And the "trade quality for performance" options may help for low power GPUs, but barely made a dent in power consumption.

I must say though, if Intel brings the power consumption improvements they made with the mobile Haswell chips over to the desktop next year, that alone is probably going to be enough for me to upgrade. 125W at idle is rather high these days.

Aren't you better off with one of the new GPUs? I know they're mostly "rebranded" but there are often smaller changes that people overlook. (possibly upgraded hardware decoders, for example)

The reviewer David Mackenzie posted here a while back that Jinc 3 AR looked a lot better than Sony's "digital reality creation" scaling which incorporates image sharpening in its upscaling algorithms. You might be better outputting 4K and scaling in madVR.

Very cool numbers you put up..

But how many hours of 720p do you watch..

Is the power use "really" going to add up to something significant relative to your income/ other expenses?

tp4tissue

12th October 2013, 14:22

If you are watching 720p or 1080p content on a 720p TV you cannot use Jinc3 for scaling the image (only the chroma is scaled up). Jinc3 is not an option for downscaling the image so it would be downscaled using something else as set in your downscaling options. I made this same mistake not long ago but when watching 2160p content on a 1440p screen. Jinc3 requires much more GPU power as source and destination resolutions go up.

Edit: Still it is nice to know the APU is fast enough to do Jinc3 chroma to 1080p and then downscale to 720p.

Hay guys.. where are you getting 2160p content?:(

Siso

12th October 2013, 15:00

Hi guys,

I've been watching this forum from a long time, so I decided to ask for help. Here is my strange problem, I'm having weird 1 presentation glitch in FSE after 1-5 min after playback, also 3-5 frame drops sometimes earlier sometime after an hour or so during watching a 1080p movies encodes 23.976-24 only. Here are my config and settings:

monitor: Dell U2913WM (21:9) 2560x1080p@60hz
CPU: Q9450 @ 3,2 Ghz
Video: Nvidia Geforce GTX 550ti core clock 999 mhz ,drivers 314.22
RAM: 4gb ddr3
Windows 7 64 bit ultimate

MPC-HC 1.7.0-stable and MPC-BE latest beta
Madvr 0.86.11
Reclock - latest version
haali media splitter latest verison
ffdshow 4500-stable
AC3 filter 2.6b
xy vsfilter-stable

Madvr settings (I've tried many variations...):

enable gamma processing-disabled

chroma upscaling - softcubic 50 without AR
image upscaling - catmull-rom without AR
image downscaling - catmull-rom without AR

rendering: delay playback until render queue is full

enable FSE

use a separate device for presentation

CPU queue size 16
GPU queue size 8

exclusive mode settings:

frames in advance 8

flush
flush & wait (sleep)
don't flush
don't flush

These are by default

Smooth Motion ON - "only if there would be motion judder without it"

Trade quality for performance: all unchecked

There is a option "don't use linear light for smooth motion frame blending" I don't know what exactly this do, and should I check it?

CPU load ~20% maximum

GPU load ~20 % maximum

rendering times: avg~ 7-8 ms
max - 8-9 ms

the queues don't drop as far I noticed. They stay stable...

If you need more info I'll provide :)

Regards.

Ver Greeneyes

12th October 2013, 16:48

I think 6233638 has a point in that any calculations done on the fly with ICC Profiles are always going to be lower precision than the specialized, high quality gamut linking that you can do with ArgyllCMS' collink. The advantage of using a LUT that you know gives the proper translation from the source you're using is that.. it's just a LUT - looking up values from a table is just about the fastest operation there is. I assume madVR uses HLSL's lerp() function to linearly interpolate between four points (or something like that), but even then that's very minimal. If the 3DLUTs you generated have issues, surely that's an issue with ArgyllCMS or the settings you used? I know it took me a while to get a visually pleasing result, but in general I think they take away a lot of uncertainty - we just have to learn to use them.

James Freeman

12th October 2013, 17:31

May I suggest adding a "Black Offset" function to MadVR.

It will let us have more control of the first few black steps, sort of brightness control to a few steps.

My goal is to make the blacks brighter but leave the picture alone.
Gamma and Brightness can't do that, they effect the whole picture.

The user will select what steps will be effected (0-255 or x-x) then another setting will control the strength (brightness/gamma) of these steps.
But leave step 0 alone (this is our native black, we don't want to elevate it) (1-255 or x-x).

Emulation of BT.1886 but totally customizable.
Or brightness/gamma for the blacks only.
Or black crush fix.

Call it as you like, but it will be very useful.

For example:
I want to use higher gamma for a deeper picture, but retain visible blacks.

Some monitors crash the first few steps to 0, this will be an excellent fix for that using a black test chart.

This will be just awesome.

To tell you the truth, I'm beginning to get tired from 20+ calibration runs I did over few weeks and endless 3DLUTS with different "viewing conditions" and more in collink to perfect the blacks..

If anyone has an idea how to write a small MPC Shader for this I will be thankful.

James

leeperry

12th October 2013, 18:17

anyone has an idea how to write a small MPC Shader for this
What about this one (http://www.avsforum.com/t/912720/)? It's been sucessfully softproofed by a number of ppl :)

Sure it only does 100% gamut mapping but it'll work in a matter of a few clicks in Excel and you can build automatic rules in PotPlayer in order to automatically roll gamuts depending on any number of conditions(frame rate, resolution, etc).

I entirely agree that the endless headaches associated with building 3DLUT's and double-checking them are a major PITA I am not willing to deal with anymore.

madshi is working on making it a smoother procedure so I'm surprised to read that you're still struggling :o

And I dunno about you, but I completely fail this test (http://www.xrite.com/custom_page.aspx?pageid=77&lang=en) being colorbind on red so 100% gamut mapping is prolly more than good enough for me :D

I really think we could do with resolution specific scaling options, though I know that would require a lot of UI changes.
Indeed, it would be most welcome but mVR is a one-man project and GUI changes usually appear to be quite annoying to implement.

Asmodian

12th October 2013, 18:35

Hay guys.. where are you getting 2160p content?:(

Google "2160p content". I wasn't watching anything interesting, just some of the test videos you will find on the first page. ;)

madshi

12th October 2013, 19:21

Actually, from a developer point of view, as long as you're using a CMS library, it's not complicated at all.

For example with LittleCMS automatically generating a 3DLUT can be done in just a few lines: you just give it the source colorspace (BT.709, etc.), the monitor's ICC profile, and it will happily give you a ready-to-use 3DLUT. That's basically equivalent to Argyll's "collink" command. This basic solution can then be improved by having some UI for customizing the result, such as custom BT.1886 gamma, rendering intent, etc. - these are just parameters for the CMS library.

Here's some code from the mplayer2 project that does exactly that. (http://git.mplayer2.org/mplayer2/tree/libvo/vo_gl3.c#n2024) It creates a BT.709 profile from the primaries, uses LittleCMS to convert from BT.709 to a user-provided profile and generates a 3DLUT. The code that does all that is less than 100 lines long. In a separate function the resulting 3DLUT is loaded into GPU memory and applied on real-time video using shaders, just like madVR.

Ideally, madVR could have such a feature alongside the manual 3DLUT calibration (for people who want to use another CMS or precisely fine-tune the results).
MPC-HC uses "Little CMS" which is an opensource color management code to implement in other Software like MadVR. :D

http://www.littlecms.com/
There is even a well written Tutorial PDF on the homepage.
The short FAQ answers important questions a new developer/user may have.

Here is the original short article form the coder (Attila Áfra) on his blog:
http://voxelium.wordpress.com/2010/09/20/icc-color-management-in-media-player-classic-home-cinema/

Please implement "Little CMS" into MadVR, this will be the best solution for Color Management.
If it's so easy to use LittleCMS, then why does nobody write a little helper tool to create a 3dlut for madVR using LittleCMS?

madVR can load external 3dlut files. The purpose of that is that I personally don't have to worry about creating such files.

Sure, I could add support for something like LittleCMS myself, but my to do list is VERY full, and I'm not really accepting any feature wishes at the moment.

Feel free to ask me again about this after madVR v1.0 is released.

Let s say I m just going to put out 1080p from my HTPC with madVR. If I let ANY algorithm do it s work in madVR won t this cause any serious artifact? I mean, first madVR will do something with the picture because of it s algorithm and after this my Sony VW1000 projector does the 2K=>4K upscaling with Reality Creation. This sounds bad to me but maybe it s just me :)

IF i m right. Is it also possible that madVR does not do ANY algorithm adaption to the picture? If so, how? I just looked in the madVR settings and I have to choose SOMETHING for Chroma and Luma upscaling? (what is the difference anyway between Chroma and Luma upscaling?)
HTPCs "think" in RGB. Video is encoded in YCbCr. There is no way for madVR to output the video untouched to the projector. Windows/Direct3D don't really allow rendering of YCbCr data in such a way that it gets transported to the display untouched. The data almost always gets forcefully converted to RGB somewhere on the way. At least that is as far as I know. Some time ago some people claimed that when using some specific renderer combination (something like EVR with Hardware Overlay or so), the video would be output untouched in YCbCr, but I highly doubt it.

There's also one key reason why it's technically impossible to output the video untouched to the display: The video in its original form is 4:2:0. But HDMI up to version 1.4 doesn't even allow 4:2:0 to be transported. Only HDMI 2.0 recently added the ability to transport 4:2:0.

Usually the best solution is to let your HTPC do all the processing and send the final renderer video image in the native resolution of your projector (4K) to the projector.

I've been watching this forum from a long time, so I decided to ask for help. Here is my strange problem, I'm having weird 1 presentation glitch in FSE after 1-5 min after playback, also 3-5 frame drops sometimes earlier sometime after an hour or so during watching a 1080p movies encodes 23.976-24 only.
What does the madVR OSD (Ctrl+J) say about how many frame drops/repeats are to be expected? Maybe Reclock isn't work as intended. Try resetting the Reclock timing database. If that doesn't help you could create a debug log, zip it and uploaded it somewhere for me to look at. Then I can tell you why those frame drops occurred.

Presentation glitches are a different story, though. These are usually bugs in the GPU driver. If the frame drops happen at the same time as the presentation glitches, there's probably nothing I can do about it.

May I suggest adding a "Black Offset" function to MadVR.

It will let us have more control of the first few black steps, sort of brightness control to a few steps.

My goal is to make the blacks brighter but leave the picture alone.
Gamma and Brightness can't do that, they effect the whole picture.

The user will select what steps will be effected (0-255 or x-x) then another setting will control the strength (brightness/gamma) of these steps.
But leave step 0 alone (this is our native black, we don't want to elevate it) (1-255 or x-x).

Emulation of BT.1886 but totally customizable.
Or brightness/gamma for the blacks only.
Or black crush fix.
Sounds interesting, but I don't accept any feature requests, anymore, until I've reached v1.0.

You could try using a pixel shader to do something like this.

James Freeman

12th October 2013, 19:27

I entirely agree that the endless headaches associated with building 3DLUT's and double-checking them are a major PITA
I am not willing to deal with anymore.

Agreed (strongly).
The 3DLUT and yMCS are just not user friendly at all.

All we really need for a great & accurate picture:

1. Automatic profile loader to take care for Color Space (And let the OS to handle the Gamma/Calibration curve (GPU's LUT)).
Like I've mentioned before, MPC does this perfectly with LittleCMS.

2. Blacks Control, to compensate for crushed blacks and viewing environment.
I have explained it in me last post.

madshi is working on making it a smoother procedure so I'm surprised to read that you're still struggling :o

The procedure should be non existent at all.
It should just be an On/Off switch or handled automatically like any other color managed software (Photoshop, Picasa, MPC, etc..).

madshi

12th October 2013, 19:30

Here's new test build for debanding:

http://madshi.net/madVRdeband2.rar

I've added some more quality optimizations to the algorithm. There are now 4 different debanding settings:

(1) low
(2) mid
(3) custom (starts with mid settings)
(4) high

The "low/high" settings of the previous test build are now "mid/high" and the "low" setting is new. The "low" setting should now really leave detail alone and only reduce banding artifacts. Please give this a try and report back. Detail loss in "mid/high" should be slightly reduced, too, hopefully without impacting debanding quality too much.

The "custom" setting allows you exact control over the algorithm parameters. There are 4 different parameters. You can control them by pressing the keys Ctrl+Alt+1, Ctrl+Alt+2, ..., Ctrl+Alt+9 and Ctrl+Alt+0. Debanding itself can be toggled with Ctrl+Alt+D, same as last test build. The custom option will be removed from the official build. This is just for testing purposes! Now is your chance to help me fine tune these debanding options. I'd like to have 3 options, low, mid and high. Please play with the custom option to check if my current presets are good, or whether they can be improved in any way. The most important thing is to balance detail loss and debanding quality.

The "localContrast" parameter can be turned on/off. Turning it on results in doubled rendering times. Please check if this parameter is needed at all. Maybe we can drop it? That would be good for rendering speed.

Edit: Actually, it seems the new "mid/high" have a lower debanding strength compared to the previous test build. My algorithm changes seem to have lowered overall debanding strength.

James Freeman

12th October 2013, 19:49

WOW.

I test with the Greyscale Ramp from the AVS709HD disc.

Low: Not strong enough, still visible gradients.
Mid: Smoooooooooooth with detail (best setting).
High: Strong but also preservers detail, good.

"localContrast": I can't see any difference.

e-t172

12th October 2013, 20:23

If it's so easy to use LittleCMS, then why does nobody write a little helper tool to create a 3dlut for madVR using LittleCMS?

That would be reinventing the wheel, as Argyll's collink command does exactly that. The point of doing that automatically is that as long as the user has his ICC profile correctly configured in the Windows color control panel applet, Everything Just Works©®™, meaning madVR would pick it up automatically and generate a 3DLUT on the fly based on the configured profile, just like other applications like Photoshop etc. do. That's as close to zero-configuration as it gets.

I do understand that you have other things on your mind right now, though. Technically it's just a "user-friendlyness" issue, so it can wait.

@people who are complaining about 3DLUTs generated with Argyll: have you tried voicing your concerns on the Argyll mailing list? I'm sure Graeme would have some idea or could suggest some option that you didn't know about. It's not productive to just whine about Argyll without at least trying to get to the bottom of the issues.

James Freeman

12th October 2013, 20:58

I do understand that you have other things on your mind right now, though. Technically it's just a "user-friendlyness" issue, so it can wait.

I think otherwise.

If MadVR is striving to be the best/professional picture renderer (which currently it is), Color Management (that Everything Just Works©®™) is the FIRST thing that should be taken care of.

@people who are complaining about 3DLUTs generated with Argyll:

Believe me, I've tried.

There is no setting in collink to generate a 3dlut with Rec709 color space, and preserve my calibration gamma curve from my .icm profile.
collink forces the Rec709.icm Gamma curve on the resulting 3dlut, or BT.1886 gamma curve.
Another option is to use "viewing conditions" which also tinkers with the gamma, that's why I requested a Black Offset setting in MadVR to eliminate the need to compile endless test 3dluts.

No setting in collink leaves my gamma alone and only does Color Space conversion, NONE.

The closes option I got is to enter manually the Primaries Yxy (measured with HCFR) in yCMS tab in MadVR.
Which at least does what I expect it to do (Color Space conversion) and does not change my OS loaded calibration curve.
Although is has some bizarre behavior that it exceeds the 235 step in the Color Clipping test I have poster earlier.
May be its related to 16-235 to 0-255 conversion when yCMS generates the 3dlut?

Siso

12th October 2013, 21:13

What does the madVR OSD (Ctrl+J) say about how many frame drops/repeats are to be expected? Maybe Reclock isn't work as intended. Try resetting the Reclock timing database. If that doesn't help you could create a debug log, zip it and uploaded it somewhere for me to look at. Then I can tell you why those frame drops occurred.

Presentation glitches are a different story, though. These are usually bugs in the GPU driver. If the frame drops happen at the same time as the presentation glitches, there's probably nothing I can do about it.

The strange frame drops occur way way later after the presentation glitch around and hour or more after the presentation glitch, also in OSD is showing , 1 frame repeat or drop ~ from hours to days.

turbojet

12th October 2013, 21:17

I was kind of hoping high debanding would be stronger because some banding still exists. I could try to find some example pics when I have more time next week but 6233638's initial picture (http://forum.doom9.org/showthread.php?p=1646593#post1646593) is a great example.

The detail loss with deband high isn't noticeable to me at 24fps but the pre and post sharpening could have something to do with it. Image anti ringing shows noticeable detail loss though.

There's no noticeable difference to me between LocalContrast off (ctrl+alt+9) and 2.0 (ctrl+alt+0) other than ~8% increase in gpu usage at 24fps. On a still frame there's bit of a difference.

madshi

12th October 2013, 22:04

That would be reinventing the wheel, as Argyll's collink command does exactly that.
Yes, but it seems that some people are not happy with what Argyll is doing. So a little tool which would turn an ICC profile into a madVR 3dlut by using LittleCMS might still be useful.

If MadVR is striving to be the best/professional picture renderer (which currently it is), Color Management (that Everything Just Works©®™) is the FIRST thing that should be taken care of.
Probably 99% of madVR users do not have a meter. And madVR is still not feature complete. So you will surely understand that there are other features which are more important at the moment. Features which the majority of madVR users can benefit from. madVR supports full calibration, through yCMS, ArgyllCMS, Calman or LightSpace. Maybe you're not happy with any of these choices for whatever reason. But if you're not then you'll have to wait until I find time to implement something else. And that doesn't have high priority right now.

The strange frame drops occur way way later after the presentation glitch around and hour or more after the presentation glitch, also in OSD is showing , 1 frame repeat or drop ~ from hours to days.
Well, as I said, try resetting Reclock timing database. And you can upload a debug log.

I was kind of hoping high debanding would be stronger because some banding still exists. I could try to find some example pics when I have more time next week but 6233638's initial picture (http://forum.doom9.org/showthread.php?p=1646593#post1646593) is a great example.
That picture was brightened in Photoshop or something. So it's not a good test sample. For debanding testing purposes I also need a video sample, not a PNG image.

I do agree, though, that "high" is not as strong as it should be. The algorithm changes I implemented to reduce detail loss have overall also reduced the debanding strength. I'll have to look into that and re-introduce a stronger option again. You can still play with the custom parameters, though, to check whether you can find a better setting for the "low", "mid" and "high" options.

e-t172

12th October 2013, 22:10

There is no setting in collink to generate a 3dlut with Rec709 color space, and preserve my calibration gamma curve from my .icm profile.
collink forces the Rec709.icm Gamma curve on the resulting 3dlut, or BT.1886 gamma curve.
Another option is to use "viewing conditions" which also tinkers with the gamma, that's why I requested a Black Offset setting in MadVR to eliminate the need to compile endless test 3dluts.

No setting in collink leaves my gamma alone and only does Color Space conversion, NONE.

The reason why you're not getting what you want is because what you want quite frankly does not make a lot of sense, and ICC as a workflow is not designed to accommodate such strange needs.

There is no such thing as the "gamma curve from my .icm profile". An ICC profile describes a device by defining a transformation between an absolute color space (e.g. XYZ) to the monitor's color space. It doesn't know about gamma, nor does it care; it is completely agnostic to such things.

When you do color conversion, what you want to do is make sure your device reproduces color from the source material as accurately as possible. When using the collink command, you tell Argyll "here's my source colorspace (BT.709), here's my destination colorspace (my monitor), now go and compute a transformation that translates one into the other in the most perceptually convincing way possible". Argyll allows you to fine-tune some of the strategies it uses to achieve that goal (such as rendering intent, BT.1886 or viewing conditions, etc.) depending on your workflow (such as proofing), but the end goal is always the same: converting color from the movie's colorspace to the monitor's colorspace. This is how colorimetric workflows work. That's how they always worked, and that's how they're supposed to work.

Now I hope you can understand why Argyll does not make it easy to "generate a 3dlut with Rec709 color space, and preserve my calibration gamma curve from my .icm profile" (whatever that means). It's kinda like saying "okay, so I want you to convert between these two colorspaces, but I want you to do it in this weird way that goes contrary to what you're trying to achieve". Argyll presents you with sensible, perceptually relevant (scientifically backed) options for converting between color spaces. If you want it to implement some weird way of computing the transformation, then you'll first have to convince Graeme that your approach actually makes sense, i.e. that it results in perceptually superior results. Considering that the algorithms Argyll uses are strongly backed by scientific literature and technical standards (BT.1886, CIECAM02), I think you will need more than your own experience to convince others of the superiority of your approach.

Yes, but it seems that some people are not happy with what Argyll is doing. So a little tool which would turn an ICC profile into a madVR 3dlut by using LittleCMS might still be useful.

LittleCMS is just a lightweight equivalent to Argyll. AFAIK, there is nothing that LittleCMS does that Argyll cannot do. So I guess that if people are dissatisfied with their results with Argyll (which, barring a nasty bug, IMHO means that they're simply using it wrong, or that they have unreasonable expectations), then they will be even more dissatisfied with LittleCMS.

turbojet

12th October 2013, 23:42

That picture was brightened in Photoshop or something. So it's not a good test sample. For debanding testing purposes I also need a video sample, not a PNG image.

I do agree, though, that "high" is not as strong as it should be. The algorithm changes I implemented to reduce detail loss have overall also reduced the debanding strength. I'll have to look into that and re-introduce a stronger option again. You can still play with the custom parameters, though, to check whether you can find a better setting for the "low", "mid" and "high" options.

None of the custom options are strong as high. Just watched a show that I expected to see banding but didn't. I'll keep an eye out for missed banding but it happens rarely outside of anime which is all I have.

6233638

13th October 2013, 01:06

The "localContrast" parameter can be turned on/off. Turning it on results in doubled rendering times. Please check if this parameter is needed at all. Maybe we can drop it? That would be good for rendering speed.Local Contrast definitely seems to help preserve details near black.

From some very limited testing so far, I'm quite liking:
avgDif: 1.0
maxDif: 3.0
gradient: 2.5 (p.s. you have a typo there)
local contrast: 1.5
This seems to have slightly better debanding than medium, and preserves detail much better.

With local contrast set any lower than 1.5, I cannot achieve totally smooth debanding on many of the samples I've looked at. 1.5 seems to be about the threshold for that, but it may have to be set a bit higher.
I was kind of hoping high debanding would be stronger because some banding still exists. I could try to find some example pics when I have more time next week but 6233638's initial picture (http://forum.doom9.org/showthread.php?p=1646593#post1646593) is a great example. That example was brightened quite a bit. (the screenshot, not the video) Debanding is strongest near black, and less effective the brighter that it gets.

Even with the maximum settings available, there is still banding in many sources though:
http://www.abload.de/thumb/no-debandcsqy0.png (http://www.abload.de/img/no-debandcsqy0.png) http://www.abload.de/thumb/max-debandtxpzb.png (http://www.abload.de/img/max-debandtxpzb.png)
You can see that the dark areas are looking quite smooth, but not the brighter ones.

But I don't know that we should expect "perfect" debanding - that's surely going to result in a lot of detail loss.

Image anti ringing shows noticeable detail loss though.Do you have sources for this? Anti-ringing seemed to be relatively benign in its current state.