Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Hardware & Software > Software players

Reply
 
Thread Tools Search this Thread Display Modes
Old 6th June 2011, 13:22   #7961  |  Link
SamuriHL
Registered User
 
SamuriHL's Avatar
 
Join Date: May 2004
Posts: 5,351
Quote:
Originally Posted by madshi View Post
Yes. Furthermore: This is just with the standard resamplers. Image quality should further improve when I implement some better quality upsamplers. (Not too soon, though.)
That would be really nice. I'm at the beginning of a project that will likely take me all summer to complete. We ran out of shelf space in my living room, so, I took most of my DVD's and boxed them up. The plan is to get a couple external hard drives over the summer and rip all my DVD's to it. Probably as MKV's so I can use madVR. Upscaling is very important to me. That's why I'm so excited by what we're seeing already.

Quote:
Originally Posted by madshi View Post
Oh, this does look like a madVR problem, not an MC problem. Is this 100% reproducible?
On that one file it is. I checked a couple other DVD->MKV's that I have and they don't do it. Just Empire Strikes Back. This wasn't happening before. Let me know what I can do to help on this one and I'll see if I can find some time.
__________________
HTPC: Windows 11, AMD 5900X, RTX 3080, Pioneer Elite VSX-LX303, LG G2 77" OLED
SamuriHL is offline   Reply With Quote
Old 6th June 2011, 13:24   #7962  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Quote:
Originally Posted by madshi View Post
Are you sure? If that's true, I consider it a bug in yCMS. yCMS should not clip BTB/WTW, so it should also not clip full-range videos.
Since v1.6 yCMS is not clipping BTB/WTW anymore.
yesgrey is offline   Reply With Quote
Old 6th June 2011, 13:41   #7963  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Andy o View Post
OK, here's the log for that situation. madVR just doesn't switch.

http://www.filesonic.com/file/114189...adVR_-_log.zip

BTW, it's not a huge problem personally cause I don't have a lot of 60p content.
I don't understand that. The log says that madVR actually tries to activate the 1080i59 mode, but Windows returns with an error code of "bad mode".

Can you send another log where madVR actually manages to switch from a different mode to 1080i59?

Quote:
Originally Posted by Andy o View Post
Also, since you're tweaking the logic, is it possible for madVR, if 1080i59/60 and 1080p59/60 both are present, to switch 59i/60i content to 1080i instead of 1080p? My display will only apply auto IVTC up to 1080i.
Hmmmm... That might be difficult, not sure. Will have to check if I can detect that the source is interlaced.

Quote:
Originally Posted by 6233638 View Post
It does make me want to wait until this is fixed, to verify that the Cyberlink DVD Decoder is still sending YV12/NV12 before spending a lot of time on it. (neither ffdshow nor LAV CUVID/splitter work with DVD)
When using MPC-HC, you can check the connection format in the filter properties. But of course you can also wait...

Quote:
Originally Posted by SamuriHL View Post
On that one file it is. I checked a couple other DVD->MKV's that I have and they don't do it. Just Empire Strikes Back. This wasn't happening before. Let me know what I can do to help on this one and I'll see if I can find some time.
Can you try cutting this file down to a very small sample? If the crash still occurs with the small sample, it might help me reproduce & fix the problem.
madshi is offline   Reply With Quote
Old 6th June 2011, 13:44   #7964  |  Link
noee
Registered User
 
Join Date: Jan 2007
Posts: 530
Quote:
On that one file it is. I checked a couple other DVD->MKV's that I have and they don't do it. Just Empire Strikes Back. This wasn't happening before. Let me know what I can do to help on this one and I'll see if I can find some time.
I've been trying to get a log, but when I turn logging on in MC, it never fails....I think with MC logging on and the madVR debug, we should get something usable.
noee is offline   Reply With Quote
Old 6th June 2011, 13:47   #7965  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by STaRGaZeR View Post
Is it intended that all the options under devices->Mymonitor (display calibration, gamma, levels, etc.) affect RGB32 video as they do now? If so, what's the reason behind this behaviour?
You seem to consider RGB32 video as "the truth" which must not be touched, anymore. That's not really correct, though. It is intentional (and IMHO absolutely correct) that madVR applies all of its calibration processing on RGB32 input, too. Why should it not do that? Do you have a scientific reasoning for that?

Quote:
Originally Posted by STaRGaZeR View Post
What should I do to get untouched RGB32 output?
Use the default settings, but change the "gamut / primaries" setting on the display "properties" page to "something else". That will make madVR not touch the RGB32 output. IMHO doing that is not correct, though. You will not get correct colors this way if you e.g. play SD video on your HD display.
madshi is offline   Reply With Quote
Old 6th June 2011, 13:48   #7966  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by noee View Post
I've been trying to get a log, but when I turn logging on in MC, it never fails....I think with MC logging on and the madVR debug, we should get something usable.
Unfortunately for crashes the madVR debug log usually doesn't help much (though if we're extremely lucky maybe this is an exception, you never know). Much better would be for me to get a sample with which the crash is 100% reproducable.
madshi is offline   Reply With Quote
Old 6th June 2011, 13:53   #7967  |  Link
janos666
Registered User
 
Join Date: Jan 2010
Posts: 479
If I tell madVR that these are my supported display modes: 1080p23, 1080p24, 1080p25, 1080p29, 1080p30, 1080p50, 1080p59, 1080p60, 1080i29, 1080i59 then it switches to 1080p29 for 1080i30 BD materials (it could be correct if there would be a deinterlace filter in the graph which produces 29.97 progressive frames). And the result is very bad as madVR doesn't really deinterlace anything (yes, I know that it's not a bug but a missing feature with very low or zero priority witch I understand...)

If I disable auto-switching and manually set 1080i30Hz from the AMD CCC (which is interlaced 60.00Hz according to the madVR OSD) then the TV seems to understand it and correctly deinterlace it. Well, at least for a few seconds until something looses the sync and the video starts to jag like hell. It gets back to work if I pause the playback for some seconds.

So I tried to fill my display modes line with this: 1080i29, 1080i59 and madVR now switches to interlaced 59.941Hz (said by madVR OSD) for 1080i30 materials (29.970fps according to the source filter). And the TV still understand it and apply deinterlace. But it didn't solve the sync problem, it still starts to jag after a few seconds.

I am not sure if it's madVR or the TV which looses the sync but I guess it's madVR (why the pause/play cycle would help the TV? and the TV streams from coax work well...).

I am using the D3DFS mode and I tried to tick the DX11 presentation and a very strange thing happened: madVR switches to interlaced 50.00Hz now (for the same 1080i30 material).
So, I removed anything but 1080i59 from madVR's list and it still switches to interlaced 50Hz (and the same thing happens if I keep 1080i29 only)!

Last edited by janos666; 6th June 2011 at 14:13.
janos666 is offline   Reply With Quote
Old 6th June 2011, 13:53   #7968  |  Link
SamuriHL
Registered User
 
SamuriHL's Avatar
 
Join Date: May 2004
Posts: 5,351
Quote:
Originally Posted by madshi View Post
Can you try cutting this file down to a very small sample? If the crash still occurs with the small sample, it might help me reproduce & fix the problem.
Yea, it might take a little bit. I've got some video editing to do on that machine. I'll try to get you a sample later today. Knowing my luck, cutting the file down will fix it and not repro it.
__________________
HTPC: Windows 11, AMD 5900X, RTX 3080, Pioneer Elite VSX-LX303, LG G2 77" OLED
SamuriHL is offline   Reply With Quote
Old 6th June 2011, 13:58   #7969  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,340
Quote:
Originally Posted by madshi View Post
Hmmmm... That might be difficult, not sure. Will have to check if I can detect that the source is interlaced.
If all you do is check media types, then that information is sadly not present. There are the "dwInterlaceFlags" in VIH2, however many decoders always set them even on progressive content, and set the actual type of the frames on the sample properties.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 6th June 2011, 14:06   #7970  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by madshi View Post
If you use a 3dlut, the primaries/gamut setting on the "Properties" page has no effect. As I mentioned before, I plan to make gray out this option in the next madVR version, if you activate a 3dlut. If you do not use a 3dlut, you should set this option to the closest match. The value "Something Else" means that madVR disables gamut correction, if no 3dlut is used. Same as with "primaries/gamut".
In that case, you should consider changing "Something Else" to something less ambiguous.
Edit: As I noted below, it may be nice to have a "Custom" option which you could specify arbitrary values as well.

Quote:
Originally Posted by madshi View Post
Setting this to "Something Else" means that madVR treats your display as having the default Pure power curve of 2.2, though. This has no meaning, though, unless you modify the "Color & Gamma" settings. If you keep all options to the default values madVR will not touch the gamma at all. That's the default behaviour. If you enable yCMS calibration (or use an external 3dlut file), madVR will still not touch the gamma at all, if you keep using the default settings on the "properties" and "color & gamma" pages.

As explained above, with the default settings there is no forced gamma correction at all.
Thanks for the confirmation that Pure-power 2.2 means gamma isn't touched. I initially changed things since they weren't the correct values for my display.
If "Something Else" means disabled in the properties page, could you add a "Something Else" to the Color & Gamma page as well. That would be less confusing (when you plan to set input=output), even if it does nothing different than setting Pure-power 2.2 there.

Just to confirm, the following both imply gamma correction is disabled and will have identical behavior?
Properties (pure-power 2.2) -> Color & Gamma (pure-power 2.2)
Properties (something else) -> Color & Gamma (pure-power 2.2)

Properties (inverse 2.2) -> Color & Gamma (inverse 2.2)
Properties (pure-power 2.35) -> Color & Gamma (pure-power 2.35)
Edit: Does madVR assume the 3dlut is a 2.2 power-curve, meaning these last two will do something? Would this have different behavior with shaders-only vs using a 3dlut?

Edit2: Thinking about this a bit, it may make sense to link changes to the Property page gamma to the Color & Gamma page. In other words, default to input=output gamma when a change is made to the Property page. At which point if someone wanted to apply a gamma adjustment, they could make the necessary change in the Color & Gamma page.

Quote:
Originally Posted by madshi View Post
Let's say you want to use a 2.35 gamma for night time watching and a 2.2 gamma if there's some ambient light. How can you do that? With older madVR versions you had to create and then switch between different 3dlut files for that to work. Now with madVR v0.62 you create only one 3dlut file and you can do gamma adjustments on the fly. And you can do this with the same (or even better) quality than before.
I don't mind having the additional functionality available, but currently I have no use for it. When I'm not using something I want it obvious that it is indeed disabled and doing nothing. I'd still like to see a check-box by certain settings to disable and gray them out to be more intuitive than guessing the madVR defaults.

Quote:
Originally Posted by madshi View Post
The one standard 3dlut file created by madVR v0.62 defaults to a "Gamma_Curve" of a 2.2 pure power curve, which is also the default setting in the "color & gamma" settings page. If you want to achieve a different gamma curve, you can realize that by changing the "color & gamma" settings. Having the "color & gamma" settings set to the default values means that madVR is not doing any gamma processing at all.

Or in other words: v0.62 uses the 3dlut only to correct display faults. It does not use the 3dlut, anymore, to achieve specific gamma curves / values. So basically the yCMS command "Gamma_Curve" is what you can configure now in the "color & gamut" madVR settings page. This is done via shader math now, though. The purpose of this change is higher usability, because you only need one 3dlut, anymore, and you can switch "Gamma_Curve" on the fly, without delay.
I realize what you are doing and why you set things up this way, but I don't like getting forced into using shader vs 3dlut for gamma correction. If for example a 3dlut is set with special Input_Transfer_Functions, Output_Transfer_Functions, Gamma_Curve, or even non-yRGB with YUV->RGB conversion, madVR should use it and bypass any shader code which duplicates functionality. It shouldn't be hard for madVR to parse the settings in the first few bytes of an externally loaded 3dlut and adapt accordingly. I like having the flexibility have a 3dlut which can be used anywhere and does all the corrections I need.


Quote:
Originally Posted by madshi View Post
The real bug is that the yCMS tab is visible sometimes when it should not be. It should only be visible if you've selected the "calibration" tab. The yCMS tab should not be visible in any other case.
I've see both the yCMS and the Calibration tab show up on the Color & Gamma page, so don't forget to fix both.

Quote:
Originally Posted by madshi View Post
If you edit it manually, you have to use commas. However, you can copy & paste the full "Gamma_Measurements" and "Grayscale_Measurements" sections from your 3dlut script to the madVR settings gamut/gamma sections and madVR will accept them as they are (with spaces). But for that to work, the "xxx_Measurements" header must be part of the copy & pasted text.
There is still a bug that clicking edit doesn't load a template for Grayscale_Measurments and forces you to manually edit.

Quote:
Originally Posted by madshi View Post
I wasn't sure which output transfer function yCMS was using for yRGB, so I defined it, just to be safe. Since then yesgrey confirmed that the default yRGB output transfer function matches the one I manually defined. So I can remove that, but it won't make any practical difference.
I noticed you always used the same value when creating a 3dlut, so I assumed you were overriding something (which is the purpose of specifying that value). Does this mean yCMS uses also uses a 2.2 power-curve as the input_transfer_function in the preset as well? I'm not familiar with the intricacy of the changes yesgrey made for yRGB, but I assume the presets still default to using the same input & output transfer functions? Can you confirm?

Quote:
Originally Posted by madshi View Post
Are you sure? If that's true, I consider it a bug in yCMS. yCMS should not clip BTB/WTW, so it should also not clip full-range videos. That said, full-range videos are extremely rare.
Unless yCMS ignores that value with yRGB (you'll need to ask yesgrey) or YUV->RGB has completely different behavior than RGB->RGB it is true. I'm not very familiar with yCMS RGB->RGB behavior, so you'll need confirm with yesgrey.

I see it as a bug as well, but yesgrey doesn't. He purposefully clips input to limited-range in his presets since fullrange videos are rare. You needed to explicitly specify input is full-range when creating a 3dlut. With the previous YUV->RGB 3dluts, you needed three different ones to support all types of videos.

YUV (16-235 clipped) -> RGB (0-255)
Input_Format HD YCbCr 8
Output_Format HD RGB_PC 16

YUV (16-235 clipped) -> RGB (16-235)
Input_Format HD YCbCr 8
Output_Format HD RGB_Video 16

YUV (0-255) -> RGB (0-255)
Input_Format HD YCbCr 8
Input_Range 0 255
Output_Format HD RGB_PC 16


Quote:
Originally Posted by madshi View Post
What extra options in the yCMS config file do you need? I think most users won't need this. So those few who do can create the 3dlut manually and use the "use external" option in madVR.
I'm asking that madVR can be used to create that manual 3dlut file with an external yCMS config so I don't need to mess with the command prompt of batch files. This should be very simple for you to support. Pass the yCMS config file as-is to yCMS, just make the filename for the 3dlut the same as the config file, and let yCMS do its thing, creating the 3dlut and placing it in the madVR directory.

The problem still remains that you can create a 3dlut which conflicts with the madVR shaders. If a user is used to creating a 3dlut manually and doesn't realize this, they could make similar assumptions as I did, causing madVR to apply gamma corrections both with the 3dlut and shaders. Optimally madVR should support 3dlut only, shaders only, and 3dlut + shaders. Maybe adding a drop-down menu to pick your desired mode would be the best solution.


Quote:
Originally Posted by madshi View Post
The problem is that there are various situations users can be in:

(1) They might have a meter and want to use yCMS.
(2) They might have a meter and use a different 3dlut creator.
(3) They might have no meter, but have their displays calibrated by an ISF calibrator to e.g. BT.709.
(4) They might have a display which is known to be mostly BT.709 calibrated out of the box.
(5) They might have a display with an unknown calibration.

I need to support all of that. And I want to offer all of these users the option to use both gamut correction (so both DVDs and Blu-Rays are shown with correct colors) and gamma adjustments (to match the ambient light level, or to match movies with a weird encoding).

If I would only have to take care of one of those 5 groups mentioned above, the settings dialog would be easier. But I don't really feel like creating 5 different versions of the settings dialog, either. So I have to find a solution which works for everyone. Of course it's going to be somewhat complicated. So help me optimize it. I'm open for suggestions.
Make a 'First-run Wizard' type of thing which asks simple questions about your needs and guides you through all the scenarios listed above, step-by-step, in a very simple way.

Supporting all these things is all well and good, but it should be more obvious how to make madVR meet your needs, especially for someone unfamiliar with such things and aren't very tech-savvy.

That gamma itself is relative could lead to trouble for users. Unless you are fully aware of the properties of your display and set everything correctly, the output gamma specified in madVR would never match the output gamma you actually see. A common example is if a display has a flawed power-curve gamma or an arbitrary gamma which doesn't match the scaling of the Rec709/601 shader logic. Changing gamma with in such cases will cause undesired behavior, since madVR would be making inaccurate assumptions about the properties of the display.

On another note, if you can now do Rec709/Rec601/PAL gamut adjustments in madVR, how difficult would it be to add custom gamut measurements to by applied by shaders? That would allow someone with a meter to take advantage of this new shader functionality more accurately, when not using a 3dlut. I imagine it would be trivial to support if you already have the framework in place.

Quote:
Originally Posted by madshi View Post
My logic behind all this is that there are some settings which should be setup once and then never touched again ("properties" and "calibration") and there are other settings which users may want to tweak depending on ambient light level or movie ("color & gamma"). I think these settings should be separated into different tabs. Because of that I cannot put "input and output settings" into one tab, as you suggest.
Since you don't want to group them, can you label the Properties page as Input somewhere and the Color & Gamma page as Output somewhere? If that was there in the first place, I wouldn't have needed to ask some of these question and play with setting to trying to figure out what they do. My first impression was the Color & Gamma page was a yCMS setting, but this turned out not to be the case. Maybe pages should specify they are Shader Operations and yCMS 3dlut Operations as well (add color-coding, heh)...

Last edited by cyberbeing; 6th June 2011 at 14:55.
cyberbeing is offline   Reply With Quote
Old 6th June 2011, 14:06   #7971  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by janos666 View Post
If I tell madVR that these are my supported display modes: 1080p23, 1080p24, 1080p25, 1080p29, 1080p30, 1080p50, 1080p59, 1080p60, 1080i29, 1080i59 then it switches to 1080p29 for 1080i30 BD materials (it could be correct if there would be a deinterlace filter in the graph which produces 29.97 progressive frames). And the result is very bad as madVR doesn't really deinterlace anything (yes, I know that it's not a bug but a missing feature with very low or zero priority witch I understand...)

If I disable auto-switching and manually set 1080i30Hz from the AMD CCC (which is interlaced 60.00Hz according to the madVR OSD) then the TV seems to understand it and correctly deinterlace it. Well, at least for a few seconds until something looses the sync and the video starts to jag like hell. It gets back to work if I pause the playback for some seconds.

So I tried to fill my display modes line with this: 1080i29, 1080i59 and madVR now switches to interlaced 59.941Hz (said by madVR OSD) for 1080i30 materials (29.970fps according to the source filter). And the TV still understand it and apply deinterlace. But it didn't solve the sync problem, it still starts to jag after a few seconds.
Not sure where the sync problem comes from. Can I have a log from the "1080i29, 1080i59" situation where madVR switches to interlaced 59.941, please?

Quote:
Originally Posted by janos666 View Post
I am using the D3DFS mode and I tried to tick the DX11 presentation and a very strange thing happened: madVR switches to interlaced 50.00Hz now (for the same 1080i30 material).
Can I have a log from that, too?
madshi is offline   Reply With Quote
Old 6th June 2011, 14:13   #7972  |  Link
janos666
Registered User
 
Join Date: Jan 2010
Posts: 479
I filled the modes line with this: 1080p23, 1080i50, 1080i59 (It covers all my need after all...)
BD with 1080p24 works (of course, they always worked from the bigging of the auto-switch)
HDTV streamrip with 1080i25 works without any deinterlace or sync problems (well, I let it run for a minute)
BD with 1080i30 works for a few seconds

Ok, I will try to capture a log.
janos666 is offline   Reply With Quote
Old 6th June 2011, 14:14   #7973  |  Link
yesgrey
Registered User
 
Join Date: Sep 2004
Posts: 1,295
Some possible bugs:
-after activating and selecting the external 3DLUT file for one of the displays, when activating the external 3DLUT file for the other it by defaults uses the same file from the other display. IMHO it should appear blank.
-In the calibration->yCMS tab the grayscale measurements edit button is disabled. It only is enabled after filling up the gamut measurements. I think both should be enabled.
-The Gamut_Measurements are not being accepted through copy/paste. The save button keeps disabled.
yesgrey is offline   Reply With Quote
Old 6th June 2011, 14:45   #7974  |  Link
janos666
Registered User
 
Join Date: Jan 2010
Posts: 479
I used these settings: 1080p23, 1080i50, 1080i59 and the situation is the same with DX11: 1080i30_madvr_log.rar
janos666 is offline   Reply With Quote
Old 6th June 2011, 15:18   #7975  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by nevcairiel View Post
If all you do is check media types, then that information is sadly not present. There are the "dwInterlaceFlags" in VIH2, however many decoders always set them even on progressive content, and set the actual type of the frames on the sample properties.
Sample properties? Do you mean IMediaSample::GetMediaType()? Or do you mean IMediaSample2::GetProperties? Thx.

Quote:
Originally Posted by cyberbeing View Post
Just to confirm, the following both imply gamma correction is disabled and will have identical behavior?
Properties (pure-power 2.2) -> Color & Gamma (pure-power 2.2)
Properties (something else) -> Color & Gamma (pure-power 2.2)
Yes.

Quote:
Originally Posted by cyberbeing View Post
Properties (inverse 2.2) -> Color & Gamma (inverse 2.2)
Properties (pure-power 2.35) -> Color & Gamma (pure-power 2.35)
Inverse? You mean the BT.709 curve type? Anyway, if you set the Properties and Color & Gamma options to the same values, madVR will not do any gamma changes - if you don't use a 3dlut. If you do use a 3dlut:

Quote:
Originally Posted by cyberbeing View Post
Edit: Does madVR assume the 3dlut is a 2.2 power-curve, meaning these last two will do something?
If you do have a 3dlut madVR will assume it produces a pure-power curve of 2.2, because that's how madVR creates its own 3dluts. Which means, if you're using a 3dlut you need to set the Color & Gamma option to pure power 2.2 to have no processing.

Ok, I can see that this might be confusing overall. I'll try to improve on that. Maybe I can add an option "don't process" or something like that to the "color & gamut" option and use that as default.

Quote:
Originally Posted by cyberbeing View Post
I realize what you are doing and why you set things up this way, but I don't like getting forced into using shader vs 3dlut for gamma correction. If for example a 3dlut is set with special Input_Transfer_Functions, Output_Transfer_Functions, Gamma_Curve, or even non-yRGB with YUV->RGB conversion, madVR should use it and bypass any shader code which duplicates functionality.
I'm sorry, but this is not possible. madVR has strict requirements on the 3dlut. It *MUST* be yRGB RGB_Video input, or else you will not get proper results. In the same way older madVR versions had a strict requirement that the 3dlut *MUST* be YCbCr. Older madVR versions were a bit "stupid" in that they naively sent all content to the 3dlut, not caring whether the 3dlut matched the source or not. Now with v0.62, madVR requires the 3dlut to have a specific "input" format. That way madVR can do the necessary conversions to make any content compatible to the 3dlut. So in other words: The 3dlut input side is defined and you can't change it, if you want to get proper results. But the output side is still more or less flexible. Output must be 16bit RGB_Video, but other than that madVR will accept whatever you want as 3dlut output.

I think the new concept is good and I don't really see any disadvantage in having the 3dlut input side strictly defined. If you see any disadvantages of that (in real life), please let me know.

Quote:
Originally Posted by cyberbeing View Post
There is still a bug that clicking edit doesn't load a template for Grayscale_Measurments and forces you to manually edit.
Please recheck that with the next build. It works fine here. Might be fixed together with the other bugfixes.

Quote:
Originally Posted by cyberbeing View Post
I noticed you always used the same value when creating a 3dlut, so I assumed you were overriding something (which is the purpose of specifying that value). Does this mean yCMS uses also uses a 2.2 power-curve as the input_transfer_function in the preset as well? I'm not familiar with the intricacy of the changes yesgrey made for yRGB, but I assume the presets still default to using the same input & output transfer functions? Can you confirm?
The transfer function depends on which input "format" you choose. If you use "yRGB" this will automatically default to a 2.2 pure power transfer function. If you use "HD" that will default to a BT.709 curve, I think. Same with output.

Quote:
Originally Posted by cyberbeing View Post
Unless yCMS ignores that value with yRGB (you'll need to ask yesgrey) or YUV->RGB has completely different behavior than RGB->RGB it is true. I'm not very familiar with yCMS RGB->RGB behavior, so you'll need confirm with yesgrey.
The new 3dlut concept is to let madVR convert any source format to "yRGB RGB_Video". If the source is full range, the proper madVR behaviour would be to stretch the source to video levels before feeding it into the 3dlut. This is not implemented in madVR yet, though.

Quote:
Originally Posted by cyberbeing View Post
I'm asking that madVR can be used to create that manual 3dlut file with an external yCMS config so I don't need to mess with the command prompt of batch files. This should be very simple for you to support. Pass the yCMS config file as-is to yCMS, just make the filename for the 3dlut the same as the config file, and let yCMS do its thing, creating the 3dlut and placing it in the madVR directory.
It's not a matter of how easy it is for me to implement. The real question for me is how many people would use it. I don't want to add controls to the settings dialog which only a handful of people will ever use. The problem is not my programming time, but the usability of the settings dialog.

Quote:
Originally Posted by cyberbeing View Post
Make a 'First-run Wizard' type of thing which asks simple questions about your needs and guides you through all the scenarios listed above, step-by-step, in a very simple way.
Sure. Can you please ask God to extend my days to 48hours each? Seriously, wizards are nice and might come at some time. But there are so many other things I need to do which are more important.

Quote:
Originally Posted by cyberbeing View Post
That gamma itself is relative could lead to trouble for users. Unless you are fully aware of the properties of your display and set everything correctly, the output gamma specified in madVR would never match the output gamma you actually see. A common example is if a display has a flawed power-curve gamma or an arbitrary gamma which doesn't match the scaling of the Rec709/601 shader logic. Changing gamma with in such cases will cause undesired behavior, since madVR would be making inaccurate assumptions about the properties of the display.
If the display has a flawed gamma curve then without a meter + measurements + yCMS correction the display will stay flawed, no matter if I change the gamma via shader math or not. The user can try modifying the gamma with madVR's shader math gamma tweaks. Eventually it might make the image quality better or worse overall. I'll leave that up to the user. E.g. just imagine a user has a display which has a flawed but ok gamma curve, which is just way too bright. If he has no meter, madVR should still allow him to bring the overall gamma curve down to a more reasonable level. Of course it won't be "accurate". But it would still be a noticeable improvement.

Quote:
Originally Posted by cyberbeing View Post
On another note, if you can now do Rec709/Rec601/PAL gamut adjustments in madVR, how difficult would it be to add custom gamut measurements to by applied by shaders? That would allow someone with a meter to take advantage of this new shader functionality more accurately, when not using a 3dlut. I imagine it would be trivial to support if you already have the framework in place.
If that someone does have a meter, why is he not using yCMS?

Quote:
Originally Posted by cyberbeing View Post
Since you don't want to group them, can you label the Properties page as Input somewhere and the Color & Gamma page as Output somewhere? If that was there in the first place, I wouldn't have needed to ask some of these question and play with setting to trying to figure out what they do. My first impression was the Color & Gamma page was a yCMS setting, but this turned out not to be the case. Maybe pages should specify they are Shader Operations and yCMS 3dlut Operations as well (heh)...
You're seeing this with your experience with yCMS. But if you think about a new user, seeing this for the first time, he won't care what is done via yCMS and what is done via shader math. I don't want to design the settings dialog after technical things like that.

What exactly do you understand as "Input" in this context, btw? It is not clear to me. Why would the "Properties" page be "Input"? Do you mean input into the display? Or input into madVR? Or input into yCMS? Or input into the 3dlut? I don't think marking the "Properties" page as "input" would be of any help. It wouldn't help myself, at least, because I don't see the connection between "Properties" and "input".

Quote:
Originally Posted by yesgrey View Post
-after activating and selecting the external 3DLUT file for one of the displays, when activating the external 3DLUT file for the other it by defaults uses the same file from the other display. IMHO it should appear blank.
Agreed. Will check that.

Quote:
Originally Posted by yesgrey View Post
-In the calibration->yCMS tab the grayscale measurements edit button is disabled. It only is enabled after filling up the gamut measurements. I think both should be enabled.
Are there people who provide grayscale measurements but not gamut measurements? What would be the purpose of that?

Quote:
Originally Posted by yesgrey View Post
-The Gamut_Measurements are not being accepted through copy/paste. The save button keeps disabled.
Works for me. Can you post the exact text you've copy/pasted here for me to test with?
madshi is offline   Reply With Quote
Old 6th June 2011, 15:27   #7976  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by janos666 View Post
I used these settings: 1080p23, 1080i50, 1080i59 and the situation is the same with DX11: 1080i30_madvr_log.rar
Thanks, another bug located.
madshi is offline   Reply With Quote
Old 6th June 2011, 15:44   #7977  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,340
Quote:
Originally Posted by madshi View Post
Sample properties? Do you mean IMediaSample::GetMediaType()? Or do you mean IMediaSample2::GetProperties? Thx.
IMS2::GetProperties
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 6th June 2011, 16:26   #7978  |  Link
STaRGaZeR
4:2:0 hater
 
Join Date: Apr 2008
Posts: 1,302
Quote:
Originally Posted by madshi View Post
You seem to consider RGB32 video as "the truth" which must not be touched, anymore. That's not really correct, though. It is intentional (and IMHO absolutely correct) that madVR applies all of its calibration processing on RGB32 input, too. Why should it not do that? Do you have a scientific reasoning for that?
First, let me say I have absolutely no background in video renderers and D3D stuff in the sense that I don't know what happens once I feed the renderer with a frame.

What you call "the truth" is what ffdshow RGB32 outputs, or what Fraps lossless outputs, for example. These 2 decoders output RGB32. Why do I think that this output should not be touched? Because both of them compute the RGB32 frames using the correct matrices for 601/709, SD/HD, levels, etc. They do (in ffdshow you can configure it, Fraps is always 709/PC range) what you do in madVR when feeded with YV12, so their RGB32 output is comparable to the RGB32 output of madVR to the graphics card. Processing in madVR is a bad idea, because it'll redo everything, messing up colors, levels, gamma, etc. as it does right now.

The most interesting effect happens with the levels setting. My monitor is a PC monitor, so 0-255 of course. When PC levels is selected in madVR the videos are double expanded: by ffdshow/fraps (because they assume no further conversions will be done) and then by madVR, yet I'm telling madVR the truth, my monitor is PC range. This option doesn't have a "something else" setting, so I have to lie to madVR and tell it my monitor uses TV range to get proper levels.

RGB32 is a format that is intended to be displayed as-is, unless video renderers do something to the image that I'm not aware of before displaying it. Yet again, RGB32(ffdshow)->EVR and YV12->madVR look the same here (not counting the difference in processing quality of course) in both SD and HD. So I really think your processing should be disabled for RGB32/24, or at least you should offer an option to do so.

On a side note, in MPC-HC you can tell EVR your monitor's output range, and it does work when EVR itself does the YCbCr->RGB conversion. However, if you feed EVR with RGB32 the setting will have no effect, like it should be.

Quote:
Originally Posted by madshi View Post
Use the default settings, but change the "gamut / primaries" setting on the display "properties" page to "something else". That will make madVR not touch the RGB32 output. IMHO doing that is not correct, though. You will not get correct colors this way if you e.g. play SD video on your HD display.
I do get proper colors playing SD and HD videos if the RGB32 frames are untouched, as in EVR, as explained above.
__________________
Specs, GTX970 - PLS 1440p@96Hz
Quote:
Originally Posted by Manao View Post
That way, you have xxxx[p|i]yyy, where xxxx is the vertical resolution, yyy is the temporal resolution, and 'i' says the image has been irremediably destroyed.
STaRGaZeR is offline   Reply With Quote
Old 6th June 2011, 17:13   #7979  |  Link
smsmasters
Registered User
 
Join Date: Sep 2006
Posts: 25
I have a Core i5 + GT 420M laptop and MPC-HC crashes when switching to full screen exclusive mode, as if it can't keep up with buffering.
smsmasters is offline   Reply With Quote
Old 6th June 2011, 17:34   #7980  |  Link
groen
Registered User
 
Join Date: May 2011
Posts: 16
madVR works great, not sure if already mentioned. But a few feature requests.

1) an option to disable reinit on display, this way i can drag between dual monitors without it glitching.
2) an option to set the amount of seconds that it goes in to exclusive mode, from four to any number.
3) dxva support, but only if the seek remains as good as it is now.
4) volume control to go with the cool seekbar.
groen is offline   Reply With Quote
Reply

Tags
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 07:11.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.