madVR - high quality video renderer (GPU assisted)

[Plutotype]

It's an European VT50, specifically TX-P50VT50Y and yes it looks a bit like that, not as bad though. Maybe I spend too much looking for possible errors than enjoying the content. :rolleyes:

The image I have attached is a shot of a VT30, which had these bad..VT50 improved a lot.

[Niyawa]

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?

[e-t172]

If you mainly watch HD content and don't care about SD, you don't need to concern yourself with SMPTE-C or EBU/PAL primaries. They are obsolete, basically.

[mindbomb]

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.

[Niyawa]

If you mainly watch HD content and don't care about SD, you don't need to concern yourself with SMPTE-C or EBU/PAL primaries. They are obsolete, basically.
I see, thanks.

[turbojet]

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

[Graeme Gill]

After a lot of testing, tweaking and fixing bugs, I think I'm done for the moment, and the visual results seem quite promising.
To try it for yourself you need ArgyllCMS V1.5.2 from here http://www.argyllcms.com/downloadwin.html
and then this set of extra & replacement files from here http://www.argyllcms.com/Win32_collink_3dlut.zip installed over the top of it, plus a color instrument and some patience.
The main guide is at the bottom of doc/Scenarios.html, & updated documentation for collink in doc/collink.html. Video colorspace profiles are in ref.

[madshi]

@Graeme, thanks a lot! :) Two questions, if you don't mind:

(1) Are you ok now with the current way madVR supports only one external 3dlut for all source media types? Or do you think results would be better using one separate 3dlut per source media type?
(2) Does ArgyllCMS take color measurements in one IRE (e.g. 75 or 100) and base its calibration on that? Or do you measure and correct a raster like 5x5x5, similar to how professional image editor 3dlut correction works?

@madVR users, feedback (and comparison to yCMS) very welcome!

[Graeme Gill]

Having 3dluts be a 2^x size makes things easier for Direct3D and my shader code. Also it allows me to feed BTB and WTW into the 3dlut, which may or may not be useful, depending on the software which creates the 3dlut.

The disadvantage of feeding Video encoded RGB values through the 3DLut is that it is highly desirable that black lands on a grid point, and 64 isn't as good as 65. You could pull the same trick as the eeColor and fake a 65 res. grid out of a 64 by hard coding the last rows at full scale out, since they are reserved for sync. anyway.

If you were to feed full range RGB into & out of the 3dLUT, then the grid resolution is not so critical for RGB. You do need to consider where neutral lands if you were doing YCbCr in though (ie. Cb and Cr = 0 need to land on a grid point).

How about the following workaround: Instead of allowing users to specify only one external 3dlut I could allow them to specify one external 3dlut per each input media type. Wouldn't that do the trick for now, without me having to totally change the way madVR calibration works right now?

I think in practice it works quite well at the moment - the different video colorspaces are not huge, so a single .3dlut will suffice. But a no compromise purist would want the option of having 3 different 3DLuts for the 3 different Video input spaces. So it's worth thinking about providing that, if it is not too hard.

I have zero knowledge about how ICC works. Currently madVR is pretty "stupid" in that it simply feeds data into the 3dlut and that's it. Ok, I'm doing some gamut and gamma processing, but that's just relatively simple math. I think good quality calibration is probably much more complicated. So basically I don't know how to convert an ICC device link into a proper 3dlut.

It's not that complicated to use ICC device profiles or links. A library like LittleCMS or ArgyllCMS/icclib makes it fairly straightforward - it takes care of all the details of loading the profile and then making the transformations it contains available. For instance, it takes about a page or so of C code to open an ICC device link and create a 3DLut. Using a single ICC device profile is a very similar piece of code. Of course it can take some effort understand the terminology and required technical detail.

I also don't know the extent of what ICC supports. I've been told that photo editors measure their displays at e.g. a 5x5x5 raster and then calculate a full 3dlut based on those measurements to make the display response perfect at all IRE levels. AFAIK this is also what the latest Lumagen Radiance 5x5x5 calibration does.

I'm afraid that's rather crude by my standards :-) A regular grid of test values is about the least efficient way of doing it - it's only advantage is simplicity.

"Conventional" calibration usually only corrects everything at one IRE, and then you have to hope that your display behaves linearly, so that the other IREs may look more or less right, too. Does ICC support such 5x5x5 measurements and the corresponding complex corrections to make a display virtually perfect?

ICC has nothing to say on the matter - it's a file format for storing color models, a super-set of something like a 3DLut. There are two basic models - 1D curves/Luts + a matrix, and cLUT. You can make the cLUT any res. you want up to 256^input channels, but the way those grid points are set is up to the profile builder. ArgyllCMS uses a scattered data point interpolation/extrapolation algorithm (regular splines), so the measurement data can be anything. By default it's a set of points that aims to optimally sample the colorspace. On top of the cLUT are per channel input and output curves. They play an important role in characterising some devices, but are probably not so important for Video, since RGB video colorspaces and displays are reasonable perceptually uniform due to the gamma encoding. I don't know how comprehensible it is, but I wrote an introduction here http://www.argyllcms.com/doc/ColorManagement.html that may be of interest.

From my naive point of view, for ideal results I'd imagine to measure maybe 5x5x5 and in addition to that the gray scale in maybe 32 or 64 steps. Throwing all those measurements together and turning it into a monstruous 3dlut should allow to get a perfect color and gamma response, I'd imagine. Does ICC support that concept?

Yes. That's what ArgyllCMS lets you do.

Just double checked my code. You're right. The OSD doesn't show the source transfer function, nor do I even care what it is. The reason for that is that BT.601 and BT.709 use the same transfer function and for PAL (AFAIK) it is usually recommend to use the same once again.

Yes, I agree. BT1886 does use a power of 2.4 though. There is some slight disagreement amongst various authorities as to whether "typical" CRT's have a gamma of 2.2 or 2.4. I suspect it actually comes down to the viewing conditions, 2.4 for quite dark conditions, and 2.2 for not so dark conditions.

madVR is using a pure power 2.2 conversion to get to linear light, then it performs gamut, contrast, saturation and hue changes (if necessary), then it converts back to gamma corrected light by using a pure power 2.2 conversion again. So the transfer function stays untouched by madVR. Unless you activate gamma processing in the madVR settings. Then madVR might actually modify the transfer function, depending on the settings...

OK - I can work with that. The fact that the transfer curve isn't touched when no contrast/sat/hue changes are present makes it transparent enough.

[Graeme Gill]

You can think of it as current versions of madVR treating the input transfer function of all videos is a 2.2 power curve for the purpose of converting to and from linear light.

Yes, that seems to be the conclusion.

Alternative 1: madshi's current implementation of optional shader-based gamma correction implementation expects that you have the 3DLUT change Display's response curve to output an actual 2.2 power-curve. This allow expected results, if for example, you enable gamma processing in madVR, and change the gamma to a 2.4 power-curve, the display response should actually end up as a 2.4 power-curve when measured. 3DLUT Gamma in -> 3DLUT 2.2 Power Curve out (gamut changed, gamma changed).

OK, I think I understand. It does provide a level of transparency at the moment, but I guess I'm still worried that it's heading in a direction that doesn't guarantee that a video in to display out Device Link/3dLut will continue to be viable.

Alternative 2: You can ignore madshi's intentions, and use a 3DLUT to change the display's gamma from the video's input transfer function to anything you want. Gamma in -> Custom Gamma out (gamut changed, gamma changed).

Yes, that's what I'm doing. It's not so much "Custom Gamma out" as "display color space out".

nand-chan made ti3 parser (http://forum.doom9.org/showthread.php?t=162285) which allows merging a ICC profile gamma ramp into a 3DLUT, but the results were always somewhat poor, occasionally resulting in low-light banding and clipping. If this a flaw how ti3 parser modifies 3DLUT files, or a limitation of doing gamma correction in a 3DLUT, I don't know.

I'm afraid I've always been puzzled as to why he uses the .ti3 file, when a matrix ICC profile made from that .ti3 file would be so much more solid and easier to deal with. The low-light behaviour of my .3dluts seems pretty reasonable as far as I can tell. If I do a screen scrape and exaggerate the steps I can see each step from black up in MadVR dithered pixels.

[madshi]

But a no compromise purist would want the option of having 3 different 3DLuts for the 3 different Video input spaces. So it's worth thinking about providing that, if it is not too hard.
It wouldn't be hard at all. I'll put it on my to do list.

Anything else coming to your mind which I could do to improve madVR <-> ArgyllCMS? Should I use a different way to do contrast, saturation and hue changes (e.g. a different way to convert to/from linear light, instead of a pure power 2.2 curve)? Or would it help if I allowed ArgyllCMS to remote control madVR to show color test patterns for measurement? The code for that (including network access etc) has been mostly ready for years now, but has never been put to use yet...

The disadvantage of feeding Video encoded RGB values through the 3DLut is that it is highly desirable that black lands on a grid point, and 64 isn't as good as 65. You could pull the same trick as the eeColor and fake a 65 res. grid out of a 64 by hard coding the last rows at full scale out, since they are reserved for sync. anyway.

If you were to feed full range RGB into & out of the 3dLUT, then the grid resolution is not so critical for RGB.
Gotta admint, it never crossed my mind that black not landing on a grid point could be a problem. That's probably because I was always thinking of 256x256x256 3dluts and didn't spend too much time thinking about smaller sized 3dluts.

It's not that complicated to use ICC device profiles or links. A library like LittleCMS or ArgyllCMS/icclib makes it fairly straightforward - it takes care of all the details of loading the profile and then making the transformations it contains available. For instance, it takes about a page or so of C code to open an ICC device link and create a 3DLut. Using a single ICC device profile is a very similar piece of code. Of course it can take some effort understand the terminology and required technical detail.
Maybe I'll look into this in the future. For now I'm happy that the latest ArgyllCMS now can create good 3dluts for madVR! :)

I'm afraid that's rather crude by my standards :-) A regular grid of test values is about the least efficient way of doing it - it's only advantage is simplicity.

ICC has nothing to say on the matter - it's a file format for storing color models, a super-set of something like a 3DLut. There are two basic models - 1D curves/Luts + a matrix, and cLUT. You can make the cLUT any res. you want up to 256^input channels, but the way those grid points are set is up to the profile builder. ArgyllCMS uses a scattered data point interpolation/extrapolation algorithm (regular splines), so the measurement data can be anything. By default it's a set of points that aims to optimally sample the colorspace.
Cool, that's much better than I expected!

So do you think madVR + ArgyllCMS can now compete in calibration quality with e.g. Lumagen + Calman's 5x5x5 calibration? That would be very very nice!!

[n3w813]

After a lot of testing, tweaking and fixing bugs, I think I'm done for the moment, and the visual results seem quite promising.
To try it for yourself you need ArgyllCMS V1.5.2 from here http://www.argyllcms.com/downloadwin.html
and then this set of extra & replacement files from here http://www.argyllcms.com/Win32_collink_3dlut.zip installed over the top of it, plus a color instrument and some patience.
The main guide is at the bottom of doc/Scenarios.html, & updated documentation for collink in doc/collink.html. Video colorspace profiles are in ref.

Awesome! Testing this now. Question, can ArcgyllCMS be configured to profile/calibrate a display outputting 16-236? I have 2 TVs that does not support 0-255 from a PC.

[fairchild]

I'd be willing to test the Argyll usage if someone can walk me through it somewhat. I am not new to doing calibrations but have never done it with Argyll and especially not in a non-gui version. I currently have access to a Colormunki spectrometer which I've already used to perform a pretty good calibration at the display level using ColorHCFR fork which implements Argyll code in it. From briefly reading the Scenarios.html section of MadVR. I would enter the following:

collink -v -3 m -e t -E t -I b -I 2.2 -G -i r Rec709.icm TV.icm HD.icm

And this would perform a calibration for me? Or is there much more to it.

This is different than my past experience with MadVR and 3dluts, where I'd just manually enter in the grayscale and gamut information into it and it would spit out a 3dlut which would perform additional conversions.

For example this is what I had entered into ycms using calibration data that I had obtained from colorHCFR:

red, Yxy, 21.018, 0.641, 0.330
green, Yxy, 72.897, 0.301, 0.601
blue, Yxy, 8.324, 0.148, 0.060
white, Yxy, 103.463, 0.314, 0.332

30, Yxy, 6.689, 0.312, 0.329
40, Yxy, 12.683, 0.314, 0.329
50, Yxy, 21.290, 0.313, 0.328
60, Yxy, 31.541, 0.315, 0.327
70, Yxy, 46.163, 0.312, 0.329
80, Yxy, 61.423, 0.315, 0.331
90, Yxy, 79.445, 0.314, 0.329
100, Yxy, 101.703, 0.314, 0.332

[n3w813]

I'd be willing to test the Argyll usage if someone can walk me through it somewhat. I am not new to doing calibrations but have never done it with Argyll and especially not in a non-gui version.

Use the following guide to profile/calibrate your display using ArgyllCMS and DispcalGUI but skip the ti3parser section. Instead, use the commands in the Scenarios.html to generate the MadVR 3dlut using the icm and cal files from the profile/calibration.

http://www.hometheatershack.com/forums/video-calibration/65669-htpc-color-calibration-3d-lut.html

[fairchild]

Use the following guide to profile/calibrate your display using ArgyllCMS and DispcalGUI but skip the ti3parser section. Instead, use the commands in the Scenarios.html to generate the MadVR 3dlut using the icm and cal files from the profile/calibration.

http://www.hometheatershack.com/forums/video-calibration/65669-htpc-color-calibration-3d-lut.html

I followed that guide, but once I get to the point where I have to hit calibrate + profile it's greyed out.

http://imageshack.us/a/img94/3872/dispcalgui.th.jpg (http://imageshack.us/photo/my-images/94/dispcalgui.jpg/)

I'm guessing this is happening because I don't have my spectrometer connected and ready to get readings or is it something else? Either way, I'll check back later, gotta head off to work now. Thanks for the link.

[n3w813]

Awesome! Testing this now. Question, can ArcgyllCMS be configured to profile/calibrate a display outputting 16-236? I have 2 TVs that does not support 0-255 from a PC.

Got quite good results on my laptop! Attached are 25% saturation charts for before and after.


I'm guessing this is happening because I don't have my spectrometer connected and ready to get readings or is it something else? Either way, I'll check back later, gotta head off to work now. Thanks for the link.

Yes, you will need to have a meter connected....how else are you going to measure the patterns??? ;)


Madshi,
Confirming Graeme's observation, the "disable GPU gamma ramps" had no effect on the image in both Windowed or FSE modes during my testing. Is this a bug or does the option only apply with specific settings in the OS or MadVR?

[e-t172]

Yes, I agree. BT1886 does use a power of 2.4 though. There is some slight disagreement amongst various authorities as to whether "typical" CRT's have a gamma of 2.2 or 2.4. I suspect it actually comes down to the viewing conditions, 2.4 for quite dark conditions, and 2.2 for not so dark conditions.

Well, actually, BT.1886 translates to an average gamma of 2.4 when the display is "perfect" (i.e. infinite contrast, think CRT), and translates to an average gamma of 2.2 when you feed it with black/white luminance values for typical LCDs (which typically have a CR of approx. 1000:1). You might be interested in this calculator (http://www.avsforum.com/t/1409045/how-power-law-gamma-calibration-can-lead-to-crushed-blacks/90#post_22208270) which illustrates it quite well.

[Graeme Gill]

@Graeme, thanks a lot! :) Two questions, if you don't mind:

(1) Are you ok now with the current way madVR supports only one external 3dlut for all source media types? Or do you think results would be better using one separate 3dlut per source media type?
(2) Does ArgyllCMS take color measurements in one IRE (e.g. 75 or 100) and base its calibration on that? Or do you measure and correct a raster like 5x5x5, similar to how professional image editor 3dlut correction works?


1) Yes, the current support is workable, and should give satisfactory reslt. Being able to specify a 3dlut for each meadia source type would be a potential quality improvement.
2) I'm not really sure what you mean. It's pretty typical device value color management. I have RGB values in one colorspace (the Video media) and I know what device independent color they should be (From Rec709/Pal/NTSC + BT.1886 + viewing conditions adjustment). I have a display and know what device independent colors it produces when I feed RGB into it (the display ICC profile). I link the two together to create a Video RGB to display RGB transformation, and store it in the 3dlut.

[Graeme Gill]

IShould I use a different way to do contrast, saturation and hue changes (e.g. a different way to convert to/from linear light, instead of a pure power 2.2 curve)? Or would it help if I allowed ArgyllCMS to remote control madVR to show color test patterns for measurement? The code for that (including network access etc) has been mostly ready for years now, but has never been put to use yet...

I think your current color adjustment code will interact OK with the ArgyllCMS 3dluts, since (when used in the recommended fashion) it emulates a device with a pure power curve. A purist won't use such controls anyway.
As for test patterns - it would be interesting for verification through the whole video rendering system, but certainly isn't needed (or probably useful) for the display characterisation.
One way of hooking things up for video verification would be to have MadVR respond to a command to set a color. Argyll's tools have a call-out option - see http://www.argyllcms.com/doc/dispread.html#C - so having something that works with that would be good.

Gotta admint, it never crossed my mind that black not landing on a grid point could be a problem. That's probably because I was always thinking of 256x256x256 3dluts and didn't spend too much time thinking about smaller sized 3dluts.

In ICC profiles, the per channel input curves are used to finesse things so that certain critical values land on grid points.

So do you think madVR + ArgyllCMS can now compete in calibration quality with e.g. Lumagen + Calman's 5x5x5 calibration? That would be very very nice!!

Should be at least as good, and is much more sophisticated and mature in most ways, even if it's not so tailored to Video work currently (they're still obsessed with regular grid measurement, and aren't even using something like body centred cubic, etc.).

If someone really gets keen, they could also consider throwing http://www.argyllcms.com/doc/refine.html at a display as well, although some tweaks may be needed to target Video.

[Graeme Gill]

Awesome! Testing this now. Question, can ArcgyllCMS be configured to profile/calibrate a display outputting 16-236? I have 2 TVs that does not support 0-255 from a PC.
Not currently. My understanding was that most graphics cards either automatically, or as an option do this scaling. If you tell me they do not, I think I can add an option to dispcal & dispread to do this (I am a little worried about how to detect how many bits are being sent to the display though, since Video encoding uses a shift rather than a scale when operating at higher bit depths.)

[Graeme Gill]

Well, actually, BT.1886 translates to an average gamma of 2.4 when the display is "perfect" (i.e. infinite contrast, think CRT), and translates to an average gamma of 2.2 when you feed it with black/white luminance values for typical LCDs (which typically have a CR of approx. 1000:1).
Yes, you're right about the average gamma, but at the end of the day I'm not sure if it will make an enormous difference. I'm guessing that the preferred way of adjusting the display for the viewing conditions is to adjust the BT.1886 2.4 gamma to something else (which is what collink allows for), but if the adjustment is to compensate for the source material, then a pure power curve adjustment before the BT.1886 is probably fine too, and the MadVR controls are much more convenient for that task (not need to re-generate the 3dlut).

[n3w813]

Not currently. My understanding was that most graphics cards either automatically, or as an option do this scaling. If you tell me they do not, I think I can add an option to dispcal & dispread to do this (I am a little worried about how to detect how many bits are being sent to the display though, since Video encoding uses a shift rather than a scale when operating at higher bit depths.)

Most video cards do but some don't. Additionally, not all TVs have an option to select 0-255 or 16-235. Some are limited to 16-235 only. I know ArcgyllCMS is for PC (0-255) monitor calibration but it will be great if you can add support to calibrate 16-235 only output. :)

[fairchild]

Ok after performing a calibration (which failed at the end and said profile not complete) using this guide (http://www.hometheatershack.com/forums/video-calibration/65669-htpc-color-calibration-3d-lut.html), I am left with a bunch of files in a newly created directory in my dispcal folder: (followed up to here: Set dispcalGUI to video, profile type XYZ LUT + matrix. Click the advanced button to set gamut mapping options: check both boxes; select an Rec. 709 profile; set the intents to absolute colorimetric. Click on the Calibrate & Profile button. When finished install the ICM profile. Check that it is loaded as the default profile for your display in the color management control panel.)

Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX

But again, I am missing some files or am not understanding how I now create the actual 3dlut. Per the Scenarios.html readme, it says to use the following:

collink -v -3 m -e t -E t -I b -I 2.2 -G -i r Rec709.icm TV.icm HD.icm

I can copy and paste the Red709.icm easy enough to the directory where collink.exe is located, but I can't find TV.icm or HD.icm and I don't understand where all the files I just created after an hour long calibration/profile with dispcal factor in.

I have the following in the Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX folder:

Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.all.cmd
Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.cal
Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.dispcal.cmd
Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.dispread.cmd
Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.ti1
Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.ti3

Someone halp, if this should go to PM's then please advise.

[Graeme Gill]

But again, I am missing some files or am not understanding how I now create the actual 3dlut. Per the Scenarios.html readme, it says to use the following:

collink -v -3 m -e t -E t -I b -I 2.2 -G -i r Rec709.icm TV.icm HD.icm

I can copy and paste the Red709.icm easy enough to the directory where collink.exe is located, but I can't find TV.icm or HD.icm and I don't understand where all the files I just created after an hour long calibration/profile with dispcal factor in.

"TV.icm" is the profile you have created for your display. "HD.icm" is the device link/3dlut basename.

Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.all.cmd
Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.cal
Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.dispcal.cmd
Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.dispread.cmd
Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.ti1
Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.ti3

You don't seem to have created a profile. As per Scenarios.html, try:

colprof -v -qm -bl "Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX"

which will create a cLUT type profile. You should end up with

Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.icm

which you can feed into collink:

collink -v -3m -et -Et -Ib -I2.2 -G -ir Rec709.icm "Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.icm" HD.icm

And load the HD.3dlut file created into MadVR.

You also need to make sure that the display profile is either installed, or at least that it's calibration curves ('vcgt') is loaded into the graphics card, ie:

dispwin "Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.cal"

or

dispwin -I "Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.icm"

If you installed the profile, then a gamma loader application or the Operating System color management needs to be setup to load the calibration on system start. See http://www.argyllcms.com/doc/dispprofloc.html for information on how to do this.

[fairchild]

Thanks for the write-up, definitely understand more, but I'm still getting errors. I get this error when entering (colprof -v -qm -bl "Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX"):

colprof: Error - CGATS file read error : Unable to open file 'Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.ti3' for reading

I made sure to even run the cmd in administrator mode, but still that error pops up.

I wonder if this is similair to why after the calibration portion finishes, it dispcalgui, gives an error saying that it didn't create a profile. I tried to calibrate+profile a second time, but same error occurred.

I also tried to run the app in Admin mode and just profile, again same error. I'm stumped.

http://imageshack.us/a/img594/5184/dispcalguiprofileerror.th.jpg (http://imageshack.us/photo/my-images/594/dispcalguiprofileerror.jpg/)

[cyberbeing]

@Graeme Gill

I notice that collink created 3DLUT will always change the measured gamma of my display from my intended target. Could you add a switch to ignore the input transfer function of the src profile, and make it assumed to be the same transfer function as the dst profile? Alternatively, could add a way to force "-a tv.cal" as both the src and dst transfer curve? Something similar to yCMS when only providing primaries+wtpt but not grayscale measurements, where input->output gamma on the neutral axis is untouched but gamut and white point correction is still preformed?


"Device Link will override the calibrated transfer curve characteristic of the display"

I really hate this, and it's the main reason I've never been fond of using Device Links (ti3 parser) or ICC profiles (mpc-hc lcms) for video color management.

How can this be prevented without hacking ICC profiles values, if the calibrated transfer curve characteristic of the display is already verified as the intended target before a 3DLUT touches anything?


Other comments:

It is confusing that the same lowercase/uppercase switches are used multiple times for complete different purposes.

Documentation is unclear about which switches when used together with force collink into a different mode not capable of creating a madVR 3DLUT.

Why for example is "-I b -G -G 2.4" invalid for creating a madVR 3DLUT, while your documentation seem to suggest this is a valid combination?

Optimally I would like would like to:
1) Profile my display without calibration and have Argyll create a 3DLUT for madVR (or intermediary ICC profile)
2) Have Argyll load the 3DLUT (or intermediary ICC profile) and perform Display calibration on the VIDEO LUT based on the values measured when the LUT in 1) is used.
3) Argyll creates a final madVR 3DLUT for use with VIDEO LUT
3b) Argyll creates a final madVR 3DLUT for use without VIDEO LUT

Alternatively:
1) Calibrate my display's neutral axis and transfer curve
2) Profile my display and create an ICC profile for use in Photoshop
3) Create a madVR 3DLUT which maintains the neutral axis results measured after step 1) whatever it may be, but has an optimal src->dst gamut adaption for video gamuts.


I'm strongly of the opinion that changing the viewing gamma and neutral axis of a video's source pixels should be optional and non-default. If you want a 3DLUT to make changes to the neutral axis of a video's source pixels, the result should match 1) when the VIDEO LUT (gpu gamma ramp) is disabled. In other words, something similar to how ti3 parser can merge a .cal file into a 3DLUT as a replacement for using the VIDEO LUT.

Currently providing a CAL file with "-a" does not act a replacement for the VIDEO LUT which assumed image source pixels do not contain an ICC profile and should be viewed linearally (i.e color management disabled). collink generated madVR 3DLUTs make the VIDEO LUT produce unexpected results, since both are modifying the neutral axis in conflicting ways, with the combined result never verified by measurements in Argyll and corrected for.

[madshi]

Not currently. My understanding was that most graphics cards either automatically, or as an option do this scaling. If you tell me they do not, I think I can add an option to dispcal & dispread to do this (I am a little worried about how to detect how many bits are being sent to the display though, since Video encoding uses a shift rather than a scale when operating at higher bit depths.)
Wouldn't this problem be solved "automatically" if you used madVR (without a 3dlut) as a test pattern generator to do the initial measurements? madVR already knows internally (if it's configured correctly) whether to send 0-255 or 16-235 to the display. So if you asked madVR for a specific color value, madVR would take care of stretching it to either 0-255 or 16-235.

If you currently only support 0-255, what does your 3dlut contain in the 0-15 and 236-255 values? Does your 3dlut clip BTB and WTW? It would be nice if you could passthrough BTB and WTW somehow. This would allow the use of BTB/WTW calibration test patterns, even with the 3dlut active. Also I've been told that some ISF calibrators like to calibrate so that a tiny amount of BTB is still visible on screen, so they sometimes calibrate to have 15-236 visible instead of 16-235.

Thanks!

[Graeme Gill]

Most video cards do but some don't. Additionally, not all TVs have an option to select 0-255 or 16-235. Some are limited to 16-235 only. I know ArgyllCMS is for PC (0-255) monitor calibration but it will be great if you can add support to calibrate 16-235 only output. :)

Update is here http://www.argyllcms.com/Win32_collink_3dlut.zip. I've added -E flags to dispcal and dispread, that should do the right thing.

[Graeme Gill]

I get this error when entering (colprof -v -qm -bl "Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX"):

You need to locate the file. It obviously isn't in your current directory.
If you run "cd" it will show you what your current directory is.
If you run "dir "Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.ti3" " I'm guessing
dir won't find it. You need to locate the path to the file, either relative to your current directory, or from the top (ie. c:\whatever\whatever\Panasonic-TV 2013-05-02 D6500 2.2 HQ XYZLUT+MTX.ti3). Omit the ".ti3" when giving the filename to colprof.

[Graeme Gill]

@Graeme Gill
I notice that collink created 3DLUT will always change the measured gamma of my display from my intended target. Could you add a switch to ignore the input transfer function of the src profile, and make it assumed to be the same transfer function as the dst profile?

No, that wouldn't make any sense - it would like using a screwdriver to hammer in a nail.
The aim is make your display emulate an ideal display, therefore lots of effort is going in to removing its native response as much as possible from the result.

It would be best if you could state what problem you are trying to solve.

Alternatively, could add a way to force "-a tv.cal" as both the src and dst transfer curve?

I'm not sure what you mean. "-a tv.cal" concatenates the display calibration curves created by dispcal onto the link/3dlut. It's just doing what is expected to be done by the graphics card for the display profile to be a valid description of the display response. There doesn't have to be a display calibration curve - you can skip that and profile the display "as is" if you like, but calibration is a good way of setting the white point.

"Device Link will override the calibrated transfer curve characteristic of the display"

I really hate this, and it's the main reason I've never been fond of using Device Links (ti3 parser) or ICC profiles (mpc-hc lcms) for video color management.

How can this be prevented without hacking ICC profiles values, if the calibrated transfer curve characteristic of the display is already verified as the intended target before a 3DLUT touches anything?

You appear to be going about it the wrong way, or using the wrong tool for the job. The whole approach is about not having to setup the display to your desired response - the profiling takes care of characterising the display rather than adjusting it, and the emulated response is defined by the source profile & adjustments between the profiles (ie. BT.1886, gamut mapping, apperance mapping etc.), something that is portable and independent of the display.

It is confusing that the same lowercase/uppercase switches are used multiple times for complete different purposes.

Agreed - but I've made them as consistent as I can, given historical constraints and the number of options. For casual use it's best to set up some "recipes" and save them in a text file for copy and paste to the command line, or create a script.

Documentation is unclear about which switches when used together with force collink into a different mode not capable of creating a madVR 3DLUT.

I'm not aware of such a combination - typically I've tried to automatically fix anything (with a warning) that would stop something useful being created.

Why for example is "-I b -G -G 2.4" invalid for creating a madVR 3DLUT, while your documentation seem to suggest this is a valid combination?

Sorry, that's a typo on my part. It's meant to be "-I b -I 2.4 -G"

I'm strongly of the opinion that changing the viewing gamma and neutral axis of a video's source pixels should be optional and non-default. If you want a 3DLUT to make changes to the neutral axis of a video's source pixels, the result should match 1) when the VIDEO LUT (gpu gamma ramp) is disabled. In other words, something similar to how ti3 parser can merge a .cal file into a 3DLUT as a replacement for using the VIDEO LUT.

You're trying to do something rather different to color management then, and ArgyllCMS mightn't be much help to you.

Currently providing a CAL file with "-a" does not act a replacement for the VIDEO LUT which assumed image source pixels do not contain an ICC profile and should be viewed linearally (i.e color management disabled). collink generated madVR 3DLUTs make the VIDEO LUT produce unexpected results, since both are modifying the neutral axis in conflicting ways, with the combined result never verified by measurements in Argyll and corrected for.

Sorry, but I'm not really following at all. A Graphics card VideoLUT can be used for a multitude of things (it's often used to smoothly dim a display), but in a color managed context it is typically used to provide basic display calibration, mainly for the benefits of non-color managed applications. The benefits to non-color managed applications is a desired white point, a neutral R=G=B response, and a progressive response that is roughly what is expected for a "typical" display (ie. something like sRGB). If you are unhappy with the effects of the VideoLUT, then I'd suggest either modifying the dispcal parameters (perhaps using -gs for an sRGB curve would be a better starting point) to get it to something that is acceptable, or skip that part entirely. It would be good if you could explain what you mean by "both are modifying the neutral axis in conflicting ways", since both are striving to give a neutral response while maintaining the contrast range. If you are working on an LCD display, you might find that collink -ila rather than -ir works a bit better for you.

[Graeme Gill]

Wouldn't this problem be solved "automatically" if you used madVR (without a 3dlut) as a test pattern generator to do the initial measurements? madVR already knows internally (if it's configured correctly) whether to send 0-255 or 16-235 to the display. So if you asked madVR for a specific color value, madVR would take care of stretching it to either 0-255 or 16-235.

Right, but does MadVR know whether it's operating though the VideoLUTs or not ?

While there are quite a few advantages to operating through the same display path, it's certainly not something that is generally applicable - ArgyllCMS is used for many purposes outside MSWin systems or MadVR.

If you currently only support 0-255, what does your 3dlut contain in the 0-15 and 236-255 values?
Does your 3dlut clip BTB and WTW? It would be nice if you could passthrough BTB and WTW somehow.

It contains a linear interpolation from the black and white output device values to 0 and 255 respectively. Yes, BTB and WTW are passed through.

This would allow the use of BTB/WTW calibration test patterns, even with the 3dlut active. Also I've been told that some ISF calibrators like to calibrate so that a tiny amount of BTB is still visible on screen, so they sometimes calibrate to have 15-236 visible instead of 16-235.

Right, but tweaking the black like that isn't something you'd do in a color managed situation. In fact it's desirable to err on the side of making the display a tiny bit too dark, to make sure that you are getting the best possible black, and the profiling will then adjust things appropriately.

[madshi]

Right, but does MadVR know whether it's operating though the VideoLUTs or not ?
I can disable the VideoLUTs. There's already an option for that in the madVR settings. It currently only works in fullscreen exclusive mode, but I could make it work for windowed mode, too.

-------

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. Would it be ok with you if I automated the whole calibration process as far as technically possible? For that I'd have to...

(1) ... automate the ArgyllCMS software download from within the madVR settings dialog, or from a helper tool. This step is optional. I could also require the user to manually download ArgyllCMS and store it in a specific folder.
(2) ... call the ArgyllCMS command line tools from within my helper tool to create the 3dlut file(s). Ideally, I'd like to use SW_HIDE (= hidden command line window).

Of course I'd make it very clear that ArgyllCMS is used for calibration in the GUI and in the readme/license text etc.

If you don't like this idea, that'd be ok with me. But I thought I'd ask, for the benefit/comfort of madVR users...

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.)

[cyberbeing]

The aim is make your display emulate an ideal display, therefore lots of effort is going in to removing its native response as much as possible from the result.

It would be best if you could state what problem you are trying to solve.

The native response of my reference CRT display is the "ideal display" I want to emulate (i.e. no change). I only have a need to adapt white point and gamut from REC709 to a few minor lacking areas in my display's native gamut and white point. This is my problem I'm trying to solve.

I'm not sure what you mean. "-a tv.cal" concatenates the display calibration curves created by dispcal onto the link/3dlut. It's just doing what is expected to be done by the graphics card for the display profile to be a valid description of the display response. There doesn't have to be a display calibration curve - you can skip that and profile the display "as is" if you like, but calibration is a good way of setting the white point.
...
Sorry, but I'm not really following at all. A Graphics card VideoLUT can be used for a multitude of things (it's often used to smoothly dim a display), but in a color managed context it is typically used to provide basic display calibration, mainly for the benefits of non-color managed applications. The benefits to non-color managed applications is a desired white point, a neutral R=G=B response, and a progressive response that is roughly what is expected for a "typical" display (ie. something like sRGB). If you are unhappy with the effects of the VideoLUT, then I'd suggest either modifying the dispcal parameters (perhaps using -gs for an sRGB curve would be a better starting point) to get it to something that is acceptable, or skip that part entirely. It would be good if you could explain what you mean by "both are modifying the neutral axis in conflicting ways", since both are striving to give a neutral response while maintaining the contrast range. If you are working on an LCD display, you might find that collink -ila rather than -ir works a bit better for you.


1) Calibrate the VIDEO LUT with dispcal to BT.1886 (or ambient light scaled BT.709 curve)
2) Measure & Record Y values for 5% grayscale steps with the VIDEO LUT active
3) Create an ICC Profile
4) Use collink to create a madVR 3DLUT with "-a tv.cal"
5) Measure & Record Y values for 5% grayscale steps in madVR with 3DLUT active and VIDEO LUT Disabled

1) Calibrate the VIDEO LUT with dispcal to BT.1886 (or ambient light scaled BT.709 curve)
2) Measure & Record Y values for 5% grayscale steps with the VIDEO LUT active
3) Create an ICC Profile
4) Use collink to create a madVR 3DLUT
5) Measure & Record Y values for 5% grayscale steps in madVR with 3DLUT active and VIDEO LUT Enabled

Result: Grayscale Y values measured in Step 2) do not match Y values measured in Step 5). The gamma curve if no longer the "ideal curve" which was calibrated to in Step 1).

This is what I mean by the Device Link generated 3DLUT conflicting with VIDEO LUT and/or CAL file.


You appear to be going about it the wrong way, or using the wrong tool for the job. The whole approach is about not having to setup the display to your desired response - the profiling takes care of characterising the display rather than adjusting it, and the emulated response is defined by the source profile & adjustments between the profiles (ie. BT.1886, gamut mapping, apperance mapping etc.), something that is portable and independent of the display.
...
You're trying to do something rather different to color management then, and ArgyllCMS mightn't be much help to you.
...
If you are unhappy with the effects of the VideoLUT, then I'd suggest either modifying the dispcal parameters (perhaps using -gs for an sRGB curve would be a better starting point) to get it to something that is acceptable, or skip that part entirely. It would be good if you could explain what you mean by "both are modifying the neutral axis in conflicting ways", since both are striving to give a neutral response while maintaining the contrast range. If you are working on an LCD display, you might find that collink -ila rather than -ir works a bit better for you.
I'm wanting essentially ISF calibration + 3DLUT gamut adaption, which I'd perceive as optimal for the purpose of Video calibration, while a ICC workflow I don't consider to be. The concept of video calibration is a bit different from traditional color management where you want all displays to look the same at a particular target which everybody needs to match for proofing and printing. Instead you are highly optimizing the gamut of a single display to a reference display response of your choice. This "reference display response" could be one of many targets like BT.1886, or it could be something completely custom being used for a particular purpose.

Essentially I need more flexibility in specifying the "ideal reference display response" I want the Argyll CMS generated 3DLUT to target. I also would like a way to verify measurements using such a 3DLUT (or the temp ICC profile), and feed those back into collink so it can fine-tune 3DLUT measured display response the result for error introduced. Currently there is no consistency or cross-checking between Dispcal and collink generated 3DLUT files.

I already tried all the different -i values but none seem to give the results I expect.


Maybe if you clarified the following I could live with the current collink behavior:

Using the command line
collink -v -3 m -e t -E t -I b -G -i r -a TV.cal Rec709.icm TV.icm HD.icm

Would it be possible to measure or have Argyll CMS output 16 bit neutral grayscale values from the generated LUT, and convert that into a new CAL file? If you are saying that the 3DLUT output is outputting an "ideal target" display response, I'd see value of being able to load such a CAL back into the Video LUT.

If this was possible, and I created a new ICC profile with colprof, and a new 3DLUT with collink -a TV.cal, would 5% grayscale measurement now match between:
1) madVR 3DLUT "VIDEO LUT disabled"
&
2) Argyll measured values with "VIDEO LUT enabled"

If there was some way to match the measured display response of a dispcal VIDEO LUT calibtration to the measured display response of a Argyll generated 3DLUT in madVR, I'd be happy. Currently I'm not seeing a way to do this.

[Graeme Gill]

Something else to keep in mind is that it's probably not a good idea to try and use all the internal controls to calibrate a TV, and then throw a 3dlut at it. Some of the internal controls can really screw up the color response. Putting a display in a state where it behaves well and is capable of its full potential is good, and then let profiling and a 3dlut do it's thing.
There's some good advice here http://www.lightillusion.com/display_calibration.html

[cyberbeing]

FWIW, I'm only testing this on my GDM-F520 CRT + i1pro at the moment.

My dilemma in a nutshell:

dispcal -> colprof -> collink
BT.1886 ideal == dispcal BT.1886 calibration != collink 3DLUT BT.1886

Z is an ideal target (i.e. BT.1886)
dispcal calibrated to ideal target Z.
You verify that your display response along the neutral axis is now exactly target Z, but gamut is incorrect.

Generate 3DLUT with collink.
Upon verifying the display with 3DLUT active, you are no longer at ideal target Z, but something else entirely, yet gamut is now correct.

Desire to maintain ideal target Z along the neutral axis at all costs when performing gamut adaptions.


If dispcal was verified to be "accurate" target Z's neutral axis response curve, then collink must be "inaccurate" or rather using a different target which is a hybrid of Z and something else undesired. Considering a BT.1886 curve needs to be calculated based on the bpt+wtpt of a display which dispcal does accurately, why doesn't collink trust that dispcal measurements already contain the optimal adjustment for all neutral Y values, and force the gamut adaption to work around that? Is the flaw in LUT generated by colprof in the ICC profile, the REC709 profile used with collink, or something else entirely which skews things? If the response curve in the REC709 profile or the -i switch in collink is the problem, why not offer a switch in collink to workaround this issue?

[n3w813]

Update is here http://www.argyllcms.com/Win32_collink_3dlut.zip. I've added -E flags to dispcal and dispread, that should do the right thing.

Thanks! Jeez you work fast!! :D Will test 16-235 this weekend.

An observation on the files in the zip; collink.exe is in two different folders, bin and link. The modified date of these two files are different. Is this by design?

[n3w813]

Something else to keep in mind is that it's probably not a good idea to try and use all the internal controls to calibrate a TV, and then throw a 3dlut at it. Some of the internal controls can really screw up the color response. Putting a display in a state where it behaves well and is capable of its full potential is good, and then let profiling and a 3dlut do it's thing.
There's some good advice here http://www.lightillusion.com/display_calibration.html

If ALL video playback from a HTPC can incorporate a 3DLUT correction, like you stated, there is no need to calibrate the TV/display.

At the moment, MadVR (paired with a DirectShow player/program) and MPC-HC are the only programs that allows for a 3DLUT correction. Unfortunately, these two programs do not support Bluray playback with menus, frame-packed 3D Bluray playback, etc. Which means another media player without correction will need to be used.

Also, for many, Windows Media Center is used for LiveTV and video playback. WMC allows the playback of protected content via CableCard but only allows MS own video renderer to be used to maintain the protected path. If you try to change the video renderer, playback will be limited to non-encrypted streams.

In my case, a Sharp Elite with bad color tracking needs to be calibrated via TV controls first to ensure non-3DLUT corrected sources can be as accurate as the display allows. :)

[n3w813]

I've created a thread over at AVSForum for instructions and information for ArgyllCMS/MadVR 3DLUT generation. *WIP

http://www.avsforum.com/t/1471169/madvr-argyllcms

[fairchild]

I've created a thread over at AVSForum for instructions and information for ArgyllCMS/MadVR 3DLUT generation. *WIP

http://www.avsforum.com/t/1471169/madvr-argyllcms

Sweet thanks for this! I will try it at some point. I performed a new calibration with my Colormunki spectro at a different gamma point with the AVSHD709 75% color patterns (not sure if these are 75% luminance/amplitude and 100% saturation) and a 2.4 gamma point. Not sure how/if this will work with this, but will be sure to tag it.

[n3w813]

Update is here http://www.argyllcms.com/Win32_collink_3dlut.zip. I've added -E flags to dispcal and dispread, that should do the right thing.

Graeme,
In the docs for dispcal, -E option is listed as "Run only verify pass on installed calibration curves." Did you replace this option with the one that calibrates 16-235?

[dansrfe]

I've created a thread over at AVSForum for instructions and information for ArgyllCMS/MadVR 3DLUT generation. *WIP

http://www.avsforum.com/t/1471169/madvr-argyllcms

Birthday present :D Can't wait for the finished product! :)

[Eustachy_Kapusta]

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

[kasper93]

(The "disable GPU gamma ramps" flag doesn't seem to have any effect).

Hmm, it does for me, but only in FSE mode.

@madshi
Do you think it makes sense to disable gamma ramps also in windowed mode? I would like to have that option.

@Graeme Gill
Thanks for your work :) It gets a lot easier to create .3dlut for madvr.

[Asmodian]

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

If you are making the GTX650 do anything else it might be too slow for highest, try high instead. Is smooth motion turning on for your TS streams but not for the others?

Are your source files interlaced? What frame rates? What resolution source and display?

As a test you could try using software decoding and disable deinterlacing in MadVR. You can enable yadif in LAV if you need deinterlacing.

The MadVR osd (ctrl-J) might help track down what is different between the working and nonworking files.

[Eustachy_Kapusta]

If you are making the GTX650 do anything else it might be too slow for highest, try high instead. Is smooth motion turning on for your TS streams but not for the others?

Are your source files interlaced? What frame rates? What resolution source and display?

As a test you could try using software decoding and disable deinterlacing in MadVR. You can enable yadif in LAV if you need deinterlacing.

The MadVR osd (ctrl-J) might help track down what is different between the working and nonworking files.


Video
ID : 576 (0x240)
Menu ID : 192 (0xC0)
Format : MPEG Video
Format version : Version 2
Format profile : Main@High
Format settings, BVOP : Yes
Format settings, Matrix : Custom
Format settings, GOP : M=3, N=15
Codec ID : 2
Duration : 1h 30mn
Bit rate mode : Variable
Bit rate : 20.6 Mbps
Maximum bit rate : 24.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan order : Top Field First
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.332
Time code of first frame : 17:03:50:03
Time code source : Group of pictures header
Stream size : 13.0 GiB (94%)
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Example of TS I wanted to watch. Changing madVR settings to "high" made it watchable (I'm still getting dropped frames but only a few so it isn't a big issue). I disabled deinterlacing in madvr - and I've yadif deinterlacing enabled in lav. But I can use "highest" setting on any other 1080p (even 10bit) video I've without any dropped frames. And maybe I didn't clarify my issue enought - I get dropped frames (amount which make video unwatchable) ONLY in TS files, all other types are playing fine.

[Asmodian]

Are the other files that work also interlaced, 1080i, 29.97fps? 10-bit uses software decoding, are you using software decoding in LAV for these TS files?

You don't want to use hardware decoding because with a GTX650 and highest you need to keep all the GPU resources free for MadVR.

[huhn]

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

first of all use software decoding then press control + j and look for the rendering time and give us this number or make a screen of it.

[Graeme Gill]

Graeme,
In the docs for dispcal, -E option is listed as "Run only verify pass on installed calibration curves." Did you replace this option with the one that calibrates 16-235?
Yes, I've tried to keep the option consistent, so I've moved what was -E to be -z. The usage is correct (ie. run "dispcal -?")

[madshi]

@Graeme,

have you missed this post?

http://forum.doom9.org/showpost.php?p=1626634&postcount=18635

A reply would be great - thanks!

[n3w813]

@Graeme,
I have a meter correction that I created using Calman v5 (see attachment) that I would like to use in ArcgyllCMS. How should I transpose the values into the ccmx file for ArcgyllCMS use?

NUMBER_OF_FIELDS 3
BEGIN_DATA_FORMAT
XYZ_X XYZ_Y XYZ_Z
END_DATA_FORMAT

NUMBER_OF_SETS 3
BEGIN_DATA
X1? Y1? Z1?
X2? Y2? Z2?
X3? Y3? Z3?
END_DATA

:thanks: