because it’s been a while, i just wanted to give a brief update on what’s happened in vkdt. it’s not much but may be of interest to a person or another. all of this is, as usual, super rough. i’ll post some better example images once i stabilise some of these features.
local contrast refinements
i’ve experimented a bit with doing local laplacian pyramid style contrast enhancements in log space. i think the results are a lot more pleasing especially near the blacks (doing it in linear will result in drowning some values, leading to clipped blacks). will post examples, but now i became greedy and want to fix another thing or two with the current curve. maybe i can demonstrate even prettier results soon.
i implemented a cursory input colour module, which can employ the camera’s white balance coefficients and matrix. since this might shoot colours out of gamut, there is a layer of radial basis function (RBF) right after that, which is used for gamut mapping (either to rec709 or whatever colour space you want, or to the full spectral locus approximated by a polygon):
in this graph, the spectral locus (green) is approximated by a low vertex poly (purple) and the XYZ gamut (light blue) is projected inside it (yellowish). the somewhat unusual shape is because i’m mostly running in rec2020 and so the gamut is considered in rec2020 red/blue space instead of xy chromaticity coordinates. in contrast to dt, the RBF here is 2d, so it’s useful for colour correction, but not for general artistic/colour zones style manipulation (in particular you can’t condition changes on brightness).
while implementing this i noticed that the RBF kernel used by
darktable-chart produced really bad results. the matrix has quite a few 0 entries (for both distances of 0 and of 1), which made my radial basis functions behave really strange. because they are fun to look at, here are some shots of my debugging test case:
note that the view in the top right is the vanilla waveform histogram… it just happens to look like a curve widget because of how the colours are arranged in the main image. anyways using dt’s kernel would not keep the nodes at (0,0) and (1,1) fixed in this view. i’m suspecting
darktable-chartmight improve matching performance using a different kernel. will try at some point.
of course i want to use this to correct whatever mess the matrix made and pull the source colours to the correct ones whenever i know the correct values (say IT8/darktable-chart kindof thing). for this i need to pick colours on images.
this is one nightmare in a cached environment such as darktable’s processing pipeline. in vkdt i don’t have a pipeline, but a graph (DAG). so what i do is attach a picker module anywhere i like:
this makes sure the data is always up to date. well, granted you pass the “upload sink to host” runflag to the graph. usually i’m reluctant to copy data from GPU->host, because slow.
for the picking itself, i’m autogenerating a gui (remember the gui is strictly separated from the core, the module just comes with a few textual annotations of what parameters there are). this means it’s not smooth to use (to say the least) and ugly and redundant and wastes space. will fix with low priority at some point. that said, you can pick a variable number of spots:
these colour buttons are std imgui arsenal, they show a tooltip with numeric values if you hover over them. (chose this synthetic image because it has fluorescent colours stored in XYZ colour space).
so much for now, hope to find time to polish some of this to make it actually useful.