Can’t export within CIELAB. Even after editing the darktablerc with allow_lab_output set to TRUE. Any tinkering around this? Thank you.
Hi,
I have used IT8 Target by Wolf Faust to create styles which look like the camera jpg processing of my Olympus OM-D EM5 II.
One important thing for me: I used Rec2020 as Input color profile. this way i get much better (natural) color in dark blue. I think standard matrix is “blowing out” extreme colors when you shoot in extreme light conditions (disco, concert…)
https://dtstyle.net/index.php/a/Norman%20Schülke
(just the last for EM5 II)
Its a good Starting Point for Olympus OM-D cameras (16MP Sensor)
This was a highly interesting read, thanks for such a detailed write-up.
Now I’m left wondering, is there a repository or other central location where people can share the results of their profiling? The suggested process is at the very least somewhat arduous: requires research specific to a location, good weather, specific equipment (color target) and access to something like a large parking lot. I don’t doubt that the process is very much worth it (and the price of a color target laughable) for a pro photog, or highly dedicated enthusiast.
However, for the average amateur, is there something that gets 90% of the way to “good” (similar to in-body jpg) color? It seems to me that being able to download a profile from someone who has the same body as I do would satisfy that requirement.
(ps: If anyone has profiled a Canon 100D (SL1), let me know ;))
The plan still is to have a website where you can upload the RAW and corresponding JPG so that we can create color profiles.
A color chart from Wolf Faust costs 30$. That isn’t really much.
1 Like
Thanks for answering!
Another question: Is this process compatible with the new linear RGB workflow released in DT 3.0?
Sort of: You probably don’t need to use the Tone Curve if you’re going to use Filmic RGB, but the LUT portion can still be used.
@asn Hey Andreas, I hope your doing fine. Finding your way in this COVID world and safe and sound. I had a question regarding your profiling article. It is using the DT method and so I wonder if that is why you set the input to standard matrix. Many people seem to use Rec709 or Rec2020 is suggested over at Pascals Colormatch Git site. Many are also using Argyll and an ICC so maybe what you recommend is specific to using the DT approach as it involves the JPG…in any case I just wondered as I get quite different images depending on what I use for a profile setting esp input and this affects selection based on the white patch. RT and dcraw produce raw linear images without an input profile and they are quite dark. The only way I get that dark in DT is when I set the input profile to sRGB and I have noted that DT embeds this in the Tiff the others do not but I read that Argyll ignores the embedded tiff…lots of rambling there but I was just going to try to compare your approach with the ICC route and see what results I got and I wanted to confirm the most appropriate settings so as to compare apples to apples so to speak…thanks for any suggestions you have and keep well
Ok, after a look I’m not sure.
I would say it should be a no-op so that we should not convert. If you select linear rec2020 as input and output it is a no-op. The data is passed through. But we write Lab so I’m not sure if rec2020 is the right choice but worth a try 
Thanks…ya just trying to reconcile that vs Argyll which uses a Tiff file…which it appears most people sync the export profile to the image by selecting image settings or the same as they have used for color profile…
We convert to Lab, not sure if that is the best idea
@asn I think the issue was I was getting confused between the two approaches and colorspace handling between applications. So I think as you say as long as there is no color conversion things should be fine and that is why there are different approaches for the color space used, ie some rec2020 some rec709 etc. When you do this in DT and save the uncompressed Tiff the raw data many not be affected but DT embeds an ICC for the chosen colorspace and by default it reads that when you open the tiff back up in DT so It was confusing as the same file processed with dcraw or RT was quite dark and the DT file would be much lighter. The dcraw and RT files have no embedded ICC so by default DT assigns sRGB when it opens them. When I set the input profile for the exported Tiff in DT to sRGB it matched those created by RT and dcraw so this was the difference. It was disconcerting at first because you select the image and match to the color chart by tweaking the black and white points and WB setting from the gray. Doing the same in RT and DT was not resulting in a tiff with the same values but that was because of the embedded ICC. I think for Argyll its not an issue as Elle Stone’s posts seem to indicate that scanin will ignore an embedded ICC and use the raw data so in theory I should get the same result. I think where it might become more interesting is with the DT method. You do export to LAB without any basecurve or tone curve etc but as a source image would you want to preserve the camera color space settings as that likely goes in to processing the jpg…so your original assertion to use the standard or embedded matrix might be more in line with the darktable chart approach…I might try it both ways and just see what the results appear to be?? I am tinkering with Raw files from a couple of phones and they are DNG files so another option is to grab the internal profile data stored in there and make an ICC file to see what affect that has…sadly its a bit too nice out to be on the computer that much so it may be some time before I get to it…
I have been trying to run this script from Pascal…GitHub - pmjdebruijn/colormatch: ColorMatch I have argyll and exiv2 running fine. I am using WSL2 Ubuntu on my Windows PC but for some reason the script throws an error about bad bash interpreter or just says it can’t find it. I think I have everything set properly and I have the script in the home directory…I’m not too familiar with Linux so I am not sure what I am doing wrong…I took the text from git and saved it as a *.sh file but maybe that is not the right thing…Would you know from his instructions how and where this should be saved and how to run it?? The wsl2 is Ubuntu 20.04 if that matters. I have no idea of the difference between bash and sh so maybe I am just a complete screw up…I may try again…I guess I could try to write a simple hello script and see if I can get that to run…ha ha…
What is the exact error?
I just did a quick search of “bad bash interpreter” and found one reason for it to be Windows line endings. If your error looks like this:
/bin/bash^M: bad interpreter: No such file or directory
then you need to run dos2unix colormatch to convert the line endings. You may have to install dos2unix…
If it’s not line endings, then run this:
$ whereis bash
and you’ll get something like this:
bash: /bin/bash /etc/bash.bashrc /usr/share/man/man1/bash.1.gz
Now, the first line of the colormatch script should read:
#!/bin/bash
and it all should work. Well, to the extent the script is correct… 
@ggbutcher @paperdigits Thanks Glen it is throwing the bash^M so maybe this is it…although I thought this was a true linux kernal so inside there I thought it would interpret it without any windows specific interference. I will try to use your suggestions…I was basically stuck with where should I put the image files…by default I was putting them with the script. Also I have the text for the script but was’t sure if I should name it .sh or not. I’ll play around a bit more trying not to give up…
I get this to whereis bash 'bash: /usr/bin/bash /etc/bash.bashrc /mnt/c/WINDOWS/system32/bash.exe /usr/share/man/man1/bash.1.gz"
Just thinking now I copied the text and pasted in into notepad and saved it…likely there is a way to grab this in git but I am again not versed on how to do this but likely I introduce the carriage return issue with notepad?? Also from my whereis…do I need to alter the script to #!/usr/bin/bash ?? or is usr implied??
If whereis thinks bash is at /usr/bin, then the script’s #! needs the same path. Most linux distros have bash at /bin, so the wsl is at odds with that.
All of this behavior is based on the contents of the PATH environment variable.
Notepad had likely save the script with the wrong line endings and the wrong character encoding. You can go to the dt github and download the script direct. You should not need to alter the bash path.
Thanks Mica it’s a bit of a deviation in the thread the Colormatch script is at a git project of Pascal de Bruijn’s he wrote something using Argyll and Exiv2 which I think sort of emulated the darktable chart approach of using a raw and jpg but it creates an icc not a style…I was trying to give it a test. I may be better to run a linux VM with a GUI instead of the wsl2, it seems fine but I am not great with the command line. It is likely an easy task to grab that from the git page from the terminal without going to a browser but I wouldn’t know how to start……I’ll go see what I can drag up