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 31st March 2013, 23:20   #18161  |  Link
DragonQ
Registered User
 
Join Date: Mar 2007
Posts: 934
As far as I'm aware from my limited research, anywhere between 2.2 and 2.4 is fine. 2.2 is usually suggested for brighter environments (including PC monitors) and 2.4 for darker environments.
__________________
TV Setup: LG OLED55B7V; Onkyo TX-NR515; ODroid N2+; CoreElec 9.2.7
DragonQ is offline   Reply With Quote
Old 31st March 2013, 23:30   #18162  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
You should not calibrate your display to the BT.709 curve. It is not intended to be used on displays. Generally a 2.4 power curve is accepted to be reference gamma now if your display is capable of more than 10,000:1 contrast. Otherwise use the BT.1886 function.
I'll try out using BT.1886 (-f0 -G2.4) next time I calibrate, but unless it's much different, I've always found using a 2.4 power curve (-f1 -G2.4) to be horrible on my >10,000:1 GDM-F520 CRT. There gets to be a point where everything has unrealistic contrast, and while dark tones are defined and evenly spaced, they become difficult to be seen unless you are in a pitch black room.

An ambient light scaled BT.709 curve via ArgyllCMS helps compensate for this, in a similar way that sRGB curve does for the PC space. I've heard people say that sRGB shouldn't be calibrated to either, yet if you don't, color management software will change the curve to sRGB anyway on sRGB images. Not exactly same thing for the TV space, but that a lot of content isn't mastered to have natural looking contrast @2.4 Gamma, I still see as a major problem for my subjective viewing experience.

Last edited by cyberbeing; 1st April 2013 at 00:49.
cyberbeing is offline   Reply With Quote
Old 1st April 2013, 05:37   #18163  |  Link
Stephen R. Savage
Registered User
 
Stephen R. Savage's Avatar
 
Join Date: Nov 2009
Posts: 327
While we are on the subject of gammas, what does calibrating a display to a set gamma with ArgyllCMS do when using the generated 3DLUT (either from yCMS or TI3Parser) with madVR? Also, when using yCMS to generate a 3DLUT, should the GPU gamma ramp be disabled or not?

For example, if the video has 2.2 gamma (for the sake of argument) and you have calibrated your display via ArgyllCMS to 2.4, will madVR then remap the video gamma to your new 2.4 display gamma (hence not changing anything) or will the perceived image have "2.4 gamma" contrast? Do you need to check "enable gamma processing" to see the image with "2.4 gamma"?
Stephen R. Savage is offline   Reply With Quote
Old 1st April 2013, 06:19   #18164  |  Link
dansrfe
Registered User
 
Join Date: Jan 2009
Posts: 1,210
Quote:
Originally Posted by Stephen R. Savage View Post
While we are on the subject of gammas, what does calibrating a display to a set gamma with ArgyllCMS do when using the generated 3DLUT (either from yCMS or TI3Parser) with madVR? Also, when using yCMS to generate a 3DLUT, should the GPU gamma ramp be disabled or not?

For example, if the video has 2.2 gamma (for the sake of argument) and you have calibrated your display via ArgyllCMS to 2.4, will madVR then remap the video gamma to your new 2.4 display gamma (hence not changing anything) or will the perceived image have "2.4 gamma" contrast? Do you need to check "enable gamma processing" to see the image with "2.4 gamma"?
madVR will remap the 2.2 gamma video to 2.4 based on the 3DLUT. The gamma processing option is if you aren't using a 3DLUT.
dansrfe is offline   Reply With Quote
Old 1st April 2013, 06:29   #18165  |  Link
Stephen R. Savage
Registered User
 
Stephen R. Savage's Avatar
 
Join Date: Nov 2009
Posts: 327
Quote:
Originally Posted by dansrfe View Post
madVR will remap the 2.2 gamma video to 2.4 based on the 3DLUT. The gamma processing option is if you aren't using a 3DLUT.
I've read in a few places that to properly view images the "correct way", one should reinterpret the Rec709 (approximately "2.2") encoded data as 2.4 without correction. Apparently this is intended to correct for the difference between studio (1000 lux) and regular (4-32 lux) viewing conditions. In this case, would I want gamma processing enabled or not?
Stephen R. Savage is offline   Reply With Quote
Old 1st April 2013, 16:52   #18166  |  Link
Pat357
Registered User
 
Join Date: Jun 2006
Posts: 452
Quote:
Originally Posted by vivan View Post
There's something wrong with new madTestPatternSource.
With new version image is broken with any renderer (except madVR), pic. With old one everything is ok.
What do you mean by "new madTestPatternSource" ?
I have the feeling that I'm missing something', because my "madTestPatternSource" is dated 09/04/2009, not exactly new i'd say.

I noticed however that the latest MadVR v0.86.1 did not include a "madTestPatternSource.ax", so I still have the one from previous MadVR versions in my directory.

Where is this new "madTestPatternSource.ax" available ?
Was it released as a seperate file ?

Thanks if you could clear this up for me !
Pat357 is offline   Reply With Quote
Old 1st April 2013, 17:30   #18167  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Quote:
Originally Posted by Pat357 View Post
Where is this new "madTestPatternSource.ax" available ?
Was it released as a seperate file ?
Look in the first post in this thread.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 2nd April 2013, 17:13   #18168  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
Quote:
Originally Posted by cyberbeing View Post
I'll try out using BT.1886 (-f0 -G2.4) next time I calibrate, but unless it's much different, I've always found using a 2.4 power curve (-f1 -G2.4) to be horrible on my >10,000:1 GDM-F520 CRT. There gets to be a point where everything has unrealistic contrast, and while dark tones are defined and evenly spaced, they become difficult to be seen unless you are in a pitch black room.
That sounds like you were calibrated to an average of 2.4, and not 2.40 gamma at every point on the curve. (10% and below are particularly important, and difficult to get right on a CRT)
If your display has more than 10,000:1 contrast, the BT.1886 curve is 2.40 gamma.

Quote:
Originally Posted by cyberbeing View Post
I've heard people say that sRGB shouldn't be calibrated to either, yet if you don't, color management software will change the curve to sRGB anyway on sRGB images.
I can't think of any professional calibration package that calibrates to the sRGB curve by default - few even offer the sRGB curve as an option. A 2.2 power curve is typical for PC displays.

The sRGB specification also defines white at 80cd/m˛ and black at 1cd/m˛, giving you a display contrast of 80:1, which looks ridiculous today.

Quote:
Originally Posted by Stephen R. Savage View Post
I've read in a few places that to properly view images the "correct way", one should reinterpret the Rec709 (approximately "2.2") encoded data as 2.4 without correction. Apparently this is intended to correct for the difference between studio (1000 lux) and regular (4-32 lux) viewing conditions. In this case, would I want gamma processing enabled or not?
The BT.709 curve is approximately 1.96 gamma, not 2.2 and is "camera gamma" it is not intended to be used on displays. Nothing was specified because CRTs were in use at the time, and they have a native gamma of approximately 2.4 when correctly set up. (at least studio monitors do)
6233638 is offline   Reply With Quote
Old 2nd April 2013, 17:51   #18169  |  Link
baii
Registered User
 
Join Date: Dec 2011
Posts: 180
Which colorimeter do you have? depending on the model, it may not even work properly for wide gamut.

My personal approach (although may not theoretical correct. It is easy to use)
Argyllcms with dispcalgui - > ti3praser–>madvr gamma depend on the content and my liking.
D65 or 6500k hardly matters unless you have reference grade equipment imo .
baii is offline   Reply With Quote
Old 2nd April 2013, 18:03   #18170  |  Link
6233638
Registered User
 
Join Date: Apr 2009
Posts: 1,019
Quote:
Originally Posted by baii View Post
D65 or 6500k hardly matters unless you have reference grade equipment imo .
Again, CCT is not a specific point, it is a line.

D65 has a CCT of 6504K, but not all measurements that read 6504K are D65. You can have a strong green or magenta tint and still measure 6504K.

I suggest evaluating your white balance using dE u'v' values as it will give you the strictest results, and ignores luminance (gamma) errors.

Last edited by 6233638; 2nd April 2013 at 18:06.
6233638 is offline   Reply With Quote
Old 2nd April 2013, 18:48   #18171  |  Link
dansrfe
Registered User
 
Join Date: Jan 2009
Posts: 1,210
Are there any recommendations for beginner calibration guides and advanced calibration guides that I can go to after that? I really want to learn all the ins and outs of calibration but I don't know where to start.
dansrfe is offline   Reply With Quote
Old 2nd April 2013, 19:37   #18172  |  Link
e-t172
Registered User
 
Join Date: Jan 2008
Posts: 589
Quote:
Originally Posted by e-t172 View Post
- You say "use 2.4 if you have high contrast, BT.1886 otherwise". Thing is, BT.1886 uses a gamma function with… 2.4 as the exponent. What's the difference? Is it because the BT.1884 function has "black compensation" (the "+ b" term)? As far as I'm aware, most calibration software (at the very least HCFR) displays black compensated gamma, i.e. when calculating gamma, L' is used with L' = L - L(black). That would mean that, within such software, the "+ b" is already accounted for and thus your target really is 2.4 as calculated by the software.

- Appendix 2 indicates that "This Recommendation does NOT change any signal parameters defined in Recommendation ITU-R BT.709". The way I understand it, this only makes sense assuming that BT.709 defines the optical → electrical transfer function, while BT.1884 defines the electrical → optical transfer function. However, having different transfer functions for "input" and "output" strikes me as odd, as that would mean that when capturing something using an ideal reference camera and then playing it back on an ideal reference monitor, the display will not be consistent with the reality of what has been captured, because of the difference between the transfer functions used for capture and playback. What gives?
Okay, so, thinking about it some more, I arrive at the following conclusions:

- BT.709 very clearly uses the term "opto-electronic conversion", while BT.1886 uses the term "electro-optical transfer function". This does seem to indicate that BT.709 defines the parameters for the capture/transfer side, while BT.1886 defines the parameter for the playback side. I am still unsure why they are different, but I assume there's a good reason.

- BT.1884 describes "black-compensated gamma", which, as far as calibration software and procedures are concerned, is basically what is referred to as simply "gamma". Black-compensated gamma is equal to simple gamma when the display contrast is infinite (e.g. CRT).

- According to BT.1884, the One True Display Gamma©®™ is 2.4.

One very interesting thing is that display gamma being 2.4 and not 2.2, this means it is actually different from the sRGB gamma, which is 2.2 (well, approximately). This brings me to an interesting thought regarding madVR: considering that madVR is running on a Windows PC, the defaults should assume that the display is calibrated for sRGB, which is the standard for this platform, and should by default convert the content from 2.4 to 2.2.

In other words, for maximum compliance with current specifications, madVR should default "the display is calibrated to the following transfer function / gamma" to "pure power curve 2.20" (IIRC it already does), because sRGB, and more importantly, it should default "enable gamma processing" to "enabled, pure power curve 2.40", because BT.1884.

@madshi: I'm advocating a change in the default settings. What do you think of this reasoning?

On a related note, it would be useful to have a "sRGB curve" option under the "calibration" tab. It should be extremely easy to implement as it is exactly the same curve as BT.709 but with different coefficients for the linear part. If this is to be implemented then the default setting would be "sRGB curve 2.40" (as 2.2 is just the pure power curve approximation).

Last edited by e-t172; 2nd April 2013 at 19:55.
e-t172 is offline   Reply With Quote
Old 3rd April 2013, 01:33   #18173  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,859
Quote:
Originally Posted by 6233638 View Post
That sounds like you were calibrated to an average of 2.4, and not 2.40 gamma at every point on the curve. (10% and below are particularly important, and difficult to get right on a CRT)
If your display has more than 10,000:1 contrast, the BT.1886 curve is 2.40 gamma.
No I calibrated to a 2.40 gamma curve exactly, verified by plotting the measurements against a reference. The native gamma of this GDM-F520 CRT is very close to a 2.4 gamma power-curve to begin with. I maintain that I subjectively find using a true >=2.4 gamma power-curve as pretty horrible, unless I never intend to watch in any conditions except a completely dark room. If there is any ambient light whatsoever, the human visual system will begin crushing shadow detail, making images appear darker than they actually are and completely unnatural.

From what I've seen, my Panasonic GT50 plasma also naturally ends up with something close to a scaled BT.709 curve, rather than a power-curve, when calibrated to darker gamma.

Quote:
Originally Posted by 6233638 View Post
I can't think of any professional calibration package that calibrates to the sRGB curve by default - few even offer the sRGB curve as an option. A 2.2 power curve is typical for PC displays.
Only basICColor and ArgyllCMS seem to allow calibrating to an sRGB curve directly, but that's not the point. No matter what gamma you calibrate to, using an ICC profile in color managed software like Photoshop will adapt the gamma curve to sRGB when viewing an sRGB image.
cyberbeing is offline   Reply With Quote
Old 3rd April 2013, 12:43   #18174  |  Link
kostik
Registered User
 
Join Date: Jul 2007
Posts: 161
Does anyone know if its possible to disable dithering in Lav video decoder?
madVR dither the video so both of them doing dithering add more noise , isn't it?
thanks!
kostik is offline   Reply With Quote
Old 3rd April 2013, 13:18   #18175  |  Link
Qotscha
Registered User
 
Join Date: Dec 2012
Posts: 40
I think LAV Video does dithering only when it is needed (e.g. when input is 10-bit and LAV outputs 8-bit). So, when using with madVR, LAV Video does not dither unless you have disabled some output formats in LAV or you have some filters between LAV and madVR which e.g. do not accept 10-bit input.
Qotscha is offline   Reply With Quote
Old 3rd April 2013, 13:35   #18176  |  Link
iSunrise
Registered User
 
Join Date: Dec 2008
Posts: 496
Quote:
Originally Posted by kostik View Post
Does anyone know if its possible to disable dithering in Lav video decoder?
madVR dither the video so both of them doing dithering add more noise , isn't it?
thanks!
A quick search on Google for you:

http://forum.doom9.org/showpost.php?...ostcount=12403

@Qotscha: Yes, madVR should only ever need to dither at the output stage, before all the data is send to the display.
iSunrise is offline   Reply With Quote
Old 3rd April 2013, 14:40   #18177  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,342
Quote:
Originally Posted by Qotscha View Post
I think LAV Video does dithering only when it is needed (e.g. when input is 10-bit and LAV outputs 8-bit). So, when using with madVR, LAV Video does not dither unless you have disabled some output formats in LAV or you have some filters between LAV and madVR which e.g. do not accept 10-bit input.
This is correct. Dithering in LAV is only performed when the format is converted to a lower bitdepth - if you output 10-bit untouched to madVR, no dithering is ever performed, and if you don't output untouched, you need to dither, otherwise rounding will be used, and that adds banding.
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is online now   Reply With Quote
Old 4th April 2013, 16:48   #18178  |  Link
digitech
Registered User
 
Join Date: Jun 2012
Posts: 54
Quote:
Originally Posted by nevcairiel View Post
This is correct. Dithering in LAV is only performed when the format is converted to a lower bitdepth - if you output 10-bit untouched to madVR, no dithering is ever performed, and if you don't output untouched, you need to dither, otherwise rounding will be used, and that adds banding.
I have to sacrifice and select don't use dithering in madvr cause i have an acer nvidia ion, what's the disadvantages of doing that as quality concerns Nev? I also has selected use 10 bit croma & image buffer instead of 16 bit in madvr trade quality 4 performance settings.
digitech is offline   Reply With Quote
Old 5th April 2013, 03:14   #18179  |  Link
Dodgexander
Registered User
 
Join Date: Jul 2008
Posts: 157
Quote:
Originally Posted by digitech View Post
I have to sacrifice and select don't use dithering in madvr cause i have an acer nvidia ion, what's the disadvantages of doing that as quality concerns Nev? I also has selected use 10 bit croma & image buffer instead of 16 bit in madvr trade quality 4 performance settings.
I would read the first post from Madshi to understand what dithering does.
Dodgexander is offline   Reply With Quote
Old 5th April 2013, 03:18   #18180  |  Link
Niyawa
Registered User
 
Niyawa's Avatar
 
Join Date: Dec 2012
Location: Neverland, Brazil
Posts: 169
I may have missed something, but is madshi working on something else like commercials again? He's been online and all but no replies.
__________________
madVR scaling algorithms chart - based on performance x quality | KCP - A (cute) quality-oriented codec pack
Niyawa 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 12:04.


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