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 10th July 2016, 19:04   #38601  |  Link
e-t172
Registered User
 
Join Date: Jan 2008
Posts: 589
Quote:
Originally Posted by madshi View Post
But CAM02-UCS is not hue linear, or is it?
I don't know. I'm also not convinced that it matters as much as you think it does. What you want is the closest color that is contained in the destination gamut, so that the color shift is minimized. One could imagine a scenario in which the destination gamut is constrained in such a way that the best color to map to happens to have slight hue shift in order to avoid large swings in saturation or brightness. It would depend on the situation and the specific source and destination gamuts, I guess. The closest color is the closest color, and this is what traditional gamut mapping methods (based, for example, on CAM02-SCD, which is basically DeltaE but based on CAM02-UCS instead of CIELAB) give you. I'm not sure I see the point in obsessing about whether hue is preserved or not; CIECAM02 is smarter than this, and already takes this into account.

Quote:
Originally Posted by madshi View Post
Why did Dolby invent ICtCp if CAM02-UCS would be better? ICtCp is brand new and recommended by Dolby for HDR processing.
I just read the whitepaper. I suspect Dolby invented ICtCp for two reasons:

First, it seems to me that performance mattered in the design of ICtCp:

Quote:
Originally Posted by Dolby whitepaper
Performing these tasks in an efficient essence representation reduces complexity and increases speed. ICtCp is designed for this purpose.
In contrast, I don't think "traditional" gamut mapping done by CMS is optimized for speed at all. That might mean that "traditional" methods such as CAM02-UCS could give better results because they don't make this tradeoff.

Specifically, ICtCp is meant to be a simple transformation on top of RGB (i.e. matrix + EOTF/gamma curve/tone mapping curve, a.k.a. "matrix + shaper"). Gamut mapping in CMSes, including gamut mapping using CAM02-UCS (which Argyll can do), is way more costly from a performance perspective. First you need to generate a transform (e.g. in Argyll you would run collink, which can take some time to do the computation), and then the output of that is a full-blown 3DLUT, not a simple matrix and EOTF.

Second reason (and probably the most critical one): from the tone of the paper it seems that ICtCp is meant to be an encoding format, which is a very different set of constraints compared to an intermediate color space such as CIECAM02. The former is meant to be used as a storage or transmission format; the latter is meant to be used as a color space inside some color management pipeline/workflow, such as madVR or other color-critical applications. For example, in the ICtCp whitepaper (page 1) they explain that while designing the color space they made sure that the encoded color information could withstand operations such as chroma subsampling or fading. These are reasonable constraints for an encoding format, but they make no sense for an intermediate, transient representation such as CIEXYZ, CIELAB or CIECAM02, which are meant to be used as "bridges" between a source gamut and a destination gamut, not for encoding.

In light of the above, I suspect that using ICtCp as an intermediate color space to do gamut conversions is not the best choice. From what I can tell, it's simply not designed to do that - it's designed to encode video, not do heavy color-critical processing such as gamut mapping. If you want to use a perceptually linear color space that is designed for such heavyweight transforms, then use CIELAB, or better yet, CIECAM02 - that's what they're for. (Conversely, you wouldn't encode video in CIELAB or CIECAM02 - though that didn't stop the DCI people from inventing a format that uses CIEXYZ…) Or, you could delegate all this work to a CMS that will generate a high-quality gamut-mapping 3DLUT for you using the best known perceptually linear color spaces and tricks that are known to color scientists.

There might be vendors out there that use ICtCp as an intermediate color space for actual processing. If that's the case, I suspect that they do it for simplicity/performance reasons, not because it is the most perceptually accurate.

Last edited by e-t172; 10th July 2016 at 19:26.
e-t172 is offline   Reply With Quote
Old 10th July 2016, 19:52   #38602  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by e-t172 View Post
I just read the whitepaper. I suspect Dolby invented ICtCp for two reasons: [...]
The Dolby ICtCp White Paper is mostly an advertising brochure to tout the benefits of using ICtCp instead of YCbCr for encoding. So in order to judge the suitability of using IPT or ICtCp for gamut mapping, this Dolby White Paper is pretty much useless.

To get the full picture you should start with the IPT science paper, which contains all the real meat. Here's the conclusion of the IPT science paper:

Quote:
A color space named IPT has been developed that is more uniform in perceived hue than existing popular color spaces. It is simple to implement and invertable, thus lending itself to imaging applications. The IPT color space is similar in model to CIELAB color space, although the coefficients are different. Visualization of several psychophysical data sets were shown for IPT, CIELAB, and CIECAM97s. In all cases shown, IPT appears to perform as well as (and in some cases performs better than) either CIELAB or CIECAM97s. A verification experiment was performed the results of which show that IPT is judged to be more uniform than two constant hue data sets.
So basically IPT beats CIECAM97s (at least in the confines of those tests/data sets). CIECAM02 seems to be an evolution of CIECAM97s. I'm not sure how much it is improved over CIECAM97s in quality. Websites mostly state performance and simplicity improvements over CIECAM97s, so it's hard to say.

Next, see here:

http://ieeexplore.ieee.org/xpl/login...mber%3D5170710

Quote:
The uniformity of color appearance space is a important yardstick for evaluating color appearance model. This paper is focused on the test of three color appearance spaces CIELAB, IPT and CIECAM02. Several psychophysical data sets were used to evaluate three types of scales and color difference formula in these color spaces. The results show that IPT performs as well as (in some cases performs better than) either CIELAB or CIECAM02.
I see no reason to bother with a very complicated CIECAM02, if IPT seems to perform just as well. And ICtCp is a further improvement over IPT.

More information:

http://www.hpl.hp.com/news/2005/oct-...MICC_final.pdf

Quote:
CIECAM02 does not invert for a range of colors, real and impossible, inside the encoding range of the ICC PCS. Therefore, any processing needs to consider careful handling of these colors. This implementation does two geometric mappings – one to the extended spectrum locus and another to the device gamut. It is important to ensure that artifacts do not result from these distinct mappings.

Another point worth considering is whether a color appearance model like CIECAM02 is the best possible choice if one wants to attack the problem of hue constancy and perceptual uniformity. Alternatives would be to perform the gamut mapping in a space like IPT.
I originally used IPT in the madVR HDR mapping algorithms, but had some problems with that. So the SpectraCal/Calman devs suggested that I'd look into ICtCp. Which is what I'm using now and it solved all the problems I had with IPT.
madshi is offline   Reply With Quote
Old 10th July 2016, 20:07   #38603  |  Link
e-t172
Registered User
 
Join Date: Jan 2008
Posts: 589
Oh well, if there is evidence that ICtCp is actually better than CIECAM02 at being perceptually uniform, then by all means, ignore everything I said I was working on the assumption that ICtCp was a performance tradeoff between YCbCr and CIECAM02. If it's not actually a tradeoff, then there's no reason to use CIECAM02 instead of ICtCp. I'm quite impressed that people managed to come up with a superior alternative to CAM02-UCS that also has other nice characteristics. We live in exciting times!

For completeness, I should probably also mention that, sometimes, some standard will mandate some method to do the display adjustment (i.e. gamut mapping by another name). For example, BT.2390 indicates that for a PQ HDR system, the recommended method to adjust for display luminance constraints is to apply some function to the I channel of ICtCp (§5.4.1). In that case, it makes sense to use ICtCp for processing, since the standard defines the transform in ICtCp terms.

That doesn't answer the question as to how exactly gamut mapping should be done in ICtCp, though - specifically, which color difference function to use (DeltaE and CAM02-SCD work in CIELAB and CAM02-UCS respectively, not in ICtCp). From what you wrote previously, currently you're using an ad-hoc color difference function that considers hue changes to be infinitely more important than luminance changes. It would be interesting to find out if there's a better way.
e-t172 is offline   Reply With Quote
Old 10th July 2016, 20:18   #38604  |  Link
nevcairiel
Registered Developer
 
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,340
Quote:
Originally Posted by madshi View Post
But CAM02-UCS is not hue linear, or is it? Why did Dolby invent ICtCp if CAM02-UCS would be better? ICtCp is brand new and recommended by Dolby for HDR processing.
The usual reasons, slap a patent on it and make money?
Who says everything is ruled by technical reasons that would make sense?
__________________
LAV Filters - open source ffmpeg based media splitter and decoders
nevcairiel is offline   Reply With Quote
Old 10th July 2016, 20:26   #38605  |  Link
jerryleungwh
Registered User
 
Join Date: Jun 2016
Posts: 39
I have this laptop PC which has both Intel HD 530 GPU and a Nvidia 960M GPU. I use MPC-HC with madVR but when I'm using the intel GPU, the video stutters and freezes my computer eventually, and I've tried copying the MGC-HC exe file and renaming it so I can use the Nvidia GPU, but it fails to enter D3D11 FSE mode(it says "exclusive mode failed"). How can I fix this problem?

Last edited by jerryleungwh; 10th July 2016 at 20:37.
jerryleungwh is offline   Reply With Quote
Old 10th July 2016, 20:48   #38606  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Quote:
Originally Posted by Werewolfy View Post
I uploaded a sample. On the 90.19 version this artifact happened a lot of time during all this sample but now (90.20 version) it happens at only one moment so it's already a big improvement. You can find this scene easily, I attached some pictures with the sample, just look at the timer.
Which artifacts do you mean exactly? Earlier you mentioned teeth, but I can't see any artifacts there. I do see some artifacting under the glasses. Is that what you mean? Or something else?

Quote:
Originally Posted by QBhd View Post
Mixed scaling is broken again
Quote:
Originally Posted by Qotscha View Post
This issue still exists. Seems to me that madVR calculates scaling factor = (window height) / (source height), which can activate image doubling even when the image is actually downscaled quite a lot as this example shows. With doubling set to activate when the scaling factor is 1.2 or bigger, it actually activates when the window height is increased from 839 pixels (first picture) to 840=1.2*700 (second picture) pixels regardless of the window width which in this case actually defines the scaling factor.
These two problems should hopefully be fixed in the next build. If not, please let me know.

Quote:
Originally Posted by e-t172 View Post
Oh well, if there is evidence that ICtCp is actually better than CIECAM02 at being perceptually uniform, then by all means, ignore everything I said I was working on the assumption that ICtCp was a performance tradeoff between YCbCr and CIECAM02. If it's not actually a tradeoff, then there's no reason to use CIECAM02 instead of ICtCp. I'm quite impressed that people managed to come up with a superior alternative to CAM02-UCS that also has other nice characteristics. We live in exciting times!

For completeness, I should probably also mention that, sometimes, some standard will mandate some method to do the display adjustment (i.e. gamut mapping by another name). For example, BT.2390 indicates that for a PQ HDR system, the recommended method to adjust for display luminance constraints is to apply some function to the I channel of ICtCp (§5.4.1). In that case, it makes sense to use ICtCp for processing, since the standard defines the transform in ICtCp terms.
FWIW, I'm not sure if IPT/ICtCp are always and for all purposes equal to or better than CIECAM02. E.g. iCam06 uses CIECAM02 for some processing steps and IPT for some other processing steps. So I suppose both may have their strengths and weaknesses. But from what I've seen IPT/ICtCp should be well suited for what I'm doing.

Quote:
Originally Posted by e-t172 View Post
That doesn't answer the question as to how exactly gamut mapping should be done in ICtCp, though - specifically, which color difference function to use (DeltaE and CAM02-SCD work in CIELAB and CAM02-UCS respectively, not in ICtCp). From what you wrote previously, currently you're using an ad-hoc color difference function that considers hue changes to be infinitely more important than luminance changes. It would be interesting to find out if there's a better way.
I'm considering hue changes and luminance changes to be very bad and I try to avoid both at all costs. I'm happy enough to desaturate colors to keep (perceived) hue and luminance as intended. I'm not sure if this is the best approach, but considering that the human eye is most sensitive to brightness variations, I thought that reproducing luminance correctly should have the highest priority.

Anyway, I've emailed Graeme about this.

Quote:
Originally Posted by nevcairiel View Post
The usual reasons, slap a patent on it and make money?
Who says everything is ruled by technical reasons that would make sense?
True enough.

Quote:
Originally Posted by jerryleungwh View Post
I have this laptop PC which has both Intel HD 530 GPU and a Nvidia 960M GPU. I use MPC-HC with madVR but when I'm using the intel GPU, the video stutters and freezes my computer eventually, and I've tried copying the MGC-HC exe file and renaming it so I can use the Nvidia GPU, but it fails to enter D3D11 FSE mode(it says "exclusive mode failed"). How can I fix this problem?
Try searching this thread for "Optimus". You may find some hints about that. Personally, I can't help because I don't have such hardware to test with.
madshi is offline   Reply With Quote
Old 10th July 2016, 21:03   #38607  |  Link
zoyd
Registered User
 
Join Date: Sep 2009
Posts: 43
Quote:
Originally Posted by e-t172 View Post
I don't think that matters. Tone mapping by itself does not affect gamut, it affects how colors are encoded within the gamut. Arbitrary tone mapping curves can be represented in an ICC profile. If you want to generate a source profile with an ST.2084 curve, nothing is stopping you (I think). At worst, maybe you could run into numerical precision issues with some CMSes due to the huge dynamic range.
yes I think constructing a source profile would work that way but it's not a desirable solution. IMO it's better to decouple it and use an ideal source to destination link switch (like BT.1886 is handled) and also to incorporate destination black and peak white ala BT.2390.
zoyd is offline   Reply With Quote
Old 10th July 2016, 21:37   #38608  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
madVR v0.90.22 released

http://madshi.net/madVR.zip

Code:
* added Shiandow's new (Cross) Bilateral chroma upscaler version
* optimized black bar detection performance, should now work for 4K 60p
* removed Anti-Bloating for SuperRes, because it didn't really help
* fixed: mixed x/y SSIM2D downscaling produced green screen
* fixed: doubling decision was based on window size instead of video size
* fixed: HDR peak luminance of 120/180 nits negatively affected SDR playback
* fixed: HDR "measure each frame's peak luminance" froze with Intel/NVidia
* fixed: HDR compressed/clipped highlights were ever so slightly too saturated
* HDR: disabled HDR processing now disables 3dlut, color and gamma tweaks
* HDR: improved quality for 120 and 180 nits
* HDR: file "DisableHdrBrightnessTweak" disables 1xx nits special handling
You can now choose between the "old" Bilateral chroma upscaler (from v0.90.21 and older) and two new versions, "soft" vs "sharp". Please let me know which of the 3 algos you like best. They all have advantages and disadvantages, depending on which images you test with. So don't limit your testing to just one test image, please.
madshi is offline   Reply With Quote
Old 10th July 2016, 22:25   #38609  |  Link
har3inger
Registered User
 
Join Date: Feb 2014
Posts: 139
Just tested out the new filters and have some quick impressions.

The old bilateral scaler is the fastest by far of the three. It sometimes struggles with a noisy/irregular look for edges and lines in the chroma layer, but these tend to be hidden by the same line in the luma layer, mitigating its visual impact. This scaler (and all the other bilateral ones) suffers problems with desaturating thin lines of color, and occasionally completely erases edge lines (for cartoons). Both these problems are almost completely solved with superres2 in chroma, at the cost of slightly increased edge irregularity and ringing. In my experience, the old bilateral plus sr2 is better than nnedi3 with or without SR in almost all scenarios.

Soft: in a lot of ways looks like the old bilateral algorithm, but with much smoother and cleaner edges. The downside is performance and a tendency to randomly emphasize the 2x2 pixelation in the chroma layer as edges in certain scenes, while no other algorithm in madvr does this. I'll post up some screenshots at some point. Erases edge lines less than the old algorithm, but is still a long ways away from nnedi64 in preserving the original intent of those edge lines. I'd switch to using this plus SR1 or SR2 in a heartbeat if the pixelation issues are solved and performance is increased. Otherwise, doesn't really justify use over the old one.

Sharp: Damn those edges are clean. Very sharp overall, and haven't seen any bad artifacts resulting from that yet. Suffers the same pixelation issue as the soft variant, except they look even more obvious. Sometimes the details in the chroma end up sharper than other (non-overlapping) details in the luma, which can look a little strange.

For now, mainly sticking to the old algorithm because the new ones don't improve enough on it for their performance costs.

Images demonstrating pixelation: (look at blood spatter on left half of image, particularly over the guy's right ankle)

nnedi64: https://i.imgsafe.org/2c02181112.png
old with SR2: https://i.imgsafe.org/2c024d841f.png
old: https://i.imgsafe.org/2c0247a68b.png
soft: https://i.imgsafe.org/2c025200c0.png
sharp: https://i.imgsafe.org/2c025c831f.png

Shiandow: PM me if you want the source where those screenshots came from.

Last edited by har3inger; 10th July 2016 at 22:46.
har3inger is offline   Reply With Quote
Old 10th July 2016, 22:39   #38610  |  Link
madshi
Registered Developer
 
Join Date: Sep 2006
Posts: 9,140
Thanks for the feedback! Shiandow would probably appreciate some samples (+ screenshots) which demonstrate those "pixelation" issues.
madshi is offline   Reply With Quote
Old 10th July 2016, 22:47   #38611  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Thanks a lot for the new build but I really liked SR's AB, what could ever bring it back please? Screenshots comparisons of some sort? Was the "it didn't really help" reason purely subjective on your end and if so, is it prone to reevaluation ?
leeperry is offline   Reply With Quote
Old 10th July 2016, 22:49   #38612  |  Link
zoyd
Registered User
 
Join Date: Sep 2009
Posts: 43
Quote:
Originally Posted by madshi View Post
madVR v0.90.22 released


* fixed: HDR "measure each frame's peak luminance" froze with Intel/NVidia
Thanks, that fixed the crash/freeze I was seeing.
zoyd is offline   Reply With Quote
Old 10th July 2016, 23:08   #38613  |  Link
Warner306
Registered User
 
Join Date: Dec 2014
Posts: 1,127
Quote:
Originally Posted by leeperry View Post
Thanks a lot for the new build but I really liked SR's AB, what could ever bring it back please? Screenshots comparisons of some sort? Was the "it didn't really help" reason purely subjective on your end and if so, is it prone to reevaluation ?
My screenshot comparisons showed SuperRes anti-bloat suppressed valid sharpening because SuperRes doesn't really bloat if it isn't oversharpening. You are probably doing more harm than good.
Warner306 is offline   Reply With Quote
Old 10th July 2016, 23:09   #38614  |  Link
Warner306
Registered User
 
Join Date: Dec 2014
Posts: 1,127
SuperRes anti-ringing could also be removed. That's just my opinion.
Warner306 is offline   Reply With Quote
Old 10th July 2016, 23:15   #38615  |  Link
Shiandow
Registered User
 
Join Date: Dec 2013
Posts: 753
Quote:
Originally Posted by har3inger View Post
Just tested out the new filters and have some quick impressions.

[...]

For now, mainly sticking to the old algorithm because the new ones don't improve enough on it for their performance costs.
It should be possible to improve performance somewhat (especially the 'sharp' version could be made faster), but for now I'm focusing on improving the quality.
Shiandow is offline   Reply With Quote
Old 11th July 2016, 01:45   #38616  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
Quote:
Originally Posted by Warner306 View Post
SuperRes anti-ringing could also be removed.
Fully agreed, SR doesn't ring to begin with.

Quote:
Originally Posted by Warner306 View Post
My screenshot comparisons showed SuperRes anti-bloat suppressed valid sharpening because SuperRes doesn't really bloat if it isn't oversharpening. You are probably doing more harm than good.
That's the thing, IIRC you like a very sharp picture but I don't, there's no such thing as "valid sharpening" to me and my personal goal is to reach the sharpest/most natural compromise and 75% AB for SR@2 did just that with sxbr75 to my eyes, by removing some of the harsh digital look(especially on 360x288@1080p refined after every 2x step).....I just tried to find another way to do what I want but I very seriously miss SR AB(especially with the new deringer code that's drastically sharper than the very first build), hopefully I can change madshi's mind somehow =/

Last edited by leeperry; 11th July 2016 at 02:21.
leeperry is offline   Reply With Quote
Old 11th July 2016, 02:08   #38617  |  Link
huhn
Registered User
 
Join Date: Oct 2012
Posts: 7,903
than post picture that show the benefit.

wouldn't be the first time that this would change his mind.
huhn is offline   Reply With Quote
Old 11th July 2016, 02:11   #38618  |  Link
leeperry
Kid for Today
 
Join Date: Aug 2004
Posts: 3,477
sure thing, reason why I asked madshi whether it was all subjective and/or what screenshots would change his mind but I really don't see why AR stayed and AB left

I also can't find any practical use for the built-in AB versions of sxbr for that matter but you can leave them there, I don't mind ^^

Last edited by leeperry; 11th July 2016 at 02:41.
leeperry is offline   Reply With Quote
Old 11th July 2016, 04:45   #38619  |  Link
James Freeman
Registered User
 
Join Date: Sep 2013
Posts: 919
Quote:
Originally Posted by madshi View Post
madVR v0.90.22 released
Thank you, all is well.
__________________
System: i7 3770K, GTX660, Win7 64bit, Panasonic ST60, Dell U2410.
James Freeman is offline   Reply With Quote
Old 11th July 2016, 05:13   #38620  |  Link
QBhd
QB the Slayer
 
QBhd's Avatar
 
Join Date: Feb 2011
Location: Toronto
Posts: 697
Thanks for the mixed scaling fix. All seems to be good. I can't thank you enough for your time and skills!

QB
__________________
QBhd 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 10:31.


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