This doesn't correct the problem at all (Placing LUTs in wrong directory issue)

[Nicol Craig]

This doesn't correct the problem at all. I have just tested this method three times and the same problem persists. I have opened a previous project from two years ago, client wants a simple change, but now the LUT that it was referencing is in the incorrect place and therefore a five minute job now has become a whole day re-colour job. (who can remember which LUT they used two years ago?)

Francis, I tried your method of putting LUTs into the /Common/ folder within the library preferences however the same issue applies. PPro will read the LUTs from there, great, however it will still affect the LUT order and therefore change the LUT that Lumetri references.

This is quite frankly unacceptable.

Unless I am missing something?

The only workaround I can see is to rename all custom LUTs so they have a "z" before them to make sure they come after the order of the LUTs provided with the default software.

But I wish I knew this for the last couple of years. Every single project I might need to go back to will need fixing because of this.

Seriously this is just a rubbish way of dealing with this, just return the reference paths to absolute (named) paths again and this issue will go away.

Seriously thinking about moving to resolve as main editing program.

[R Neil Haugen]

Double post. I answered in the other thread.

I will just note here that in two years of using the specified correct process, through multiple app version changes and many LUT additions and removals, I haven't had a single issue of mis-referenced LUTs.

It works when done correctly.

Neil

[R Neil Haugen]

First thing ... looking at my last posts, I was responding quickly from my phone, and they come across as rather curt. My apologies ... as I do fully understand your frustrations. And concerns.

Thinking a bit more, as far as the issue you have of the change in what's applied if you move the LUTs out of the Program folder.

If you use one of the included LUTs from the internal list, and ... then remove the added LUTs including something in front of that included LUT ... yea, in that case, it would change the order and therefore which LUT it would use. Which ... is just a nasty thing to work with. No question about that.

When they started the LUTs thing in Lumetri, naturally I added my home-rolled ones into the Program files package, and was ticked when they changed the operation. I still don't get the reason for  the relative-linking they chose to use rather than an absolute-link, but it ain't gonna change.

But I quickly got to the location and started using it, and ... with a linked icon for the proper folders on my desktop ... managing my LUTs as I add them and then delete them works easily.

And has continued to work perfectly over what ... 10, 12 version updates/upgrades since then? So the system does work.

And I do understand the frustration and pain if you've been using the program folders all this time and need to change.

Neil

[Nicol Craig]

Thanks for your response. I have responded on the other thread however I've got another question here if that's alright.

When you say "But I quickly got to the location and started using it..." are you referring to /library/applicationsupport/adobe/common/LUTs ? Or do you mean you have a separate folder/location that you use for custom LUTs?

Does the new folder also reference order instead of name? i.e do I have to keep an eye on the order of LUTs in the new folder going forward if I have projects that reference LUTs from this new location?