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

madshi

31st March 2014, 14:17

XYZ is 12-bit data, not sure what "format" you mean, its in XYZ format of course! :)
With format I meant integer vs. float. So it's 12bit int, good to know...

I know I've been saying this for a while and at some point you'll probably start ignoring me each time I repeat this, but CMSes (e.g. LittleCMS, Argyll) *do* know how to handle the minute details of gamut mapping, rendering intent, and white point matching. Sorry to be blunt, but you're reinventing the wheel, and it's a *very* complicated wheel to reinvent in an area in which, by your own words, you seem to have limited expertise. Let CMS libraries take that burden off your chest. It would also take the burden of generating 3DLUTs off the chest of your users (since you would be able to support ICC quite easily).

I know you said you don't want to use CMSes or ICC because you find them confusing. I would be happy to answer any questions you might have to clear up any confusion (to the best of my knowledge, of course - in any case we can still ask Graeme). I guarantee you, no matter how confusing these might look to you, they are still way, way easier to understand than the complex color conversion challenges you're facing.

I'm sorry to always bring up this topic again, but it's frustrating to see that this technically superior solution is systematically dismissed with no reasonable explanation. It's your software though, and I know how to use 3DLUTs so it's not that big of a deal for me personally, but still.
There are really 2 separate issues here:

(1) Simple gamut conversion of some source gamut to the display gamut.

If the display is externally calibrated to (or factory calibrated near to) BT.709, as probably many displays are these days, madVR does a very simple gamut conversion by using shader math. This is really simple code and should work just fine for simple conversions like BT.709 <-> SMPTE-C <-> PAL/EBU. I don't think it would make sense to use LittleCMS or Argyll for such a simple operation, if the HTPC isn't used for calibration otherwise.

The situation is different if the display is calibrated by using the HTPC somehow, either by using a 3dlut, or an icc profile or something else. In that case using the calibration system to convert the source gamut to the display gamut may make sense. But this is really only the case for a very small minority of madVR users. The majority of users doesn't use the HTPC for calibration, so the simple gamut conversion shader code madVR currently uses is a much better solution for the majority of users.

Maybe proper DCI-P3 handling is a different topic, maybe there simple shader math is not good enough. I do not know this. But even if DCI-P3 does require using a complex external calibration software like LittleCMS/Argyll/Whatever, that doesn't mean that simple gamut conversion from e.g. SMPTE-C to BT.709 should also by done through the calibration software, even if the HTPC isn't used for calibration.

So from my point of view you're throwing two different things together here, which don't belong together. Saying that using ICC profiles would solve the DCI-P3 problems might be true for users who are actually using ICC profiles. But the situation is different for the majority of users, who don't use the HTPC for calibration and who don't use any ICC profiles, 3dluts or whatever. Using LittleCMS/ArgllCMS in that case would be overkill, would slow processing down, and actually hurt accuracy, because LUT interpolation is simply not as exact as floating point shader math.

(2) Using the HTPC to calibrate the display.

For this supporting ICC profiles would make some sense. And I'm not saying that I'll never support that. But you have to understand that it's not a 5 minute job to rewrite the whole calibration logic to use ICC profiles. It would be *A LOT* of work, would require a lot of thinking (how to support already existing 3dlut files etc), and in the end the main benefit would be a comfort improvement for a small percentage of madVR users. Those madVR users who actually do use madVR for calibration can create proper calibration 3dluts by using e.g. the freeware ArgyllCMS. So madVR already has all the features that are necessary for high quality calibration. It might not be as comfortable as you'd like it to be. But don't forget that madVR is still not feature complete, and there are still several key features missing, which would benefit the majority of madVR users.

So tell me: Why would I spend a large part of my development resources on something which would just result in a comfort win for a minority of users, when I could spend the time for adding totally missing features which would benefit the majority of users instead? Makes no sense. I will probably have a look at the whole calibration stuff again when I reach that point in my priority list. Which is not today, or any time soon.

Farfie

31st March 2014, 14:28

Well those two tradeoffs are both very minor IMO. Chroma doesn't need Jinc3 and ordered dithering looks very good. I would probably switch to ordered dithering myself but it is close. :)

Yeah, I've heard that chroma matters the least multiple times, and also that the Ordered Dithering + option 2 looks very very nice for the resources it consumes...

I watch mostly animated content.. what if I did:
chroma upscaling nnedi3@32
luma doubling nnedi3@64
ordered dithering + option 2
?

Seems I can handle it, and it looks nice.

e-t172

31st March 2014, 14:54

madshi: thanks for the explanation. I agree with most of it and your perspective makes a lot of sense. However, there is one point on which I disagree:

For this supporting ICC profiles would make some sense. And I'm not saying that I'll never support that. But you have to understand that it's not a 5 minute job to rewrite the whole calibration logic to use ICC profiles. It would be *A LOT* of work, would require a lot of thinking (how to support already existing 3dlut files etc), and in the end the main benefit would be a comfort improvement for a small percentage of madVR users.

That might be a chicken-and-egg problem. I suspect a lot of users are not calibrating on their HTPC (by the way, is this true? It would be great to have some numbers on that) precisely because it is currently very complicated, time-consuming and easy to get wrong. With the current state of affairs, to achieve proper calibration using madVR and 3DLUTs you need to follow a very complicated procedure comprised of a dozen convoluted steps, most of which make use of obscure Argyll programs on the command line with very specific sets of parameters (and if you get them wrong you can end up with a result that's broken in subtle ways). And if you want to generate corrections for multiple input color spaces it gets even worse. That's a horrible user experience and I would not be surprised if it deterred a lot of users from trying it out.

Contrast this with how it's done for ICC-aware applications (madVR could become one of them):

Buy a sensor.
Unpack the sensor. Install the software provided with the sensor.
Use the software's easy 3-step wizard to generate a ICC profile. (a child could do it)
Done. No need to do anything else. madVR will automatically use the installed ICC profile and do The Right Thing out-of-the-box for all input colorspaces. That includes BT.1886 and all the bells and whistles.

Wouldn't that be wonderful? In fact, this can be simplified even further if the user is comfortable using a third-party profile (either from the monitor manufacturer or from the community), in which case it goes down to only two steps!

I have a lot of ideas in my head about how this could be implemented in madVR (including how madVR would use the CMS and generate the 3DLUT, how the UI would look like etc.). I would be happy to write them down in a comprehensive coherent document, but I get the feeling I would be wasting my time at this point. Oh well, at least I tried. As I said above, you do make some good points.

madshi

31st March 2014, 15:46

That might be a chicken-and-egg problem. I suspect a lot of users are not calibrating on their HTPC (by the way, is this true? It would be great to have some numbers on that) precisely because it is currently very complicated, time-consuming and easy to get wrong. With the current state of affairs, to achieve proper calibration using madVR and 3DLUTs you need to follow a very complicated procedure comprised of a dozen convoluted steps, most of which make use of obscure Argyll programs on the command line with very specific sets of parameters (and if you get them wrong you can end up with a result that's broken in subtle ways). And if you want to generate corrections for multiple input color spaces it gets even worse. That's a horrible user experience and I would not be surprised if it deterred a lot of users from trying it out.

Contrast this with how it's done for ICC-aware applications (madVR could become one of them):

Buy a sensor.
Unpack the sensor. Install the software provided with the sensor.
Use the software's easy 3-step wizard to generate a ICC profile. (a child could do it)
Done. No need to do anything else. madVR will automatically use the installed ICC profile and do The Right Thing out-of-the-box for all input colorspaces. That includes BT.1886 and all the bells and whistles.

Wouldn't that be wonderful? In fact, this can be simplified even further if the user is comfortable using a third-party profile (either from the monitor manufacturer or from the community), in which case it goes down to only two steps!
It's not as easy as that, unfortunately. You make it sound as if every calibration software produces the same results, which is not the case, unfortunately. E.g. look here:

http://www.avsforum.com/t/1517849/a-comparison-of-3dlut-solutions-for-the-eecolor-box

There's quite a fight over which calibration software produces the best 3dluts. And these are the pro software packages. If you use the simple applications coming with a cheap meter the resulting ICC profiles will probably pretty low quality. So which software should madVR use? Some end users may already have a Calman, ChromaPure or LightSpace license, so they will want to use that software to do the madVR calibration. Then add to that the free ArgyllCMS.

Of course I could try to automate ArgyllCMS. But then there's the question which exact settings to use. Some people get best results using absolute rendering intent, while others get better result with relative rendering intent. Some get better results doing an extra dispcal calibration pass, some get better results without it. Those who use dispcal either get better results when including the calibration into the 3dlut, or not. So many different variations and how would madVR know which one to use? Sure, I could make that all available as options, but then how would this be so very different from the dispcalGUI?

And again the key point: This would cost me several days to implement, and there are many things that I could in the same time which IMHO would benefit a larger percentage of the madVR users.

I have a lot of ideas in my head about how this could be implemented in madVR (including how madVR would use the CMS and generate the 3DLUT, how the UI would look like etc.). I would be happy to write them down in a comprehensive coherent document, but I get the feeling I would be wasting my time at this point. Oh well, at least I tried. As I said above, you do make some good points.
I'm quite open to suggestions, but I would store all of your ideas under "to look at some time in the future", and it could take quite a while until I get to that. Furthermore, I could only make use of your ideas if we are on the same page about the basic concept. And I think we are not at the moment. You seem to want to use the software shipping with the meter, and I think that might not be the best solution.

Generally, there are many features in madVR which are "half complete", meaning they mostly work, but are not as nice and polished and comfortable as they could be. Calibration is one of those, others are e.g. display mode switching, screenshots, OSD, and many more. At some point I'm going to polish it all up, but for now I'm more concentrated on adding in all the missing features. And I'm aiming for such features which I either personally wish for/need, or which I think would bring the highest benefit for the largest number of madVR users.

annovif

31st March 2014, 15:57

I think e-t172 is right, in practice he has read in my mind. I've just bought a good sensor to calibrate my projector, but i was waiting for a more simple procedure. Thank you for your very good idea.:thanks:

Madshi , i read now your answer and i can tell you that my sensor can wait. YOU are the BOSS!!!!!!!:):):)

Ver Greeneyes

31st March 2014, 16:21

dispcalGUI has a lot of options since the underlying package (ArgyllCMS) has a lot of options, but if you just follow a guide it's a pretty simple process (if a lengthy one). The only extra step for madVR is that after profiling, you have to go into the Tools menu and use the Create 3DLUT option. Sure, experimenting with command line options using ArgyllCMS might not be everyone's cup of tea, but if options dazzle you so much that you don't want to use dispcalGUI, maybe madVR isn't your cup of tea either..

Mind you, I'm not saying you have to use dispcalGUI or ArgyllCMS if you're already using another package that you like, but using them just to make a 3DLUT out of your existing profile isn't hard.

e-t172

31st March 2014, 16:29

It's not as easy as that, unfortunately. You make it sound as if every calibration software produces the same results, which is not the case, unfortunately. E.g. look here:

http://www.avsforum.com/t/1517849/a-comparison-of-3dlut-solutions-for-the-eecolor-box

There's quite a fight over which calibration software produces the best 3dluts. And these are the pro software packages. If you use the simple applications coming with a cheap meter the resulting ICC profiles will probably pretty low quality. So which software should madVR use? Some end users may already have a Calman, ChromaPure or LightSpace license, so they will want to use that software to do the madVR calibration. Then add to that the free ArgyllCMS.

Of course I could try to automate ArgyllCMS. But then there's the question which exact settings to use. Some people get best results using absolute rendering intent, while others get better result with relative rendering intent. Some get better results doing an extra dispcal calibration pass, some get better results without it. Those who use dispcal either get better results when including the calibration into the 3dlut, or not. So many different variations and how would madVR know which one to use? Sure, I could make that all available as options, but then how would this be so very different from the dispcalGUI?

True. I follow a more restrictive principle in that in most cases, people's personal preferences don't matter: what matters is what's correct from a colorimetric point of view and from a standards (e.g. BT.709, BT.1886) point of view. Besides, I'm not saying that we should remove the possibility to use other software packages. There would still be the option of using 3DLUTs, and by adding support for ICC device link profiles it is possible to support transforms generated by any third party ICC software. What I'm saying, however, is that madVR should provide a default high-quality, out-of-the-box support for ICC; I'm not saying that it should make it inflexible or prevent people from using their own software. As you said, people who want to spend a lot of time on this are not the target user for this feature as they probably don't mind going through the hassle of dealing with 3DLUTs. The point is to make it easy and less error-prone for the average madVR user.

If you use the simple applications coming with a cheap meter the resulting ICC profiles will probably pretty low quality.

I don't think so. Such software would only be used to measure the device and generate an ICC profile, which is not hard to get right. What's hard is generating the transform, for which madVR would a trusted CMS.

And again the key point: This would cost me several days to implement, and there are many things that I could in the same time which IMHO would benefit a larger percentage of the madVR users.

Fair enough.

You seem to want to use the software shipping with the meter, and I think that might not be the best solution.

That was just an example of how the user could use this feature in the quickest way possible (path of least resistance). Again I'm not saying madVR should restrict the user when it comes to which software to use for color correction. If the user wants to use more trustworthy software to generate the ICC profile, so be it. In fact I believe madVR shouldn't even have a say in this, because it shouldn't care. After all Photoshop doesn't care which software you use to generate the ICC profile either. That's what makes ICC so attractive as an industry standard (which 3DLUTs are not).

Generally, there are many features in madVR which are "half complete", meaning they mostly work, but are not as nice and polished and comfortable as they could be. Calibration is one of those, others are e.g. display mode switching, screenshots, OSD, and many more. At some point I'm going to polish it all up, but for now I'm more concentrated on adding in all the missing features. And I'm aiming for such features which I either personally wish for/need, or which I think would bring the highest benefit for the largest number of madVR users.

Yes, I realize that, and I realize from reading my own first paragraph above that this clearly fits into the "polish" category, so it makes sense not to prioritize it with regard to your development strategy. I'll shut up now :)

madshi

31st March 2014, 16:55

True. I follow a more restrictive principle in that in most cases, people's personal preferences don't matter: what matters is what's correct from a colorimetric point of view and from a standards (e.g. BT.709, BT.1886) point of view.
Yes, of course. But even then the different calibration applications produce different results. And it depends on the display, too. E.g. zoyd measured ArgyllCMS to produce mathematically better results than Calman/LightSpace (see the thread I linked to earlier), but that only applies to his display. With my display (which has undersaturated primaries), using zoyd's ArgyllCMS options, I'm not getting very good results. I'm getting better results with a different AryllCMS command chain. And I've not tested Calman/LightSpace yet...

Besides, I'm not saying that we should remove the possibility to use other software packages. There would still be the option of using 3DLUTs, and by adding support for ICC device link profiles it is possible to support transforms generated by any third party ICC software. What I'm saying, however, is that madVR should provide a default high-quality, out-of-the-box support for ICC; I'm not saying that it should make it inflexible or prevent people from using their own software. As you said, people who want to spend a lot of time on this are not the target user for this feature as they probably don't mind going through the hassle of dealing with 3DLUTs. The point is to make it easy and less error-prone for the average madVR user.
Ok, let's talk about how to make it easy for the average madVR user: Either he has a meter or he doesn't. If he has a meter, why would it be better to let him use the software shipping with his meter instead of e.g. letting madVR automate ArgyllCMS? If madVR automated ArgyllCMS, that would mean even less things to do for the user, and the final quality would probably be better.

I don't think so. Such software would only be used to measure the device and generate an ICC profile, which is not hard to get right.
But such software would probably only measure the white point, the primaries and maybe the gamma response, and then store those results in the ICC profile, correct? Such a calibration only works properly if the display response is more or less linear. If the display is non-linear, you need a real 3dlut with measurements and corrections for e.g. a 17x17x17 3D cube. I don't think that software shipping with a meter usually creates such ICC profiles.

James Freeman

31st March 2014, 17:10

madVR v0.87.8
Thank You !!!

I can see improvement for chroma with NNEDI 16 from Lanczos 3.
Although it's so small I'm not sure its worth the +30% GPU Load (from 9% to 42%).

omarank

31st March 2014, 17:13

If the gamut conversion is done with white point matching, the data should be 235/235/235 in that case. My understanding of colorimetry is limited though, so maybe someone else can correct me here. Anyway, the point is that if the white point matching is done, there should not be any colour cast with any content being played and this can be best seen with a 100% white pattern.

I'm not sure if that's correct. And I'm not sure if white point matching should be done. I simply don't know...

Perhaps when you revisit the colour correction and calibration features in madVR, you can consult with somebody having an expertise in this area like Graeme, e-t172. It would be really great if you could at least optionally provide gamut conversion with white point matching.

@ e-t172: Since you seem to have good knowledge in this area, could you please tell if what I wrote is correct? If not, then what will be the right approach to do gamut conversion if the source and target white points differ? IMHO, watching a video with some colour cast is not a pleasant experience.

e-t172

31st March 2014, 17:19

To be honest I am not an expert in these colorimetric matters. madshi isn't either which is precisely why I was advocating the use of a CMS (which does a good job at hiding all this complexity, or at least most of it). I would not be able to confidently answer your question. Graeme is probably the one to ask.

Budtz

31st March 2014, 18:41

My card can run ether NNEDI chroma upscaling or the image doubleing - but not both

i watch equal parts high qulity 1080p or 720p content and no sd content.

wich setting is good?

michkrol

31st March 2014, 18:53

My card can run ether NNEDI chroma upscaling or the image doubleing - but not both

i watch equal parts high qulity 1080p or 720p content and no sd content.

wich setting is best?

The one you like better :sly:
It depends greatly on your target resolution. I personally don't see much of a difference between 720p->1080p with NNEDI or Lanczos/Jinc and on 99% of HD sources I see no difference beetween chroma upscaling algorithms (apart from nearest neighbor). It might be just me.
You can always make profiles to use NNEDI doubling for 720p and smaller, but use NNEDI chroma upscaling for 1080p.
You need to test it for yourself, maybe you'll prefer disabling NNEDI altogether to have cooler and quieter GPU? The choice is yours.

pokazene_maslo

31st March 2014, 19:51

Hi. I have found a bug. When I connect to my computer through remote desktop and start file playback, MPC-HC will stop responding. No image will appear.

System spec:
Win 8.1 x64 PRO
MPC-HC 1.7.3
madVR 0.87.8 (same behavior with 0.87.7)
AMD radeon HD6970 2GB+ catalyst 14.3b1

Thanks.

e-t172

31st March 2014, 19:58

* fixed: smooth motion frc sometimes incorrectly dropped frames

I hereby confirm that this bug is fixed for good. All counters at zero even after 5h+ of playback on a 770 with drivers 335.23. Many thanks!

(though I cannot help but quietly weep at the fact that I spent entire week-ends trying to chase down a bug that madshi fixed in 3 hours just by looking at a log :( )

madshi

31st March 2014, 20:37

My card can run ether NNEDI chroma upscaling or the image doubleing - but not both

i watch equal parts high qulity 1080p or 720p content and no sd content.

wich setting is good?
Usually image doubling gives you a bigger improvement.

When I connect to my computer through remote desktop and start file playback, MPC-HC will stop responding. No image will appear.
I'm aware of this, but I can't fix it at the present time. The GPU is not reporting any proper VSync scanline information to madVR in this situation, which is required by madVR to time the rendering/presentation.

I hereby confirm that this bug is fixed for good. All counters at zero even after 5h+ of playback on a 770 with drivers 335.23. Many thanks!

(though I cannot help but quietly weep at the fact that I spent entire week-ends trying to chase down a bug that madVR fixed in 3 hours just by looking at a log :( )
I'm sorry about that. FWIW, it took quite some detective work to find the cause of the problem in the log. And if it's any consolation for you, I'm spending entire weeks (which I should really spend on commercial work) developing madVR...

truexfan81

31st March 2014, 20:40

and we thank you for that madshi

e-t172

31st March 2014, 20:58

I'm sorry about that. FWIW, it took quite some detective work to find the cause of the problem in the log. And if it's any consolation for you, I'm spending entire weeks (which I should really spend on commercial work) developing madVR...

Sorry if I came off as rude, that wasn't my intention. What I meant was I was angry with myself - I should have tested Intel and sent you a new log much earlier instead of chasing ghosts.

Guest

31st March 2014, 21:11

I'm half way through ST-Deep Space Nine, with the best DVD rip I can source You replied in PM that these were torrent downloads. Since you're new here apparently you haven't read our rules, because otherwise you would know you can't discuss that stuff here. So it's a warning this time. Please read and follow our forum rules, especially rule 6. Thank you.

@all

No help to be given on this issue.

Werewolfy

31st March 2014, 21:32

madVR v0.87.8 released

http://madshi.net/madVR.zip

* added workaround for NVidia OpenCL <-> D3D9 interop driver bug
* fixed: #158: NNEDI3 chroma upscaling + DXVA deint + NVidia -> green image
* fixed: DirectCompute rendering resources weren't properly released
* fixed: some multi monitor problems introduced in v0.87.7
* fixed: smooth motion frc sometimes incorrectly dropped frames
* fixed: toggling subtitle "trade quality" option required restart
* some DirectCompute stability improvements
* added vendor based OpenCL device filtering
* non-DX11-GPUs: error diffusion now falls back to ordered dithering
* improved Windows 8.1 FSE mode refresh rate hack
Extra thanks to qduaty for providing the workaround for the NVidia OpenCL driver bug.

The workaround for the Nvidia OpenCL driver bug works on my PC too so I can finally update my drivers :) When I read that you improved the FSE refresh rate hack, I hoped it would resolve my problem but unfortunately it's still note the case.

madshi

31st March 2014, 21:37

Sorry if I came off as rude, that wasn't my intention.
I didn't read it as rude at all, no harm done. I just felt sympathy for your lost weekends...

The workaround for the Nvidia OpenCL driver bug works on my PC too so I can finally update my drivers :) When I read that you improved the FSE refresh rate hack, I hoped it would resolve my problem but unfortunately it's still note the case.
FWIW, the improvements were the tries to fix the problem, which didn't really work in the end (already tested). But I left the improvements in there, in the hope that it might help some people.

turbojet

31st March 2014, 21:37

Could the lanczos vs cr ll depend on if screen is calibrated or not? If that's the case, the vast majority have a non-calibrated display, tough to recommend something that very few have.

Madshi: I agree the pre-resize doesn't look very good in that example. At low resolutions, sharpening is difficult to do, this is another reason for post-resize sharpening. While the picture is a great test for sharpeners the low resolution doesn't really represent a common use these days. I've been trying to figure out how to get stronger sharpening post-resize without having to set lumasharpen strength to ridiculous values like 8.0, that destroys high contrast edges, I think I've found out how but that's for another thread.

The latest madvr seems to be a little faster on a gtx650, it works well with latest whql and can now do either nnedi16 chroma upscaling + nnedi16 luma or nnedi32 luma for SD versus nnedi16 luma. I chose the latter as I didn't care for nnedi16 for chroma upscaling, seemed like a lot of artifacts. I know 32+ neurons is suggested but I never had an issue with 16 neurons luma and don't really notice a difference with 32 neurons.

Confirmed that nvidia levels have to be adjusted after every driver install and again madlevelstweaker didn't work. Luckily the tv can output full range in pc mode but are all tv's able to do this? This would be another reason to add profiles for ranges.

madshi

31st March 2014, 22:22

Confirmed that nvidia levels have to be adjusted after every driver install and again madlevelstweaker didn't work.
madLevelsTweaker does work. Let me guess: You probably have a multi-monitor setup and you didn't move the madLevelsTweaker window to your TV before activating the "Force PC levels" checkbox, correct? madLevelsTweaker is intentionally written to only affect the monitor the window is placed on. In contrast to that the other tool you've been using simply forces PC levels on all monitors. I think madLevelsTweaker does it better because there might be cases where you want to force PC levels on one monitor, but not another. Besides, madLevelsTweaker works for both NVidia and Intel GPUs, while that other tool only works for NVidia.

turbojet

31st March 2014, 22:28

It's only a single display setup but I have a fake screen set as primary and that's where I ran the tweaker on. There's only one display seen by madvr and device manager though. I'll try moving it to the other screen next time. Another thing is the exe doesn't request admin on windows 8.1 but does on windows 7.

nevcairiel

31st March 2014, 22:32

Are you sure you didn't turn down UAC on Windows 8.1 so it just doesn't come up? Asks for admin for me.

turbojet

31st March 2014, 22:34

I set UAC down one from default, so it doesn't dim the display. Other exe's request fine. Windows 7 with same uac setting also requests. On the exe icon there is no colored shield like other exe's that request admin. The exe is v1.1.0.0 dated 1/23/2014

EDIT: Default UAC doesn't request either.

Madshi: I understand the reason for using on a certain display but that's a real shot in the dark for multi display setups. Maybe notifying the user that has to be done in the gui or something?

JonnyRedHed

31st March 2014, 23:25

You replied in PM that these were torrent downloads. Since you're new here apparently you haven't read our rules, because otherwise you would know you can't discuss that stuff here. So it's a warning this time. Please read and follow our forum rules, especially rule 6. Thank you.

@all

No help to be given on this issue.

I apologize to everyone, it will not happen again.

sexus

31st March 2014, 23:28

well thanks alot madshi youve did it again , now we nvidia users can finally use NNEDI3 again thanks alot bro , insane just think about it one person working for free fixes direct compute dx9 interop issue in less than a week , while nvidia that has an entire paid team on fixing driver issues

Guest

31st March 2014, 23:30

Thanks for your understanding, Jonny. We have this policy to protect our forum.

You mentioned you own the box set but it's on loan. We certainly can help you with stuff you legitimately own. Please be careful to make that clear when you post.

And welcome to the forum!

JonnyRedHed

31st March 2014, 23:32

leeperry

31st March 2014, 23:59

It would be nice to see a proper nvidia/AMD comparison chart in order to see how the AMD inter-op lag translates IRL, it's pretty handy how CUVID's deinterlacing doesn't work behind Reclock's back :)

Asmodian

1st April 2014, 02:54

The point is to make it easy and less error-prone for the average madVR user.

I am sure madshi is done with this topic (please ignore me unless you really want to comment madshi. :) ). I just wanted to point out that you are assuming something like Photoshop's use of ICC profiles for color management is correct all the time. People have issues creating ICC profiles for Photoshop too. Sure the simple no-option calibration software always generates an ICC profile you can use in Photoshop that corrects more than simple GPU gamma ramps but that doesn't mean the same isn't true with Argyllcms. If you want simple just run with the default madVR settings in dispcalgui and use the resulting 3DLUT. You might be able to get better results but that is true with any method.

The idea that "it just works" with ICC profiles is simply not true. The same trade-offs still need to be made and there are still no correct answers for all situations and all displays.

Also the rendering intents of Photoshop are quite different from what is wanted in madVR. The defaults in many calibration packages are terrible for madVR.

I do agree that calibration in madVR is a bit more complicated than is ideal but I think most of that is mixing the people who want a one-click option with the people who want to tweak until it is perfect. The one click people get scared away because the tweakers can never agree on the ideal settings. If madVR v100+ had a very simple one-click automated option for Argyllcms with decent settings I believe most everyone would be happy. Us tweakers would never agree on the "decent settings" but our discussions would be hidden from the one-clickers. :)

kasper93

1st April 2014, 03:04

Us tweakers would never agree on the "decent settings" but our discussions would be hidden from the one-clickers. :)

For me there is nothing to agree on, settings depends on hardware, viewing conditions and so on. There is none perfect set of settings. Of course if we are aiming at decent calibration and not just crappy one. And I think everyone who bought colorimeter want to get the best out of it and this require some fine tuning.

I think http://www.avsforum.com/t/1471169/madvr-argyllcms/ is very easy guide to start with and 1666 posts where you can find all informations needed to get "perfect" 3dlut for madVR. And if you are still not sure about something you can ask there :)

One-click solution would be just bad. Of course standalone tool only for madVR with ability to set most important settings would be ok, but we have dispcalGUI already and it does good job.

Asmodian

1st April 2014, 03:20

But what about the people who ask for madVR to "just use my ICC profile that XYZ software generated"? They don't want to have to decide options.

Of course if you think http://www.avsforum.com/t/1471169/madvr-argyllcms/ is a very easy guide to start with you are not the target user for this hypothetical one click (OK, maybe not quite one-click but just a few of the most important options) tool. ;)

Happy tweaking fellow tweaker. :D

Farfie

1st April 2014, 03:29

But what about the people who ask for madVR to "just use my ICC profile that XYZ software generated"? They don't want to have to decide options.

Unfortunately due to my limited knowledge, I am precisely one of these :o
I bought a Spyder4Pro and did what it told me, and as far as I could tell, whenever I hit "disable GPU gamma ramps" in madvr, it simply turned the generated ICC profile off, so I left it unticked, like so:
http://puu.sh/7Rx2Z.png

As for the other settings, well, they're just my best guess, lol. :confused:

Asmodian

1st April 2014, 03:57

With a normal monitor or TV that probably looks great.

I would say that is the correct settings for you unless your monitor has a wider or narrower gamut.

What you need to understand is that there are two parts of the calibration in an ICC profile.

There are the gamma ramps which correct white to be the target white, all the grays to be gray, and can change the overall gamma. This is loaded into the video card and effects everything displayed.

There is also a profile stored in an ICC profile. This is a map of what is displayed when asking for 100% red, 100% green, 100% blue, and a lot of other ratios. There are a lot of different ways of storing this kind of information in the profile, LUTs, matrices, etc. but they all allow coveting gamuts and correcting non-white/gray colors. If you have a wide gamut display your 100% red, for example, is probably more red than the video expects so the profile will tell you how much green and blue to add to get the same 100% red as defined in the standard (e.g. BT.709). Also a display will probably not be perfectly linear so as you increase the saturation of a color the color actually displayed will increase differently, slower in some ranges and faster in others. A profile storing this information allows you to account for it.

Simply leaving your calibrated gamma ramps in place is a good start for calibration and probably does the most obvious changes but if you want to correct everything you need to use the information from a profile too and the only way for madVR to do this now is using yCMS (simple gamut mapping) or a 3DLUT (anything you can get Argyll to do).

James Freeman

1st April 2014, 04:18

I didn't read it as rude at all, no harm done. I just felt sympathy for your lost weekends...
:D Funny stuff.

About ICC profiles,
I have suggested madshi to use http://www.littlecms.com/ (Little CMS).
Its a ready code, just copy and paste, MPC-HC already uses with great results.

Asmodian

1st April 2014, 04:43

That runs on the CPU doesn't it? I think madshi wants a pure GPU solution? (no extra copyback)

Farfie

1st April 2014, 06:59

Asmodian

1st April 2014, 08:48

Ah a wide gamut monitor benefits a lot more from a 3DLUT then a standard gamut monitor. Blu-ray is intended to be displayed on a standard sRGB (BT.709) gamut. A 3DLUT allows it to be converted to display correctly in your wider gamut.

http://www.avsforum.com/t/1471169/madvr-argyllcms/ is a good place to start. I do suggest figuring out how to install the correction files (http://www.argyllcms.com/doc/oeminst.html) for your Spyder4Pro, they can help avoid a color cast when using Argyll / dispcalGUI.

nevcairiel

1st April 2014, 09:41

That runs on the CPU doesn't it? I think madshi wants a pure GPU solution? (no extra copyback)

MPC-HC just uses LittleCMS to produce a LUT from the ICC, and then processes the image in a pixel shader, no copy-back.

leeperry

1st April 2014, 11:13

I do have a wide gamut monitor though, what would I change in madvr to account for this?
If you wanna map gamuts, either you go the 3DLUT route or you load this script (http://www.avsforum.com/t/912720/color-correction-with-a-htpc-simpler-solution-and-now-it-really-works/0_100) in Excel...it takes 30 secs to fill in and you're good to go. Many media players(MPC-HC, KMPlayer, PotPlayer) support those scripts and some of them will even allow you to set automatic profiles based on frame rate/resolution.

jkauff

1st April 2014, 13:29

And if it's any consolation for you, I'm spending entire weeks (which I should really spend on commercial work) developing madVR...
We keep trying to pay you. You're going to get a flood of donations when you hit 1.0, so it'll be worth it in the long run.

madshi

1st April 2014, 14:02

Well hopefully i did this right and hopefully it helps.
According to your log the Direct3D device is tied to the Intel GPU and as a result OpenCL is also executed on the Intel GPU. Are you sure you really forced the NVidia GPU active? Here's a test build which prefers NVidia/AMD over Intel, if both are available. Maybe it helps?

http://madshi.net/madVRoptimus.rar

I set UAC down one from default, so it doesn't dim the display. Other exe's request fine. Windows 7 with same uac setting also requests. On the exe icon there is no colored shield like other exe's that request admin. The exe is v1.1.0.0 dated 1/23/2014

EDIT: Default UAC doesn't request either.
Weird, it does here.

Madshi: I understand the reason for using on a certain display but that's a real shot in the dark for multi display setups. Maybe notifying the user that has to be done in the gui or something?
Yeah, I guess I can add a hint to the GUI to make clear that you have to move the window to the target monitor.

We keep trying to pay you.
True. Well, I wasn't really complaining about my time investment...