Jump to content
Jursdotme

LUT Export not working

Recommended Posts

If this is a limited scope of work and you need the LUTs to work in a timely manner, you can send me the LUTs to fix them. It's just a matter of fixing the reading order of the channels. Something Affinity's LUT tool once was capable of on its own. Now that it can't do that anymore, export is broken as well.

Share this post


Link to post
Share on other sites

If this is a limited scope of work and you need the LUTs to work in a timely manner, you can send me the LUTs to fix them. It's just a matter of fixing the reading order of the channels. Something Affinity's LUT tool once was capable of on its own. Now that it can't do that anymore, export is broken as well.

Thank you, i appreciate the help. I have workarounds that i use for the time being but when the functionality is there, but broken for the last 2 releases one gets a little frustrated.  :huh:

Share this post


Link to post
Share on other sites

The official line was because it was unpredictable to know if a LUT was 3D or 1D or both and so the new engine didn't have that. It never made any sense since 3D LUTs start with "LUT_3D_SIZE" while 1D LUTs start with "LUT_1D_SIZE". Shaper LUTs are designated by both lines being present. Basically, if you can interpret a LUT you know what it is.

Share this post


Link to post
Share on other sites

LUT EXPORT MALFUNCTION

When making a LUT the colours change when it's imported.

The colours are inverted and they look wrong. This happens in Affinity Photo or when used in a LUT facility inside FCP X. 

Share this post


Link to post
Share on other sites

LUT EXPORT MALFUNCTION

When making a LUT the colours change when it's imported.

The colours are inverted and they look wrong. This happens in Affinity Photo or when used in a LUT facility inside FCP X. 

I have this exact problem also.

 

I was wondering if there was something I could do about it, but I guess no. 3dl-files seem to work well though, while they can't be imported to Final Cut Pro X (not with my LUT-loaders anyway).

 

Would be great to hear if there's a fix to this!

 

Thanks,

Share this post


Link to post
Share on other sites

I have this exact problem also.

 

I was wondering if there was something I could do about it, but I guess no. 3dl-files seem to work well though, while they can't be imported to Final Cut Pro X (not with my LUT-loaders anyway).

 

Would be great to hear if there's a fix to this!

 

Thanks,

A fix would be great. Sadly the turnaround on bugfixing for Affinity is measured in months or years. I started this thread in January... :-(

 

I guess fixing bugs isn't as fun as making new features and iPad apps. Luring in new customers is clearly higher on the agenda than catering to existing ones.

Share this post


Link to post
Share on other sites

Hello,

what exactly means write order of the RGB channels?

Is it for example BGR instead RGB in all lines of the LUT-file? I tested this with a simple REGEX search/replace in BBEdit and changed RGB values to BGR (column 123 to 321). But that gave me not the wished result.

 

Could you tell me, what has to be changed, then I could write a shell script for easy converting?

Share this post


Link to post
Share on other sites

The bug is: Incorrect write order of the RGB channels.

If you have LUTs that you need fixed and can't wait for Affinity to be fixed, I can fix the LUTs for you.

Thats not really the point. The point is that what seems to be a relatively minor bug that has broken an entire section of the software is being ignored in favour of new niche features...

 

And the funny thing is that there once was a function in the tool to rearrange the channels on import. This feature was removed in the same update that the bug was introduced in...

Share this post


Link to post
Share on other sites

I know. It's a shame that it got removed. Also made for interesting creative uses.

 

Thats not really the point. The point is that what seems to be a relatively minor bug that has broken an entire section of the software is being ignored in favour of new niche features...

 

And the funny thing is that there once was a function in the tool to rearrange the channels on import. This feature was removed in the same update that the bug was introduced in...

Share this post


Link to post
Share on other sites

Hello,

what exactly means write order of the RGB channels?

Is it for example BGR instead RGB in all lines of the LUT-file? I tested this with a simple REGEX search/replace in BBEdit and changed RGB values to BGR (column 123 to 321). But that gave me not the wished result.

 

Could you tell me, what has to be changed, then I could write a shell script for easy converting?

 

It's the leading read order of the RGB channels that swaps the colours. Which means you need to do a colour transform as the values in the LUT just tell you what points go where for which channel. You were right about BGR vs RGB. It just works a little differently. I attached you two LUTs that do nothing, a normal one and one from Affinity so you know what the output of your script should be.

 

You can mimic it with the channel mixer. Set RED to red 0%, blue 100%, BLUE to red 100%, blue 0% and you'll get what the bug is doing.

Affinity LUT vs Working LUT.zip

Share this post


Link to post
Share on other sites

Thank you for the files and the explanation.

 

As I assumed, only the RED and BLUE channels are toggled. I checked my REGEX again and saw the error I made in the first try.

 

I did a lot of tests, all is o.k., when I import the corrected .cube LUT in Affinity and compare it with the original adjustments.

An additional test in Final Cut Pro with mLut was also successful.

 

 

So here is my solution for all, who are interested:

 

1) open the wrong xy.cube from Affinity in a Text Editor with Regular Expression  capability (BBEdit, Text Mate, …)

 

2) search this regex:

^([0-9\.-]+) ([0-9\.-]+) ([0-9\.-]+)$

3) replace all with (BBEdit):

\3 \2 \1

or (Text Mate):

$3 $2 $1

Thats all!

 

Save and you're done.

 

 

Additionally here's a small bash-script as an alternative to the Editors:

#!/bin/bash

sed -E 's/^([0-9\.-]+) ([0-9\.-]+) ([0-9\.-]+)$/\3 \2 \1/' "$1" > "$2"

exit 0 # script end

Save as script file: xy.sh

Make it executable in Terminal in pwd: chmod +x xy.sh

 

Start the script in Terminal in pwd: ./xy.sh "path1" "path2"

Parameter 1: path to wrong xy.cube

Parameter 2: path to corrected .cube

Share this post


Link to post
Share on other sites

Hmmm. It seems that this is still broken. 

Joachims script did not do the trick for me :( 

Anyone any idea how to fix this? 

Also i find that for me almost any other adjustment layer seems to work. Just white balance messes up.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×