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. |
10th July 2016, 19:04 | #38601 | Link | ||
Registered User
Join Date: Jan 2008
Posts: 589
|
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:
First, it seems to me that performance mattered in the design of ICtCp: Quote:
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. |
||
10th July 2016, 19:52 | #38602 | Link | ||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
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:
Next, see here: http://ieeexplore.ieee.org/xpl/login...mber%3D5170710 Quote:
More information: http://www.hpl.hp.com/news/2005/oct-...MICC_final.pdf Quote:
|
||||
10th July 2016, 20:07 | #38603 | Link |
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. |
10th July 2016, 20:18 | #38604 | Link | |
Registered Developer
Join Date: Mar 2010
Location: Hamburg/Germany
Posts: 10,340
|
Quote:
Who says everything is ruled by technical reasons that would make sense?
__________________
LAV Filters - open source ffmpeg based media splitter and decoders |
|
10th July 2016, 20:26 | #38605 | Link |
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. |
10th July 2016, 20:48 | #38606 | Link | ||||||
Registered Developer
Join Date: Sep 2006
Posts: 9,140
|
Quote:
Quote:
Quote:
Quote:
Anyway, I've emailed Graeme about this. Quote:
Quote:
|
||||||
10th July 2016, 21:03 | #38607 | Link | |
Registered User
Join Date: Sep 2009
Posts: 43
|
Quote:
|
|
10th July 2016, 21:37 | #38608 | Link |
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 |
10th July 2016, 22:25 | #38609 | Link |
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. |
10th July 2016, 22:47 | #38611 | Link |
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 ?
|
10th July 2016, 23:08 | #38613 | Link |
Registered User
Join Date: Dec 2014
Posts: 1,127
|
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.
__________________
HOW TO - Set up madVR for Kodi DSPlayer & External Media Players |
10th July 2016, 23:09 | #38614 | Link |
Registered User
Join Date: Dec 2014
Posts: 1,127
|
SuperRes anti-ringing could also be removed. That's just my opinion.
__________________
HOW TO - Set up madVR for Kodi DSPlayer & External Media Players |
11th July 2016, 01:45 | #38616 | Link |
Kid for Today
Join Date: Aug 2004
Posts: 3,477
|
Fully agreed, SR doesn't ring to begin with.
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. |
11th July 2016, 02:11 | #38618 | Link |
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. |
Tags |
direct compute, dithering, error diffusion, madvr, ngu, nnedi3, quality, renderer, scaling, uhd upscaling, upsampling |
Thread Tools | Search this Thread |
Display Modes | |
|
|