Bear in mind that Pascal posted his instructions 8 years ago and that he used Ralf Faust’s IT8 target with ArgyllCMS rather than using X-Rite’s ColorChecker Passport with darktable’s own profiler. Nevertheless I think that I’ve been able to patch some of the holes in Andreas’ article.
Before we continue and so that we don’t go down the wrong path like we would, as Andreas implies would happen, if we follow the course that Harry Durgin (my darktable hero!) provides, Andreas, are you okay with what Pascal has written? If not, once again, why not?
After reviewing Pascal’s article and watching his accompanying video, it seems that:
exposures can be adjusted by dt to provide the necessary L-value
likewise, white balance can also be set by dt
if one can’t compile dt in order to be able to invoke darktable-chart, one can run ArgyllCMS instead
Andreas, are the above correct or, am I still missing something?
I think that Andreas’ call for dialogue is quite appropriate in light of the different guidance provided by a number of parties with unique experience and hence, ideas, about camera profiling.
In trying to muddle my way through this process I’ve found some instructions espoused by various learned individuals to be in direct conflict with others, some apparently superfluous, and others baffling (at least from my inexperienced perspective). With this in mind, I hope that we can move this forward in order to build consensus amongst the experts so that plebes such as me can benefit from their combined and properly-distilled wisdom.
Having said the above, I also find myself now asking: “Is it really worth it; just what the h*ll is the purpose of profiling?”. This is what I’ve been able to come up with so far:
enables the OEMs to cook Raw data into ‘pretty’ jpegs
addresses beginner’s complaints that their favourite raw processor doesn’t produce results as ‘nice’ as what the camera displays or regurgitates as a jpeg
avoids (what I assume would be) extensive post-production effort to reproduce real-world colours - if this is the result which one wants
To me, at least, the last one is the most important. Yet with today’s popular trend of coaxing increasingly unnatural visual interpretations from photographs until they resemble soft-core LSD trips, this also seems to be pointless for disciples of such wizardry.
Andreas, are the above correct or, am I still missing something?
I can only tell you that you have to try out and share your experience.
I haven’t tried this. Camera engineers put a lot of thinking into how to develop the camera produced JPEG files. It is the best to match them. However you would need to first get really good results without changing the white balance or anything else. With that you have a baseline and check what happens if you change the white balance. Then compare how accurate it is.
Camera manufacturers put a lot of thinking into how to develop a RAW into a JPEG. Also those are normally very pleasing unless you apply Creative Style. The default is normally extremely good and sometime photographers don’t do any RAW processing as the JPEG is just fine. However if you want to do process a RAW, you want to start from a already a good starting point, and that’s the colors and standard curve applied which a JPEG already has. Then start correcting the errors.
I don’t know what camera manufacturer you have, but my cameras JPEG files just look awesome and they are not over-saturated.
I found a lot of different documentation, the article is the process I used and e.g. @firstyear was able to get really good results from it. He also contributed to the article. I’m not a master of color, I’m just a simple user who tries to spend less time developing RAW pictures and instead go out and shoot pictures.
We are an Open Source community so here is a start, go experiment and contribute back
I found myself interested in this topic for two reasons - one was that I was always left a bit sad about the colour coming out of my raw processor, and second being colour blind having a tool that can “correct” colour is helpful. Especially as my eyes deceive me often enough
You ask, quite rightly “Is it really worth it?”
I spent a week following this article, contributing back and working on it - and in the end I wrote this response based on my lessons: https://636.photos/blog/blog/why-i-shoot-jpg/ For me, it was a wonderful learning experience to help @asn with this article, and to learn more about colour myself.
If you want to learn more about colour, how it works, and how cameras and software process it, profiling is a great way to learn that.
If you want to shoot RAW’s and spend time editing them later, then profiling can help you apply some great effects and corrections, along with the power of most RAW editors.
If you want to just go and take photos, perhaps skip over this as a “fun read” and use the tool in your hands - your camera.
I hope this gives you some other ideas on the topic,
For any of those who are continuing to try to make sense of this as I am, here’s a link to a video straight from one of the horse’s mouths: https://www.youtube.com/watch?v=CTlugQd3L5g
It’s produced by X-Rite with, apparently, an advanced audience in mind. As such, the sole focus (hey: another pun!) is on reproducing real-world colours rather than fiddling to emulate what some OEM engineer has dictated that you should be seeing .
What I found to be interesting (and quite logical) is that the video’s author suggests that the best thing to do is to profile the camera for each unique shoot. Because after all, reflected colours will change based on a number of variables including not only the light source, the mix of sources, the colour of the immediate environment, but even the colour of a model’s dress!
Unfortunately, the video doesn’t show how such profiling can be optimised in darktable (for some deluded reason the author uses an arcane commercial product with the name of Light-something-or-other ). Nevertheless, I think that by cobbling together some of the good suggestions within this article, some from the X-Rite video, some from The Eminent Harry Durgin’s videos and some from other sources (including Pascal de Bruijn’s ancient but still-relevant article) we should be able to come up with something quite effective.
What would be really great (Bill Ferguson, are you listening?!), is if the process can be made easier by being able to automate most of it (primarily calling and running darktable-chart) with a lua script !
After having recently dropped an almost-insane sum of €94 for a small black plastic clamshell filled with a few painted colour chips, I felt that in order to gain some value for the hard-earned money spent, I had no choice but to to delve further into this and learn more to try to separate the chaff from the wheat. Not only for my own benefit but also for others who are trying to wrap their heads around this concept of camera profiling…
Umm… now it’s becoming really confusing! If the above is true, then perhaps to prevent any misunderstandings, in the same tone of the original title it would be much better to call it:
“Profiling a camera with darktable chart: Figure out how to make your RAWs look like your camera’s jpegs”
The confusion comes from having read the following:
and…
What is “most”? What is one to do if one’s conditions fall outside of this definition yet the desire is still to benefit from camera profiling? Don’t forget that the term “conditions” used in this sense can be highly subjective!
.
.
Thank-you!
The author is to be commended for his outstanding and generous effort into producing this article. It has undoubtedly been very helpful to guide and inspire me to learn more. However, since it it now appears that the author’s primary purpose was to show how to replicate an OEM’s subjective interpretation of a “pleasing” output, others may also be left scratching their heads just as I was after assuming the article implied a workflow to develop camera profiles to produce real-world results. So, in the spirit of Contribution, here’s what I’ve surmised up to this point:
Why are cameras profiled?
Three reasons:
to enable the OEMs to convert Raw data into ‘pretty’ jpegs
to stop beginners complaining that their favourite raw processor doesn’t produce results like the pretty jpegs regurgitated by their camera
to be able to produce “accurate” results by inputting real-world colour values prior to any additional post processing tweaks, if so desired (while not forgetting the attendant critical factors of monitor and printer profiling, of course)
“But I like the OEM’s pretty jpegs”
Well then, as one of the earlier posters suggested, embrace the jpeg and be done with it! Or, if you feel adventurous, work the funky RAW further until you’re satisfied. However, there is something very important that you must keep in mind:
Each OEM has a different interpretation of “pretty”. In fact, pretty may even mean something all together different across the range of an OEM’s individual models.
In order to see the effect of the above, consider the following:
You and your buddy have been asked by your cousin to shoot her wedding. Somewhere you’ve heard that it’s important to “profile your camera”. As a conscientious photographer you do some research and then follow the steps found in an impressive and highly detailed article. After the wedding, when you begin to process the RAW shots taken by you and your ‘second’, you get an unsettling queasy feeling deep within the pit of your stomach: your cousin the perfectionist is going to flip because the colour of her dress isn’t the same in the various shots! That seems impossible; you took all the right steps:
you profiled your cameras
you shot in Raw
you even used a proper grey card (not an 18% grey) for white balancing all 4 cameras!
This is a classic apples vs oranges conundrum: Camera 1 was shooting apples, camera 2 shot oranges, camera 3 captured grapes and, finally, camera 4 recorded kumquats. Because of their OEM’s unique subjective settings, they all had different reference points which, in turn, produced different pretty results!
The only way to ensure consistency is to begin from consistency. Use a consistent reference. As far as I know, there is nothing more consistent than reality. For example, “real” colours (*let’s not get into “alternate” reality ).
.
. Profiling a camera with darktable-chart: On the way to producing accurate colour results
All right, so this is what I thought that the article was going to be about! Since it wasn’t and since I’m almost certain that many others would also be interested in this, perhaps we can now move forward. In so doing, I hope that the following notes (assumptions!) might help. At the very least, they should serve as springboards for ardent collaborative discussion (vehement disagreement?), correction and consensus leading to something which we may all benefit from:
Shooting jpegs is unnecessary for this workflow
Setting proper (or ‘best’) in-camera white balance isn’t necessary since we’re only working with RAW files
Proper exposure is necessary(!) to prevent clipping so that all of the sample’s data can be analysed. Use an 18% grey card to adjust your camera’s exposure accordingly.
A set of ISO-delineated ICCs has limited effectiveness if colour accuracy is your goal. If this is indeed your goal, conduct a proper camera profiling workflow for the environment encountered in each shooting session.
.
.
Additional Wisdom
Here are some links which may be relevant and of interest. Hopefully somebody much smarter than I am can glean some useful information within:
“Ghetto” ColourChecker. Dubious yet the most promising DIY target for those who are cheap and don’t mind living on the wild side: https://www.youtube.com/watch?v=6v5wexwSsw4
I’ve followed this article and the video, but I’ve used C1 chart from http://coloraid.de/
I’ve also converted advanced input profile from RAWStudio to ICC.
I’m sure I’ve messed things up somewhere (for one, I photographed the target at a rather large angle) as I was doing for the first time and in a hurry, but profiles I’ve got from using http://coloraid.de/ are much better to what I could get with canon base curve.
I’ve updated the article. This has quite some new information. Also if you use a ColorCheckerSG you need to use the darktable development version to create a style with darktable-chart.
I have followed the steps very carefully but run into a problem with selecting the grey ramp. I am using a basic color checker and the ColorCecker.cht for reference. However, when in process the only possible selection is A1…D6. I am guessing it should be D1…D6 as only the D row has grey squares - but maybe my understanding is incorrect. One thing for sure, its not making any photos look better at all, in fact far worse - so something is wrong somewhere - the grey ramp being my best guess as to the problem. Any help would be great - thanks
ColorChecker.cht is for a specific color target, i’d assume, as most are for specific targets. Find the cht that matches your color target and hopefully you’ll have more success @troyatlarge
ColorChecker.cht pulls up a target that fits perfect over my chart -
all the same colors, same rows, same thing so far as I can tell. It is
the bottom row, of 4 rows (rows are A, B, C, and D), that had the gray
scale - but in the drop down menu in the process tab, it has A1…D6
as the only possible selection - as if it is saying every square in
the whole ColorChecker is suitable for the grey ramp - Im guessing
that is wrong. My guess is D1…D6 should be the the correct
selection, but no such beast in the box.
@troyatlarge I had the same problem with the ColorChecker SG. In the darktable development version we changed the code to automatically detect the gray patches instead of relying a corect grey ramp definiton in the cht file.
So you either have to install the development version to get the latest darktable-chart to create a profile or wait for the release of darktable 2.6 which is normally Christmas!
Ahh - thank you! You mention “…relying a correct grey ramp
definition in the cht”. Exactly what part of the cht file defines that
grey ramp? For example, mine reads, in part;
BOXES 25
F _ _ 10.0 9.75 321.25 9.75 321.26 217 10.0 217
D ALL ALL _ _ 330 228 0 0 0 0
Y 1 6 A D 46.0 46.0 12.0 11.5 52.5 52.5
Is part of this pointing to the grey ramp, and if so - which part? I
am assuming here that part of this is building the drop down box
selection in the process tab, and in this case, is doin g so
incorrectly - like it needs to be switched to Y 16 D D or some such
thing. Am I way off base here?
No it does not look like that chart… more like the right half of that chart. It looks more like the chart seen here: ColorChecker - Wikipedia
To be exact, the chart shown is using the colors listed on the wiki page covering that color chart as seen here: ColorChecker - Wikipedia
What we did was print out, on a high quality printer up to the task, these colors on a like shaped chart and then ran a spectral analysis on the printed colors thereby being able to calculate the DE of the colors, many of which are like 0.3, 0.5, etc., save for the white which had a DE of 3.4. I now want to test the thing for issues to see if one could reasonably use it, or if I must upload its individual Lab coordinates in its own cie file and expected XYZ in a cht file.
However, at this point I feel something else is going wrong before I even get that far - the cht file, or whatever file it is that controls it, should not have the gray ramp choice as all the rows from A1 to D6, but instead should only include D1 to D6, unless I am grossly mistaken somewhere.
.
). Nevertheless, I think that by cobbling together some of the good suggestions within this article, some from the X-Rite video, some from The Eminent Harry Durgin’s videos and some from other sources (including Pascal de Bruijn’s ancient but still-relevant article) we should be able to come up with something quite effective.
for a small black plastic clamshell filled with a few painted colour chips, I felt that in order to gain some value for the hard-earned money spent, I had no choice but to to delve further into this and learn more to try to separate the chaff from the wheat. Not only for my own benefit but also for others who are trying to wrap their heads around this concept of camera profiling…
after assuming the article implied a workflow to develop camera profiles to produce real-world results. So, in the spirit of Contribution, here’s what I’ve surmised up to this point:
).