@PhilipB the bottom chunk of your .cube file consists of a very large base64 encoded part.
Wonder who/what put it there?
The file has negative values in the table, is that normal?
The number of lines seems to be correct (262,144)
The blob is indeed strange but as each line are commented that should not be a problem.
The negative values are incorrect but this is not what the error message says. A value above 1.0 is also visible here below. This is incorrect too. At least the module is designed for values belonging to [0,1].
I’ll try to understand what happens.
Sorry guys, i dont have great answers for you. I dont know about LUTs on the tech level you are discussing them. Just how to make/apply them.
This LUT was generated by 3D LUT creator. A matrix + curves correction baked to the LUT.
Ill try some more testing tonight.
Removing negative values (just removing the ‘-’) solves the issue.
Then the only issue here is not to get the right error message.
1 Like
The module calculation accepts values which are out of range [0,1].
I’ll issue a PR (#4657) where those values are accepted. Only a warning message will be shown, something like:
[lut3d] warning - 18267 out of range [0,1] values
Then the output of the module may itself be out of range (which is not always an issue depending on the following module).
Please also remember that the input image values are clipped inside [0,1].
1 Like
So does that mean there is something I can do currently to get these .cube LUTs working in Dark table?
With the current version, only LUT with values in range [0,1] work.
Normally the fix will come with dt 3.2, maybe with 3.0.2 if @Pascal_Obry thinks that’s ok.
Okay, well ill look forward to it in an upcoming release (3.0.2. hopefully… 
)
Thanks for looking at the issue.
Resolved in 3.0.2.
Thanks!!!
May have spoken too soon… now on exporting images (50 in this bunch), i get a similar error. Then only a few of the images actual export, and the border of the DT window starts flashing and I get a could not export file error. A few times DT had to be restarted. After trying a number of times still can’t get them all to export without the process mysteriously stopping. I try again and some of the files export, it doesn’t seem to choke on a particular image. Just seems to randomly stop working.
More problems associated with this issue… now sometimes the exported TIF’s dont match the edited raw.
They look much lighter, like there is a gamma issue or something.
Morning, @PhilipB,
Did you investigate the error msg you got?
cube lut 3132 out of range values [0,1]
Have fun!
Claes in Lund, Sweden
I wouldn’t know how to go about doing that…
What should I look at?
a) From where did you obtain that cube?
b) Make a copy of that cube, change the name of the copy to xxx.cube.txt
and send it to me (i.e. drag it into your reply), so I can have a look with my own fingers 
The LUT was generated using 3d LUT creator. It’s a utility kind of LUT to match perfectly the luminosity and colour of a color checker from a reference photo.
Ill attach it here as requested.
D80_8847 DT.cube.txt (7.3 MB)
Thanks for taking a look! PS. The LUT works perfectly in terms of getting the desired result on the screen.
Got it thanks.
BTW: are you on Linux, Win, or what?
Sorry, i should have caught that one…
Windows 10
Sigh. I doubt that you will be any wiser from this answer, but…
a) You do have several negative values in the .cube
b) So darktable correctly issues warnings
c) but that does not explain why your exports sometimes do not match the edited RAW (here I take for granted that you have used the same .cube in them all???).
Suggestion in order to pinpoint problem: please test using a .cube that does not contain any neg values.
Have fun!
Claes in Lund, Sweden
Yes, same .cube for all. But with slightly different adjustments to the LAB luminosity curve.
The LUT are generated by the software to provide a particular solution. Im not sure how i can address the negative values. Also, the LUTs appear to work in terms of providing the correct transformation.