I’m afraid I’ll go on vacation very soon and probably won’t have time to find the offending pictures. Strangely, they didn’t consistently send the alignment optimizer into an infinite loop. Only sometimes.
Lens correction applied? I used Canon EF 35-80 Power Zoom. my darktable has lens correction for that lens but Canon doesn’t, so the JPEG files are without lens correction.
Edit: Nevermind, I read --help and turned it off.
The photos I took today. Feel free to try. I didn’t get any decent result from them. Maybe less is more and I should just try the color checker with different exposures?
Interesting, I’ll look into it when the download is finished!
New Version is released; image alignment is now optional and more robust (working well with your image pair).
1 Like
Okay, I’ve taken a look at the dataset:
Alignment works significantly better with the new version, but still struggles in some cases:
In particular, the images of the spectrum projected on a wooden surface are problematic.
The reason is that the utilized method performs direct alignment by optimizing the transformation parameters so that a specific measure of pixel-wise similarity between the images is maximized.
Compared with feature based methods, this one has the advantage of being very precise on a (sub-) pixel level and of also working with very smooth images that don’t have detectable features.
However, it is more sensitive than feature methods to differences in gradiation and exposure between both images.
Here, the difference in rendition between the exported raw and ooc image can lead to problems.
When trying different approaches out, I found that the currently used algorithm performs best for most images, but there is always a trade-off.
Of course, it is possible to get the alignment working for almost all images, but this would require much effort in algorithm selection and tuning, so that I consider this out of scope for this little project 
I guess it is best to just disable the alignment if some images in the sample set are problematic…
Edit: But yes, the lut generated with your dataset is inaccurate…
The problem seems to originate from the raw image export from darktable: If I open the raw image in darktable and apply the style manually, everything is fine. But the export from command line has strange white balance…
3 Likes
So, I have no idea what’s going on.
I’m now just experimenting with the image pair _MG_7210.CR2 from peter’s set.
The script develops the raw with darktable-cli from command line.
However, although the same color science settings and scene-referred default pipeline is configured,
the image exported from the shell command sometimes/often differs from the output with the same style applied manually and sometimes even differs from the image shown in darktable with the style applied if darktable is invoked with the args of the shell command after --core, so that config dir and hence configuration should be identical.
Everyone who wants to experiment with this, too, is welcome…
If I try the generated LUT out on the developed raw image from the shell command, the result is visually identical to the OOC jpeg. So in principle, everything works fine except the flawed darktable export.
Would xmp that you used before work better than with style?
Okay, got it now by not using styles or xmp, but have none configured for the standard pixel pipeline.
User supplied styles via the corresponding argument may still run into issues with the darktable export, though…
New version is released.
For your dataset, alignment is definitely important for getting the gradiation right, as small mismatched features in the outer image regions have some impact. I excluded the images of the spectrum projection where the alignment struggled and obtained pretty good results!
The following arguments were used:
--resize
1000
--level
3
--n_samples
100000
--disable_lens_correction
--sample_uniform
test_peter.cube.zip (12.3 KB)
Nice work!
I’ve played around a bit more. Alignment is much more robust with the recently released version and default parameters should already yield quite good results.
2 Likes
Hello.
I am a darktable user and I wanted to use the original profile of my camera, so thank you for making a great tool.
I tried to use it right away, but I could not get it to work because of an error. I am not familiar with the program.
I would appreciate it if you could tell me how to get rid of the error and make it work.
Hi!
Seems that darktable-cli (the command line version of darktable is not in your path.
I guess you’ll get a similar error when just typing darktable-cli in the terminal?
To be honest, I don’t know how to install darktable-cli on MacOS; is it bundled wit darktable like on linux?
If you know where the darktable-cli executable is located, you can pass the location with the according argument (see --help) to darktable lut creator.
Thank you for your reply.
I tried to install Linux using UTM since you said it is difficult on Mac.
Then I tried to install and run it as per the instructions, but it showed “command not found” and could not run.
I see darktable-lut-generator in the list of installed packages, but…
I’ve done a lot of research, but I’ve never worked with linux before, so I’m at a loss.
I would appreciate it if you could help me.
Thank you in advance.
What if you run it from the installation folder? .local/bin
Meanwhile, if you want we can run the raw files and JPEG files for you if you upload them.
Konnichiwa, @kusomisotechnique,
I do not know if it is significant here, but you seem to install
darktable-lut-generator
but you seem to try to execute it as
darktable_lut_generator
???
Have fun!
Claes in Lund, Sweden
Arigatougozaimasu!
I also suspected the difference between “-” and “_” and tried running both, but to no avail.
I thought maybe the Linux I installed was bad, so I tried installing another Linux with the same result…
Hmm, calling darktable_lut_generator is correct. darktable-lut-generator is the name of the pypy package, meeting pypy naming conventions.
I don’t know why it does not work in your Linux VM. Seems you are in the correct virtual environment, as pip lists the package.
I cannot say whether running the script on Mac is difficult because, honestly, I’ve never used a Mac and hence have no idea how it works…
I’ve taken a quick look at the darktable .dmg package for Mac. Seems like darkable-cli is in fact included somehow. I don’t know how / where software is installed on Mac, but if you know, maybe just take a look into the darktable installation directory, search for the darktable-cli executable and provide darktabe lut generator the path to it with the --path_dt_cli argument. That should work without you having to deal with a linux vm (hopefully).
Maybe it is even worth asking the darktable Mac maintainer(s) about darktable-cli, as I guess that you’re not the only mac user facing problems calling darktable-cli, and one cannot find anything in this regard via google or the bug tracker…
@Peter with the new multipass-alignment, also your images with the spectrum on the wooden surface seem to work fine! 
Thank you!
Very helpful as I was still struggling with this!
Now, I will take your word for it and attach a picture.
Best regards.
LUT.zip (76.2 MB)
darktable can’t open the raw file. Is this a compressed ARW file?
Thank you for your reply.
I was able to find darktable-cli.
I ran it with the additional arguments you gave me, and it successfully created the cube file!
It took me a whole day to finally do it. I feel very accomplished.
Thank you all!
1 Like
Thank you for your prompt attention.
I think the attached ARW file is the one I couldn’t open because I sent it as a lossless file.
I was able to run it by converting it to DNG.
Thank you for your help.