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.
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].
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.
Aw, it is dead easy to remove the negative values from the .cube (which is a simple text file) – but I wonder why they were created in the first place, and wether they really should be 0.000… values, or what?
Ping @phweyland?
/Claes
I have no solution I’m afraid.
About the lut3d module itself.
A cube transformation transforms any triplet of values belonging to [0,1] to something else.
The image input values are clamped to [0,1], this is first source of distortion.
Since the last lut3d change, accepting cube values outside [0,1], the image output values can also be outside [0,1] (which wasn’t the case before the change). The destiny of those relies on the capacity of subsequent modules (and color spaces) to accept or not out of range values… There is no guarantee here I’m afraid.
I don’t know how 3D lut creator works, but the generated LUT depends on the image input bounds. There is may be a way to normalize them before calculating the lut … Or at least to match some input conditions / constraints … For what I know there is no out of range values in the distributed luts.
About the export, there is another issue (as you say that the images look good on the screen). Do you have any meaningful message ? Can you try to launch dt from the console the option -d all, capture the log into a file and share it ?