The amount of physical RAM is not the issue.
It is the memory allocation, as managed by the OS for whatever programs are running (in the background, etc.).
Any modern PC with about 4G+ would normally be ok.
Potentially the paging file size may need increasing, as well as setting more CPU and RAM resources.
You can potentially also prioritize the ColourSpace Application via Task Manager.
As well as stopping other programs opening on start-up, etc.

But VMs tend to provide much smaller allocations, and tend to run way slower.

Steve

Update: I was able to get my M1 Mac to generate 256^3 LUTs using VMware by increasing the VM's allocated resources.

Steve

I don't really understand the suggestion to test this on a madVR HTPC when an Envy is in use.
In my Parallels VM I've now allocated 6 CPU cores and 24 GB of RAM. Generating the 256³ LUT now takes 45 minutes just to crash at the very end, and the upload to the Envy still doesn't work.

I also don't see any real benefit in the generation of the 256^3 LUT. It would be much more sensible—especially for users who aren't running monster-spec systems or a VM—to be able to choose directly in the UI whether to upload a 65³ or a 256³ LUT. Having to rely on environment variables for this is anything but user-friendly.

And to be clear: this isn't user error. The bottleneck here is the extremely high hardware demand on the ColourSpace side for such high LUT sizes.

The suggestion to test madVTR HTPC (actually just madTPG, as that is all that's needed to test LUT Upload) is because we know that works, so would help isolate any issue with Envy.

But, up to you if you don't want to bother.

However, with your PC (VM) not being able to generate 256^3 LUTs it is not a relevant test anyway, as you would not be able to upload the LUT due to the PC (VM) resources issues you have.

As said above, setting decent VM resource allocations On my M1 Mac using VMware enables 256^3 LUT generation.

Steve

Another update.
I can generate 256^3 LUTs on my Surface Laptop 3.
And that is not a monster spec PC at all.
And the LUT generation takes approx. 10 minutes.

Mind you, it's borderline as sometimes it will crash so I guess it does depend on any other BG processes running.
(Edit: yes, with decent Paging File size set, and no other programs running, 256^3 LUT generation works every time.)

The M1 Mac doesn't crash.

Steve

Christian will test that as well I send him my profile and maybe we can see some others as well.

I won't buy a Windows laptop to use 256^3 LUT size which has no visual benefits.

As my M1 Mac now has no issues maybe you just need to talk to Parallels support to get better resource settings suggestions?

But, if you are happy with 65^3 LUTs just stick with that.

The madVR upload is an Env. Variable as it is a set once option. If your PC can't do 256^3 LUTs you would never change it from 65, unless the PC hardware was changed.

Steve

Fabio profile crashed CS on my 16Gb RAM laptop. It was on battery, only app running.
Although 16gb should be more than enough I guess.

As said, the physical RAM is not the issue.
I've added more info HERE.

Steve

Good morning everyone, the 256 LUT with MadVR Envy with Peak Chroma did not work, blocking just before the end and after 4:15 hours, I got in touch by phone with Enrico (erb999) for an hour trying various options! Map Space worked at 256 but loading blocked at 80% with loading error written but saving the LUT in the slot! Unfortunately I downgraded to Colourspace 22.36, it no longer loads the LUTs correctly, even the smaller LUTs like 33! My Colourspace is HTP

If you cannot generate/upload a 256^3 LUT see the info as above and linked to again HERE.
Basically your PC lacks the required resources.
As for your issue doing back to v2236, that is something else totally, and it would seem you have just got a bad workflow/configuration.
(You do NOT need to go back to an older ColourSpace version - just set the Env. Variable to as per the provided User Guide instructions.)

Oh - and madVR never loads 33^3 LUTs - they are always 65^3 or 256^3 - no other sizes.
Any other size LUT is upscaled by ColourSpace on Upload, and if you used 65^3 it is again upscaled within madVR to 256^3.

Steve

Gian luca

That's exactly the same behavior I'm seeing. It has nothing to do with the LUT that's being generated — the very same thing happens when trying to upload a Unity LUT. It aborts at 80% every single time.

Since you're experiencing the identical issue, I'd appreciate it if "User error" could be removed from the thread title. This clearly points to a problem with the newly implemented LUT upload function itself, not user error.

For context: I've assigned my Parallels VM 32 GB RAM and 6 CPU cores, yet I still can't successfully generate a Peak Chroma LUT. In any case, I don't see a practical advantage for my workflow, so I'll stick with 65^3 and the Windows ENV workaround for now. That said, the LUT generation performance should be improved, and the 80% upload failure needs investigation — it's obviously not "user error" if two people are independently hitting the same issue.

No - it is still user error, as you are attempting a process your PC doesn't have the resources for.
You provided your Profile to me and I've shown you it works on my PCs, but not my M1 Mac due to the profile being, well, basically crap.
(That is the technical term for such a profile...)

But, any PC with enough resource capability works fine, as I have proven to you via our email discussion.

The 80% value is exactly the same as the end of a LUT Generation, as the remaining 20% is allocated to the actual data upload, so the issue is at exactly the same point for LUT Generation or LUT Upload.

Steve

I'll consider changing my PC soon! Who should I contact, or is there a procedure for changing my PC?

It also fails with a Unity LUT, as I already mentioned — so this has nothing to do with a "crap" profile.

I also explained how much horsepower I've allocated to the VM, which should be more than sufficient and well above the requirements you recommended — and it still doesn't work.

Either way, I'm sticking with my point: this feature offers no real benefit (at least in my view) and, for me and others, it simply doesn't seem to work. Three users, the same issue three times. And yes, it may have worked on your machine — but unfortunately that doesn't help me.