madVR - high quality video renderer (GPU assisted)

[leeperry]

my .icc (created with lacieblueyepro) file (3ko)
http://www.zshare.net/info.html?60687437-8a14b9c25d59c48735a5bec553875850
ok so it doesn't contain a LUT.
last time I played around w/ some color management app from X-Rite it gave the option to create 1D LUT ICC files.
I'm surprised PowerDVD is color managed and will take the simple ICM file in account ?! anyway, play around w/ ARGYLLCMS it's much more accurate and works perfectly fine w/ any video renderer(except Overlay...but PDVD uses VMR9 anyway, last time Jong checked anyway :D)

atm I use a LUT in ARGYLLCMS to fix my CRT colorimetry, then ddcc() in ffdshow to convert gamuts w/ HR.

[kostik]

Why Madvr 0.10 doesnt have the two 3dlut files ?
and how do I use them? just copy them from the 0.9 release and put them in the folder where madvr is?
10X

[nuhi]

Why Madvr 0.10 doesnt have the two 3dlut files ?
and how do I use them? just copy them from the 0.9 release and put them in the folder where madvr is?
10X
They are auto-created when needed for the first time.
You can edit the templates in madvr cr3dlut folder.
What are exact rules which template is used and when I don't know but I presume it is resolution of the video among other things.


ikarad, I use display calibration as well and madvr works fine with it (Coloreyes Display Pro), it has a special lut loader on windows startup so I guess it is not dependant on Vista's ICM support.
Just saying so you know it is not all black and white.

[mr.duck]

Found a small bug with the installer. Running install.bat as admin fails to register madVR. You have to run install.bat as a regular user, then click yes to the UAC warning. I'm on windows 7.


madVR is working except if you... pause video > resize > play... it crashes. I'm guessing that's been brought up already, just thought I would mention it.

Keep up the good work :thanks:

[mr.duck]

About supporting YUY2... I've just been using the really excelent DScaler5 MPEG2 decoder to playback some TV shows. By default, it outputs YUY2, and the video looks truely dreadful because some grotty little default video renderer gets loaded in place of madVR. I finally worked out why madVR wasn't loading and I've set DScaler5 to output YV12 instead (BTW, how exactly is YV12 better than YUY2?).

I was thinking madVR being fed with YUY2 is still better than the alternatives being fed with YUY2. If madVR could support YUY2, and perhaps display an on screen warning message for 10 sec or so. Would that be a good idea?

[Egh]

I was thinking madVR being fed with YUY2 is still better than the alternatives being fed with YUY2. If madVR could support YUY2, and perhaps display an on screen warning message for 10 sec or so. Would that be a good idea?

Yeah, but as explained before, YUY2 is not YV12. Videos are in YV12 so if mVR is to accept YUY2 then you would rely on potentially substandard chroma upscale in the decoder.

I think current implementation is more reasonable.

[mr.duck]

Yeah, but as explained before, YUY2 is not YV12. Videos are in YV12 so if mVR is to accept YUY2 then you would rely on potentially substandard chroma upscale in the decoder.

Hi, I've got a basic understanding of color spaces. Do you have a link to where you explained it before? Does all video use YV12? What about high def videos like straight from blu-ray disk?

[Egh]

Hi, I've got a basic understanding of color spaces. Do you have a link to where you explained it before? Does all video use YV12? What about high def videos like straight from blu-ray disk?

Unfortunately YV12 is what is used in practice. YUY2 has more colour information compared to YV12. In simple words, if you force decoder to output YUY2, then it has to do the chroma upscale. Potentially it can do it substandard. The point of mVR is to have no compromise in quality all the way, so it cannot rely on other filters.

I didn't explain it before though, it is an explanation by madshi, so you have to look it up in one of his monster sized posts :)

If you want to get some proper understanding about colorspaces, you may try this: http://en.wikipedia.org/wiki/YUV

[Mark_A_W]

About supporting YUY2... I've just been using the really excelent DScaler5 MPEG2 decoder to playback some TV shows. By default, it outputs YUY2, and the video looks truely dreadful because some grotty little default video renderer gets loaded in place of madVR. I finally worked out why madVR wasn't loading and I've set DScaler5 to output YV12 instead (BTW, how exactly is YV12 better than YUY2?).

I was thinking madVR being fed with YUY2 is still better than the alternatives being fed with YUY2. If madVR could support YUY2, and perhaps display an on screen warning message for 10 sec or so. Would that be a good idea?


I use the Unofficial 1080i IVTC version of Dscaler5 MPEG2 decoder to perform IVTC on TS files - it's the only decoder that finds 23.976fps in the 29.97fps stream.

To get around the YUY2 thing I run Ffdshow after in the filter path - Ffdshow outputs YV12 to madVR.

It may not be ideal, but it works, and you can play with ffdshow filters too :)

[ajp_anton]

So you're going mpeg2 = YV12 -(dscaler)-> YUY -(ffdshow)-> YV12, and then madVR for its chroma upsampling quality?

[yesgrey]

I use the Unofficial 1080i IVTC version of Dscaler5 MPEG2 decoder to perform IVTC on TS files
Why don't you set the output to YV12 instead of YUY2, it's not supported in the unofficial DScaler5 version?

[DeepBeepMeep]

Why don't you set the output to YV12 instead of YUY2, it's not supported in the unofficial DScaler5 version?

Well, an YUY2 output for IVTC Dscaler is supported for YV12 materials but it is less performant since in this scenario it needs to create temporary copies of intermediate YV12 frames which are used by the IVTC algorithm. I don't think this is significant for today's CPU.

Anyway, you are right there is no point outputing YUY2 with Dscaler when the input is YV12 material since we might lose CPU time and quality for nothing.

[bur]

I saw the comparison screens in the first post and they looked quite impressive, but I certainly couldn't reproduce those. See this screenshot:

http://img194.imageshack.us/img194/3923/comparison.th.png (http://img194.imageshack.us/img194/3923/comparison.png)

The first is Nvidia VMR9, second Haali, third MadVR. I wasn't able to spot a difference even when compating single pixels and definitely not when watching a video. So what's the benefit of different renderers? Or do I get something wrong?


Shots were taken on a slightly upscaled video, VMR9 resizing set to Bicubic A=-1.

[Mark_A_W]

Why don't you set the output to YV12 instead of YUY2, it's not supported in the unofficial DScaler5 version?


Sorry, my mistake, I just checked how I have it setup.

I do have Dscaler outputting YV12.

I just have ffdshow after it for stuff like deinterlacing when needed.

[Egh]

I saw the comparison screens in the first post and they looked quite impressive, but I certainly couldn't reproduce those. See this screenshot:

The first is Nvidia VMR9, second Haali, third MadVR. I wasn't able to spot a difference even when compating single pixels and definitely not when watching a video. So what's the benefit of different renderers? Or do I get something wrong?

Shots were taken on a slightly upscaled video, VMR9 resizing set to Bicubic A=-1.

Are you sure about that? Any more details? Like how much was the upscale done, and most important is that settings did you use in Haali and mVR :)

You can have lots of blur both in Haali and mVR, depending on the settings. A=-1 iirc is the sharpest bicubic setting in VMR9.

[Egh]

Let's make then a bit more methodologically sound comparison, shall we?

Same source, same frame, all shots done via print screen.

DVD untouched source, famous touhou :)
Presented in original resolution + upscale to apply correct A/R (i.e. around 853 width instead of 720, plus normal chroma upscale).

VMR9 3D with A=-1:
http://img29.imageshack.us/img29/5450/touhouvmr9.th.png (http://img29.imageshack.us/my.php?image=touhouvmr9.png)
Haali with -0.8:
http://img190.imageshack.us/img190/8035/touhouhaali.th.png (http://img190.imageshack.us/my.php?image=touhouhaali.png)
mVR with SoftCubic50 on both luma and chroma:
http://img188.imageshack.us/img188/3896/touhoumvrsb5.th.png (http://img188.imageshack.us/my.php?image=touhoumvrsb5.png)
mVR with Lanc4 for luma and CMR for chroma:
http://img29.imageshack.us/img29/3871/touhoumvrl4cm.th.png (http://img29.imageshack.us/my.php?image=touhoumvrl4cm.png)

Of course, since I used ffdshow for all of the snapshots, in all cases but with mVR, initial (or whole) chroma upscale is performed by the decoder.

Softcubic's version is the softest one.
In terms of filesize in PNG,
VMR9 << Haali << Softcubic50 << Lanc4+CMR
Numbers don't lie :)))

[bur]

I used the default settings for Haali and MadVR (whatever those are, I just enabled them in MPC and there were no settings available - maybe that's what I did wrong?).

Other than that, the frames are still nearly 100% equal. I don't know what Egh means by "more methodologically sound", but of course I used the same frames for all three shots. Pictures were saved as BMP through MPC and later converted to PNG with Paint.Net.

I have to admit though there are some differences to be seen in Egh's shots. But still nowhere as drastic as in the thread's first post where it looks like MadVR was far superior to any other renderer.

And even though there are some differences if you compare the pictures posted by Egh on a per pixel basis, I'm not sure if you would notice them when watching the video. Especially if it's not drawn, but "real" life. I doubt you'd really notice anything much between those four settings/renderers, VMR9 and MadVR with lanczos4 look very much the same. It would make an interesting experiment, having someone else set up the video with different renderers and then watch them to compare quality.



PS: Where can I change the MadVR settings?

[Hypernova]

I used the default settings for Haali and MadVR (whatever those are, I just enabled them in MPC and there were no settings available - maybe that's what I did wrong?).

Other than that, the frames are still nearly 100% equal. I don't know what Egh means by "more methodologically sound", but of course I used the same frames for all three shots. Pictures were saved as BMP through MPC and later converted to PNG with Paint.Net.

I have to admit though there are some differences to be seen in Egh's shots. But still nowhere as drastic as in the thread's first post where it looks like MadVR was far superior to any other renderer.

And even though there are some differences if you compare the pictures posted by Egh on a per pixel basis, I'm not sure if you would notice them when watching the video. Especially if it's not drawn, but "real" life. I doubt you'd really notice anything much between those four settings/renderers, VMR9 and MadVR with lanczos4 look very much the same. It would make an interesting experiment, having someone else set up the video with different renderers and then watch them to compare quality.



PS: Where can I change the MadVR settings?

Maybe you shouldn't worry too much about that? If you don't see the difference, that's ok. If you're happy with what you have, then that's good. You don't have to try to see the difference if it does not gain you anything right? For me, I'm still waiting for madVR to play smoothly and have subtitle support because I can see the difference while watching the video. If you want to know what I'm talking about, look at my posts around page 42-45.

You can change madVR settings by go to Play->Filters->madVR (in MPC-HC)

[mr.duck]

You can also change settings with a DirectShow filter manager (http://www.softella.com/dsfm/index.en.htm).

[madshi]

If the thread which controls next displayed frame is triggered by GPU's ISR each time the displayed buffer has been flipped, 3 video frame buffers are usually more than enough to provide smoothy presentation.

Large Queue Depth at the decoder and video post-processing / rendering stages often yield bad user experience on trick play actions, especially for some stream contents which are not well muxed.
I don't believe queue depth will be an issue for trick play, once madVR is a bit better optimized. E.g. it would be easy enough to instantly clear all queues when trick play is initiated.

The better design on the resource limited embedded system often lets demuxer to control the sending sequence to video / audio decoders so that most filters in the decoding chains do not need too ridiculously many buffers in the queue. (Usually 2 ~ 3 are more than enough, 0 for the processing chain by the same thread)
In the madVR logs I've seen that the highest priority thread in madVR sometimes doesn't get called for up to 2 frames in a row. That's why I chose a queue depth of 8 frames, just to be sure.

Due to the fact that different thread filters often have the different CPU priorities, it makes the situation worse with too large queue depth. Some CPU time consuming threads could eat out most CPU time before other lower priority threads gain the CPU time again.
The rendering thread has a lower priority than the presentation thread, so I don't see why a large queue depth should be a problem. Anyway, it will be easy enough later to reduce queue depth, if that should prove to be better (which I don't believe).

mpc-hc's internal vc1 decoder produces images like this when playing vc1 in m2ts files
That's a bug in older MPC-HC versions. Please use a newer MPC-HC build.

If you feed it with RGB32, the GPU can't do any post processing AFAIK.
Then why does VMR9 not output the RGB32 values I feed to it on my PC?

I'm seeking guidance on the mimimum ATI graphics card that "should" work with the stable madVR. I know there is a bit of "looking in the crystal ball" about this
Yes, it's more guessing than knowing right now.

I'd also like to clarify if the plan is to have de-interlacing, EE, de-noise, etc still work on the ATI cards once madVR is complete. I think the answer is yet, but....
I don't like to talk about future plans. But I can tell you that deinterlacing is definitely not planned right now. Noise reduction is also rather unlikely because both deinterlacing and noise reduction can easily be done via CPU before sending the images to madVR.

With 0.10, what have seen is that if the decode and render buffers/queues are not completely full, madVR has the potential to drop/delay frames.

[...]

you may want to look into dynamically limiting the maximum buffer/queue size to what the GPU can always keep full. I wouldn't be surprised if that fixed the delayed/dropped frame problem I have occasionally run into when the render queue drops to 7/8.
Increasing the queue size won't help, unless your queue goes lower than 3-4.

What kind of resize is most demanding, maximum upscale, maximum downscale, or some "odd" non-integer resizes?
Higher input resolutions are more demanding than lower res.
Higher output resolutions are more demanding than lower res.
Downscaling is more demanding than upscaling.

will there be a x64 version?
Is there plans for a x64 version?
Why don't you guys search this thread for "x64"?

there is no reason to delay playback until the refresh rate is properly determined. At least it should be optional as most users would rather have playback start as soon as possible and take these few seconds to detect the refresh rate while the video is already playing.
madVR 0.10 is unpolished in many ways. Things like delays, crashes, trick play etc will get better in future versions.

There is a very big problem (I think it's a bad limitation of beta progress) with MadVR. With VMR9 or EVR color profile (.icm) works but with madvr color profile doesn't work (it's like if overlay is selected all the time).

I could never use madvr if this problem is not corrected because by default my monitors is not calibrated and default colors are bad.
I don't know whether .icm color profiles work or don't work. If they work in games they should also work in madVR, cause madVR basically behaves like a game.

However, I'd not be sad at all if the .icm color profiles didn't work because the plan is to use cr3dlut for complete display calibration.

but anyway, yeah my CRT is way off...so I use a CLUT in the graphic card to get it to D65/2.2, then I do gamut conversion on top of it
Why would you want to use CLUT + gamut conversion in 2 different steps? I'm not really an expert in this area, but according to my understanding in the end cr3dlut is supposed to do *all* calibration work in one step.

cr3dlut works in 8bit, the graphic card's CLUT is 10 bit solid
Careful. Are you talking about input or output bitdepth? cr3dlut uses 8bit input and 16bit output! I doubt CLUT can compete with that. Maybe eventually CLUT is 10bit input 10bit output. But I rather think it's probably 8bit input 10bit output. So worse in every way compared to cr3dlut. Also the next question would be: Does the CLUT round higher bitdepth input data down to the CLUT bitdepth? Or does it interpolate? madVR does trilinear interpolation between the 3D 8bit 3dlut. Interpolating an 8bit lut is probably better than rounding to a 10bit lut.

I just saw another thread about a panasonic TV that takes any signal and interpolates that to 600hz.
This TV is not really able to display 600 different full bitdepth images per second. That's just another marketing trick. You know that plasmas have to use dithering to be able to produce subpixel color intensities other than "on" and "off", right? Panasonic marketing conveniently includes these dithering steps in their calculation. This way they can talk of 600Hz.

the picture on my pc2 obtained from the filter combination: Haali Media Splitter, Ffdshow, madVR, although very nice, seems a little dark compared to what I see from the filter combination: Haali Media Splitter, CyberLink H.264/AVC decoder (PDVD8), vmr9 renderless.
Try switching madVR to video levels.

The 0.10 version is much slower on my 2600 Ati card.
madVR 0.10 is optimized to achieve smooth motion on capable graphics cards. It seems that the rendering approach used by madVR 0.10 does not play nice with slower/older graphics cards, unfortunately. I don't think perfect smooth playback will ever be possible on such slower/older GPUs *in windowed mode*. I expect, however, to achieve quite good (maybe perfect) results with fullscreen exclusive mode even on some older cards.

how do delayed frames alter the viewing experience? with dropped frames, there is stuttering, but how do only delayed frames change the look of the movie?
Depends a bit on the refresh rate of your display. A "delayed frame" simply means that madVR didn't manage to display the frame on the VSync it was planning to display it. The lower your refresh rate, the bigger the hit on smoothness will be. If you have 1:1 between source framerate and display refresh rate, every delayed frame usually also results in a dropped frame. Delayed frames usually show as motion stutter, just like dropped frames.

I saw the comparison screens in the first post and they looked quite impressive, but I certainly couldn't reproduce those.
As I've already explained several times, madVR is not expected to magically improve image quality by 200% in every single scene. What madVR is about is mainly:

(1) as mathematically accurate rendering as possible
(2) being independent of stupid driver behavior and driver bugs
(3) included display calibration

Some other renderers may come close to madVR image quality in specific scenes, and then fail in other scenes. In every day life scenes the difference between madVR and other renderers can be very small. But there are specific scenes where other renderers sometimes stumble. The comparison screens on the first page show such specific scenes. If you want to reproduce such big differences on your PC, try to find scenes that are similar. E.g. look for scenes with lots of red on black background ("chroma upsampling"). Or look for scenes with smooth color gradients ("dithering"). Or look for Hypernova's posts in this thread. He's posted some nice real life comparison screenshots where madVR produces visibly better results. Some of these image quality differences are harder to see in motion while other differences are actually *easier* to see in motion. E.g. banding artifacts produced by not using proper dithering can be extremely annoying in motion.

One very big annoyance factor I find with other renderers is that you never know exactly what you will get. Depending on OS, graphics card model, renderer, driver revision, connection type and even display you can get different results. E.g. I've found that sometimes simply asking PowerStrip to change refresh rate can result in the GPU switching between video <-> PC levels. Or some people seem to get good chroma upsampling quality from ATI cards, while other people don't and nobody knows why exactly. With madVR you don't have any such problems. You get 100% the same image quality on every graphics card and every OS because madVR simply doesn't leave the GPU any room for interpretation...

[madshi]

Sorry guys, another weekend without a new madVR version. I'm quite busy these days. But don't be afraid, I don't plan to stop development in the long run! :)

[SpaceAgeHero]

Sorry guys, another weekend without a new madVR version. I'm quite busy these days. But don't be afraid, I don't plan to stop development in the long run! :)

Glad you're alive. :D

[leeperry]

I don't know whether .icm color profiles work or don't work. If they work in games they should also work in madVR, cause madVR basically behaves like a game.

Careful. Are you talking about input or output bitdepth? cr3dlut uses 8bit input and 16bit output! I doubt CLUT can compete with that. Maybe eventually CLUT is 10bit input 10bit output. But I rather think it's probably 8bit input 10bit output. So worse in every way compared to cr3dlut. Also the next question would be: Does the CLUT round higher bitdepth input data down to the CLUT bitdepth? Or does it interpolate? madVR does trilinear interpolation between the 3D 8bit 3dlut. Interpolating an 8bit lut is probably better than rounding to a 10bit lut.
1) simple ICM files do not work in games...they only work in color managed apps(firefox/photoshop/etc)
the only way to get a LUT calibration that works all the time is w/ a more complicated ICC 4.0 file using the <LUT> tags, or w/ ARGYLLCMS.
ARGYLLCMS will play zillions of test patterns automatically(for 25 minutes in HQ mode), and in the end will make a 256 levels 1D LUT for R/G/B that will automatically make the graphic card match perfect calibration(D65/2.2 mostly, and you can actually check the calibration through Color.HCFR afterwards...it's stellar! ΔE is usually 1 on the whole IRE scale :))

if someday cr3dlut enables to import the .cal files from ARGYLLCMS, this might indeed become an all-in-one solution :cool:

2)well yeah, true...I know the CLUT works in 10bit on CRT, so mostly it's 8bit input > 10bit CLUT > 10bit output over VGA(ARGYLLCMS can measure the CLUT accuracy).

but DVI is 8bit anyway, so how do the 10bit get encoded to 8bit TMDS? no idea, but it's prolly ugly :D

anyway, I only use the graphic card's CLUT over VGA on my CRT, on DVI I leave the CLUT untouched.

[cyberbeing]

With 0.10, what have seen is that if the decode and render buffers/queues are not completely full, madVR has the potential to drop/delay frames.

[...]

you may want to look into dynamically limiting the maximum buffer/queue size to what the GPU can always keep full. I wouldn't be surprised if that fixed the delayed/dropped frame problem I have occasionally run into when the render queue drops to 7/8.

Increasing the queue size won't help, unless your queue goes lower than 3-4.
I was actually suggesting to dynamically decrease the maximum queue size. (i.e. if the gpu is only able to keep the queue to 7/8 100% of the time full, it changes the limit to 7/7 instead, and same idea for the decoding queue, if it's only say able to keep the queue 100% of the time to 14/16, it changes the limit to 14/14). In other words a high queue limit is stressing out some GPUs which are unable to keep up.

If you have another idea of why, when the decoder and/or render queues drop to only 15/16 and/or 7/8 respectively, I always get dropped/delayed frames, I'm open for suggestions about how it can be fixed.

Edit: Also is there any chance for you to quickly make a stop-gap release (something like 0.10b) that only fixes the remembering of luma scaling settings? It's been two weeks now, and having to manually set my scaling settings for every single video I open, is getting very annoying, very fast. I hope we don't have to wait another month or something just to see this minor thing fixed.

[honai]

Well, it doesn't annoy everyone. I'm fine with it because it's my prefered setting anyway. ;)

[cyberbeing]

Well, it doesn't annoy everyone. I'm fine with it because it's my prefered setting anyway. ;)

Blah, SoftCubic50 is excessively soft for luma upscaling and neigh unwatchable for me. At least the chroma setting sticks because SoftCubic100 blurs away most of the chroma detail. You are very lucky if you enjoy such soft settings without doing crazy over-sharpening your source, but I respect that everyone has their own tastes...

My preferred:
Upscaling: Spline36
Downscaling: Spline64
Chroma: Mitchell-Netravali

[madshi]

ARGYLLCMS will play zillions of test patterns automatically(for 25 minutes in HQ mode), and in the end will make a 256 levels 1D LUT for R/G/B that will automatically make the graphic card match perfect calibration(D65/2.2 mostly, and you can actually check the calibration through Color.HCFR afterwards...it's stellar! ΔE is usually 1 on the whole IRE scale :))
256 levels? So obviously the CLUT is only 8bit input -> 10bit output. Compared to cr3dlut which is 8bit input -> 16bit output.

But is 3x 1D LUT good enough? I think R/G/B influence each other. Why else would cr3dlut use one big 3D LUT instead of 3x 1D LUT?

if someday cr3dlut enables to import the .cal files from ARGYLLCMS, this might indeed become an all-in-one solution :cool:
Well, you have to talk to yesgrey3 about that... ;)

I was actually suggesting to dynamically decrease the maximum queue size. (i.e. if the gpu is only able to keep the queue to 7/8 100% of the time full, it changes the limit to 7/7 instead, and same idea for the decoding queue, if it's only say able to keep the queue 100% of the time to 14/16, it changes the limit to 14/14). In other words a high queue limit is stressing out some GPUs which are unable to keep up.
No offense, but you don't really seem to understand how these queues work or why they sometimes go down and up again. Trust me, increasing or decreasing the queue depth would have exactly zero effect on stuttering in your case, as far as I can say from your descriptions about how your PC behaves. The key point you're missing is that once the queues have reached their max values, the CPU/GPU stress factor is exactly the same as if the queue was only 1 frame big! After all the queues are only slowly emptied. The CPU/GPU is only stressed in the very beginning of movie playback where the queues need to be filled up. Once the queues are full, stress is over.

If I decreased the queue to only 4 entries, you'd have your queue oscillating between 3/4 and 4/4. If I increased the queue to 16 entries, you'd have your queue oscillating between 15/16 and 16/16.

Edit: Also is there any chance for you to quickly make a stop-gap release (something like 0.10b) that only fixes the remembering of luma scaling settings?
Even posting in the forum is something I shouldn't really do right now. I've too much "real" work on my hands.

SoftCubic100 blurs away most of the chroma detail.
Do you have a real-world sample where the loss in chroma detail is visible? Having such a sample here on my PC might help madVR development!

[leeperry]

256 levels? So obviously the CLUT is only 8bit input -> 10bit output. Compared to cr3dlut which is 8bit input -> 16bit output.

But is 3x 1D LUT good enough? I think R/G/B influence each other. Why else would cr3dlut use one big 3D LUT instead of 3x 1D LUT?

1)well cr3dlut will be forced to dither to 8bit anyway? RGB32 is 8bit(and so is TMDS over DVI/HDMI <1.3), only the CLUT is 10bit..

2)3x1D LUT is perfectly fine for calibration...we just want the curves to meet properly to reach perfect D65/2.2 levels...as I understand it a 3D LUT is only necessary for gamut transfer functions(which you cannot do w/ 1D LUT's) : http://www.color.org/ICC_Chiba_07-06-19_PM_DMP_Float.pdf

this PDF is simple, yet very instructive :)

the graphic card's CLUT does not support 3D LUT's, only 3x1D LUT's...they always make sure to do it as sloppy as possible as you know :rolleyes:

a .cal file looks like this :

KEYWORD "RGB_I"
NUMBER_OF_FIELDS 4
BEGIN_DATA_FORMAT
RGB_I RGB_R RGB_G RGB_B
END_DATA_FORMAT

NUMBER_OF_SETS 256
BEGIN_DATA
0.0000 0.083189 0.021229 0.023934
3.9216e-003 0.087305 0.047484 0.028051
7.8431e-003 0.091516 0.061404 0.032320
0.011765 0.095825 0.071292 0.036751
0.015686 0.10023 0.079941 0.041354
0.019608 0.10475 0.088256 0.046137
0.023529 0.10937 0.096318 0.051114
0.027451 0.11409 0.10400 0.056294
0.031373 0.11882 0.11121 0.061668
0.035294 0.12350 0.11782 0.067159
0.039216 0.12807 0.12387 0.072689
0.043137 0.13247 0.12948 0.078181
0.047059 0.13671 0.13473 0.083563
0.050980 0.14080 0.13966 0.088789
0.054902 0.14475 0.14437 0.093852
0.058824 0.14860 0.14889 0.098760
~

ARGYLLCMS's coder is very helpful, and would be more than happy to help any CMS to improve...so if yesgrey wants to talk w/ him, he can simply sign up on his mailing list or drop him an email.

I'm sure he could even output 3dlut files if we asked nicely http://forum-images.hardware.fr/images/perso/papepipoupu.gif

that's my stock CRT :

http://thumbnails18.imagebam.com/3762/b89c9f37617327.gif (http://www.imagebam.com/image/b89c9f37617327)

that's after ARGYLLCMS in HQ mode for 25 mins(in a pitch black room w/ the i1d2 stuck to the CRT) :

http://thumbnails6.imagebam.com/3762/77c90837617326.gif (http://www.imagebam.com/image/77c90837617326)

[madshi]

1)well cr3dlut will be forced to dither to 8bit anyway? RGB32 is 8bit(and so is TMDS over DMI/HDMI <1.3), only the CLUT is 10bit..
cr3dlut does not dither down, madVR does. However, dithering down to 8bit should produce very good results. I don't think anyone could see a difference between dithered 8bit and 10bit. But anyway, sooner or later madVR is going to support Windows 7 higher RGB bitdepths. So if your GPU and display supports it, in the future you can enjoy full 16bit per color. But again: I don't expect that many people will be able to see a difference to dithered 8bit...

ARGYLLCMS's coder is very helpful, and would be more than happy to help any CMS to improve...so if yesgrey wants to talk w/ him, he can simply sign up on his mailing list or drop him an email.
Sounds like a good idea to me, but that's really up for yesgrey3 to decide.

[cyberbeing]

No offense, but you don't really seem to understand how these queues work or why they sometimes go down and up again....
Sorry, I guess I don't. I apologize since it really seems I'm misunderstanding something :(

I was just assuming it was something like Haali Renderer's queue, where if you set it too high and you're decoding difficult material, the jitter will go through the roof and stay there. Reducing the Haali Renderer frame queue to something more reasonable will fix these situations when they happen.

Since you wrote madVR, and you're saying it's not the case, I'll believe you. I just hope you are able to fix whatever you believe really is causing delayed/dropped with only small drops in the queues, since you seem to be implying in previous posts that small queue drops like these should not be a major issue, but they obviously are on my PC. :confused:


Even posting in the forum is something I shouldn't really do right now. I've too much "real" work on my hands.

Understood. I'll continue to patently wait then.


Do you have a real-world sample where the loss in chroma detail is visible? Having such a sample here on my PC might help madVR development!
I believe it was from some anime DVD source, but it was awhile ago, so I can't remember exactly which I tested it on. Some previously noisy chroma became nearly flat from the blurring when upscaled with chroma set to SoftCubic100. Mitchell-Netravali was the lowest common denominator I could find which didn't seem to overly blur the chroma, and isn't overly sharp either. I'll see if I can track down another source where it is extremely noticeable.

[madshi]

you seem to be implying in previous posts that small queue drops like these should not be a major issue, but they obviously are on my PC. :confused:
I believe the queue drop is not the cause of the delayed/dropped frames. Instead I believe the real cause is responsible for *both* the queue drop and the delayed/dropped frames.

I'll see if I can track down another source where it is extremely noticeable.
Appreciated.

[roozhou]

Hi madshi
madVR is disappointing me! It seems too GPU intensive to be run on an integrated Graphic chipset.

I have an NVIDIA 6150 Go and 128M shared graphic memory. When I play something in MPC-HC w/ madVR, I encounter serious frame dropping if I upresize the window. And I can hardly do anything else because it takes ~10 secs to show a simple menu during playback. Since CPU usage is below 10%, I'm sure madVR is eating up my GPU.

In contrast VMR9+2D surface+PS 2.0 bicubic resize in MPC works perfectly for me. Also OpenGL renderer+bicubic resize in MPlayer works well and requires even less CPU and GPU. Both have good upscaling.

[Grmpf]

2)3x1D LUT is perfectly fine for calibration...we just want the curves to meet properly to reach perfect D65/2.2 levels...as I understand it a 3D LUT is only necessary for gamut transfer functions(which you cannot do w/ 1D LUT's) : http://www.color.org/ICC_Chiba_07-06-19_PM_DMP_Float.pdf

3x 1D LUT are not perfect, you have wide spaces of colors inbetween which are not direktly calibrated, most film postpro software is using 3D LUTs and all hardware calibration able displays use them as well (look for info at the eizo color graphic series, or the nec spectraviews). To me 3x 1D LUTs of 256 Steps are overkill, you will only need a calibration point every 16 steps or so, but it would be better to have them over the hole 3D colorspace and not only at those 3 vectors of the primaries. Thats what those professionals use, 17x17x17 LUTs - thats covering the hole colorspace and the distance between is not to big, so that the interpolation between is close enough. Just my opinion - using those hardware calibrated tft in my company and be happy with them, but the software we use doesn't give me access to the LUTs (basiccolor).

the graphic card's CLUT does not support 3D LUT's, only 3x1D LUT's...they always make sure to do it as sloppy as possible as you know :rolleyes:

I think madVR+cr3dlut wants to be better than those graphiccards and if yesgrey3 integrates a 3D LUT calibration support at the input side we will.

ARGYLLCMS's coder is very helpful, and would be more than happy to help any CMS to improve...so if yesgrey wants to talk w/ him, he can simply sign up on his mailing list or drop him an email.

I'm sure he could even output 3dlut files if we asked nicely http://forum-images.hardware.fr/images/perso/papepipoupu.gif


I think it would be great to have a direct support for those 3D LUTs in some kind of calibration software and an easy interface/link/whatever between cr3dlut and the calibration software.

[madshi]

madVR is disappointing me! It seems too GPU intensive to be run on an integrated Graphic chipset.

I have an NVIDIA 6150 Go and 128M shared graphic memory. When I play something in MPC-HC w/ madVR, I encounter serious frame dropping if I upresize the window. And I can hardly do anything else because it takes ~10 secs to show a simple menu during playback. Since CPU usage is below 10%, I'm sure madVR is eating up my GPU.

In contrast VMR9+2D surface+PS 2.0 bicubic resize in MPC works perfectly for me. Also OpenGL renderer+bicubic resize in MPlayer works well and requires even less CPU and GPU. Both have good upscaling.
madVR 0.10 does not run well on very slow/old GPUs right now. In fullscreen exclusive mode things should improve a lot, and that may make older GPUs like yours work. But in windowed mode I don't think you'll ever get smooth playback with a GPU like yours when using madVR. madVR was simply never intended for old/slow GPUs. There's a minimum of GPU performance that is needed for madVR to do its work and produce smooth motion results. But as I said, let's wait until fullscreen exclusive mode is fully implemented. Then we can finally judge which GPUs are fast enough for madVR and which are not...

To me 3x 1D LUTs of 256 Steps are overkill
My guess is that they simply want to feed in 8bit without having to interpolate. Of course if you don't interpolate, 8bit (= 256 steps) is the absolute minimum input bitdepth you can use...

you will only need a calibration point every 16 steps or so, but it would be better to have them over the hole 3D colorspace and not only at those 3 vectors of the primaries. Thats what those professionals use, 17x17x17 LUTs - thats covering the hole colorspace and the distance between is not to big, so that the interpolation between is close enough.
Interesting. 17x17x17 is just 4-5 bits input, while cr3dlut is 8bit input. So if 17x17x17 is used (and found good enough) by professionals then the limitation of cr3dlut to "only" support 8bit input should not really matter at all. Thanks to interpolation, madVR+cr3dlut should be able to process even 16bit per channel input data well...

[tetsuo55]

Hi madshi, here is a possible solution for the admin rights issues on Vista and windows 7:


Here is a MS tool that can test applications for problems running as a limited user: http://blogs.msdn.com/aaron_margosis/archive/2008/11/06/lua-buglight-2-0-second-preview.aspx

Basically MPC-HC(or the external filters) should ask for admin rights only when really needed. (prompt uac on action that requires admin rights if not already running with admin rights)

EDIT:
Here is a document explaining the admin rights only when needed functionality
http://www.codeproject.com/KB/vista-security/UAC_Shield_for_Elevation.aspx

[yesgrey]

But is 3x 1D LUT good enough? I think R/G/B influence each other. Why else would cr3dlut use one big 3D LUT instead of 3x 1D LUT?
That's only for correcting the gamma. When doing that each color channel only depends on itself, hence the 1D LUT.
When correcting the color gamut, each color channel will depend on all three color channels, hence the 3D LUT.

[leeperry]

That's only for correcting the gamma. When doing that each color channel only depends on itself, hence the 1D LUT.
When correcting the color gamut, each color channel will depend on all three color channels, hence the 3D LUT.
could a single 3D LUT do the same job as 3x1D LUT's? I'm not quite sure :o

[Grmpf]

could a single 3D LUT do the same job as 3x1D LUT's? I'm not quite sure :o

Yes. the 3 1D LUTs are just 3 vectors inside the 3D LUT room, to give you a image to think about, they are 3 subsets in the 3D LUT.

[leeperry]

ok cool! so importing the .cal file from ARGYLLCMS in cr3dlut would indeed be pretty awesome :)

together w/ the Color.HCFR sats if any possible : http://img19.imageshack.us/img19/5627/satz.png

but for that last point, tritical said that it wasn't doable...yesgrey left the door open :o

[yesgrey]

I've just released here (http://yesgrey3.totalh.com/) cr3dlut v2.2.
v2.2 - 2009/06/03
- Fixed: when performing both Y'CbCr->R'G'B' and color gamut conversions some errors could occur


Once again, I've just released the executable. The source code is still v2.0.
This is just an interim version due to a problem described by leeperry and sucht. I'm currently working in adding custom gamma curves to cr3dlut, so the source code is still a bit messy. In the next release, I should have time to clean up the source code...

Comments/suggestions are welcome.

everytime i use madVR together with the(from me) created *.3dlut file there are black spots or something like that
sucht,
try with v2.2. Should be ok now...

[ryrynz]

Been following your plugin for some time, I check this forum every day. I have been using Madvr as my default renderer since 0.8 and find it to be amazing.

I am currently using 0.9 with no issues what so ever except
I have no idea where to find the settings.

The only area I can find the ability to do so is in MPC under View-Renderer settings but these are often grayed out.

There are no options under shaders and DSF manager doesn't allow me to change anything either. (both of these I read in the forums as possible ways to change the settings)

I'm quite happy with the default settings but knowing where to go to change the stuff I see mentioned in this thread would be nice.

On an off note I find it amazing how you can reply to statements and questions regarding what you've created to people who know almost next to nothing about your creation in comparison to yourself.

I am of the belief they almost shouldn't be wasting your valuable time and to accept what is.

I think some people in this forum should be more humble, considering you obviously know more about MadVR than anyone else here or anywhere.

Serious respect Madshi.

[yesgrey]

I am currently using 0.9 with no issues what so ever except I have no idea where to find the settings.

Right click in the screen while playing a file, select Filters, and then Madshi Video Renderer.

[sucht]

sucht,
try with v2.2. Should be ok now...

it is OK on *.mkv *.avi files, thanks.
but i could not test it with DVDs because of this stupid Macrovision Failure, since i swiched to Vista 64bit and Windows 7 64bit :(

ciao and thank you :)
sucht

[yesgrey]

but i could not test it with DVDs
But it should be ok too. Thanks for testing it.

[ryrynz]

Right click in the screen while playing a file, select Filters, and then Madshi Video Renderer.

Currently running madVR 0.9 on two machines, both using build MPC-HC build 1.2.1220 and this option does not exist under filters.

Something wrong with my config perhaps?

Thanks Yesgrey.

[Hypernova]

Currently running madVR 0.9 on two machines, both using build MPC-HC build 1.2.1220 and this option does not exist under filters.

Something wrong with my config perhaps?

Thanks Yesgrey.

It should be there. The name is madVR. Otherwise, maybe you're not using it?

[yesgrey]

Otherwise, maybe you're not using it?
Yes. MPC-HC when cannot use the selected video renderer uses the default one. Check if you are outputting in YV12...

[ikarad]

I don't know whether .icm color profiles work or don't work. If they work in games they should also work in madVR, cause madVR basically behaves like a game.

However, I'd not be sad at all if the .icm color profiles didn't work because the plan is to use cr3dlut for complete display calibration.




...
With games I must use monitor calibration wizard to force use of .icm in games.

But with madvr monitor calibration wizard doesn't work.

[ikarad]

I don't know if you mean strictly .ICM profile or LUT files.

HR doesn't care for .ICM files because it's not color managed..but it does care for LUT files in ARGYLLCMS(actually all the renderers do, except Overlay)

anyway, ARGYLLCMS is far more accurate than any other color calibration package, especially in "HQ" mode :)

how create 3dlut file with my icm file and argyllcms?

[leeperry]

how create 3dlut file with my icm file and argyllcms?
it's not possible (yet?).
you need to create a graphic card's CLUT w/ ARGYLLCMS, it's been thoroughly discussed on HCFR ;)