madVR - high quality video renderer (GPU assisted) [Archive] - Page 374

cyberbeing

5th May 2013, 05:56

A valid check would be to use "collink -a TV.cal" and load a linear VideoLUT using "dispwin -c".
That's what I did when I originally checked with collink -a... I'm well aware that madVR's option only applies to Fullscreen Exclusive mode, so when I test 3DLUT functions similar to collink -a or ti3 parser's dispcal calibration merging method, I always manually load a linear VideoLUT. When I'm done I reload my ICC profile VideoLUT. Before doing any measurements, I always double check that the correct VideoLUT is loaded using GretagMacbeth's CalibrationTester tool.

"collink -a TV.cal" measured with a linear VideoLUT
The neutral Y values measured with Dispcal VideoLUT alone do not match Y values of Linear VideoLUT + collink -a generated madVR 3DLUT

"collink" not using -a was measured with a Dispcal VideoLUT
The neutral Y values measured with Dispcal VideoLUT alone do not match Y values of Dispcal VideoLUT + collink generated madVR 3DLUT.

collink changes the "ideal" gamma curve to something else entirely. It does not agree with the verified correct Y values which dispcal calibrates to.

the two configurations wouldn't be expected to match.
Considering my testing method was valid, not invalid as you had assumed, are what should be identical Argyll configurations not matching expected behavior for collink? I'm currently actually leaning towards yes it is intentional that what should be identical don't match, since the same behavior also occurs when using collink to create Device Links for normal ICC profiles and nobody has complained. This way of gamma adaption must be intended when creating ICC Device Links?

collink appears to perform an ICC Device Link between the gamma curve of the source (Rec709.icm) & destination (monitor.icm) profile. Use of the -I parameter override, can cause things to go even more askew of the intended target. It's a blackbox kind of adaption without any ability to target a specific (verified by measurements) gamma curve unless you hack the relevant values in both src & dst ICC profiles to match, something which is completely impractical for an end-user to do. As mentioned above, I'm actually expecting that the current behavior in collink is intentional, but that does mean it won't yield results expected by video calibration which needs to be able to target an exact (calculated or custom) response curve on the display.

I would really like to see this or another Argyll tool take a step away from the world of ICC color management, and support gamut adaption with customizable & fine-tuned user control of output results, especially for gamma curve. There is value in what collink currently offers, which is essentially ICC color management in a madVR 3DLUT, I just hope for something more tuned to the needs of video calibration some day.

In my testing, you can't disable the VideoLUT in MadVR
FWIW, if you enable Overlay mode in madVR, that will disable the VideoLUT (GPU Overlay doesn't support VideoLUT) when not in Fullscreen Exclusive mode. So if you are using "collink -a" you really should be using Overlay mode as well. Without -a, use normal Windowed mode with VideoLUT loaded.

G_M_C

5th May 2013, 08:41

Gents, i have a question:
I have a panasonic plasma that i had calibrated by an ISF professional. In my mind that means that I dont need any calibration/gamma processing done by madVR. I only have to make sure that I the get the input to the display be as close to the source as possible; a 'source direct mode' as to speak.

If i disable levels conversion in LAV filters ('as source') and disable calibration controls/gpu gamma ramps and disable gamma processing in madVR, do I get the desired 'source direct mode' ?

madshi

5th May 2013, 09:55

Why is Jinc 3 the "maximum" quality on Niyawa's chart (http://i.imgur.com/HLv1qmj.png)?
Because using more taps in many cases adds more artifacts than it helps. Jinc4 might still be an option, however I definitely don't recommend Jinc8.

BTW, is the judder test of Reclock meant to be really really dead smooth with mVR?
I don't know exactly how and when exactly Reclokc draws the judder test, so I can't really say...

While we're on it, what is "disable GPU gamma ramps for"?
Most (all?) GPUs have built in 1D Luts to perform some sort of gamma correction. By default those Luts are configured to "untouched passthrough" in Windows, I believe. But if you play around with GPU driver settings and stuff, or if you use ICC profiles, you might (accidently or not) fill those Luts with some values. For video playback, if you calibrate without those 1D GPU Luts, you want them disabled. That is the purpose of that madVR option: To disable those 1D GPU Lets. Currently this option only works in FSE mode. (And in Overlay mode it seems the GPU 1D Luts are *always* disabled).

what are presentation glitches and how can they be avoided?
These are glitches that happen somewhere between the GPU drivers and Direct3D, outside of madVR's control. madVR simply reports these. They usually only happen in fullscreen exclusive mode. Older NVidia drivers were known to produce lots of these. Thankfully this was fixed in newer drivers. So make sure you use the latest drivers. Also I'm not sure if the NVidia driver bug was fixed in XP. So if you're in XP you might be out of luck. In that case you may want to disable FSE mode. Or update to Windows 7 or 8.

I found a bug that's happened only with madVR, with other renderer all ok. I use IMFGetService::GetService() to get a pointer to IDirect3DDeviceManager9. It's need to Hook call CreateVideoDecoderMine() for detect DXVA2 mode.
Well - some commercial decoder like ArcSoft & Cyberlink init DXVA2 decoder while connect to the renderer, so I need set a Hook before decoder connect to the renderer. But - madVR give a error.
here this a code:

if (CComQIPtr<IMFGetService, &__uuidof(IMFGetService)> pMFGS = pBF) {
CComPtr<IDirectXVideoDecoderService> pDecoderService;
CComPtr<IMFGetService> pGetService;
CComPtr<IDirect3DDeviceManager9> pDeviceManager;
HANDLE hDevice = INVALID_HANDLE_VALUE;

// Query the pin for IMFGetService.
hr = pMFGS->QueryInterface(__uuidof(IMFGetService), (void**)&pGetService);

// Get the Direct3D device manager.
if (SUCCEEDED(hr)) {
hr = pGetService->GetService(
MR_VIDEO_ACCELERATION_SERVICE,
__uuidof(IDirect3DDeviceManager9),
reinterpret_cast<void**>(&pDeviceManager));
}
...

error on call pGetService->GetService(). Here is a bugreport.txt - http://aleksoid.voserver.net/MPC-BE/madVR_bugreport.txt
Thanks. Looks like a simple bug in madVR. However, it's caused by asking madVR for the D3D device so early. I will add a new interface to madVR to allow you to ask whether DXVA is used, so that you don't have to ask for a D3D device at all. I think that should be the best solution.

Funny because exclusive mode here always makes things worse. My rendering doubles when it's enabled. I used to get a lot of dropped frames with it. One funny thing I noticed about queues is that the higher the CPU queue, the lower the rendering ms and as soon as my GPU queue goes above 6 my rendering time goes "sky's the limit". In the end I'm using 32/6 respectively.
Maybe your GPU is running out of (fast?) memory when using a higher than 6 GPU queue. For most people exclusive mode performs better than windowed mode - except maybe if you use very high refresh rates (e.g. 120Hz). Not sure why that doesn't seem to apply to you. Maybe the drivers for your GPU are bad.

I noticed that when playing 1080p24 (mkv, m2ts, ts .. full screen exclusive mode, default settings) my screen goes to 23hz. Because of this, there is a drop frames every 30-40 sec.

If I uncheck 'Present Several frames in advance "(old path), my screen stays in 24hz.

Is it related to Windows 8, Desktop Window Manager (DWM)?
Weird. Now that my development PC is win8, maybe I can look into those refresh rate issues.

Spoils window caption in the MPC-BE and MPC-HC.

Sample: davichi cut.zip (http://pan.baidu.com/share/link?shareid=454759&uk=3558042035)
Thanks, will have a look at this.

I use MPC-HC with madVR and I have 2 different displays: a plasma TV and a projector. I have an AVR between HTPC and the displays.

I defined the 2 different displays in madVR connected to the AVR but I need to indicate different settings in calibration options because each of them has been calibrated with a specific 3dlut file.

Is there a way for madVR to automatically switch for each display recognizing wich one is attached at a given moment?

Now I switch to the target display manually but it is a nuisance and time wasting.
Does madVR detect different "identification"s if you switch your displays? If so, you can assign the correct display to the correct identification in the madVR device setup. If not, that means that your AVR doesn't give madVR *any* indication whatsoever that your display has changed. In that situation there's really nothing madVR can do automatically. That would be the fault of your AVR then. Or does Windows show the display name/information anywhere, or any other hint that the display might have changed?

updating the driver significantly reduced the number of presentation glitches, disabling the 'present frames in advance' in the settings removed presentation glitches from the OSD (so I'm not sure if they are non-existent or just hidden from the OSD).
When disabling "present frames in advance", a totally different presentation method is used. Presentation glitches are not counted when using that method.

With new drivers and the default madVR settings, do you get presentation glitches only during playback start? If so, you can simply ignore them, they don't matter much. If you get presentation glitches in the middle of playback, that would be bad.

First of all huge thanks to madshi for coming up with Smooth Motion. I bought a Panasonic plasma that has horrendous false contouring in both 24hz and 50hz modes that I unfortunately can't return.

Using Smooth Motion has resolved almost all possible problems I had with the 24hz and 50hz modes @ 60Hz. Only thing that could be improved upon is a bit of ghosting or double images that occurs when objects move quickly across the scene or end end credits that roll down quickly.
Does this ghosting not occur when disabling smooth motion @ 60Hz? If the ghosting also occurs without smooth motion then it's a problem of your display and not madVR's fault. Otherwise: Have you already unchecked the "don't use linear light for smooth motion frame blending" option (see "rendering -> trade quality for performance")? If so, try that. Do you see the ghosting with both 24fps and 50fps content?

Hi, madshi. I'm wondering what will madVR do with 24p content when the refresh rate is 60Hz. 2:3 pulldown?
I recently got a TV that can detect pulldown patterns and do IVTC quite correctly when refresh rate is not 24Hz. And I tried 24p video with 60Hz refresh rate using EVR, it's as smooth as playing 24p video with 24Hz refresh rate. But when I use madVR, the video keeps shaking. I think EVR is using 2:3 pulldown and TV can detect correctly, and madVR is using some kind of pulldown pattern that cannot be detected by TV.
BTW, I only play vfr videos with 60Hz refresh rate.
madVR doesn't handle 24p @ 60Hz very well if you have Smooth Motion FRC disabled. madVR doesn't really do 2:3 pulldown in that situation. It simply calculates a "good" vsync to present each frame at. That might result in a somewhat random pulldown pattern. Try activating Smooth Motion FRC.

using madVR broken call SetWindowText() in MainWindow
Not sure what you mean. Are you saying this is MPC's fault? Or are you saying it is madVR's fault?

Are you familiar with the Lightpack (http://www.kickstarter.com/projects/woodenshark/lightpack-ambient-backlight-for-your-displays)Kickstarter project? If so, what are your thoughts?
Not sure what this has to do with madVR? In any case, I prefer to watch movies in a batcave with no ambient light whatsoever...

madshi

5th May 2013, 09:58

Been using madvr for about a week now and it is superb. Only issue I have is with ripped dvd files.

It just doesn't like them on my system. I can encode the vob to mp4 or mkv and they play flawlessly without any choppiness, but playing the vob directly, results in constant dropped frames and choppiness. I really dont want to re encode all my dvds to mp4, but I will if it means I can use madvr...

I'm using mpchc x86 with lav codecs. I use dxva and it works well for every other file. The vobs play when removing madvr from the equation, but the quality drops dramatically, so I obviously want it on.

Ive noticed that during vob (mpeg2) playback, the cpu uses up to 80% of its resources. DXVA is definitley being used though, as it shows on CTRL J

CPU power is usually around 30% with other video files.
My first suggestion would be to use software decoding for DVDs because decoding DVDs is *SO* easy on the CPU. DXVA decoding is useful mainly for h264 and VC-1. Maybe for MPEG2 HD content. But DVDs are really a piece of cake even for stone age CPUs.

Dropped frames can be caused by various different things. Please take a screenshot of the madVR OSD (Ctrl+J) when those drops occur and post it here. Based on that screenshot I can tell you a bit more about why those frame drops probably occur.

To be honest, the quality loss when re-encoding a DVD to AVC will be more noticeable than the improvement you get with MadVR over EVR
I do agree that re-encoding to AVC is not a good idea (unless you absolutely have to save room on your harddisk and if you don't care about losing a bit of image quality).

However, I think madVR can bring a nice benefit over EVR especially for DVD playback. Jinc3 AR can really make a difference with aliasing and ringing. The advantages of Jinc3 AR show better the higher the scaling factor is. So it should help especially for DVD playback. Of course it will only show with reasonably sharp DVDs. Soft DVDs are beyond help...

So after playing around with things I checked off the "USE HALF FRAME RATE FOR DXVA DEINTERLACING" option in the trade quality for performance area of madvr and things are working perfectly. No frame drops at all, no stutter. The image looks good to my eyes, but are there any trade offs with this setting? My knowledge of this stuff is limited.
That option turned off means that 60i (50i) DVDs are deinterlaced to 60p (50p). That option turned on means you get 30p (25p) after deinterlacing. Basically turning that option on means madVR only has to do half of the work.

For movies turning that option on shouldn't harm too much. However, for movies the better alternative would be to use software decoding and to turn madVR into forced film mode. If you do that, you get proper IVTC, so those 60i movies are turned into perfect 24p movies. Which means: Even less work for madVR and also the 3:2 pulldown judder is removed. Please note that madVR's film mode only works with software decoding, it doesn't work with DXVA decoding (at the moment).

For native video content (e.g. sports, music concerts etc) turning that "half frame rate" option on means that you're throwing away every other frame, which means that playback will lose some smoothness.

since you said enabling "film mode" didn't help, it sounds like it's interlaced.
My best guess is that he tested film mode and software decoding separately. With DXVA decoding film mode can't be used (at the moment). I'm pretty sure that when using software decoding + film mode at the same time (!) his problems would also go away.

I have a question. Not too long ago a friend here gave me some tips about calibration options in madVR but there's still one thing I'm curious about. When I mentioned my display was calibrated with sRGB preset, he mentioned that the primaries to follow would be BT.709. Following that, in what occasion do we need the SMPTE-C or EBU/PAL? How do I know which one is/would be the one for my monitor?
What your display is calibrated to doesn't have much to do with the primaries the source is encoded it. Or rather: If the primaries of the source differs from the primaries of your display, madVR has to convert the primaries, otherwise you wouldn't get correct colors.

HD content usually uses BT.709 primaries. NTSC DVDs usually use SMPTE-C primaries. PAL DVDs usually use EBU/PAL primaries. If your display is calibrated to sRGB (= BT.709) primaries and you watch e.g. an NTSC DVD, madVR automatically converts the video primaries so that they look correct on your display. It is not something you need to worry about. madVR does this automatically.

is it a good idea to use smooth motion on a 1080i29 projector?
It looks as if madvr treats it as a 59.94 display and then the gpu creates 29.97i from that.

I have no idea how the whole interlacing process factors into this.
That's a complicated situation. If you playback movies and your display can do IVTC then it will probably be better to disable smooth motion. If your display can't do IVTC then it might be better to enable smooth motion. In any case, just try it out and trust your eyes...

When converting ntsc rec.709 hd to sd using colormatrix("Rec.709->Rec.601") which x264 primary, transfer, matrix should be used to get the most accurate colors in madvr? Which to use for pal hd sources?

from x264 --fullhelp
--colorprim <string> Specify color primaries ["undef"]
- undef, bt709, bt470m, bt470bg
smpte170m, smpte240m, film
--transfer <string> Specify transfer characteristics ["undef"]
- undef, bt709, bt470m, bt470bg, linear,
log100, log316, smpte170m, smpte240m
--colormatrix <string> Specify color matrix setting ["???"]
- undef, bt709, fcc, bt470bg
smpte170m, smpte240m, GBR, YCgCo
It doesn't matter at all to madVR. Just *please* make sure you tell x264 to store whatever primaries and decoding matrix it uses into the video stream headers. This way madVR will know and treat the video correctly.

Probably for max compatability (for players other than madVR) you should use SMPTE-C primaries and BT.601 matrix for NTSC SD content and EBU/PAL primaries and BT.601 matrix for PAL SD content. Unfortunately that x264 list doesn't mention any of that. Not sure which other values are equivalent to SMPTE-C primaries, EBU/PAL primaries and BT.601 color matrix...

I've issue with madvr - ANY transportstream file I open I get incredible amount of dropped frames which makes video unwatchable (video plays fine if I use fg. EVR-CP). I'm using newest mpc-hc (lite build) + newest lavfilters (with CUVID HW Accel [disabling it/changing to other doesn't change anything]) + newest madvr (set to Highest preset using Niyawa guide).

I've: Intel Core 2 Quad Q6600; MSI GeForce GTX650; 4GB RAM on Win7x64 Ent
Probably deinterlacing is active, which means the content turns into 1080p60 content (after deinterlacing), which means madVR has to do 2.5x as much work as for 24p movies. Probably your GPU simply can't handle the scaling settings you're using for 60p content. If we're talking about movies, try using software decoding and forcing madVR into film mode. That will result in 24p after deinterlacing, which lowers the load on your GPU and also gets rid of 3:2 pulldown judder.

Gents, i have a question:
I have a panasonic plasma that i had calibrated by an ISF professional. In my mind that means that I dont need any calibration/gamma processing done by madVR. I only have to make sure that I the get the input to the display be as close to the source as possible; a 'source direct mode' as to speak.

If i disable levels conversion in LAV filters ('as source') and disable calibration controls/gpu gamma ramps and disable gamma processing in madVR, do I get the desired 'source direct mode' ?
I'd recommend to tell madVR how your display is calibrated. That will allow madVR to convert DVDs to your display primaries. Otherwise you'll get correct colors for HD content, but incorrect colors for DVDs. You don't want a "source direct mode" for SD content because the primaries *do* need to be converted.

If you tell madVR how your display is calibrated, if the calibration matches BT.709 (which it hopefully does), madVR should produce a "source direct" output for HD content, and a color corrected output for SD content (which is necessary for correct colors).

To make sure that your GPU doesn't damage the colors in any way, make sure you turn off all funny video features in the GPU driver control panel. Also avoid DXVA2 decoding, deinterlacing and scaling, if possible.

BTW, please understand that your ISF calibrator can only work with the controls your display has. The calibration controls of most displays are rather bad in comparison to what e.g. ArgyllCMS can do. So even if your ISF calibrator did a very good job, you might still benefit from an additional calibration via ArgyllCMS. JFWIW...

sneaker_ger

5th May 2013, 10:52

Does anyone else have issues with inaccurate seeking with madVR's seek bar in FSE mode when watching DVDs? Often the seek point is missed like about a minute or so, while when using windowed mode or playing anything but DVDs seeking is always accurate to the second. I'm using MPC-HC with LAV and Windows 7's DVD Navigator (I think).

/edit:
Here's a log:
http://www.file-upload.net/download-7554619/madVR--FSE-DVD-inaccurate-seeking.7z.html

I hope you don't get confused by the length - I first went through the menus to an episode, then into FSE mode and then seeked into the middle once. It seeked way too far.

kasper93

5th May 2013, 11:59

>> 5) Measure & Record Y values for 5% grayscale steps in madVR with 3DLUT active and VIDEO LUT
>> Disabled

In my testing, you can't disable the VideoLUT in MadVR, so you would be compounding the calibration
curves, so no, the two configurations wouldn't be expected to match.

A valid check would be to use "collink -a TV.cal" and load a linear VideoLUT using "dispwin -c".

I did test with "dispwin -c" and results was still different. And for me madVR can disable VideoLUT in FSE mode. I just tested this by loading "dispwin strange.cal" and in full screen it was disabled.

> Good work, but are you sure about "Rec709_Gamma22.icm" (I don't have that file)?

It's no longer used, because it turns out that MadVR essentially passes the input space transfer curve through to the 3dLut (ie. when the 3dLut input space matches the media input space, and when no Gamma processing is being done by MadVR) - which is what I want. Even if this is not the case, the transfer curve of the media is essentially preserved by MadVR.

> And I think you should add " -I 2.2" to collink command, because this is what madVR is expecting.

No, this number has nothing to do with MadVR. Follow the advice in Scenarios.html, and use it to adapt to your viewing conditions.

Thanks, for explanation. I must have misunderstand something before.

zoyd

5th May 2013, 12:08

I would really like to see this or another Argyll tool take a step away from the world of ICC color management, and support gamut adaption with customizable & fine-tuned user control of output results, especially for gamma curve. There is value in what collink currently offers, which is essentially ICC color management in a madVR 3DLUT, I just hope for something more tuned to the needs of video calibration some day.

I've used collink to generate cLUTs for the eeColor box that have preserved the transfer function that I've calibrated using the display controls. I'm wondering if the problem you are having is in the madVR implementation and not a general ICC CM issue? When source and target space gamma curves are matched the cLUT becomes transparent to gamma as long as I include a significant number of gray patches in the profile.

Some measurements are here http://www.avsforum.com/t/1464890/eecolor-processor-argyllcms

cyberbeing

5th May 2013, 12:45

I've used collink to generate cLUTs for the eeColor box that have preserved the transfer function that I've calibrated using the display controls. I'm wondering if the problem you are having is in the madVR implementation and not a general ICC CM issue?
My dispcal gamma curve is perfectly maintained when creating a yCMS 3DLUT (primaries+wtpt only) for madVR. This is because yCMS assumes src gamma curve = dst gamma curve by default.

Collink does not do this, nor does it offer an option to do so, which is why I believe I'm seeing these issues. Either that, or colprof somehow ends up generating strange LUT ICC profiles for my display. Either way, the issue is somehow being caused by the Argyll CMS tools and not madVR.

When source and target space gamma curves are matched the cLUT becomes transparent to gamma as long as I include a significant number of gray patches in the profile.
I would agree that if the source and target space gamma curves are matched, that should resolve the problem, but how are you doing this?

The REC709.icm profile which Argyll provides to use as the source contains a gamma curve which probably will not match your monitor.icm destination profile. If you calibrate to a BT.1886, the resulting curve will be unique to your display, and not match any stock profile. If you calibrate to an ambient light scaled BT.709 curve, the resulting curve will be unique to your display because of how Argyll scales to ambient light, and not match any stock profile either. In general case, matching the source stock profile to destination gamma will only be possible if you calibrate to a pure power-curve, which I never do.

This is why I'm requesting Graeme Gill add an option to ignore the gamma curve in the source profile, and treat it as the same as curve as the destination profile. I'm not aware of any tools which can easily create a custom source ICC device profile to match the gamma curve of your monitor profile. I'm also unclear about the effect on gamma from collinks implementation of the -I b switch, and what occurs when you don't use that switch.

madshi

5th May 2013, 12:57

sneaker_ger

5th May 2013, 13:25

Does this occur with all DVDs? Then please create a bug tracker report.

I only tested three discs and all of them seem to be affected, but I have to do more tests to rule that possibility out.

Strangely it does not seem to occur before the 4 minute mark(*) and whether the seek is too late or too early does not seem totally random, i.e. in a specific area it will either always be too late or always be too early. But I will have to do some more tests on that, too.

~ 4:00 - 4:15

zoyd

5th May 2013, 15:50

I would agree that if the source and target space gamma curves are matched, that should resolve the problem, but how are you doing this?

The REC709.icm profile which Argyll provides to use as the source contains a gamma curve which probably will not match your monitor.icm destination profile. If you calibrate to a BT.1886, the resulting curve will be unique to your display, and not match any stock profile. If you calibrate to an ambient light scaled BT.709 curve, the resulting curve will be unique to your display because of how Argyll scales to ambient light, and not match any stock profile either. In general case, matching the source stock profile to destination gamma will only be possible if you calibrate to a pure power-curve, which I never do.

yes, I've calibrated to a pure power curve of 2.2 and used a source profile with the same embedded curve (Rec709_gamma22.icm). This can be done with BT.1886 as well (-I b Rec709.icm), all that is required is that your display calibration software calculate the correct function based on your black and peak white points and you calibrate to that prior to profiling.

I had the same request as you did when Graeme first built the eeColor box compatibility into ArgyllCMS, I wanted to use it for color correction only, independent of grayscale just like typical display control separation. So I took the ArgyllCMS cLUT and modified the neutral axis points so that out=in for those nodes. However, this created some fairly serious banding artifacts at "near-gray" colors for some of the cLUTs I was testing. The degree of banding depended on how much linearization needed to be done on the particular display and sometimes was not noticeable at all. The point is, forcing some of the nodes to be transparent was problematic and not advisable for this type of workflow.

JarrettH

5th May 2013, 17:29

Most (all?) GPUs have built in 1D Luts to perform some sort of gamma correction. By default those Luts are configured to "untouched passthrough" in Windows, I believe. But if you play around with GPU driver settings and stuff, or if you use ICC profiles, you might (accidently or not) fill those Luts with some values. For video playback, if you calibrate without those 1D GPU Luts, you want them disabled. That is the purpose of that madVR option: To disable those 1D GPU Lets. Currently this option only works in FSE mode. (And in Overlay mode it seems the GPU 1D Luts are *always* disabled).

By using ICC profiles, do you mean the one that automatically loads through the Spyder application when Windows starts? I have a calibration profile that loads with Windows, which is 6500K. So you're saying I should use that option if I don't want the values in my profile to be messed up? :thanks:

madshi

5th May 2013, 17:47

I'm wondering if the problem you are having is in the madVR implementation and not a general ICC CM issue?
FWIW, madVR's 3dlut implementation is very very simple. I can't imagine there being anything wrong with it. If there's something wrong, it should be totally wrong, all the time. The madVR 3dlut shaders are doing very little work. The GPU texture units do all the heavy lifting including trilinear interpolation.

yok833

5th May 2013, 19:27

zoyd

5th May 2013, 19:30

FWIW, madVR's 3dlut implementation is very very simple. I can't imagine there being anything wrong with it. If there's something wrong, it should be totally wrong, all the time. The madVR 3dlut shaders are doing very little work. The GPU texture units do all the heavy lifting including trilinear interpolation.

yes, I do now think this is just the fact that the cLUT manages the transfer function (as it must to get the correct source->target color response) and it is up to the user to find a workflow that preserves any internal display calibration if that is desired.

madshi

5th May 2013, 19:55

Hello everyone,
I have configured the catalyst settings with an output 4:2:2, same thing for lav and ffdshow.. However I have to configure Madvr with a pc levels 0-250 to have a correct black level (otherwise the picture is completely washout).. ??? Is it normal???
For madVR I'd recommend to set the catalyst to Full Range RGB output. After doing that you can probably use TV levels in madVR. Or better yet: Switch both your display and madVR to PC levels, too (if you can). This way you will see photos, desktop, games and videos with correct black levels.

Aleksoid1978

6th May 2013, 00:52

Not sure what you mean. Are you saying this is MPC's fault? Or are you saying it is madVR's fault?

When use madVR as video renderer - SetWindowText() have this issue :).

cyberbeing

6th May 2013, 01:09

This can be done with BT.1886 as well (-I b Rec709.icm), all that is required is that your display calibration software calculate the correct function based on your black and peak white points and you calibrate to that prior to profiling.
I'm unconvinced that Dispcal & Collink are in agreement on what a BT.1886 curve is, since my gamma curve always gets changed. So what tool do I need to use to match the exact curve which Collink expects with -I b Rec709.icm?

Most notable is that the collink 3DLUT somewhat crushes neutral shadow tones, and gives really strange overly desaturated results on low luminance colors when using -I b Rec709.icm. If I use -I b -I 2.2 Rec709.icm, both shadow tones and saturation of low luminance colors are mostly normal, but everything in mid-tones and above are then using a completely different much brighter gamma curve than the video source pixels.

The reason I mentioned the issue with madVR gamma correction with the Argyll 3DLUT in my previous post, is because dispcal BT.1886 + -I b Rec709.icm + madVR gamma BT.709 2.0 comes somewhat close to normalizing the gamma curve so the source pixels (linear gamma response) of the video aren't modified. But since madVR gamma correction or the 3DLUT royally screws up the WTW Blue channel when doing this, it's not very practical. The concept here is that BT.1886 is close to a 2.4 power-curve, so setting madVR gamma correction to 2.0 is equal to a -0.2 gamma offset, in other words 2.2 gamma. If Argyll's Rec709.icm profile uses a 2.2 BT.709 gamma curve, it would somewhat make sense why doing this in madVR gamma correction could reverse the damage collink did to the linear response of the video. I'm unsure that is what's actually going on here though, since the match is not exact, so possibly just a fluke. More of a curiosity than anything else, as I wouldn't actually use a 3DLUT this way in practice.

So I took the ArgyllCMS cLUT and modified the neutral axis points so that out=in for those nodes.

Could you explain how (tools/method) you went about modifying the ArgyllCMS cLUT in this way?

However, this created some fairly serious banding artifacts at "near-gray" colors for some of the cLUTs I was testing. The degree of banding depended on how much linearization needed to be done on the particular display and sometimes was not noticeable at all. The point is, forcing some of the nodes to be transparent was problematic and not advisable for this type of workflow.

This doesn't make any sense. If the gamma of the source pixels of the video are left unmodified, how are you getting banding which doesn't exist in the source video you are watching? If the 3DLUT is only doing gamut & white point correction this shouldn't be a problem. I don't get any banding with yCMS 3DLUT which only does color correction like this, yet the quality yCMS gamut correction is limited by that fact that is only accepts primary colors as measurement patches. With Argyll the sky is the limit as afar as measurement patches are concerned, so it would be the far superior solution if I could make it do what I wanted, which is unfortunately a challenge because of how ICC Device Linking normally functions. It's non-trivial to edit the tags and create custom ICC device profiles that don't use a standardized/known gamma curve.

If you are using a 3DLUT to replace the VideoLUT for doing gamma correction, this shouldn't result in banding either if done properly. Collink is already doing complex gamma correction from source profile gamma -> destination profile gamma -> BT.1886 gamma -> BT.1886 override gamma -> -a tv.cal gamma which all seems a bit crazy when gamma should at most only be modified once or twice to reach your target, yet I can't say I've seen any banding as a result.

I'd say if you were seeing banding from doing this, it was a flaw in how the 3DLUT was created (or possibly Display input / eeColor box output processing?), as it should be possible without banding. It all depends on how the 3DLUT was tuned to output 16 bit. From what I remember, yCMS post-processes the 16 bit output with dithering when writing the 3DLUT, and I assume Argyll also performs smoothing of some kind on the 16bit output. nand's TI3 Parser tools did not do any smoothing or dithering post-processing on the 3DLUT values when you merged in a Dispcal .cal file, and could result is heavy banding from what I've seen. At this point I'm naively assuming collink is already handling this properly with the -a switch, and that gamma being modified by other factors of the ICC Device Link is what results in unexpected output currently.

Graeme Gill

6th May 2013, 01:48

That's what I did when I originally checked with collink -a... I'm well aware that madVR's option only applies to Fullscreen Exclusive mode,

I'm unable to find any combination of MadVR settings that doesn't use the Graphics card VideoLUTs.

I've tried:

Window mode - No "disable GPU gamma ramps"
Window mode - With "disable GPU gamma ramps"
Full screen exclusive - No "disable GPU gamma ramps"
Full screen exclusive - With "disable GPU gamma ramps"

and in every case, the Video is being rendered through the calibration curves in the VideoLUTs.
This is quite obvious if you first load the VideoLUTs with "dispwin strange.cal".

[I've no idea if this is system and/or graphics card dependent. I'm running WinXP with a
GeForce 8600 GT. ]

I would imagine that anything using a Video overlay would not be affected by the VideoLUTs,
and I notice there is an option for that for Win7+.

Similarly, I'm reasonably confident that "collink -a disp.cal" is doing what it should, because if I create a .3dlut with "collink -a strange.cal", it looks just like the non "collink -a" .3dut with strange.cal loaded into the VideoLUTs. I also verified this quantitatively - readings taken of a step wedge using "collink + dispwin disp.cal" vs "collink -a disp.cal + dispwin -c" were identical to within measurement tollerance.

Graeme Gill

6th May 2013, 02:23

collink changes the "ideal" gamma curve to something else entirely. It does not agree with the verified correct Y values which dispcal calibrates to.

As I keep explaining, it's not meant to. It's meant to be reproducing the colorspace defined by the source profile + the BT.1886 curves (if invoked using -Ib). Setting the VideoLUT to BT.1886 or any other pure power curve is probably not the best thing to do for a good profile. The reason is that the power curve is extremely shallow near zero, and this makes the device behaviour very hard to control (ie. very subject to noise or inaccuracies). Instead a curve with a steeper slope near zero such as sRGB or L* is probably a better choice for accurate profiling and good results using a device link/.3dlut.

The exact nature of what the source target is, and the way the BT.1886 is specified and used is open to discussion - I'm certainly still thinking about it myself, but I won't complicate this reply by going into those thoughts here.

Considering my testing method was valid, not invalid as you had assumed, are what should be identical Argyll configurations not matching expected behavior for collink?

See my previous reply. I'm not able to reproduce this problem. There must be something about your system or MadVR or .3dlut or VideoLUT setup that is different. The first thing is therefore to pin this down, before going on to look at the video reproduction.

collink appears to perform an ICC Device Link between the gamma curve of the source (Rec709.icm) & destination (monitor.icm) profile. Use of the -I parameter override, can cause things to go even more askew of the intended target. It's a blackbox kind of adaption without any ability to target a specific (verified by measurements) gamma curve unless you hack the relevant values in both src & dst ICC profiles to match, something which is completely impractical for an end-user to do.

I completely disagree. -I is not an override, it forms part of the source model. The source profile and BT.1886 define a very particular "gamma" curve, one that is generally accepted as what one should use for modern video reproduction - see http://www.avsforum.com/t/1409045/how-power-law-gamma-calibration-can-lead-to-crushed-blacks . So this defines the reproduction desired, and then by using the destination profile, we can figure out how to reproduce the desired colors. "Hacking" the destination profile would completely break this, since it would ruin our ability to know what device values to send to the display to reproduce our target colors.

I would really like to see this or another Argyll tool take a step away from the world of ICC color management, and support gamut adaption with customizable & fine-tuned user control of output results, especially for gamma curve.

Which is does. That's what the -I parameter is doing, + intent + CIECAM viewing condition adjustment.

Graeme Gill

6th May 2013, 02:39

At some point (when I find the time) I might want to automate madVR <-> ArgyllCMS calibration as far as possible to make it easily accessible for madVR users with just some mouse clicks.

I'm not sure this is a viable path, although it depends on your expectations. I would imagine that the whole ArgyllCMS tool-chain is too complex to manage this easily. Installing system drivers for instruments for instance, has its complications, and switching to LibUSB-win32 drivers from the manufacturers drivers should only be done with user accent. Better to look towards DispcalGUI if this is the scope.

If you are thinking of a lesser scope, such as being able to use an existing or installed display profile, then the current tool (collink) is built more for quality than speed. You might get away with it with a judicious choice of options, but the scheme I outlined previously of the .3dlut being built by MadVR using an ICC profile library is probably a better long term goal I think.

If you insist, I could put all the code needed to automate the calibration into a separate helper tool and open source that one. (As you probably know, madVR is closed source and I want to keep it that way.)
As long as the ArgyllCMS license is complied with, you can use it as you see fit. If MadVR is not shipped/packaged with ArgyllCMS, and does not depend on it for its normal operation, ie. if ArgyllCMS is downloaded at the user instigation, and is made use of by MadVR as an optional feature, then I think this would be acceptable from a licensing point of view.

cyberbeing

6th May 2013, 02:48

I'm unable to find any combination of MadVR settings that doesn't use the Graphics card VideoLUTs.
...
I'm running WinXP
There must be a madVR bug with this option on WinXP.

If you want this fixed, you should file a bug report on madshi's bug tracker: http://bugs.madshi.net/my_view_page.php

Similarly, I'm reasonably confident that "collink -a disp.cal" is doing what it should, because if I create a .3dlut with "collink -a strange.cal", it looks just like the non "collink -a" .3dut with strange.cal loaded into the VideoLUTs. I also verified this quantitatively - readings taken of a step wedge using "collink + dispwin disp.cal" vs "collink -a disp.cal + dispwin -c" were identical to within measurement tollerance.

What was your calibration target with Dispcal? Could you provide step by step command lines for each Argyll tool which will result the identical measurements you are seeing? I'd like to see if I could reproduce your results, since you must be doing something different than I am. As mentioned previously, I'm using an i1pro on a GDM-F520 CRT computer monitor. Here (http://www.mediafire.com/?njgiz38v8b7r86a) are a couple Argyll ICM profiles from my monitor, which reproduce the issue for me, if they are in any way helpful for you debugging this.

My conclusion thus far is that the gamma curve of the Rec709.icm source profile is throwing things off when it doesn't match the curve in your Monitor.icm profile. It seem as though you are doing a gamma adaption from Rec709.icm to Monitor.icm, and then finally doing an adaption from that result to disp.cal.

When -a disp.cal is not specified, the linear gamma response of the video pixels is still changing when using a collink 3DLUT. It seem as though you are doing a gamma adaption from Rec709.icm to Monitor.icm.

Graeme Gill

6th May 2013, 02:50

I would agree that if the source and target space gamma curves are matched, that should resolve the problem, but how are you doing this?

In theory, you could get what you want by calibrating your display to Rec709 gamma curves, profiling it, and then linking it with one of the Rec709 gamma curve video input profiles. That should give you a .3dlut that doesn't significantly change the transfer curve. You would then switch the calibration back to what you want while using it.

[ I say in theory, because in reality your display can't do zero black, so it can't exactly reproduce Rec709. Depending on how good a black it has, you may want to use a black mapping intent such as "collink -ila" rather than "collink -ir". ]

cyberbeing

6th May 2013, 03:29

collink changes the "ideal" gamma curve to something else entirely. It does not agree with the verified correct Y values which dispcal calibrates to.As I keep explaining, it's not meant to.
I've heard you that the current behavior is intentional. Which I why I continue to request to add support for this alternative behavior which is more suited for the results I want to achieve.

It's meant to be reproducing the colorspace defined by the source profile + the BT.1886 curves (if invoked using -Ib). Setting the VideoLUT to BT.1886 or any other pure power curve is probably not the best thing to do for a good profile. The reason is that the power curve is extremely shallow near zero, and this makes the device behaviour very hard to control (ie. very subject to noise or inaccuracies). Instead a curve with a steeper slope near zero such as sRGB or L* is probably a better choice for accurate profiling and good results using a device link/.3dlut.
Can Argyll create an L* calibration with Dispcal? I did notice that results were better with my 32 lux ambient light scaled BT.709 profile calibrated to with Dispcal, but I was still getting strange/different Y gamma measurements when using the collink 3DLUT. I'm not seeing any way to get my display to measure the custom gamma curve I'm targeting when using a collink 3DLUT. Intentional or not, I would like to see this change.

See my previous reply. I'm not able to reproduce this problem. There must be something about your system or MadVR or .3dlut or VideoLUT setup that is different. The first thing is therefore to pin this down, before going on to look at the video reproduction.
Provided some ICC profile in my previous post if that helps.

"Hacking" the destination profile would completely break this, since it would ruin our ability to know what device values to send to the display to reproduce our target colors.
That is that opposite of what I've been saying. Argyll should have an option "hack" the gamma curve the source profile to match your destination profile and then adapt your destination profile to the desired gamma response.

Source (native monitor gamma / source gamut) -> Destination (native monitor gamma / monitor gamut) -> Final user-defined gamma target (verified by measurements)

Source -> Destination = Linear gamma adaption (Input=Output gamma)
Source -> Destination = Gamut adaption
Destination -> Gamma Target = User defined gamma adaption (w/ src->dst gamut adaption maintained)

Which is does. That's what the -I parameter is doing, + intent + CIECAM viewing condition adjustment.
This is only for BT.1886 though, what about support for other curves which Dispcal can calibrate to with/without ambient light scaling?

I'd also find it useful if you could specify ambient light lux instead of a numerical gamma number when using -I override, in order to scale a curve for viewing conditions in the same fashion as Dispcal.

In theory, you could get what you want by calibrating your display to Rec709 gamma curves, profiling it, and then linking it with one of the Rec709 gamma curve video input profiles. That should give you a .3dlut that doesn't significantly change the transfer curve. You would then switch the calibration back to what you want while using it.

Could you explain this step by step with Argyll command lines for each tool, and point me towards the source ICM profile to use?

I frequently do calibrate to Rec709 with ambient light scaling in Dispcal for video calibration, but it seem like you are suggesting something different. I guess the question would be, how do I create a source ICM profile which agrees with Dispcal's method of ambient light scaling? The REC709 profiles bundled with Dispcal GUI scale the the native Rec709 curves in a more traditional fashion while Dispcal scales to ambient light with CIECAM based on your display measurements.

Graeme Gill

6th May 2013, 04:38

Another problem I've noticed Argyll CMS collink is that the "4-Color Clipping.mp4" chart from the AVS HD 709 (http://www.avsforum.com/t/948496/avs-hd-709-blu-ray-mp4-calibration) test patterns isn't behaving correctly.
Colors are being clipped before 235 even if I use Perceptual for the 3DLUT.

My testing of "3-White Clipping.mp4" indicates that the white clip is close to perfect. The "4-Color Clipping.mp4" is not likely to be the same, unless some specific conditions are met - basically the source has to be within the gamut of the display. Yes, perceptual will try and avoid any clipping that normally results for colorimetric reproduction where the input is out of gamut, but there are a bunch of constraints on perceptual, such as ensuring smoothness and erring on the side of the primaries being fully saturated. You will find that increasing the resolution of the perceptual gamut mapping by using "-qh" or "-qu" will improve the individual channel clipping behaviour, and you should get nearer to perfect. It will be very close to perfect with -ims, but you may not want the gamut expansion. (I will change it to default to -qh 3dlut output in the next version.)

cyberbeing

6th May 2013, 05:01

The "4-Color Clipping.mp4" is not likely to be the same, unless some specific conditions are met - basically the source has to be within the gamut of the display.

"4-Color Clipping.mp4" is Rec709, while my GDM-F520 monitor (white line) has a gamut smaller than Rec709 (true color line) in RED & BLUE (http://imageshack.us/a/img22/9664/gdmf520gamut.png), so I guess that means the color clipping pattern will never be perfect. I still wonder why Blue is affected the heaviest, while Red is not affected at all, considering the gamut of my GDM-F520. I'll try -qh & -qu in collink later.

Edit: Not seeing any visible improvement on "4-Color Clipping.mp4" using -qu -ip or -qu -ir
Edit2: It would seem the -q switch is broken or not affecting ouput when using -ir , since the 3DLUT generated with defaults vs -qu are 100% byte-identical.
Edit3: Using -ir or -ila causes Green to be clipped the heaviest on "4-Color Clipping.mp4", even though that is the only color of my monitor gamut which falls within REC709.

Graeme Gill

6th May 2013, 06:13

I'm unconvinced that Dispcal & Collink are in agreement on what a BT.1886 curve is, since my gamma curve always gets changed.

No, they aren't quite the same in the current version. Assuming you are using "colprof -G2.4 -f0", there will be some subtle differences near black, depending on the dispcal -k factor. By default it is automatic, to best adapt to LCD type displays. Closer to equivalent behaviour to collink is "dispcal -k 1", but that's not an exact match either, since dispcal raises the black until it can fully correct the black point, whereas (currently) collink chooses a compromise (RGB weighted) black level to fully correct to, possibly clipping 1 or 2 channels. I am wondering whether to move the collink BT.1886 closer to "dispcal -k 0" or an automatic factor, but I haven't figured out how the neutral bend to black in the BT.1886 would interact with the gamut black point "extend and bend" code, since they essentially are aimed at solving the same problem.

Most notable is that the collink 3DLUT somewhat crushes neutral shadow tones, and gives really strange overly desaturated results on low luminance colors when using -I b Rec709.icm.
If I use -I b -I 2.2 Rec709.icm, both shadow tones and saturation of low luminance colors are mostly normal, but everything in mid-tones and above are then using a completely different much brighter gamma curve than the video source pixels.

Without seeing what you're seeing, it's hard to comment.

Here's a sanity check: On my display for black, 50% grey and White using
a .3dlut created with "-Ib -I2.2 -ir" I get:

Video in 3dlut out Expected display XYZ
0 0 0 0.010435 0.005188 -0.000180 0.000341 0.000352 0.000302
.5 .5 .5 0.533183 0.536744 0.535794 0.217556 0.229262 0.226722
1 1 1 1.000001 1.000008 1.000019 0.951394 1.000018 0.978644

[I'm using xicclu -et -Et on the device link, and icclu -ff -ia -px on the display profile. I've updated Win32_collink_3dlut.zip to include the xicclu that supports -e and -E]

So the effective display gamma is log(0.229262)/log(0.5) = 2.1249, which is what you expect for a slight input offset. The overall effective viewing gamma is therefore about 2.1249/(Rec709 ~= 2.0) = 1.06. Which is plum in the target range for a not super dark viewing conditions.

The reason I mentioned the issue with madVR gamma correction with the Argyll 3DLUT in my previous post, is because dispcal BT.1886 + -I b Rec709.icm + madVR gamma BT.709 2.0 comes somewhat close to normalizing the gamma curve so the source pixels (linear gamma response) of the video aren't modified.

Sorry, it's hard to follow what your setup is. "dispcal BT.1886" is irrelevant if you are created a .3dlut as per recommendations. I'm certainly not bringing MadVR gamma into it - it's hard enough to follow as it is.

From what I remember, yCMS post-processes the 16 bit output with dithering when writing the 3DLUT, and I assume Argyll also performs smoothing of some kind on the 16bit output.

It doesn't work like that. The 3dlut processes each pixel independently, so it's not possible to apply spatial dithering with it. It's MadVR that is the position to apply spatial dithering. All the Argyll stuff is floating point, but it is limited by the precision of the measurements, smoothing and fitting in the profiles, limited cLUT table resolution, and the 16 bit precision of the standard ICC profiles.

cyberbeing

6th May 2013, 07:12

No, they aren't quite the same in the current version. Assuming you are using "colprof -G2.4 -f0", there will be some subtle differences near black, depending on the dispcal -k factor. By default it is automatic, to best adapt to LCD type displays. Closer to equivalent behaviour to collink is "dispcal -k 1", but that's not an exact match either, since dispcal raises the black until it can fully correct the black point, whereas (currently) collink chooses a compromise (RGB weighted) black level to fully correct to, possibly clipping 1 or 2 channels. I am wondering whether to move the collink BT.1886 closer to "dispcal -k 0" or an automatic factor, but I haven't figured out how the neutral bend to black in the BT.1886 would interact with the gamut black point "extend and bend" code, since they essentially are aimed at solving the same problem.
I assume that's a typo and you mean "dispcal -G2.4 -f0" not "colprof".

It appears that the profile I linked earlier was "-g2.4 -f0 -k1.0" and not "-G2.4 -f0 -k1.0", since using "-G2.4" was crushing shadow tones too much on my CRT. I actually seem to get closer to the values on that BT.1886 Excel sheet calculator using -g2.4 because of the difficulty which the i1pro has reading extremely low luminance levels. (note: I'm the same guy from the mailing list troubleshooting the i1pro crt problem which resulted in you to adding adaptive i1pro integration time for dispcal back in 2009).

Without seeing what you're seeing, it's hard to comment.
Essentially the following:

3DLUT Disabled (http://imageshack.us/a/img201/4515/3dlutdisabled.png)
yCMS 3DLUT (http://imageshack.us/a/img805/5917/3dlutycms.png)
Argyll collink -Ib -I2.4 -ir 3DLUT (http://imageshack.us/a/img837/2276/3dlutargyllibi24png.png)
Argyll collink -Ib -I2.2 -ir 3DLUT (http://imageshack.us/a/img9/5594/3dlutargyllibi22png.png) (edit: fixed link)

Here's a sanity check: On my display for black, 50% grey and White using
a .3dlut created with "-Ib -I2.2 -ir" I get:

Video in 3dlut out Expected display XYZ
0 0 0 0.010435 0.005188 -0.000180 0.000341 0.000352 0.000302
.5 .5 .5 0.533183 0.536744 0.535794 0.217556 0.229262 0.226722
1 1 1 1.000001 1.000008 1.000019 0.951394 1.000018 0.978644

[I'm using xicclu -et -Et on the device link, and icclu -ff -ia -px on the display profile. I've updated Win32_collink_3dlut.zip to include the xicclu that supports -e and -E]

So the effective display gamma is log(0.229262)/log(0.5) = 2.1249, which is what you expect for a slight input offset. The overall effective viewing gamma is therefore about 2.1249/(Rec709 ~= 2.0) = 1.06. Which is plum in the target range for a not super dark viewing conditions.
I'm not familiar with the functionality or purpose of the xicclu or icclu tools, but I'll try to figure out from the documentation what you mean by this.

Graeme Gill

6th May 2013, 07:13

There must be a madVR bug with this option on WinXP.
If you want this fixed, you should file a bug report on madshi's bug tracker: http://bugs.madshi.net/my_view_page.php

Hard to file a bug, when I don't precisely know what the switch is meant to do.

What was your calibration target with Dispcal? Could you provide step by step command lines for each Argyll tool which will result the identical measurements you are seeing? I'd like to see if I could reproduce your results, since you must be doing something different than I am.

The step by step is as per Scenarios.html#TV1.

The .3dlut without the calibration curve is built with

collink -v -I b -I 2.2 -G -i r Rec709.icm TV.icm HD.icm

tested with the display profile in place: "dispwin TV.cal".

The .3dlut with calibration curve was built with

collink -v -I b -I 2.2 -G -i r -a TV.cal Rec709.icm TV.icm HD.icm

and tested with "dispwin -c"

For this sort of testing it shouldn't matter exactly what device profile and calibration you use, ie. you could use srgb.icm for TV.icm, and strange.cal for the calibration file, and it should still prove the equivalence.

My conclusion thus far is that the gamma curve of the Rec709.icm source profile is throwing things off when it doesn't match the curve in your Monitor.icm profile.

It can't possibly be, since the monitor response is irrelevant to the overall response. The monitor profile is used to lookup the device RGB values to send to it, to produce the desired colors. The desired colors are determined by the video data values + input profile + (optional) BT.1886 curve.

It seem as though you are doing a gamma adaption from Rec709.icm to Monitor.icm, and then finally doing an adaption from that result to disp.cal.

That's not how it works at all (or rather, it's a confusing way to think about it). Monitor.icm encapsulates the display response to RGB values being fed into it, including the effects of disp.cal. The colors to be displayed are determined by the video data values + input profile + (optional) BT.1886 curve. Then the monitor RGB values are then determined by lookup them up in the Monitor.icm. The disp.cal is part of the display path, just like the display controls and the display itself, and characterised by Monitor.icm.

Video RGB in Rec709 -> BT.1886 curve -> Input profile -> PCS - (optional gamut mapping) -> target PCS -> display profile -> calibrated display RGB -> disp.cal -> raw display RGB -> display -> expected PCS.

Monitor.icm is the inverse of how the display behaves, so that when concatenated with the actual display, it cancels out.

[The BT.1886 is plonked in front of the input profile because we know the input profile is a matrix. For a general input profile, we would have to do it in PCS space.]

It seem as though you are doing a gamma adaption from Rec709.icm to Monitor.icm.

This is the very intention of the 3dlut.

Graeme Gill

6th May 2013, 07:24

I've heard you that the current behavior is intentional. Which I why I continue to request to add support for this alternative behavior which is more suited for the results I want to achieve.

Then I can't help you, because that's not the best way of doing this kind of thing, and I'm not going to waste time pursuing it. But I fail to understand why you want to do that. If you were using the tool the way it was intended and not getting a good result, then I'm interested in figuring out why.

Can Argyll create an L* calibration with Dispcal?

Yes, but it's not very relevant to the task at hand.

Provided some ICC profile in my previous post if that helps.

Not in themselves, no. The device link might help, but not without the details about how it was created, and only if the intention is the workflow outlined in Scenarios.html#TV1.

That is that opposite of what I've been saying. Argyll should have an option "hack" the gamma curve the source profile to match your destination profile and then adapt your destination profile to the desired gamma response.

That doesn't make any sense. The source profile is what determines how the Video is interpreted, and that's the part that should be independent of the actual display. The whole point is to reproduce the video in a way that doesn't depend on the behaviour of the display.

I'd also find it useful if you could specify ambient light lux instead of a numerical gamma number when using -I override, in order to scale a curve for viewing conditions in the same fashion as Dispcal.

I'm hoping that won't be necessary, as you have the full CICAM02 available to you. See the "or using both to model a reference video display system that is adapted to your viewing conditions" suggestion.

cyberbeing

6th May 2013, 07:29

Essentially the following:

3DLUT Disabled (http://imageshack.us/a/img201/4515/3dlutdisabled.png)
yCMS 3DLUT (http://imageshack.us/a/img805/5917/3dlutycms.png)
Argyll collink -Ib -I2.4 -ir 3DLUT (http://imageshack.us/a/img837/2276/3dlutargyllibi24png.png)
Argyll collink -Ib -I2.2 -ir 3DLUT (http://imageshack.us/a/img9/5594/3dlutargyllibi22png.png) (edit: fixed link)
A few more with Grayscale steps:

3DLUT Disabled (Steps) (http://imageshack.us/a/img35/1919/3dlutdisabledsteps.png)
yCMS 3DLUT (Steps) (http://imageshack.us/a/img12/2953/3dlutycmssteps.png)
Argyll collink -Ib -I2.4 -ir 3DLUT (Steps) (http://imageshack.us/a/img521/1305/3dlutargyllibi24steps.png)
Argyll collink -Ib -I2.2 -ir 3DLUT (Steps) (http://imageshack.us/a/img90/4863/3dlutargyllibi22steps.png)

(currently reading your prior two posts)

madshi

6th May 2013, 07:32

I'm unable to find any combination of MadVR settings that doesn't use the Graphics card VideoLUTs.

I've tried:

Window mode - No "disable GPU gamma ramps"
Window mode - With "disable GPU gamma ramps"
Full screen exclusive - No "disable GPU gamma ramps"
Full screen exclusive - With "disable GPU gamma ramps"

and in every case, the Video is being rendered through the calibration curves in the VideoLUTs.
This is quite obvious if you first load the VideoLUTs with "dispwin strange.cal".

[I've no idea if this is system and/or graphics card dependent. I'm running WinXP with a
GeForce 8600 GT. ]

I would imagine that anything using a Video overlay would not be affected by the VideoLUTs,
and I notice there is an option for that for Win7+.
Weird, I'm telling Direct3D to disable the VideoLUT and from all the feedback I got so far this reportedly works in fullscreen exclusive mode but fails in windowed mode. Maybe it fails to work in XP with your specific GPU drivers, I'm not sure. There is one other API I can use to disable the VideoLUT. I will try that, maybe it works better...

I'm not sure this is a viable path, although it depends on your expectations. I would imagine that the whole ArgyllCMS tool-chain is too complex to manage this easily. Installing system drivers for instruments for instance, has its complications, and switching to LibUSB-win32 drivers from the manufacturers drivers should only be done with user accent. Better to look towards DispcalGUI if this is the scope.

If you are thinking of a lesser scope, such as being able to use an existing or installed display profile, then the current tool (collink) is built more for quality than speed. You might get away with it with a judicious choice of options, but the scheme I outlined previously of the .3dlut being built by MadVR using an ICC profile library is probably a better long term goal I think.

As long as the ArgyllCMS license is complied with, you can use it as you see fit. If MadVR is not shipped/packaged with ArgyllCMS, and does not depend on it for its normal operation, ie. if ArgyllCMS is downloaded at the user instigation, and is made use of by MadVR as an optional feature, then I think this would be acceptable from a licensing point of view.
Got it - thanks!

I've heard you that the current behavior is intentional. Which I why I continue to request to add support for this alternative behavior which is more suited for the results I want to achieve.

That is that opposite of what I've been saying. Argyll should have an option "hack" the gamma curve the source profile to match your destination profile and then adapt your destination profile to the desired gamma response.
I don't think your feature wish is possible to realize with the general concept used by ArgyllCMS (or any comparable solution like e.g. Calman's 3D cube calibration). As far as I understand, ArgyllCMS works like this:

(1) First of all it measures your display's exact behaviour. The measurements are done in 3D (not in 2D at 75IRE or 100IRE like yCMS). And the 3D measurement grid doesn't even have to be regular.
(2) In the second step ArgyllCMS calculates the desired display behaviour. Basically is calculates how your display *should* measure at every 3D measurement point.
(3) Finally, ArgyllCMS calculates a LUT that for every LUT point transforms the actual display behaviour to the desired behaviour.

The problem with your feature wish is that your gamma response is not strictly a 2D curve, and it is not separate from your overall display behaviour. Measuring primaries and gamma response separately makes things easier to understand for us humans. But ArgyllCMS's algorithms don't separate between them, I believe. ArgyllCMS just for every 3dlut data point implements a transformation which makes sure that the display measures as calculated in step (2).

In order to implement your feature wish you would either have to "hack" the measurements done in step (1), or you would have to "hack" the desired display response calculated in step (2). Both is theoretically possible. But please understand that doing such hacks would have to be done in 3D, and the hacks would affect both gamma and colors. Doing this in a way that produces the results you wish for would be really really complicated.

I don't think ArgyllCMS could do such hacks automatically, because what you ask for is to keep gamma the same but change colors, while the way ArgyllCMS works it doesn't even separate gamma and gamut (except in step (2) where gamma and primaries are specified to calculate the "wanted display response"). ArgyllCMS just tries to make the display measure a specific XYZ value at every LUT point.

I think the only practical way to implement your feature wish with the way ArgyllCMS works would be to create a very complex target model for step (2) which would somehow maintain your display's original transfer response while correcting the primaries. But such a model would have to be 3D for ArgyllCMS to make sense. Basically what you could do is take the "wanted display response" (step (2)) and then tweak it by moving around the calculated wanted XYZ values of each 3D measurement point. You could do that with trial and error, to try achieve the desired affect. But trial and error means you'd have to test every modification to see if it produces the desired results. This process would be very painful, IMHO, because it would have to be done in 3D and you'd have to move around the surrounding measurement points in 3D somewhat, too, and it would screw up ArgyllCMS' calculations, so in the end while you might be able to maintain your transfer response more or less (with a *lot* of manual work), you would likely hurt the primary calibration quality.

BTW, the CMS I considered adding to madVR would have worked *exactly* the same way ArgyllCMS works. And that btw was also the plan for yCMS v2. Meaning your wishes wouldn't have worked with my own CMS or with yCMS v2, either.

I didn't know that ArgyllCMS already did exactly what I was planning for. So now I think I will probably not do my own CMS. Why reinvent the wheel? Instead I'll probably invest some time to make it easier for users to work with ArgyllCMS (or Calman or [...]) in combination with madVR.

Edit: After thinking about it: Maybe you could simply tell ArgyllCMS to use a different gamma curve to calculate the "desired display behaviour" in step (2)? If you choose a gamma curve that is near to your display's native behaviour, shouldn't that produce the desired effect?

It doesn't work like that. The 3dlut processes each pixel independently, so it's not possible to apply spatial dithering with it. It's MadVR that is the position to apply spatial dithering.
Absolutely correct. yCMS doesn't dither, either - it's not technically possible. The only way for 3dlut creation software to produce good quality is to use a high internal bitdepth and to output 3dluts with the highest possible bitdepth and resolution.

-------

@Graeme, are ICC 3dluts hard limited to max 65x65x65 resolution? Would it be worth considering an option to create bigger ICC 3dluts? Maybe not for using them as actual ICC profiles, but it would allow producing a more exact 3dlut for madVR.

My thinking is that it might help adding a lot of grayscale measurements to prettify the measured gamma response. E.g. if you go hardcore and measure every 219 possible 8bit grayscale values, producing a 219x219x219 3dlut with a fully scanned gamma curve (and then converting it to a 256x256x256 madVR 3dlut) might noticably improve gamma measurements.

Ok, I'm not sure if this would just prettify those measurement charts, or if it would also help with real life video playback. Just a thought...

madshi

6th May 2013, 07:38

When use madVR as video renderer - SetWindowText() have this issue :).
Ok, but is this a bug in madVR or a bug in MPC-BE? Do I have to change anything in madVR to fix it?

FWIW, this problem does *not* occur with the latest MPC-HC build. So does this mean it's a bug in MPC-BE?

Aleksoid1978

6th May 2013, 07:44

Ok, but is this a bug in madVR or a bug in MPC-BE? Do I have to change anything in madVR to fix it?

FWIW, this problem does *not* occur with the latest MPC-HC build. So does this mean it's a bug in MPC-BE?

There is no special code - just call CWnd::SetWindowText().
I do not understand. :)

madshi

6th May 2013, 07:47

Weird. Why does the problem not occur with MPC-HC? I don't understand, either!!

sneaker_ger

6th May 2013, 08:14

Does this occur with all DVDs? Then please create a bug tracker report.

I've created a report. Just delete the ticket without the attachment. It didn't take the .7z extension and then I must have misclicked (or it's a bug in the tracker?). It also made "~4 minute mark" into "0000001:0000004 minute mark".

cyberbeing

6th May 2013, 08:31

For this sort of testing it shouldn't matter exactly what device profile and calibration you use, ie. you could use srgb.icm for TV.icm, and strange.cal for the calibration file, and it should still prove the equivalence.
You would need to explain what you mean by equivalence. Different calibration targets do not give equivalent final gamma response on the display with collink generated 3DLUT files.

It can't possibly be
...
That's not how it works at all (or rather, it's a confusing way to think about it)
...
Video RGB in Rec709 -> BT.1886 curve -> Input profile -> PCS - (optional gamut mapping) -> target PCS -> display profile -> calibrated display RGB -> disp.cal -> raw display RGB -> display -> expected PCS.

Monitor.icm is the inverse of how the display behaves, so that when concatenated with the actual display, it cancels out.

[The BT.1886 is plonked in front of the input profile because we know the input profile is a matrix. For a general input profile, we would have to do it in PCS space.]
I'm having a bit of trouble wrapping my head around this, and how I'm supposed to have control over the final gamma response measured on my display after a video passes through an Argyll 3DLUT.

Which knob do I need to turn to change the gamma output of an Argyll 3DLUT if I (for example) do not want to use BT.1886 or REC709, and no ICM device profiles exist from my intended target?

It seem as though you are doing a gamma adaption from Rec709.icm to Monitor.icm
This is the very intention of the 3dlut.

My problem with this in general, is you are assuming that a given video does not have a linear response on a particular display, and has a known gamma curve which need to be adapted to something else. I'm of the opinion that the video gamma should not be touched at all input=output. Only the absolute gamma response of the of the display at the end of the chain matters.

If dispcal were capable of re-calibrating VideoLUT gamma based on 3DLUT grayscale output, that could be nice, but it still means that the 3DLUT is messing with gamma of video pixels in an undesired way.

I don't think your feature wish is possible to realize with the general concept used by ArgyllCMS (or any comparable solution like e.g. Calman's 3D cube calibration). As far as I understand, ArgyllCMS works like this:
...
(1) First of all it measures your display's exact behaviour. The measurements are done in 3D (not in 2D at 75IRE or 100IRE like yCMS). And the 3D measurement grid doesn't even have to be regular.
(2) In the second step ArgyllCMS calculates the desired display behaviour. Basically is calculates how your display *should* measure at every 3D measurement point.
(3) Finally, ArgyllCMS calculates a LUT that for every LUT point transforms the actual display behaviour to the desired behaviour.
...
The problem with your feature wish is that your gamma response is not strictly a 2D curve
...
Doing this in a way that produces the results you wish for would be really really complicated.
...
I don't think ArgyllCMS could do such hacks automatically
...
I think the only practical way to implement your feature wish with the way ArgyllCMS works would be to create a very complex target model for step (2)

So is the ultimate conclusion that I should just give up on having control over the final gamma response of my display when viewing a video? If so, I don't like that...

You, me, and yesgray had these very same discussions during yCMS v1 development, and came to the ultimate conclusion that no gamma correction should be the default behavior. As well as that the video should not be assumed to have any gamma curve and treated linearly in yCMS unless grayscale measurements were specified. It would be sad if you had done away with the capability to do gamut correction without gamma correction in a future madVR version.

Absolutely correct. yCMS doesn't dither, either - it's not technically possible. The only way for 3dlut creation software to produce good quality is to use a high internal bitdepth and to output 3dluts with the highest possible bitdepth and resolution.
I know yesgrey had mentioned dithering before in relationship the processing he did for the creation of 3DLUT files, was he talking about madVR then? Are you positive that his high internal bitdepth pre-processing didn't include dithering? The post is somewhere here on Doom9. His latest version of yCMS even added a Denoise_Black_Level option, which was just one of the latest of the special tweaks he did internally in yCMS when calculating gamma and gamut correction for 3DLUT files. I seem to remember him mentioning special handling for reducing 3DLUT color banding as well. He also used to say that yCMS did neither Perceptual or Relative Colorimetric gamut adaption, but some kind of custom hybrid approach. What this means, who knows? Did you ever see his source code to know what he was talking about half the time?

Edit: After thinking about it: Maybe you could simply tell ArgyllCMS to use a different gamma curve to calculate the "desired display behaviour" in step (2)? If you choose a gamma curve that is near to your display's native behaviour, shouldn't that produce the desired effect?

@Graeme is this possible? It seems similar to what I've already been requesting by using Dispcal measurements to override things.

madshi

6th May 2013, 08:47

So is the ultimate conclusion that I should just give up on having control over the final gamma response of my display when viewing a video?
No, ArgyllCMS does allow you to specify which gamma curve you want to target. However, at the moment at least dispcalGUI seems to be limited to a specific set of gamma curves and values. If none of these curve/value combinations comes close to what you want to have, you've got a problem. Maybe it would be worth a thought for ArgyllCMS to allow specifying a totally custom gamma target curve. You could then model it to match an estimation of your current gamma response. But I'm just thinking out loud here, only Graeme can say if that is making any sense or not.

cyberbeing

6th May 2013, 09:02

No, ArgyllCMS does allow you to specify which gamma curve you want to target. However, at the moment at least dispcalGUI seems to be limited to a specific set of gamma curves and values. If none of these curve/value combinations comes close to what you want to have, you've got a problem. Maybe it would be worth a thought for ArgyllCMS to allow specifying a totally custom gamma target curve. You could then model it to match an estimation of your current gamma response. But I'm just thinking out loud here, only Graeme can say if that is making any sense or not.

I'm happy with the curves which dispcal allows, I'm unhappy that I so far have failed to get the dispcal curves I normally calibrate to, to display properly after passing through an Argyll collink 3DLUT. All I want to be able to do is calibrate to a curve with dispcal, create a 3DLUT, and still have the same final display gamma response with the 3DLUT vs dispcal only. What should be simple, obviously is not. Graeme Gill has said dispcal curves not matching the 3DLUT curve when measured on your display is intended behavior in a previous post, so as far as I can tell I am out of luck.

madshi

6th May 2013, 09:12

I'm not sure I understand. What exactly do you mean with "3DLUT vs dispcal only"? Do you mean "3DLUT = VideoLUT + madVR 3dlut" and "dispcal only = VideoLUT"? If so: What happens if you disable the VideoLUT when using the madVR 3dlut, do you get correct results then?

Graeme Gill

6th May 2013, 09:15

"4-Color Clipping.mp4" is Rec709, while my GDM-F520 monitor (white line) has a gamut smaller than Rec709 (true color line) in RED & BLUE (http://imageshack.us/a/img22/9664/gdmf520gamut.png), so I guess that means the color clipping pattern will never be perfect. I still wonder why Blue is affected the heaviest, while Red is not affected at all, considering the gamut of my GDM-F520. I'll try -qh & -qu in collink later.

Edit: Not seeing any visible improvement on "4-Color Clipping.mp4" using -qu -ip or -qu -ir
Edit2: It would seem the -q switch is broken or not affecting ouput when using -ir , since the 3DLUT generated with defaults vs -qu are 100% byte-identical.
Edit3: Using -ir or -ila causes Green to be clipped the heaviest on "4-Color Clipping.mp4", even though that is the only color of my monitor gamut which falls within REC709.

It's pretty obvious in the verbose output. -qm is "Gamut map resolution: 25". -qu is "Gamut map resolution: 41". I get two .icm's and .3dluts that differ within a few hundred bytes of the cLUT data.

Red, Green and Blue are all outside your displays gamut:

icclu -ff -ir -pl Rec709.icm

/src/argyll/link:icclu -ff -ir -pl Rec709.icm
1.000000 0.000000 0.000000 [RGB] -> MatrixFwd -> 54.285218 80.831212 69.906123 [Lab]
0.000000 1.000000 0.000000 [RGB] -> MatrixFwd -> 87.820812 -79.285064 80.992273 [Lab]
0.000000 0.000000 1.000000 [RGB] -> MatrixFwd -> 29.569144 68.284819 -112.028372 [Lab]

/src/argyll/test/cyberbeing:xicclu -a -fif -ir -pl GDM-F520_2013-04-15_BT.1886_MQ.icm

54.285218 80.831212 69.906123 [Lab] -> Lut -> 0.952400 0.000000 0.000000 [RGB] (clip)
[Actual 55.227343 75.324788 72.225882, deltaE 6.048933]

87.820812 -79.285064 80.992273 [Lab] -> Lut -> 0.399021 1.000000 0.000000 [RGB] (clip)
[Actual 86.520454 -69.126831 81.851552, deltaE 10.277110]

29.569144 68.284819 -112.028372 [Lab] -> Lut -> 0.000000 0.000000 0.998954 [RGB] (clip)
[Actual 34.504783 47.212857 -103.267859, deltaE 23.348120]

Graeme Gill

6th May 2013, 09:27

I assume that's a typo and you mean "dispcal -G2.4 -f0" not "colprof".

Yes.

It appears that the profile I linked earlier was "-g2.4 -f0 -k1.0" and not "-G2.4 -f0 -k1.0", since using "-G2.4" was crushing shadow tones too much on my CRT.

Right. -G2.4 is for standard BT.1886, but one potential problem with BT.1886 is that the effective gamma (ie. what it does to the mid tones) is highly sensitive to the black point. But I would expect moving to -g2.4 to make this even darker !

I actually seem to get closer to the values on that BT.1886 Excel sheet calculator using -g2.4 because of the difficulty which the i1pro has reading extremely low luminance levels.

It's certainly a trick to get the i1pro stable with very low black levels. i1d3 is pretty good, and the i1pro2 is much improved over the i1pro.

I'm not familiar with the functionality or purpose of the xicclu or icclu tools, but I'll try to figure out from the documentation what you mean by this.
They are tools for looking up colors in icc profiles and links. xicc is a superset of icclu. The res 65 device link is what's interpolated up to build the res. 256 .3dlut.

cyberbeing

6th May 2013, 09:36

Red, Green and Blue are all outside your displays gamut
I had forgotten about the 3D gamut projection. Bright green tones are indeed missing compared to Rec709 (white wireframe).
GDM-F520 3D Gamut (http://imageshack.us/a/img444/1327/gdmf5203dgamut.png)

Right. -G2.4 is for standard BT.1886, but one potential problem with BT.1886 is that the effective gamma (ie. what it does to the mid tones) is highly sensitive to the black point. But I would expect moving to -g2.4 to make this even darker !
Well as mentioned before, even with adaptive integration, my i1pro has trouble taking a reliable black point measurement. Using -g2.4 I ended up with an average gamma curve of ~2.35, but closer to 2.2 near black. Using -G2.4 I ended up with nearly exactly as 2.4 gamma power-curve which I didn't want.

My preference is usually to have a gamma curve which goes from somewhere in the range of 1.9-2.2 near-black, ~2.4 in midtones, and ~2.6 in highlights. When I scale a REC709 curve to 32 lux ambient light, that is basically the end-result on my GDM-F520. Recently I've been testing out BT.1886, but still think I prefer the characteristics of the dispcal scaled REC709 curve instead. What all this ultimately comes down to is that I'm just very picky about the final gamma response of my display, and I don't like loosing control and flexibility for the end result.

It's certainly a trick to get the i1pro stable with very low black levels. i1d3 is pretty good, and the i1pro2 is much improved over the i1pro.
I may need to consider getting an i1d3 at some point for cost reasons, as I don't think I'll get lucky and find an i1pro2 for <$600 like I did when I bought my i1pro basic from Amazon when they were closing out the old bundle package.