You did 
1 Like
If editing is a lower priority (and believe me, I get that), I think thatâs a decent approach to photography.
I used to handle things that way, but I came to realize what I was doing in a lot of cases was to apply a tone curve that reversed the effect of the âbaseâ curve, or whatever was applied to get the first notion of âresultâ. And that slewing of the image data first one way, then the other, just accumulates hue shift that can eventually become noticeable if you lay curve upon curve.
If you realize that and take care with how many tone curves you lay in the workflow (and donât forget the last of those which is the display/export color profile, which we tend to forget about), you can get decent results. Just realize that every tone curve in the workflow adds to the hue shiftâŠ
5 Likes
This first Hue paper was interesting. I would summarize it in the following way:
- Reduce dynamic range using rgb ratio
- Introduce hue shifts following the BezoldâBrĂŒcke effect
- Map out of gamut colors to the display saturation boundary
Here is a good illustration from handprint : colormaking attributes
(That page has a ton of other stuff to digest as well at a later stage)
If I read the diagram correctly, this effect is similar to what we get with the crosstalk option. It is at least in the same direction. This would explain why it seems natural that bright objects shift like this.
They are not focusing on the problem of out of gamut saturation, itâs just very shortly mentioned. So Iâm a bit hesitant to conclude that from this paper.
The second paper is more involved and it, more importantly, includes local effects for the tone mapping. Iâm currently working with the hypothesis that most local effects are better dealt with as separate modules earlier in the darktable pipeline.
And finally, that post by sankos you linked @afre has some interesting links that finally took me all the way to a small open-source software called dcamprof. A single man effort in trying to make profiles that are as correct as possible for later use in image editing pipelines. Tried to have a look at the code and it seems like his approach is based on what I have named preserve hue. He names it after the fact that it seems to be used in the Adobe dng tone curve. This result is then modified to match saturation from the original picture and some hue adjustments are finally applied to the highlights. These include making red colors more yellow for pleasing sunsets. Again similar to the effect with crosstalk but just for a selected range of colors.
5 Likes
Indeed!
Given the fact of rod intrusion, mesopic vision is actually tetrachromatic.
Thatâs a cool snippet from that page and also quite scary when you think about the consequencesâŠnice!
1 Like
can this program be integrated in darktable to make better camera profiles? or the present one in colour calibration module is sufficient?
As it stands dcamprof is mostly about generating DCP profiles which DT does not support but I think @jandren is looking at the code used by dcamprof as it has some commands that can be used to tweak those profiles and they have a Neutral tone reproduction operator that can be introduced to control hue shiftsâŠI canât speak for @jandren but I think this is what he is looking into wrt the code and how that might be leveraged with his work on the sigmoid tone mappingâŠ
1 Like
dcamprof is not only creating DCP profiles but it also creates very good ICC profile for Capture One. Only thing is that you have to export your colorcheckr pic in a proper tiff file which is explained in detail for Capture One. If someone can explain how to export it from DT we can use it to create an ICC profile for DT. here is the link http://lumariver.com/lrpd-manual/#make_icc
1 Like
Nice to hear from some dcamprof users!
@Rajkhand Doing any form of integration of either dng or icc profiles from dcamprof is out of scope for what Iâm trying to figure out in this thread. Iâm also not sure if it at all fits with the darktable scene-referred pipeline. I just found it to be an interesting example with public source code which makes it possible for me to try to learn something from it which hopefully could propagate to a better sigmoid module. But something you could help me with is providing some example images where you think it works well in Capture One. I.e. RAW + lightly edited jpeg. Iâm especially interested in how it behaves with bright objects in the image.
@PhotoPhysicsGuy uff, tetrachromatic? That might cause problems⊠Wonder if it can be exploited for a better model!
Rewriting color-theory to be 4-dimensional seems like a monumental task. Itâs a long discussion in 3 dimensions already. Or it may be 1D for achromatic light and 2.5D instead of 2D for chromatic stuff?
Haha, yeah, like international research team sponsored by large industry partner monumental! Could be an interesting PhD position though 
Thereâs a solution for this with argyllcms & darktable.
See pcode â Darktable Camera Color Profiling
But itâs more easy is just use new colorcalibration enhancement to take the calibration from a color checker target in upcoming 3.6
I donât have lumariver only the commandline dcamprof but as for DT the proper way to generate the tiff for color profile programs is generally as outlined hereâŠGitHub - pmjdebruijn/colormatch: ColorMatch The key is the input and output profile should be the same. This way DT does a direct pass thru and gives you a tiff with no color corrections.
Actually Pascals script using argyllcms and using a jpg/raw pair does a nice job of matching the two if that is something people want to try. I havenât gotten around to comparing a custom icc with Aureliens correction in color calibration yetâŠmaybe doing both would really nail the color so do a custom icc and then further tweak it with color calibration âŠ
I think you could actually double up. So you could make that custom profile and use that and then you could add the color calibration which in the end is like a set of channel mixer tweaks to try to match the color better . At least you could try a couple of time to see if it was worth it?? But I think we are hijacking the topic a bitâŠ
Itâs what I use to make LUT ICC camera profiles from spectral measurements.
Note that in darktable 3.6, the colour calibration module will support improving colours using a Color Checker.
1 Like
I think he asked about it already above but was just not sure if it was any goodâŠ
It would be interesting to use the evaluation features and compare the standard profile vs custom and see what sort of a deltaE difference there was between them using the color correction profile assessment
The story of hot lightsabers and why even monochromatic lasers should desaturate at high brightness levels.
Why do lightsabers in both the old and the new movies look super bright and highly energetic even on both prints and low dynamic range screens?
First an example from one of the classics:
And one from the third trilogy
Compare that with this disaster
Why is this last one so bad compared to the two from the movies? Whoever made them thought that the actual blade should be in bright saturated displayable colors while the movie frames are essentially white. This is quite understandable, just study you local traffic lights next time you are out for a strool at night. They do not desaturate at all to our human eyes but they still look bright. But it somehow does not work for images and paintings. Have a look at this classical lightsaber VFX tutorial: VIDEO COPILOT | After Effects Tutorials, Plug-ins and Stock Footage for Post Production Professionals Andrew uses a white solid for the blade and a colored glow around to make it look bright, and it works, its white but we precive it as a self luminous colored lightsaber.
Here is a more modern version of the same tutorial where Ian Hubert takes advantage of the ACES-like desaturation of high brightness colors and adds a scene-referred glow to make it, well glow!
So why does this work so well? Itâs called glare effect or grey glow illusion, making it possible to make reflective materials like a print appear emissive. Here is a classical test image and some papers to read if it is of interest:
The Glare Effect and the Perception of Luminosity
Gradient representations and the perception of luminosity
But how does this translate into image editing? Here is my take. A global scene to display transform should smoothly converge to pure white as the brightness goes up. It actually should not preserve saturation of highlights. The problem is that good lenses are designed to suppress glare like this which will causes bright light sources to just be white with no punch. I generated my own version for this using Blender, one with and without glare (known as bloom in Blender). A good lens will produce the second version without bloom which will look much worse than a lens with some imperfections! Import the exr add sigmoid with preserve hue and a bit of exposure tuning to reproduce the results.
With Bloom - âBad lensâ
glare triangle bloom.exr (21.7 MB)
Without Bloom âGood lensâ
glare triangle.exr (1.1 MB)
The solid triangle in the above two images are the same, think about that for a second! A global tone mapper which only works on individual pixel values and takes the second image without bloom could and should never produce anything like the version with bloom. The correct result for a global tone mapper, be it sigmoid, filmic or something else, is instead just the white triangle. The bloom effect has to be either created manually when shooting by some filter / dirt or in post in a separate module.
I hope that some of you darktable users now shout, but the bloom module, we have the bloom module for this! And you absolutely should because that is the correct way of solving this in post! The only problem is that the results of that module is, weeeeeelllâŠ, kind of disappointing. The reason? Simple, the module assumes a display referred workflow and needs an update to scene referred (operate on rgb ratios instead of L in Lab) for it to work as expected.
PS I cant stop laughing over how bad the darktable bloom module looks on this test image. DS
15 Likes
Enjoy your long form posts. Hope D isnât feeling particularly litigious. 
1 Like
The darktable user manual already states quite clearly that when working with a scene-referred workflow, the âbloomâ module should be avoided, for the exact reason that it does blurs in Lab space:
https://darktable-org.github.io/dtdocs/overview/workflow/edit-scene-referred/
So, no need for litigation 
There is a new âdiffusionâ module based on heat transfer equations that is proposed, which works in linear scene-referred space, and it might be interesting to apply that module to this sort of problem.
1 Like