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].
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].
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.
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.
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.
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.
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?
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 ?