As you presently cannot export a 256^3 LUT that could be a useful bit of information.
It likely means the LUT has some form of distortion that is below the granularity of the exported LUT, so the distortion is removed with the export.
So you will need to test with different profiles, as it may be a profile error causing the LUT issue.
But impossible to tell without the actual profile.

Should be easy to test using a synthetic profile such as a DCI P3 one used to generate a Rec709 LUT.
(Must be a profile, such as using the Virtual Probe, and not a colour space to colour space LUT.)

Edit: Oh - and obviously if there is an issue with the LUT you will see that when using LUT Preview on different images.

Steve

I've spoken to Mathias have he still cannot replicate the issue using ColourSpace.
He can only see an issue when you send the internal Envy data LUT to him, which is useless for any testing.
Provide the profile you are using as well as the ColourSpace and Envy configurations.

Steve

Quick update from my side — madshi has identified two separate issues behind the ColourSpace → Envy 256³ (1D1+3D) upload problems, and with the new Envy build + updated DLL I can confirm the issue is resolved on my system.

What was going on (two independent problems)

1) 32-bit memory limitation in ColourSpace network DLL

ColourSpace is a 32-bit application, so it uses madHcNet32.dll. A 256³ 3D LUT is very memory-heavy, and madshi found cases where the 32-bit DLL ran out of address space.
Result: the 3D LUT could arrive empty/invalid, while the 1D LUT still contained meaningful data. That also explains why the issue was hard to reproduce consistently across different PCs.

2) Near-black "non-monotonic" values + PC→TV level conversion/extrapolation

The actual visible color artifacts were traced to the combination of:
· ColourSpace sending PC-level LUTs (black at 0,0,0), while
· Envy internally works in TV levels (black at 16,16,16), therefore Envy must convert the LUT and extrapolate values for 0..15.

madshi found that some ColourSpace-generated 256³ 3D LUTs contained near-black inversions (example: output at 0,0,0 slightly brighter than 0,0,1).
That makes the Envy's required 0..15 extrapolation unstable, producing the artifacts we were seeing near black (pink borders / distortions).

He addressed this on the Envy side in a new build, so the conversion/extrapolation no longer breaks even if the incoming LUT has these near-black irregularities.

Current status (confirmed)

With:
· the new Envy build (2.0.3.30) and
· the updated madHcNet32.dll provided by madshi,

I can now reliably upload a 256³ 1D1+3D LUT with ColourSpace connected as madVR Envy, and I'm seeing no artifacts anymore (tested repeatedly).

Critical questions for the workflow / responsibility

This is where I'd really like your input, because it impacts "best practice" guidance:
1. Why does ColourSpace sometimes generate non-monotonic near-black values in 256³ 3D LUTs?
· Is this expected behavior under certain profiling / smoothing / fitting settings?
· Could it be a rounding / quantization effect in the "live send" pipeline vs export/import?
(Notably, 65³ doesn't show this, likely due to coarser spacing.)
2. Should Envy be expected to accept a PC-level LUT directly from ColourSpace and convert it internally?
· Or should the "correct" workflow be: scale the LUT in ColourSpace LUT Tools from 0–255 to 16–235 before loading for a TV-level pipeline?
3. Why did the issue not appear via madVR HTPC connection?
Because there was no PC→TV extrapolation step there — which suggests the HTPC path may be "safe" visually, but could also mean it's technically mismatched unless users manually scale levels.
4. Would it make sense for ColourSpace to optionally offer a "TV-level send" mode (16–235) when targeting Envy / video-level devices?
That could remove the need for extrapolation entirely and avoid edge cases in 0..15.

I'm happy to provide additional captures / example LUTs if needed, but the key point is: this wasn't "one bug" — it was (A) a 32-bit memory edge case plus (B) near-black LUT behavior interacting with level conversion.

Thanks again to madshi for the quick fixes — now it would be great to clarify the recommended, correct pipeline so users don't unknowingly run a level-mismatched workflow.

Thanks for your information, I'll wait to upload the 3dlut until everything is clearer and more automatic! Let's hope the 64-bit version of colourSpace coming soon.

BlackJoker

It is very good madVR Labs have fixed the Envy issues.

And those are madVR Envy issues.
Mathias has confirmed he was trying to allocate too much memory to the madVR dll.
And having non-monotonic data in a LUT is perfectly valid and should not cause any issues with any LUT application.

For information, non-monotonic LUT data can be due to two main reasons, both due to the profile data containing measurements that require non-monotonic corrections.
First, from probe readings when the granularity of the profiling is too fine, and either the displays or probe are unstable.
Or second due to the display actually being non-monotonic, as can indeed be the case with some display technologies.
And ColourSpace never applies any fitting/filtering/smoothing - it is not Calman.

ColourSpace will therefore always generate a LUT that has non-monotonic data with such profiles, as that is the correct thing to do.
There are no issues with ColourSpace LUTs in such situations.

And as for LUT range/level conversions, that is nothing to do with ColourSpace.
That is entirely down to the LUT system signal path workflow.

Gian Luca
Having a 64-bit version of ColourSpace will change nothing with respect to any of this.

Steve

As follow-up information, madVR has two distinct workflows, as the madVR User Guide states.

madVR HTP: Any LUT will likely need to have a ColourSpace Video Scale applied before uploading, as madVR HTPC only works with Video Range signals.
(At least that is how it has always been, unless the madVR HTPC restriction has been changed.)
madVR Envy: As Envy can work with Video and/or Data range signals the LUT should be uploaded unscaled, and Envy should then manage the range requirement based on the input video signal.

Steve

And yet another follow-up.
Mathias provided Fabio's profile that caused the issue for madVR Envy.
As can be seen, ColourSpace was doing exactly what was asked of it based on the profile data...
The way madVR Envy was handling the non-monotonic data was the issue.

Steve

Edit: I originally posted graphs from a different Fabio profile with similar non-monotonic data.
This is the correct graph from the profile Fabio provided to MadVR Labs.

Non-monotonic Profile

Envy Firmware 2.0.3.40 ist available.

- improved displayport support
- fixed slow handshakes with hdmi 2.0 gpus
- fixed various ip control issues
- fixed colourspace issue
- fixed apple tv menu presentation glitch

I hope that my LUTs are now working. The upload has now been successful. However, the calibration did not produce good results. There were always shifts, especially with red and green.

As they are all Envy firmware changes you will need to ask madVR...

Steve

Chris1964
I can't confirm that on my side. In fact, with the current workflow I'm now achieving even better results than before.

After the successful upload, my LUTs are tracking very cleanly — no systematic red/green shifts and no unexpected hue rotations. Especially with the adjusted LUT handling and correct sizing, the behaviour is now significantly more stable and predictable than in earlier builds.

Steve adding the LUT size option to the GUI — as I had suggested — was absolutely the right decision. Having explicit control over LUT size removes ambiguity in the pipeline and prevents user errors. From a calibration perspective, that change was important and clearly beneficial.

If red/green shifts are still visible on your end, I would look at:
· LUT size vs. cube resolution consistency (65³ vs 256³)
· Any pre-existing 1D calibration interaction
· processing algorithm used during LUT generation
· Possible noise or inversion artefacts in the source profile

On my side, with the current structure (clean profiling, correct LUT size selection, and controlled processing), the results are excellent.

Let me know your exact LUT size and generation settings — I'm happy to take a closer look.

I wanted to share a quick update on the results I'm currently achieving with the latest firmware and the recent ColourSpace update.

After updating both the Envy Firmware and ColourSpace, I'm now seeing consistently excellent and much more stable measurements on my VisionMaster Max workflow. Just as importantly, the monochrom issue I was dealing with is now gone. That alone has made the overall process feel much more reliable and predictable.

I also updated my ADMESY colorimeter to the latest state, which appears to have contributed to the improved stability as well.
What stands out most is how clean and controlled the final result now looks:

- RGB Balance: Extremely tight. The grayscale tracking is very stable, with only minimal deviations and no concerning drift. The channels stay closely aligned across the range, which is exactly what I was hoping to see.
- EOTF Tracking: Very accurate overall. Tracking is impressively close to target, with only tiny deviations in a few areas. The curve looks smooth and well behaved, which gives me much more confidence in repeatability.
- dE Performance: The most impressive part is the verification result — I'm getting a dE2000 average of just 0.54 across more than 1000 measured points. For this kind of volumetric verification, that is an excellent result and clearly shows how well the current firmware + ColourSpace combination is performing.

The screenshots really reflect that:
- grayscale and RGB tracking are highly controlled,
- EOTF is tracking very cleanly,
- and the 3D verification result is outstanding for such a dense measurement set.









At this point, I can say that the latest updates have made a very noticeable positive difference in my workflow. Measurement stability is better, repeatability is better, and the final LUT verification is stronger than before.

So from my side: the latest firmware together with the ColourSpace update is delivering excellent results, and I'm very happy with where things are now.

There are some very obvious issues there that are not related to madVR or ColourSpace.
Either the probe or the display is unstable, and the granularity of the profile shows this.
If the issues are consistent in repeated verifications of the calibration, meaning the original profile used to generate the LUT has invalid measurements, they will manifest as image artefacts, specifically banding.
If the issues are inconsistent across multiple verifications, the display/probe instability is an inherent underlying issue,

But this is a good example as to why using more profile points is not always better, especially when the probe/display is unstable.

Steve