madVR - high quality video renderer (GPU assisted)

[e-t172]

If you can make an ICC profile you should be able to make a 3DLUT which should be an even better solution than an ICC profile.

I find your statement confusing. It's not a "better solution", it's just that some applications (Photoshop, Windows 7 photo viewer, probably Gimp) use the full contents of the ICC profile to generate a 3DLUT on the fly, while other applications (madVR) need the 3DLUT to be pregenerated in advance and manually configured. The application doesn't give you a choice, so it's pointless to say that one is better than the other.

[Asmodian]

The 3DLUT is is a better solution, technically, than it would be if madVR used the full contents of the ICC profile.

Also what is in an ICC profile, beyond the simple 1D LUTs, varies wildly. Often they contain simple measurements that can only be used to do a rough conversion with little or no user control over how it is done. madVR's 256x256x256 3DLUT allows full control of the conversion with very fine grained corrections being possible.

[Siso]

The 3DLUT is is a better solution, technically, than it would be if madVR used the full contents of the ICC profile.

Also what is in an ICC profile, beyond the simple 1D LUTs, varies wildly. Often they contain simple measurements that can only be used to do a rough conversion with little or no user control over how it is done. madVR's 256x256x256 3DLUT allows full control of the conversion with very fine grained corrections being possible.

I couldn't said it better, I totally agree.

[SEX]

If you can make an ICC profile you should be able to make a 3DLUT which should be an even better solution than an ICC profile.

My calibration software does not have the ability to create a 3DLUTs, unfortunately

[mytbyte]

@SEX: I already proposed displayCAL twice, I think ;)

[SEX]

@SEX: I already proposed displayCAL twice, I think ;)

I tried it. Does not recognize my colorimeter.

[huhn]

it may be possible to take the readings and create a 3D LUT with it.

[SEX]

it may be possible to take the readings and create a 3D LUT with it.

I think that the DisplayCAL can't do this

[e-t172]

My calibration software does not have the ability to create a 3DLUTs, unfortunately

ArgyllCMS can (at least in principle) generate a 3DLUT from any ICC profile using the collink -3m command. See the documentation (http://www.argyllcms.com/doc/Scenarios.html#TV1), especially the section about madVR at the end of the section.

[SEX]

ArgyllCMS can (at least in principle) generate a 3DLUT from any ICC profile using the collink -3m command. See the documentation (http://www.argyllcms.com/doc/Scenarios.html#TV1), especially the section about madVR at the end of the section.

This information would be useful in the madVR's help. It's terrible to imagine how many people see not flawless colors

[huhn]

why? windows can load icc files too. they are generally of bad quality but...

[e-t172]

This information would be useful in the madVR's help. It's terrible to imagine how many people see not flawless colors

Most people do not have a colorimeter or even know what a gamut is to begin with, so while I do agree with you in principle, I think you are mistaken about people's priorities :)

why? windows can load icc files too. they are generally of bad quality but...

Windows cannot "load" ICC files, per se - or at the very least it would be quite misleading to say so. It can load the vcgt (GPU gamma ramps) that's within an ICC file (and even then, only if you tick the right checkbox), but that's only a small part of the data contained within the profile, and it can only be used for basic gamma and white point adjustment - not for gamut mapping. It's the responsibility of each individual application (e.g. Photoshop) to load the full profile and come up with a proper color space transformation.

[SEX]

why? windows can load icc files too. they are generally of bad quality but...

Сonfusion with the purpose of the settings in the madVR, especially "disable calibration controls for this display" and "this display is aleready calibrated" does not give an idea of the actual situation

[Asmodian]

Hmm, pehaps we are too close to it but the "disable GPU gamma ramps" should clue you in if you understand how calibration works in Windows. Those options are designed for those who are familiar with Windows calibration because they are the only ones who ask for the feature at all. :o

It can be very difficult to come up with short descriptions that are clear to everyone. With the knowledge that madVR does not reference ICC profiles everything else should be clear. Please check out the link in my signature and let me know if anything does not make sense to you. :)
I tried it. Does not recognize my colorimeter.

Does it not? DisplayCal supports the common meters, X-rite or Spyder. Which meter are you using?

ArgyllCMS can (at least in principle) generate a 3DLUT from any ICC profile using the collink -3m command. See the documentation (http://www.argyllcms.com/doc/Scenarios.html#TV1), especially the section about madVR at the end of the section.

That doesn't support a lot of possible ICC profiles, I couldn't get it to work using ICC profiles created by X-rite's i1Profiler.

[SEX]

Hmm, pehaps we are too close to it but the "disable GPU gamma ramps" should clue you in if you understand how calibration works in Windows. Those options are designed for those who are familiar with Windows calibration because they are the only ones who ask for the feature at all. :o

It can be very difficult to come up with short descriptions that are clear to everyone. With the knowledge that madVR does not reference ICC profiles everything else should be clear. Please check out the link in my signature and let me know if anything does not make sense to you. :)


Does it not? DisplayCal supports the common meters, X-rite or Spyder. Which meter are you using?



That doesn't support a lot of possible ICC profiles, I couldn't get it to work using ICC profiles created by X-rite's i1Profiler.

Just based on madVR options, there can be a persistent feeling that it will use the ICC profile, simply as EVR do. I think that the warning that this is not so, will be useful.

I use NEC MDSVSENSOR

[Ver Greeneyes]

Personally I think it would be nice if madVR could load say LCMS as an external dll or something and generate its 3DLUTs on the fly from the monitor's ICC profile for each target color space. The resulting 3DLUTs (which could be cached somewhere) would presumably be of somewhat lower quality than using ArgyllCMS' collink, but I think it would significantly increase the number of people receiving color correction (even if they did still have to download LCMS separately due to licensing or whatever).

[Asmodian]

Just based on madVR options, there can be a persistent feeling that it will use the ICC profile, simply as EVR do.

Wow, EVR uses an ICC profile in Windows 10 now? That is new and great news, it is almost weird having Windows finally support color management. I remember recently thumbnails started being corrected but Windows assumed you had an sRGB display so it would convert anything tagged something besides sRGB to your profile as if your profile was sRGB (counter productive on my DCI-P3 displays). I need to do more experimentation with 1607.

[SEX]

Wow, EVR uses an ICC profile in Windows 10 now? That is new and great news, it is almost weird having Windows finally support color management. I remember recently thumbnails started being corrected but Windows assumed you had an sRGB display so it would convert anything tagged something besides sRGB to your profile as if your profile was sRGB (counter productive on my DCI-P3 displays). I need to do more experimentation with 1607.

No. If I use the "Use Display ICC Color Gamut Correction" in the PotPlayer, then the colors match in the PotPlayer, but only for EVR, does not work for madVR

[SEX]

Personally I think it would be nice if madVR could load say LCMS as an external dll or something and generate its 3DLUTs on the fly from the monitor's ICC profile for each target color space. The resulting 3DLUTs (which could be cached somewhere) would presumably be of somewhat lower quality than using ArgyllCMS' collink, but I think it would significantly increase the number of people receiving color correction (even if they did still have to download LCMS separately due to licensing or whatever).

It would be fantastic!

[Asmodian]

No. If I use the "Use Display ICC Color Gamut Correction" in the PotPlayer, then the colors match in the PotPlayer, but only for EVR, does not work for madVR

Ah, it is just PotPlayer hacks then. :devil:

[huhn]

It would be fantastic!

creating a 3d lut takes easily 5 mins...

[SEX]

Ah, it is just PotPlayer hacks then. :devil:

If it's hack, then for me it's a mystery why it does not work for the madVR. Since they receive data from the decoder in the same format, and this "hack" possibly works as an intermediate layer

[SEX]

creating a 3d lut takes easily 5 mins...

Why do this every time you start if the ICC profile has not changed?

[bkrieger]

I have a GTX 980 TI 6GB paired with a Ryzen 8 1800X. I just want to know if the following settings are correct or if anything needs to be changed. Thanks


Chroma Upscaling- NGU AA high

Image Upscaling- doubling NGU Sharp

Luma doubling - high

Luma quadrupling- let MadVR decide


Chroma- Normal


Activate doubling / quadrupling

doubling- always- supersamplong

Quadrupling- let madvr decide

if any more Upscaling- Upscaling and downscaling let MADVR decide

Image downscaling - SSIM 1D 100%. LL- Ringing Fiktet strict soft




Thanks

[ryrynz]

Depends on your content, personally I'd drop chroma or luma scaling back if you need the headroom to hit that sweet SSIM 2D, your decision if you want to stick AR on top of that but personally I'd rather use that headroom for luma and chroma.

[mytbyte]

I tried it. Does not recognize my colorimeter.There is a small program that comes with DisplayCAL, it's called 3D LUT maker, which can convert your ICC to MadVR LUT. It's right there on the program list in DisplayCAL section.

Wow, EVR uses an ICC profile in Windows 10 now?

There has been an option in MPC as well to use system ICC profile with EVR, so it's not the feature of EVR per se but players have supported it for quite some time now.

Sent from my GM 5 Plus d using Tapatalk

[SEX]

There is a small program that comes with DisplayCAL, it's called 3D LUT maker, which can convert your ICC to MadVR LUT. It's right there on the program list in DisplayCAL section.


It creates a 3DLUT with standard profiles, but as soon as I open the profile of the monitor in it, gives an error

[mytbyte]

It creates a 3DLUT with standard profiles, but as soon as I open the profile of the monitor in it, gives an error

Where do you open the monitor profile, source or destination? I should be destination.

[Asmodian]

It creates a 3DLUT with standard profiles, but as soon as I open the profile of the monitor in it, gives an error

Yes, I have never gotten it to work with a profile created by anything but Argyllcms.

Unfortunately there are simply too many formats or types of ICC profiles and that tool doesn't support all of them. Proper handling of most ICC profiles is a big job. :(

[Ver Greeneyes]

creating a 3d lut takes easily 5 mins...
Firefox's qcms does it on the fly whenever it encounters an image with a new color space (albeit only with gfx.color_management.enablev4 set to true I think). The resolution is something like 30x30x30 though. I imagine madVR would want something a bit bigger, then use interpolation to get the full 256x256x256 and cache the result. Of course, that's assuming madshi has any interest in doing this :P I'm just saying it should be possible.

[huhn]

that's not my point it's just that it takes easily 5 mins for a 64³ a 256 takes well... easily hours.

[SEX]

Where do you open the monitor profile, source or destination? I should be destination.

Destination. Getting an error "not an ICC or .cal file"

[e-t172]

That doesn't support a lot of possible ICC profiles, I couldn't get it to work using ICC profiles created by X-rite's i1Profiler.

Yeah, that comes down to the fact that ArgyllCMS doesn't support ICCv4 :(

Personally I think it would be nice if madVR could load say LCMS as an external dll or something and generate its 3DLUTs on the fly from the monitor's ICC profile for each target color space. The resulting 3DLUTs (which could be cached somewhere) would presumably be of somewhat lower quality than using ArgyllCMS' collink, but I think it would significantly increase the number of people receiving color correction (even if they did still have to download LCMS separately due to licensing or whatever).

I've already made that exact suggestion to madshi 5 years ago (https://forum.doom9.org/showthread.php?p=1647443#post1647443), but I failed to convince him.

With modern HDR tech there is a new, additional reason to do this: if you generate the 3DLUT on the fly, you can fine-tune it according to the source metadata (especially things like source gamut and luminance metadata), something that's impossible to do with a static, pregenerated 3DLUT. I suspect this will become more and more useful in a world where we're moving away from static source colorspaces and towards dynamic metadata.

No. If I use the "Use Display ICC Color Gamut Correction" in the PotPlayer, then the colors match in the PotPlayer, but only for EVR, does not work for madVR

Perhaps PotPlayer is using their own custom presenter for EVR, in which they implemented ICC support themselves.

that's not my point it's just that it takes easily 5 mins for a 64³ a 256 takes well... easily hours.

That's only if you want a 256x256x256 3DLUT, though, which is grossly overkill. Virtually all color management software uses smaller 3DLUTs (64x64x64 or less), interpolating between points. There is no evidence that anyone can see the difference. In fact, the ArgyllCMS docs (colprof -q option) explicitly tell you *not* to generate an ICC profile with too many points, because otherwise you can end up with sudden "jumps" in the data (due to colorimeter error and stuff) that end up creating banding and generally being counter-productive. Sometimes better is the the enemy of good. Using smaller 3DLUTs would also make madVR start up faster (no need to load a 100 MB file) and would likely get rid of various bugs caused by the huge size of the 3DLUT (http://bugs.madshi.net/view.php?id=462). (madshi said (http://bugs.madshi.net/view.php?id=462#c2022) that he might consider giving the option of using smaller 3DLUTs.)

[SEX]

Perhaps PotPlayer is using their own custom presenter for EVR, in which they implemented ICC support themselves.


But how did the color correction work in the madVR before the 3DLUT appeared?

[e-t172]

It didn't :)

(Well, there was a time where madVR supported something called yCMS, which IIRC was just a rudimentary 3DLUT generator integrated into madVR directly. It had no ICC support either. You had to input your primaries/white point manually. Fun times.)

[mytbyte]

Perhaps PotPlayer is using their own custom presenter for EVR, in which they implemented ICC support themselves.



As well as MPC-HC (and MPC-BE consequently). It's available with the selection of EVR Custom presenter.

[nevcairiel]

With modern HDR tech there is a new, additional reason to do this: if you generate the 3DLUT on the fly, you can fine-tune it according to the source metadata (especially things like source gamut and luminance metadata), something that's impossible to do with a static, pregenerated 3DLUT. I suspect this will become more and more useful in a world where we're moving away from static source colorspaces and towards dynamic metadata.

Except that generating a madVR-style 3DLUT in any quality is actually a quite slow process and can take minutes in processing time, which makes "on the fly" not quite so snappy.

[e-t172]

Except that generating a madVR-style 3DLUT in any quality is actually a quite slow process and can take minutes in processing time, which makes "on the fly" not quite so snappy.

Considering that Photoshop and other image viewer software (e.g. web browsers) do such on-the-fly gamut mapping on a routine basis with no perceivable delay, I don't think that's an unsolvable problem.

[huhn]

sorry but the current 3D LUTs are not just slow for fun.

we are talking about to change a process from 5 mins to at most a couple of sec.

sorry to say this but web browser don't do this in an quality way comparable to the 3d LUT in madVR and most important no one said they do it with a 3D LUT at all.

just to make this clear what a web browser does with a ICC file when a video plays is just garbage in term of quality.

[Jong]

I posted this over at JRiver Media Center's forum (https://yabb.jriver.com/interact/index.php/topic,114516.0.html) because MC has some of it's own display mode switching code, but Nevcairiel thinks it's a pure MadVR question better suited to here.

I have an LG E6 and an HTPC with an Nvidia GTX1050 GPU (390.65 driver). In Nvidia control panel, if I select 2160p YCbCr 4:2:2 and tell MadVR I have a 10-bit capable display all works well for HDR video.

I noticed by accident that if I change Nvidia video mode to RGB 8-bit then when I play a 60Hz HDR test clip (eg. LG's "Chess") I was getting "sparkles", showing HDMI errors.

I noticed that MadVR was outputting 10-bit depth even when using RGB and 4K/60 RGB 10-bit is not allowed by HDMI 2.0. Hendrik/Nevcairiel told me that this was not necessarily wrong as MadVR can/should output 10-bit RGB regardless whether the driver is in YCbCr 4:2:2 or RGB mode and the driver will do any necessary conversion as requested in the driver and allowed by HDMI 2.0. I.e. the driver should convert to 4:2:2 10-bit or RGB 8-bit as necessary.

However, I also connected the PC via an Oppo 203, hoping to get more information on the video mode being used by the PC. Instead I found that MadVR used 8-bit mode when connected via the Oppo instead of 10-bit when connected direct.

Any thoughts on why MadVR behaves differently when the Oppo is in the chain, which 'seems' to keep the PC 'legal'?

[e-t172]

sorry but the current 3D LUTs are not just slow for fun.

we are talking about to change a process from 5 mins to at most a couple of sec.

sorry to say this but web browser don't do this in an quality way comparable to the 3d LUT in madVR and most important no one said they do it with a 3D LUT at all.

I don't know about web browsers, but software like Photoshop seems to be able to apply an ICC profile with no perceivable delay. And it would be pretty ludicrous to say that professional image editing software like Photoshop do this in subpar quality. In fact people using Photoshop probably care even more about color accuracy than videophiles.

As for "3DLUTs are not just slow for fun", well, it might be that programs like ArgyllCMS's collink command are slow because there is no perceived need to make them fast: people use it offline and very infrequently, no one cares a great deal about how long it takes. I suspect it would be possible to do it much faster with little loss in quality if one were to specifically optimize for that. (Does anyone know how long LittleCMS takes to generate a transform?)

just to make this clear what a web browser does with a ICC file when a video plays is just garbage in term of quality.

I don't think web browsers use ICC profiles for video, but they do support it (to some extent) for still images. (Although they support it in kind of a retarded way because they don't use the monitor ICC profile - they always use sRGB as the destination. But that's neither here nor there.)

[huhn]

first of all madVR it self doesn't send any image out of the graphics card at all. it a renderer it just send an image to the GPU driver that have to do with the rest.
so if the image send out of the GPU is 8 bit or 10 bit is a pure GPU driver thing.

the 10 bit setting has to be set up for each connected devices separately and is by default 8 bit so that's most likely everything that's happening here.

and the oppo needs 10 bit input support in the first place the specs of tis thing are not really clear...

[Jong]

first of all madVR it self doesn't send any image out of the graphics card at all. it a renderer it just send an image to the GPU driver that have to do with the rest.
so if the image send out of the GPU is 8 bit or 10 bit is a pure GPU driver thing.

the 10 bit setting has to be set up for each connected devices separately and is by default 8 bit so that's most likely everything that's happening here.

and the oppo needs 10 bit input support in the first place the specs of tis thing are not really clear...I guess this is aimed at me. Thanks for replying.

The Oppo definitely supports HDR10 on it's HDMI input. It's used quite regularly for this and, indeed, I tested it myself using 4:2:2, when the Oppo reports the PC outputting 4K/60 4:2:2 12-bit, as expected.

In RGB mode the Oppo reports 4K/60 RGB 8-bit, which again is good and as expected, given the limitations of HDMI 2.0.

What I don't understand is why, if MadVR is as removed from the display as suggested, MadVR reports in its HUD outputing 10-bit when connected direct (which seems to lead to the driver outputting an illegal video mode), yet MadVR reports outputing 8-bit via the Oppo and all remains "legal". It seems MadVR is more aware of the display chain than thought.

Edit: wait a minute I get what you are saying. Probably MadVR realises it has a different "display" connected, when the Oppo is in the chain and has defaulted to 8-bit. makes sense.

[huhn]

I don't know about web browsers, but software like Photoshop seems to be able to apply an ICC profile with no perceivable delay. And it would be pretty ludicrous to say that professional image editing software like Photoshop do this in subpar quality. In fact people using Photoshop probably care even more about color accuracy than videophiles.
ok let's assume PS is as flawless as you make it is here.
does PS have to color correct an image 60 times a sec or even more?
is the calculation PS uses done in a way it can be applied to a totally different image in a reasonable speed?

As for "3DLUTs are not just slow for fun", well, it might be that programs like ArgyllCMS's collink command are slow because there is no perceived need to make them fast: people use it offline and very infrequently, no one cares a great deal about how long it takes. I suspect it would be possible to do it much faster with little loss in quality if one were to specifically optimize for that.

i'm not going to blindly assume that it is so bad coded that it can be speed up by a magnetite of 1000 and most important the result is ~100 mb.
a 3d LUT takes so long to get a fast high quality color correction by using a huge amount of space and a huge amount of processing power for the creation of the LUT itself.

[e-t172]

ok let's assume PS is as flawless as you make it is here.
does PS have to color correct an image 60 times a sec or even more?
is the calculation PS uses done in a way it can be applied to a totally different image in a reasonable speed?

If you can color correct a single image, then it de facto means you can trivially generate a 3DLUT. It's super easy: just generate a single image containing all the source colors you care about, then color correct it. The resulting image is de facto your 3DLUT. It's as simple as that. If you have the transform to color correct a single image, then just generate a 3DLUT from that transform and then it's business as usual. Thus the "60 times a sec" that you're worried about is a non-issue. The hard part is generating the transform - once you have that, the rest is trivial.

(The reason why it's so simple is because the color of a destination pixel is only determined by the color of the source pixel - there is no other input, which is the very reason why you can use a LUT in the first place.)

i'm not going to blindly assume that it is so bad coded that it can be speed up by a magnetite of 1000 and most important the result is ~100 mb.
a 3d LUT takes so long to get a fast high quality color correction by using a huge amount of space and a huge amount of processing power for the creation of the LUT itself.

Again, the only reason why it's 100 MB is because madshi wrote the simplest possible 3DLUT code without support for interpolation, therefore users are forced to generate full 256x256x256 3DLUTs which are grossly overkill. If you can get away with using smaller 3DLUTs, just like all other color-managed software does, then I suspect it will be much faster. (A 64x64x64 16-bit 3DLUT is 1.5 MB.)

[Ver Greeneyes]

ok let's assume PS is as flawless as you make it is here.
does PS have to color correct an image 60 times a sec or even more?
is the calculation PS uses done in a way it can be applied to a totally different image in a reasonable speed?
I don't know about Photoshop, but like I said, Firefox does do this - it calculates a 3DLUT on the fly in a manner of milliseconds, then caches it (the system isn't perfect incidentally, various APIs interacting in ways that aren't ideal, so I'm not sure it can reuse the generated 3DLUT for all images with the same profile, but that's not a fundamental problem). Now I imagine Firefox cuts corners to do this, and they replaced LCMS with the in-house qcms because LCMS wasn't fast enough - but if madVR has to spend say half a second to generate a 3DLUT, then caches it for every video with a matching color space, I think that would be fine.

[nevcairiel]

Again, the only reason why it's 100 MB is because madshi wrote the simplest possible 3DLUT code without support for interpolation, therefore users are forced to generate full 256x256x256 3DLUTs which are grossly overkill. If you can get away with using smaller 3DLUTs, just like all other color-managed software does, then I suspect it will be much faster. (A 64x64x64 16-bit 3DLUT is 1.5 MB.)

The reason the 3DLUT is so large is specifically to front-load the processing requirement, and not have to do it for every single video frame. Thats the entire purpose of such a LUT in first place - solve complex math once.

Photoshop for example isn't going to care if displaying a single image takes 100ms of color processing, its not in any area a user is going to notice. Video playback does care, hence entirely different requirements.

[huhn]

If you can color correct a single image, then it de facto means you can trivially generate a 3DLUT. It's super easy: just generate an image containing all the source colors you care about, then color correct it. The resulting image is de facto your 3DLUT. It's as simple as that. If you have the transform to color correct a single image, then just generate a 3DLUT from that transform and then it's business as usual. Thus the "60 times a sec" that you're worried about is a non-issue. The hard part is generating the transform - once you have that, the rest is trivial.

(The reason why it's so simple is because the color of a destination pixel is only determined by the color of the source pixel - there is no other input, which is the very reason why you can use a LUT in the first place.)
and who said that the image has all possible colors and who said PS is saving it for all possible colors?

Again, the only reason why it's 100 MB is because madshi wrote the simplest possible 3DLUT code without support for interpolation, therefore users are forced to generate full 256x256x256 3DLUTs which are grossly overkill. If you can get away with using smaller 3DLUTs, just like all other color-managed software does, then I suspect it will be much faster. (A 64x64x64 16-bit 3DLUT is 1.5 MB.)

the 256³ LUT is interpolated from a 64³ with default settings. so you want to make it faster by skipping the interpolation which is suspected to be slow to be done later in realtime?

[e-t172]

The reason the 3DLUT is so large is specifically to front-load the processing requirement, and not have to do it for every single video frame. Thats the entire purpose of such a LUT in first place - solve complex math once.

If your 3DLUT is smaller than full size (say, 64x64x64 instead of 256x256x256), then the only "complex math" you need to do in real time is interpolation between the 3DLUT points, such as basic bilinear or bicubic interpolation. Which is laughably trivial for a GPU to do, and something that I'm sure madshi would be able to do in his sleep.

You don't even need to use a fancy upscaling algorithm for that - no one is going to notice the difference. (Keep in mind that the color response of any reasonable monitor is at least somewhat linear, so basic interpolation is highly likely to land very close to the correct point. And in fact, you really don't want to get too fancy, because a response that's not smooth will result in banding artefacts. Which is why ArgyllCMS docs warn you against generating a transform that's trying to be too precise.)

and who said that the image has all possible colors and who said PS is saving it for all possible colors?

It is trivial to generate an image that has all possible colors. In fact, a full 3DLUT is, itself, by definition, an image that has all possible colors. You just need to deal with that once (not for every frame), and then you're done. In practice though, you would use sampling (only generate an image with a subset of all possible colors, such as 64³) and then interpolate, as described above.

the 256³ LUT is interpolated from a 64³ with default settings. so you want to make it faster by skipping the interpolation which is suspected to be slow to be done later in realtime?

Huh? I didn't know that madVR could interpolate from a 64³ 3DLUT. I've always used a 256³ 100 MB 3DLUT (256x256x256 x 3 colors x 16-bit = ~100 MB). Maybe I've missed that option.

In any case, yes, I'm saying that 3DLUT interpolation can, and should, be done in real-time. That's completely trivial and can be done extremely quickly. (Just like video upscaling, except you can get away with very basic interpolation.) Interpolating a large 3DLUT from a small one is not hard nor expensive. It's generating the initial transform that's the hardest part. Everything else after that is peanuts.

[Ver Greeneyes]

Huh? I didn't know that madVR could interpolate from a 64³ 3DLUT. I've always used a 256³ 100 MB 3DLUT (256x256x256 x 3 colors x 16-bit = ~100 MB). Maybe I've missed that option.

I think what huhn is referring to here is the processing in collink - collink generates a 3DLUT of a lower resolution (determined by the quality setting) then interpolates it to 256x256x256 to produce a file compatible with madVR. But you can override the resolution using -r256 to make it produce a 256³ 3DLUT directly without interpolation (which obviously takes a while).