madVR - high quality video renderer (GPU assisted)

[Asmodian]

Guys can you try latest nvidia driver V368.69. I'm getting nicer video. Richer colors


Sent from my iPhone using Tapatalk

These kind of reports do not make sense to me, the color values sent to the display are not a fuzzy concept.

Richer colors would be incorrect. I do not want the GPU sending my display (234,0,0) when it was supposed to send (230,0,0), how else would a GPU or driver version have richer colors? The pixel in my monitor hasn't changed and neither has my backlight. I have my display calibrated so when my GPU sends (230,0,0) the red displayed has the correct hue and saturation.

Using test patterns it seems like GPUs do a good job of sending 1:1 pixels to display. Where is there room for improvement or what could have changed?

I am running 368.69 here, my calibration is still the same. :confused:

[Ver Greeneyes]

Yeah, if changing drivers changes how the video looks on your screen, either the old or the new drivers are broken. Same with differences between vendors. We're not talking about an analog signal here, if pixels aren't displayed with the color values that madVR gave them, there's something wrong (or you've enabled some sort of enhancement feature, but that's something you should at least know about).

[ryrynz]

These kind of reports do not make sense to me, the color values sent to the display are not a fuzzy concept.


Definitely, any color change would be a bug or some re-enabled feature.

If someone with good technical knowledge could post a video presentation analysis of a recent model AMD card vs an Nvidia card on the same screen it would be appreciated. I think any further discussion about this until then should be avoided here.

[huhn]

Over the past few years prior to MadVR availability, I tested AMD & Nvidia GPU cards for what I perceived to be the best picture quality. I also got third parties involved that did not have a clue technically and they simply indicated which picture they preferred. At that time the AMD cards always seemed to be preferred. To my eyes AMD gave the picture more punch and depth than the Nvidia products. I tested at least 3 Nvidia cards at the time and always preferred any of my AMD cards 3000, 4000 series.

I note on this forum that Nvidia is very popular. Is it possible that MadVR has had a secondary effect of leveling the playing field regarding perceived video performance?

The GPU driver is changing the image by design.
so there are some image enhancements that are active on default.

madVR is avoiding these settings EVR isn't doing that.

on top of it AMD was and is always sending a 10 bit signal with default settings if that is possible. nvidia was using 8 bit when the input was 8 bit.

in the end this is very easy to check all that is needed is a capture card with HDMI and RGB support.

[Village Guy]

This is likely placebo. But I need to know for certain.. Can we get a definite answer on this?

The testing I refer to was carried out many times especially with the 4000 series cards. Some of the Nvidia card used for testing are still in the cupboard unused as a result of disappointing results.

My background is electronic engineering and with respect I do not believe I am prone to the placebo effect especially especially if it causes me to lose money;)

I do hear what you say though. Personally from a hardware perspective I prefer Nvidia. Can I add that all my testing was done using a high quality projectors.

[Village Guy]

on top of it AMD was and is always sending a 10 bit signal with default settings if that is possible. nvidia was using 8 bit when the input was 8 bit.

I was not aware of this, very interesting especially when you consider that my projectors would have been able to manage more than 8 bits.

[Village Guy]

With or without madvr, what difference in quality could there be between an nvidia or amd card ?


Let me be clear, I have absolutely no allegiance to Nvidia or AMD.

I have not carried out what I refer to simply as the Nvidia/AMD test for a couple of years and never utilising MadVR hence my post.

I have recently experienced a very similar scenario when I switched from Win 8 to Win 10. The GPU is an AMD 6650 and the only change was the operating system and associated drivers. After the upgrade, to my eyes the picture had more depth and seemed smoother. My video player is JRiver (Red October HQ)

In theory you might expect the picture to be identical between the two operating systems, for me that was not the case.

[shmizan]

anyone else having this? or had this?
I have the exact same problem. couldn't find a setting in MPC-HC for this. I use:
MPC-HC 1.70.10
madVR v0.90.21
LAV v0.68.1
OS : Windows 8.1 (x64)


No problems here with the same setup and a GTX770. Third-party mouse driver problem, maybe?

to put a close on this. this WAS actually a setting that had to be changed in MPC-HC.
it's in options->playback->fullscreen->hide controls in fullscreen.
that setting is, unfortunately, not properly defined.
if you select "show when hovering controls" or "show when moving cursor", it has no difference WITHOUT madVR's exclusive mode, but has a difference WITH it enabled. :)

[huhn]

I was not aware of this, very interesting especially when you consider that my projectors would have been able to manage more than 8 bits.

i haven't seen an TV/projector that doesn't accept 12 bit input.

that doesn't mean it is a good idea sending this type of signal.
but the major picture difference should be from the post processing each vendor is doing.

deinterlancing is different too.

but with madVR and without DXVA processing the output should be identical but i don't know if it is. both amd and nvidia can be setup to send 8 bit.

[Knight77]

Meanwhile GTX1060 has been confirmed: 6GB Ram @ 249 dollars, looks like I can change my current GTX960 with it, also because now I have a 4K TV and even with Super-XBR works well but the GPU is working a lot and the fans have to run at high speed (with noticeable noise). With a GTX1060 I hope I can use more functions with less stress for the GPU.

[Sunspark]

Well.. different device and software.. but I'll throw this out there for consideration, as it would be a driver and cabling thing..

HDMI supports Deep Color, and I don't think other protocols like DVI do. Now PS3 which uses a Nvidia chip has a toggle for Deep Color on and off. The monitor I use the PS3 with is a 6 bit panel with FRC.. but on the HDMI cable with Deep Color on, the gradients are smoother and there is less banding. So it is accepting something and doing something..

Maybe it is the same with the cards.. some are automatically outputting Deep Color over HDMI and some are not?

[nevcairiel]

Maybe it is the same with the cards.. some are automatically outputting Deep Color over HDMI and some are not?

Deep Color is just output bitdepth > 8-bit (typically 12-bit for HDMI). You can toggle this both in the AMD and NVIDIA control panels for HDMI connections.

[Village Guy]

Deep Color is just output bitdepth > 8-bit (typically 12-bit for HDMI). You can toggle this both in the AMD and NVIDIA control panels for HDMI connections.

Has this always been the case or is it a recent facility? To be honest I do not recall seeing this option for the earlier Nvidia/AMD cards.

[nevcairiel]

Has this always been the case or is it a recent facility? To be honest I do not recall seeing this option for the earlier Nvidia/AMD cards.

Its relatively new for NVIDIA cards, added in some driver I think last year? Might have been the one before that, memory is fuzzy.

Not sure when AMD added it, probably in a similar timeframe.

[Village Guy]

Out of curiosity I have researched my last Nvidia/AMD test. It was carried out in 2011 and used:

GIGA/GV-N440D3-1GI
Product Desc. 1GB GByte GT440 DDR3 PCI-E
Serial Number 8915225998

An earlier test in 2006 was made using NVIDIA GeForce 7600GT. This card was DVI only.

According to my invoices I also tested Gigabyte Nvidia Gtx 960 Version PCI-E Graphics Card June last year. Unfortunately senile dementia is kicking in. For the life of me I cannot remember why I returned it still favouring my AMD 6670:o

[huhn]

in the past nvidia driver was controlling the outpout bitdeep by it self. so this option is not really needed in the past. with high bitdeep input the driver switched to high bit deep output if possible.

the first AMD driver with output bit deep control was a 14.x driver.

AMD has just "better" control of the output. i can send 6 bit with an AMD card to my VS248QE with nvidia that'S not possible.

but i don't see any benefit using 6 bit and madVR.

[madshi]

Is Dolby Vision metadata now recognized and passed-through?
No.

So I updated my driver and it switches to stereoscopic resolution when I play mvc mkv file. But I'm not getting 3d. Its like it's switching to 3d and playing the 2d file and then when I exit, it stays in 3d resolution and I need to manually go to display panel and turn off 3d to get back to normal 1080p resolution.
Can you make a screenshot of the madVR OSD (Ctrl+J) please? Please upload it to some other site and link to it here.

does madVR Support assFilterMod (http://forum.doom9.org/showthread.php?p=1769770) ?
I don't know, haven't tried it yet. It seems to use the "new" subtitle interface, same as XySubFilter. So in theory it should work just fine. Have you tried it?

Stable as not crashing, or better video performance with Madvr?

Windows 10 is working nice on my PC, but if Madvr performes much better under Windows 8.1 I would very much like to know, and why, if you can spare the time explaining this to me. Thanx :)
If you have no problems, then there's no need to change. I can only say that there have been much more support and stability issues with Windows 10 so far. Maybe things have already improved, I don't know.

Without SVP the queues sometimes empty themselves for no apparent reason, render time is about 6 ms. I do not get dropped frames in that instance.
Which queues exactly?

In which step of the processing chain, does madVR gamma correct the video with gamma 2.4: before image scaling or after scaling?
Before scaling.

If it is done before image scaling then if Linear Light setting is used for say downscaling, does madVR use gamma 2.4 (in the given case) for linear light processing? Or irrespective of the video gamma madVR always uses gamma 2.2 for linear light processing?
It always uses the same gamma for linear light downscaling.

If the user is using a 3dlut, then what gamma does madVR use to gamma correct the video before 3dlut processing?
madVR 3dluts are always made for a 2.2 gamma input. The output is whatever the calibration software wants.

I didn’t see this option in the HDR settings page. Where can I find this?
Clipping highlights is the opposite of compressing highlights.

If it doesn't take much of your time, could you please show some illustration or sample images to show what details are lost and how well madVR is able to restore them at the default settings: anti-ringing and anti-bloating enabled with strength 100%?
Try the madTestPatternSource HDR test patterns (see first page).

Also, there's an option that states it won't work with DXVA scaling... so i need to turn off DXVA copy-back?
DXVA copyback is fine. Only DXVA native makes problems. Actually, madVR doesn't even know if DXVA copyback is used or software decoding. It doesn't make any difference to madVR.

It does seem to sudden stop playback (?Crash) frequently on my system.
Can't say much about this without more information.

In windows 10 x64 using Potplayer x64 bit with nvidia 368.39 drivers madVR v0.90.21 I can play NNEDI3 in Chroma Upscaling Nvidia 970 GTX.

Using the same settings in windows Potplayer x64 Nvidia 368.39 MadVR 0.90.21 Nvidia 970M , the movies crashes when it start playing.

What could be the issue ?
Most likely an NVidia OpenCL driver bug. You could try installing a different GPU driver.

2nd question , does Gsync cause issue if it stays enabled for Potplayer ? I didn't see any differences in performance enabled vs disabled , we still need to disable it ?
I don't know. I don't have Gsync, so I can't comment on that.

1. When I enable "measure frame luminance" the video freezes completely and not even Ctrl+J shows.
Oh, I probably forgot to check if your GPU can do DX11. I suppose your's can't?

2. I don't think 120 and 180 should elevate the shadows, just treat them as all other modes. *No special recipe needed.
I've tried that but it doesn't look very good, especially with the "Life of Pie" demo. Anyway, in the next build there will be a special hack: If you create an empty file named "DisableHdrBrightnessTweak", madVR will do as you suggest. Otherwise it will keep doing what it's doing. With a small improvement, though.

I sometimes see some images where "preserve hue" is actually too abrupt in transition between the shades and looks worse than without it.
Usually the color is less saturated (sometimes completely white) with it enabled and the transition might be too steep from color to white...
I believe it is because the somewhat steep knee of the highlight compression algorithm. If the goal is not to compress below 100nit the knee must be sharp/steep.
Samples?

I am sure the HDR algorithm will continue to improve in madVR.
Right now I don't know what I could do better.

MadShi i have asked you before about this but i can't get it to work. You told me that your overlay seekbar could be placed in active movie area when a movie is 2.35:1 did i understand you correctly? and if so how can i make this happen? the subtitles gets moved into active movie area with "zoom control, detect hc black bars, crop black bars", but i can't find any info about the seekbar.
This is mainly a feature for front projection. So it's hidden in the "screen config" settings page if you have specified your display to be a projector. The setting is called "move OSD into active video area".

Btw do you have plans to work on some motion compensate sharpener?
Nothing planned atm.

Long time no use madVR, recently updated to 90.21, and found there are many color noises over the screen. OS is XP, and AMD card. Bug?
Probably a GPU hardware or driver problem. Screenshot?

madshi, just wondering: how come such seemingly not so big changes lead to almost doubling of the filter's file size?
Wow, I didn't even notice!!

I can only imagine that the difference comes from all the addition shader variations introduced by the new HDR algorithms. I've compiled and stored all possible shader variations into the ax files, and it seems they add up to gigantic size now.

Could someone please point me to a guide on how to calibrate for HDR modes using hardware controls and madVR?
As long as you let madVR do the tone+gamut mapping your old SDR calibration should continue to work just fine for HDR content, too. The situation becomes much more problematic if you disable HDR processing in madVR and let the display do all the tone+gamut mapping. In that case I can't tell you how to calibrate.

I upgraded my video card from a GTX 970 to a GTX 1070 (FE).

At the same time I did a clean install of Windows 10. Only other installed programs are:

After configuring Emby to use MadVR, and maxing out the quality settings (more or less), I get a VIDEO_SCHEDULER_INTERNAL_ERROR BSD as soon as I attempt to launch a title from within Emby Theater.
Definitely a GPU driver issue.

the guys over on the nVidia GeForce forum are telling me they don't think it is a nVidia driver issue at all.
Then they probably don't know what they're talking about... :p

Bsod should always be driver's fault, not application's.
Yes. At least in most cases a BSOD comes from a misbehaving driver.

Does rendering speed change as a movie is playing?
I can see it changing from average stats of 10.86ms up to 27.80ms then it goes back down to 10.86ish.
I have been recently seeing a weird behavior where avg render times are increasing 5-10 seconds into any scene (say from 34ms to 38-39ms). What's weird though is, if I start the playback few seconds later, the scene that had increased render time previously is fine, but now next scene gets the hit and so on. So it looks like something is happening over time that is bringing up the render time and seems unrelated to a given scene.
3dlut calibration can lead to some varying render times, but with a decent GPU it shouldn't be that much. A more probable explanation would the the GPU switching between different power states / clocks.

I continue to have the same issue even in the latest rev v0.90.21 which was supposed to fix this
I was able to reproduce leeperry's green screen bug and fixed it. So if you still have this issue, it must be a different one. Which means: Please report it properly, with screenshots and lots of detail.

Blank screen when using non-DXVA2 downsapling here:
player: MPC-HC
video: http://demo-uhd3d.com/fiche.php?cat=uhd&id=144
Does the Ctrl+J OSD still work? If so, please post a screenshot of the OSD. Do other 4K samples work fine? Or do all show the same problem?

has anyone compared any HDR demos on a HDR tv and compared the picture quality to what you get here with madvr?
From the reports I've received so far, users who's done this comparison usually preferred madVR's tone mapping over what the display does.

Unfortunately madVR can't be used to playback UHD Blu-Ray discs atm, because the copy protection is not broken yet.

one more suggestion for HDR is if its possible to add the APL (average pixel level) information?
it seems that APL on most of the LG demos are higher than what UHD movies is at.
UHD movies are graded around 100 nits APL only but the LG demos are way to bright overall i think
"Add" where/how?

[madshi]

Is it possible madvr support transfer the HDR metadata with HDMI 2.0a or DP 1.4 ?
Not yet. No proper APIs available for that yet from NVidia, AMD, Intel and Microsoft. They're working on it, though. Actually, NVidia released something a couple of days ago, but I'm not happy with it yet, so I'm waiting for the next improved version.

For my eyes the 0.90.21 has more saturated highlights, then the 0.90.17, for me the latter one is more realistic and looks better. In case Sony HDR demo, the clouds at sunset are too yellowish with 0.90.21, it would be fine to have an option to set up the compressed highlight's saturation manually.
In theory 0.90.21 should be much more accurate than 0.90.17. There are several improvements in the accuracy of the algorithms in 0.90.21. I've tested a lot of different HDR demos, and sometimes 0.90.17 does look better. But in the majority of situations I prefer 0.90.21.

Question for madshi: Which is your reference HDR video?
I have one I like very much, but I got it under NDA, so I can't even say what it is. I do test with several demos, though.

I'm not in front of my computer now but it's the first buffer on the left.
That would be the decoder queue. If that one goes empty that means that whatever decoder you're using is not fast enough.

Madshi were you still interested in splitting the neuron pass settings up like in MPDN?
It's on my (very long) to do list.

Does madVR support windowless mode?
You mean from a developer point of view (windowless, renderless etc)? If that's what you mean, then the answer is no, not at the moment. Might be added in some far away future, though.

I was experimenting wit the excellent (IP) remote ability of MadVR (mad homecinemacontrol).

I was asking myself if I could talk directly to this API with my home automation system. (which can communicate with any UDP/TDP socket)

What is really interesting is that to the contrary of my mediaplayer (which uses MadVR) the mediaplayer itself does notpush player status..it has to be polled and further doesn't expose as much information as madvr does.

Listening to the right port I do get : [...]

The information pushed out by MADVr is excellent and could be so helpfull for home automation purposes (feedback and control).

I was also experimenting how I could "send commands" to madvr. Clearly using the Mad homecinema pop-up I can change language, subtitles, play/pause....it would be excellent if one could adress these commands directly with a UDP/TDP command string.

As I'm PC savvy but a complete programming noob I'm maybe asking for something impossible right now.

It would be really excellent if the mad homecinemacontrol api could be elaborated further...it's potential is really huge
There's a very limited number of network commands madVR currently supports. I've just implemented those I needed myself for the tray icon menu, for the calibration stuff etc. Of course it would be possible to add more commands and make it easier available somehow. But it would also cost a lot of time that I don't have, unfortunately.

The network protocol used between the tray icon app and the madVR instance is rather complicated. The protocol is "public" (see "developers" subfolder). However, it's not too easy to implement. So if you don't have development experience, it will probably be too hard for you.

Maybe I'll look into a more 3rd party friendly communication protocol in some far away future, but most probably not any time soon, due to lack of time.

Any progress on Vapoursynth integration?
No, not yet.

Currently, using SVP exponentially increases the workload on your GPU which makes using it alongside NNEDI3 and image doubling through madVR only possible on the very latest graphics cards. However most quad core CPUs could handle OpenCL based svpflow interpolating upscaled FullHD frames well above 60 fps
I have strong doubts about that. I think you're over-estimating what CPUs can do. Upscaled 4K frames at 60fps means lots and LOTS of data.

Anyway, if I do implement any kind of Vapoursynth support, it's likely to be before scaling, not after scaling, for the simple reason that the most important scripts for users would be noise reduction sort of stuff, and those need to be run before upscaling.

Hey madshi, I'm not able to send the crash report via error dialog to you as I keep getting this error message: [...]

I also didn't get bug report text file after closing the error dialog.
Not sure why it doesn't work. In any case, you can manually get the bug report text by pressing on "show bug report", then press Ctrl+C. Afterwards the bug report text should be in your clipboard.

Hi, I have a JVC HD350 Projector (RS10),i can use mkv to 4k in HDR ?(obviously in a limited way with respect to a panel HDR)
I want to see 4K material downscaling to 1080p, but wanted to know if he can use the HDR processing of madVR (if there is information in the metadata file) and be able to view the improvements even partially.

Native Gamut is large is extensive compared to the rec 709 .. and accepts 10bit 4.4.4 signals. It can be used to view the effect HDR (partially?)
Yes. The HD350 is not very bright, though, so the benefit of HDR over SDR will be rather small. You'll get some benefit from the higher bitdepth, though, and maybe from the higher gamut. Also the higher resolution, downscaled with SSIM looks visibly sharper and more detailed than the 1080p Blu-Ray.

Two problems, though: 1) For HEVC decoding you need a GPU that can decode it (e.g. NVidia 950/960/10xx, AMD 4xx). And 2) You can't play UHD Blu-Ray with madVR yet because the copy protection isn't broken yet.

Oh and question, anybody else have random BSOD when watching some video since the last windows security update (Vulnerability in Windows graphics component) ?
Try reinstalling your GPU drivers, or try a different GPU driver version.

Basically with a 2nd monitor attached, playing a file on my main monitor while it is at high refresh (144/165) in windowed mode will have lots of presentation glitches and some dropped frames. It stops happening if I either 1) disable the 2nd monitor or 2) drop the refresh rate down to 60. The refresh on my 2nd display is 60.
Windowed mode does have its reliability limitations, especially in combination with high refresh rates and multi monitor setups. Sorry to say, but this is a Windows/Direct3D limitation. Try either Overlay mode (if you have an NVidia GPU) or otherwise you have to use fullscreen exclusive mode.

I'm having a weird issue, I'm sometimes getting random white pixels, seems to happen more on darker content.
As was already mentioned, likely either a GPU hardware or a GPU driver problem. Try different driver versions.

When I enable or disable deinterlacing with MadVr the picture becomes darker or lighter depending on the setting. Nothing else has changed. Is that normal or a bug?
Oh, the joy of DXVA. madVR tries a lot of tricks to avoid such problems. It seems it doesn't work in your case. Have you tried resetting your GPU control panel "video" settings to neutral values?

Over the past few years prior to MadVR availability, I tested AMD & Nvidia GPU cards for what I perceived to be the best picture quality. I also got third parties involved that did not have a clue technically and they simply indicated which picture they preferred. At that time the AMD cards always seemed to be preferred. To my eyes AMD gave the picture more punch and depth than the Nvidia products. I tested at least 3 Nvidia cards at the time and always preferred any of my AMD cards 3000, 4000 series.
My best guesses:

1) Either you were using analog output.
2) Or you were using DXVA deinterlacing and/or scaling.

Could that be the case? With digital output, and when avoiding DXVA deinterlacing and scaling, I would expect modern AMD and NVidia GPUs to produce exactly the same image quality.

Oh well:

3) Maybe you had one of the GPUs set to 16-235 output? That would cost quality. You should use RGB 0-255 in the GPU control panel for best quality.

I am having problems with the 3D play back. I am using a optimus computer which uses both intel and Nvidia graphic cards and for some reason I can't select the Nvidia for MPC- HC to work on by normal means. I found a workaround online which is making a copy of the exe file of mpc- hc and change 5he name of it then I can choose to use the Nvidia graphic card. However when I play a MVc mkv with it, it immediately crashes my computer and a blue screen pops up saying there is a problem with the intel graphic driver. When I'm using the original one which only uses the intel graphic card, it displays 3D content correctly but with no sound. What can I do to fix it? My set up us to bit stream directly to my AMP but it's not working when it's a 3D video
These "Optimus" PCs are really far from optimal. I've seen all kinds of problems reported with these PCs. There have been some posts recently about how to make it work half way decent, though. Have you searched this thread for "Optimus"? I don't have such a system myself, though, so I can't really comment on it much. And I don't know if any Optimus user has tried 3D output yet. That could be highly problematic because 3D is already hard by itself, and with an Optimus system, Intel and NVidia GPUs *and* drivers have to work together, which makes things that much harder...

Hi, maybe this is just a lack of understanding on my part in which case I apologize, but I wonder if the aspect ratio automatically selected for this 16:9 display is wrong.

For a tv file with resolution 1920x1088 and a draw resolution of 1920x1074, 1.79:1 is auto selected. 1920x1088 is 1.77:1 and 16:9 is 1.78:1. If one overrides it to 16:9 it pulls it a tiny bit taller.

Same with a cinema file, draw of 1920x808=2.38:1, 21:9 (2.33:1) is auto selected, file resolution is 1920x816 which is 2.35. Manually selecting 2.35:1 pulls it a tiny bit taller.

The effect of pulling it taller makes circles more round and less squat.
It's hard to say anything without seeing some screenshots with the debug OSD (Ctrl+J) turned on. Also, do you have black bar detection turned on or off in the "zoom control" settings? If you have turned it on, does anything change if you turn it off instead?

[huhn]

I don't know, haven't tried it yet. It seems to use the "new" subtitle interface, same as XySubFilter. So in theory it should work just fine. Have you tried it?

i'm using it for over a month now (first the original version).
and it is working great so far.

i haven't done a color test yet. there was a test file but i don't have access to it.

3dlut calibration can lead to some varying render times, but with a decent GPU it shouldn't be that much. A more probable explanation would the the GPU switching between different power states / clocks.

i have rendertime changes of over 600% using a 960.

i'm going to replace this card "soon" and hope it is not an nvidia driver problem. but there is maybe more to it.

there where some more people reporting varying rendertimes and if i'm not mistaken they where all nvidia user.

[Magik Mark]

I have a movie with 23.976fps and a tv show with 23.976 as well. My display refresh rate is 23.970 as reported by madvr. How come judder is stronger in tv shows? Movies are soother. They just both have the same fps

Is there a way to correct this? Should I choose to reencode, are there any filters that would help? Except svp. It introduces artifacts. Maybe something similar to movie pan and motion quality. Less judder

[CarlosCaco]

I asked in other thread but have no answers... if madvr reports 1 frame dropped every 2,86 hours, the 86 means 86 minutes? (Like 3 hours and 26 minutes) Or 86 is a percentage of an hour? I really want to convert this value to seconds to calculate a custom resolution, but i do know whats correct...

[zoyd]

Does the Ctrl+J OSD still work? If so, please post a screenshot of the OSD. Do other 4K samples work fine? Or do all show the same problem?



Same problem here, any non-DXVA downscaling with HDR enabled leads to black screen with no OSD - sometimes it will crash mpc-hc as well.

https://dl.dropboxusercontent.com/u/2621383/madvrhdr_crash.png

[huhn]

which GPU is used?

[zoyd]

which GPU is used?

Intel HD5500 - I don't need realtime playback, just paused images to take a look at what HDR tone mapping madVR.

[Sunspark]

It's hard to say anything without seeing some screenshots with the debug OSD (Ctrl+J) turned on. Also, do you have black bar detection turned on or off in the "zoom control" settings? If you have turned it on, does anything change if you turn it off instead?

Hi, I took 4 screenshots saved as jpg (since we're just looking at the HUD) from 1 of the 2 files I had mentioned to demonstrate. Had to switch to windowed mode to do it. Also rendering time should be ignored since I paused playback and the focus is on the resolution.

Display is 2048x1152 resolution.

I know in a web browser it's hard to see much with the screenshots I took, but in fullscreen mode you can see the shift. Circles do change.

Summary:
1- 2.39:1, scaled to 2050 AutoBlack On, Default Aspect
2- 2.36:1, scaled to 2050 AutoBlack On, 2.35:1 Forced
3- 21:9, scaled to 2048 AutoBlack Off, Default Aspect
4- 2.35:1, scaled to 2048 AutoBlack Off, 2.35:1 Forced

1- Autodetect Black Bars On - Default Aspect Ratio
https://dl.dropboxusercontent.com/u/50794070/Misc/AutodetectBlackBarsOn.jpg

2- Autodetect Black Bars On - 235 Aspect Ratio Forced
https://dl.dropboxusercontent.com/u/50794070/Misc/AutodetectBlackBarsOn_235Forced.jpg

3- Autodetect Black Bars Off - Default Aspect Ratio
https://dl.dropboxusercontent.com/u/50794070/Misc/AutodetectBlackBarsOff.jpg

4- Autodetect Black Bars Off - 235 Aspect Ratio Forced
https://dl.dropboxusercontent.com/u/50794070/Misc/AutodetectBlackBarsOff_235Forced.jpg

[truexfan81]

i hope they get these windows 10 issues fixed soon, after doing my clean install, i've had to back my madvr settings way way down from where they were on windows 8.1. funny thing tho everything else is faster on windows 10, only madvr is slower

[huhn]

Intel HD5500 - I don't need realtime playback, just paused images to take a look at what HDR tone mapping madVR.

try lowering the GPU queue to 4 and give your GPU at least 2GB Vram this may work as a work around for now.

[Sunspark]

i hope they get these windows 10 issues fixed soon, after doing my clean install, i've had to back my madvr settings way way down from where they were on windows 8.1. funny thing tho everything else is faster on windows 10, only madvr is slower

Try checking on the boxes for "use separate device for presentation, dxva" and see if it makes a difference.

[JarrettH]

there where some more people reporting varying rendertimes and if i'm not mistaken they where all nvidia user.

Yeah, one was me.

I almost forgot I asked about the performance impact of a 3D LUT :D The estimate of a swing up of 5-10 ms sounds accurate, whereas without one, render times hardly vary (~1 ms). I'm on a 550 Ti (1 gb) with the latest driver.

[James Freeman]

1. When I enable "measure frame luminance" the video freezes completely and not even Ctrl+J shows.
Oh, I probably forgot to check if your GPU can do DX11. I suppose your's can't?
GTX660 supports D3D11 just fine, NNEDI3 working as it should.
I even use D3D11 for presentation.

The images stays frozen even when I turn On "measue each frame" and turn OFF "compress highlights"!, so everything greyed out yet the image still frozen.
This will probably get you closer to finding the problem.

2. I don't think 120 and 180 should elevate the shadows, just treat them as all other modes. *No special recipe needed.
I've tried that but it doesn't look very good, especially with the "Life of Pie" demo. Anyway, in the next build there will be a special hack: If you create an empty file named "DisableHdrBrightnessTweak",
madVR will do as you suggest. Otherwise it will keep doing what it's doing. With a small improvement, though.
Thank you for letting the user choose, as always.

I sometimes see some images where "preserve hue" is actually too abrupt in transition between the shades and looks worse than without it.
Usually the color is less saturated (sometimes completely white) with it enabled and the transition might be too steep from color to white...
I believe it is because the somewhat steep knee of the highlight compression algorithm. If the goal is not to compress below 100nit the knee must be sharp/steep.
Samples?

To me it appears that the change is too abrupt in luminance and color, in audio compression it's called a "knee".
Sometimes a Soft knee sounds more natural than a Hard knee, because you hear less the transition from uncompressed to compressed.
When hdr processing is turned off everything looks natural.

*PS
Download the LG Chess HDR demo, much can be revealed there.

From the Sony HDR video, look at the hand:

http://www.mediafire.com/convkey/339c/w1nunu9usbzbhxbzg.jpg
http://www.mediafire.com/convkey/5bc8/0daj7k5t9jtsg0jzg.jpg
http://www.mediafire.com/convkey/e106/fcadnib9da7nb3mzg.jpg

[mogli]

I asked in other thread but have no answers... if madvr reports 1 frame dropped every 2,86 hours, the 86 means 86 minutes? (Like 3 hours and 26 minutes) Or 86 is a percentage of an hour? [...]
That's probably because you gave the answer yourself:
If it would be minutes, then it would be 3,26 hours. Unless of course madVR defines hours as having 100 minutes. Then 2,86 hours in madVR would be 4 actual hours and 46 minutes. Nah, just joking.
It's 2,86 hours = 171,6 minutes = 10296 seconds. Just multiply the number shown by madVR with 3600 and you got what you want. :p

[madshi]

i'm using it for over a month now (first the original version).
and it is working great so far.
Good to hear!

i have rendertime changes of over 600% using a 960.

i'm going to replace this card "soon" and hope it is not an nvidia driver problem. but there is maybe more to it.

there where some more people reporting varying rendertimes and if i'm not mistaken they where all nvidia user.
And it's not power state / clock related?

I have a movie with 23.976fps and a tv show with 23.976 as well. My display refresh rate is 23.970 as reported by madvr. How come judder is stronger in tv shows? Movies are soother. They just both have the same fps
No idea, if the TV shows are really 23.976 then there shouldn't be a difference. In any case, try optimizing your refresh rate. 23.970 seems to low/slow.

Same problem here, any non-DXVA downscaling with HDR enabled leads to black screen with no OSD - sometimes it will crash mpc-hc as well.
Hmmm... The crash is when referencing an freshly allocated texture. I can only imagine that you're running out of GPU RAM? As huhn has suggested, try saving GPU RAM by reducing the size of the GPU queue, and maybe the number of pre-presented frames.

Downscaling with HDR enabled definitely works fine on my PC.

Hi, I took 4 screenshots saved as jpg (since we're just looking at the HUD) from 1 of the 2 files I had mentioned to demonstrate. Had to switch to windowed mode to do it. Also rendering time should be ignored since I paused playback and the focus is on the resolution.

Display is 2048x1152 resolution.

I know in a web browser it's hard to see much with the screenshots I took, but in fullscreen mode you can see the shift. Circles do change.

Summary:
1- 2.39:1, scaled to 2050 AutoBlack On, Default Aspect
2- 2.36:1, scaled to 2050 AutoBlack On, 2.35:1 Forced
3- 21:9, scaled to 2048 AutoBlack Off, Default Aspect
4- 2.35:1, scaled to 2048 AutoBlack Off, 2.35:1 Forced
Ok, the numbers don't properly add up, that's for sure. Can you please check if you get the same or different results when using something other than DXVA for upscaling?

GTX660 supports D3D11 just fine, NNEDI3 working as it should.
I even use D3D11 for presentation.

The images stays frozen even when I turn On "measue each frame" and turn OFF "compress highlights"!, so everything greyed out yet the image still frozen.
This will probably get you closer to finding the problem.
Doesn't seem to happen on my PC. Could it be you're running out of GPU RAM, like (probably) zoyd? Does reducing the size of the GPU queue help?

Download the LG Chess HDR demo, much can be revealed there.

From the Sony HDR video, look at the hand
Download links? FWIW, the hand seems to change the hue, without "preserve hue", it becomes yellow/orange. That doesn't seem right to me.

My algos put highest priority on reproducing the proper brightness for each pixels. The hand is probably supposed to have the same color, but different brightnesses/saturations. The problem is that an SDR display cannot handle very saturated pure color (red, green, blue) highlights. So I'm between a rock and a hard place there: Either I try to reproduce the correct luminance. That means I have to desaturate the pixel. Or alternatively I try not to desaturate, but then the luminance is all wrong (much too low).

Example: If you have a 4000 nits pure blue pixel. With a 400 nits SDR display after tone mapping it becomes 400 nits pure blue. But the SDR display can really only show 400 nits as a white pixel. With pure blue the display can only achieve about 30 nits because that's the part the blue subpixel contributes to overall luminance in a white pixel!!! So what do you want me to do? Display the blue pixel as 30 nits pure blue? Then the color and saturation is correct, but the luminance is WAY off. So what madVR does instead is: It desaturates, if neccesary, just enough to make the pixel bright enough. I see no other proper solution to this problem.

So the problem is not the knee at all, it's rather highly saturated pure red, green or blue colors.

[e-t172]

My algos put highest priority on reproducing the proper brightness for each pixels. The hand is probably supposed to have the same color, but different brightnesses/saturations. The problem is that an SDR display cannot handle very saturated pure color (red, green, blue) highlights. So I'm between a rock and a hard place there: Either I try to reproduce the correct luminance. That means I have to desaturate the pixel. Or alternatively I try not to desaturate, but then the luminance is all wrong (much too low).

Example: If you have a 4000 nits pure blue pixel. With a 400 nits SDR display after tone mapping it becomes 400 nits pure blue. But the SDR display can really only show 400 nits as a white pixel. With pure blue the display can only achieve about 30 nits because that's the part the blue subpixel contributes to overall luminance in a white pixel!!! So what do you want me to do? Display the blue pixel as 30 nits pure blue? Then the color and saturation is correct, but the luminance is WAY off. So what madVR does instead is: It desaturates, if neccesary, just enough to make the pixel bright enough. I see no other proper solution to this problem.

So the problem is not the knee at all, it's rather highly saturated pure red, green or blue colors.

This is a classic gamut mapping problem - what to do with out of gamut colors. This is exactly the type of problem that a CMS (such as ArgyllCMS or LittleCMS) is designed to solve through the concept of rendering intent (https://en.wikipedia.org/wiki/Color_management#Rendering_intent). There are plenty of ways (http://www.argyllcms.com/doc/collink.html#i) to approach the issue. From what you're saying it seems like you went for a simple clipping rendering intent that attempts to minimize the luminance delta. This seems similar to Argyll's "-ir" option (which Graeme recommends (http://www.argyllcms.com/doc/Scenarios.html#TV1) for video). However Argyll's "-ir" option tries to minimize DeltaE in general, not just the luminance delta, which seems more perceptually appropriate.

[James Freeman]

Ok, the numbers don't properly add up, that's for sure. Can you please check if you get the same or different results when using something other than DXVA for upscaling?
Actually, all the queues are empty starting from the Decoder one, I guess i7 3.9@GHz is not enough for 60fps 2160p decoding.
My old GTX660 doesn't decode HEVC.

Still, it doesn't matter, because with Exodus HDR where all queues are full it freezes too when I turn on "measure frame peak luminance".

Download links? FWIW, the hand seems to change the hue, without "preserve hue", it becomes yellow/orange. That doesn't seem right to me.
http://demo-uhd3d.com/categorie.php?tag=hdr
Skin tones will be the most noticeable, so concentrate on that.
I wonder how the Samsung UHD player manages that.

[huhn]

And it's not power state / clock related?

yes for sure. the card is using max boost clock, it is rarely dropping down a little bit it is not really stressed out.

i have to use not optimal settings like a GPU queue of 4. so i can't say the 3D LUT is the problem.

i have rendertimes of ~14 ms with a 3D LUT if nothing special happens.
than there are some "special" colors and they can easily stay up to ~26 ms AVG. i can reliable reproduce this.
with a disabled 3D LUT the rendertimes stay at 12 ms even with "special" color.

sometimes stuff like AVG 80-120 ms happens for a couple of secs but i can't reliable reproduce this.

i can't test this right now so the ms maybe inaccurate by a couple of ms.

edit:

you are aware that the images from Sunspark have a small black bar at the right side so after cropping them the numbers change of cause.

[madshi]

This is a classic gamut mapping problem - what to do with out of gamut colors. This is exactly the type of problem that a CMS (such as ArgyllCMS or LittleCMS) is designed to solve through the concept of rendering intent (https://en.wikipedia.org/wiki/Color_management#Rendering_intent). There are plenty of ways (http://www.argyllcms.com/doc/collink.html#i) to approach the issue. From what you're saying it seems like you went for a simple clipping rendering intent that attempts to minimize the luminance delta. This seems similar to Argyll's "-ir" option (which Graeme recommends (http://www.argyllcms.com/doc/Scenarios.html#TV1) for video). However Argyll's "-ir" option tries to minimize DeltaE in general, not just the luminance delta, which seems more perceptually appropriate.
But the problem I was describing is different: The hue (by itself) is not really out of gamut at all! If you plot the pixel color in xyY, it's within e.g. the BT.709 triangle. The problem is that the HDR source asks for a highly saturated (but still in gamut) color to be displayed at a very high luminance value. The problem is not that the hue would be outside of the BT.709 triangle, but the problem is the high luminance of a highly saturated color.

BTW, I'm doing the desaturation in a perceptually (more or less) uniform color space.

Actually, all the queues are empty starting from the Decoder one, I guess i7 3.9@GHz is not enough for 60fps 2160p decoding.
My old GTX660 doesn't decode HEVC.
What does any of that have to do with my guess that you might be running out of GPU *RAM*?

I wonder how the Samsung UHD player manages that.
I haven't tested it, but I would guess that madVR has much more complex and accurate algorithms than any CE device out there atm, except maybe Dolby Vision devices when playing back Dolby Vision content, I'm not sure about that.

[James Freeman]

What does any of that have to do with my guess that you might be running out of GPU *RAM*?
Sorry, I failed to mention that the GPU RAM is not even half full (860/2048 MB), so I went straight ahead to other apparent reasons to me.
Reducing queue does not help either.

Now that I look again at the CPU usage, I see that the decoding stops when the image freezes, while the playback bar still running in MPC-HC.

[e-t172]

But the problem I was describing is different: The hue (by itself) is not really out of gamut at all! If you plot the pixel color in xyY, it's within e.g. the BT.709 triangle. The problem is that the HDR source asks for a highly saturated (but still in gamut) color to be displayed at a very high luminance value. The problem is not that the hue would be outside of the BT.709 triangle, but the problem is the high luminance of a highly saturated color.

No, this is exactly the gamut mapping problem. You might be confused by the fact that gamuts are often represented in 2D form (a "slice" at 50% luminance, typically), but that's misleading. When Argyll and other CMSes use the term "gamut", they mean the full 3D gamut, including luminance, not just hue and saturation. Internally, gamuts are always represented as 3D volumes. Argyll even has a tool (http://www.argyllcms.com/doc/viewgam.html) to visualize the actual gamut as a 3D object.

When translating HDR highlights to SDR, the source color is out of gamut. Maybe it won't appear out of gamut on a 2D gamut view that only shows partial information (i.e. hue and saturation, discarding luminance), but it will definitely appear out of gamut (on the luminance axis) on the actual, 3D gamut view.

Here's an example of what the complete BT.709 gamut looks like, including luminance information. (https://www.youtube.com/watch?v=BQGbbobBsiw) It's quite clear on this representation that if you have a red color (for example) that is both very bright and very saturated, it will be out of gamut (it will be "too high" on the Y axis). Also notice how, at the very end of the video, the gamut looks just like the popular 2D gamut representation when viewed from above, and the Y axis "disappears".

BTW, I'm doing the desaturation in a perceptually (more or less) uniform color space.

You mean LAB? In that case wouldn't it be possible to just minimize DeltaE (which is a "more correct" approach, perceptually speaking) instead of trying to minimize luminance? Modern DeltaE formulas such as dE94 and dE2000 can be directly applied on LAB coordinates. I'm not sure if it's that easy though, because you're trying to find the closest point contained within a given gamut, which itself is an arbitrary 3D volume. I'm not good enough with math to know if that's an easy problem or not. However, no matter how hard the problem is, any CMS library knows how to solve it, because that's by definition what a CMS does all day.

[zoyd]

You mean LAB? In that case wouldn't it be possible to just minimize DeltaE (which is a "more correct" approach, perceptually speaking) instead of trying to minimize luminance? Modern DeltaE formulas such as dE94 and dE2000 can be directly applied on LAB coordinates. I'm not sure if it's that easy though, because you're trying to find the closest point contained within a given gamut, which itself is an arbitrary 3D volume. I'm not good enough with math to know if that's an easy problem or not. However, no matter how hard the problem is, any CMS library knows how to solve it, because that's by definition what a CMS does all day.

What he's doing now (with "maintain hue") is very close to what is produced using CalMAN to generate the mapping in an external LUT on the tests that I have run. Unfortunately ArgyllCMS does not have ST.2084 implemented (let alone any compressed tone mapping).

https://dl.dropboxusercontent.com/u/2621383/tonemap.png

[madshi]

Now that I look again at the CPU usage, I see that the decoding stops when the image freezes, while the playback bar still running in MPC-HC.
Hmmmm... So the freeze could be caused by decoding stopping to work? Do you ever get crashes, or "just" that freeze?

No, this is exactly the gamut mapping problem. You might be confused by the fact that gamuts are often represented in 2D form (a "slice" at 50% luminance, typically), but that's misleading. When Argyll and other CMSes use the term "gamut", they mean the full 3D gamut, including luminance, not just hue and saturation.
Fair enough. I thought when you said "out of gamut" you meant DCI-P3 colors when using a BT.709 screen.

You mean LAB? In that case wouldn't it be possible to just minimize DeltaE (which is a "more correct" approach, perceptually speaking) instead of trying to minimize luminance? Modern DeltaE formulas such as dE94 and dE2000 can be directly applied on LAB coordinates. I'm not sure if it's that easy though, because you're trying to find the closest point contained within a given gamut, which itself is an arbitrary 3D volume. I'm not good enough with math to know if that's an easy problem or not. However, no matter how hard the problem is, any CMS library knows how to solve it, because that's by definition what a CMS does all day.
I'm not using LAB because it's not hue linear. I'm using ICtCp, the latest Dolby creation for HDR color processing, which should be approximately hue linear and perceptionally uniform (I hope).

Anyway, what does a CMS do for out of gamut colors? If the asked for luminance is within the display's capabilities, does a CMS ever decrease luminance, to avoid desaturation? Isn't the usual approach to not touch luminance, but move the pixel from out-of-gamut to in-gamut by desaturating it appropriately?

What he's doing now (with "maintain hue") is very close to what is produced using CalMAN to generate the mapping in an external LUT on the tests that I have run.
So does that mean what I'm doing is "good"? (I hope so :D )

[James Freeman]

Hmmmm... So the freeze could be caused by decoding stopping to work? Do you ever get crashes, or "just" that freeze?

It very well could be.
Just that freeze.
Decoding is done by the CPU, I don't see a reason why it would stop.

[madshi]

Does it stop when using a different renderer?

P.S: It only occurs when activating "measure each frame's luminance value"?

[zoyd]

So does that mean what I'm doing is "good"? (I hope so :D )

I think so! Presumably CalMAN finds the closest in-gamut color while minimizing dE2000. Your rendering may be desaturating a little more than needed but you'd have to run test patches and measurements to quantify. BTW, mascior@avsforums will be releasing a set of UHD/HDR10 calibration streams in the near future.

[James Freeman]

Does it stop when using a different renderer?

P.S: It only occurs when activating "measure each frame's luminance value"?

Other renderer? like EVR? No, only madVR.
EDIT: It doesn't freeze at all with madVR or EVR at normal playback, only when I enable this particular option in madVR.

I enable "measure each frame's luminance value" and as soon as I click Apply -> freeze.

[Ver Greeneyes]

I'm not using LAB because it's not hue linear. I'm using ICtCp, the latest Dolby creation for HDR color processing, which should be approximately hue linear and perceptionally uniform (I hope).I haven't heard of that one (which doesn't mean anything in and of itself), but an alternative might be CAM02-UCS, which was specifically designed to be perceptually uniform. There's a python implementation here (https://github.com/njsmith/colorspacious), though I don't know how readable it is (IMO one of the hardest parts about implementing it is figuring out what viewing conditions you want to use).

[e-t172]

Unfortunately ArgyllCMS does not have ST.2084 implemented (let alone any compressed tone mapping).

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.

Anyway, what does a CMS do for out of gamut colors? If the asked for luminance is within the display's capabilities, does a CMS ever decrease luminance, to avoid desaturation? Isn't the usual approach to not touch luminance, but move the pixel from out-of-gamut to in-gamut by desaturating it appropriately?

As I said, it all depends on the rendering intent that you select, and it's also a point of differentiation between different CMSes. The process is often tunable (for example Argyll's "-i" option). It's not clear if there is one single "best" approach (of course there are bad ones). I believe Argyll simply tries to minimize DeltaE between source color and destination color, and that sounds like the most reasonable approach to me, but I'm not an expert :)

As Ver Greeneyes just said, CAM02-UCS is the state of the art in that field, so trying to minimize the color difference in that space would probably give the most accurate result. But converting into CAM02-UCS requires viewing conditions to be known, so things become more complicated. In any case, again, CMS libraries are there to help. Argyll does implement CIECAM02, for example.

[zoyd]

I'm not using LAB because it's not hue linear. I'm using ICtCp, the latest Dolby creation for HDR color processing, which should be approximately hue linear and perceptionally uniform (I hope).


These are the suggested coordinates for applying the roll-off function in BT.2390. In addition there is a saturation adjustment recommended after applying that function.

[Sunspark]

Ok, the numbers don't properly add up, that's for sure. Can you please check if you get the same or different results when using something other than DXVA for upscaling?


Sure thing, I switched it to Jinc luma upscaling and ran it through all 4 selections again. The 4 aspect ratios and scale-to numbers displayed for each option were exactly the same as when Dxva was selected.

[madshi]

I think so! Presumably CalMAN finds the closest in-gamut color while minimizing dE2000. Your rendering may be desaturating a little more than needed but you'd have to run test patches and measurements to quantify. BTW, mascior@avsforums will be releasing a set of UHD/HDR10 calibration streams in the near future.
Thanks!

Other renderer? like EVR? No, only madVR.
EDIT: It doesn't freeze at all with madVR or EVR at normal playback, only when I enable this particular option in madVR.

I enable "measure each frame's luminance value" and as soon as I click Apply -> freeze.
Ok, will have to check with my NVidia GPU then, maybe it's GPU dependent. With my AMD it works just fine.

an alternative might be CAM02-UCS, which was specifically designed to be perceptually uniform.
As Ver Greeneyes just said, CAM02-UCS is the state of the art in that field
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.

These are the suggested coordinates for applying the roll-off function in BT.2390. In addition there is a saturation adjustment recommended after applying that function.
I'll have to check the saturation adjustment, sounds interesting.

Sure thing, I switched it to Jinc luma upscaling and ran it through all 4 selections again. The 4 aspect ratios and scale-to numbers displayed for each option were exactly the same as when Dxva was selected.
Ok, thanks. My display maxes out at 1080p, so I can't really test your results. Can you please create a debug log for me with Jinc upscaling and black bar detection disabled?

[Ver Greeneyes]

But CAM02-UCS is not hue linear, or is it?Hue isn't one of the final coordinates, but a* and b* (which together represent a combination of hue and saturation) are separate from the brightness/lightness. The final coordinates are intended to be linear, so scaling a* and b* by the same amount should perceptually preserve the hue and saturation as much as possible as far as I know. So long as you change both by equal amounts the actual hue angle shouldn't change, since a* and b* incorporate the sine and cosine of the hue angle.

Why did Dolby invent ICtCp if CAM02-UCS would be better? ICtCp is brand new and recommended by Dolby for HDR processing.That I don't know :) Maybe worth asking on the ArgyllCMS mailing list or something; Graeme at least is an actual color scientist (I'm certainly not).

One caveat to CAM02-UCS is that it involves a fair number of calculations, so it might be slow and create a large rounding error. It might be that ICtCp tries to address this while still giving fairly good results.