Ya it’s just from the CSS sheet… I fiddled and got something brighter and more contrast but not as nice as yours,
okay this is way too much fun and i shall stop coding features now and finally do the release. but just one more:
i wrote a contrast equaliser module similar to the edge avoiding wavelets in darktable.
[perf] sum eq: 12.819 ms on a laptop with GTX1650 max-q, 6000x4000px full res processing.
5 Likes
Now that you’re ready for an official release, can you elaborate on if any modules in vkdt share math code with the new scene-referred modules in darktable? E.g. since there has been a lot of effort to implement these modules in a high-quality way (e.g. avoid artifacts, color shifts, etc) in darktable, it would be great if that same work could be re-used in vkdt
heya, good question with a complex answer. i’m currently mostly afk, let me get back to you with a more detailed correspondence map dt<->vkdt once i’m back.
in short: there’s some/relatively little code that is shared directly (glsl vs opencl) but a lot of shared concepts/philosophy and some modules that are almost 1:1.
1 Like
I am trying to build vkdt on my Mac. However, I get an error that OpenMP is not found in spite of being installed via MacPorts. any ideas?
@hanatos now that you have a tag on the repository, you could change your service file like this:
Index: _service
===================================================================
--- _service (revision 87)
+++ _service (working copy)
@@ -2,7 +2,7 @@
<service name="obs_scm">
<param name="url">https://github.com/hanatos/vkdt.git</param>
<param name="scm">git</param>
- <param name="versionformat">0~git%ct.%h</param>
+ <param name="versionformat">@PARENT_TAG@+git@TAG_OFFSET@.%h</param>
<param name="changesgenerate">enable</param>
</service>
<service mode="buildtime" name="tar" />
that changes your version from 0~git1671824120.13f28c8 to 0.0.1+git580.c485020f.
also you want to apply this change to your dsc file:
Index: vkdt.dsc
===================================================================
--- vkdt.dsc (revision 87)
+++ vkdt.dsc (working copy)
@@ -24,3 +24,4 @@
glslang-tools
Package-List:
vkdt deb graphics optional arch=any-amd64
+DEBTRANSFORM-RELEASE: 1
that will make sure that the same release number handling is applied to debs as it is done for rpms. if you want those changes, I can also do the commit. Just didnt want to make it without your ok.
Sounds good, I look forward to the detailed update later. Thanks!
i know next to nothing about macintosh computers, but if you want a guess i’ll need some more detailed output 
maybe you need openmp for the specific compiler and version you’re using? which one is that? on linux there’s libgomp for gcc and libomp for clang, and it requires a matching version to be installed.
ah great that would be good i suppose… though the tag is really just a placeholder for exactly the purpose you describe. the new tag i’m planning to call 0.5.0. want to do some cleanup work first though (probably not in the next 2-3 days).
@hanatos It seems to be related to rawspeed.
-- Looking for OpenMP
-- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS OpenMP_CXX_LIB_NAMES) (Required is at least version "4.5")
-- Could NOT find OpenMP (missing: OpenMP_CXX_FOUND) (Required is at least version "4.5")
CMake Error at cmake/src-dependencies.cmake:42 (message):
Did not find OpenMP! Either make it find OpenMP, or pass -DWITH_OPENMP=OFF
to disable OpenMP support.
Call Stack (most recent call first):
CMakeLists.txt:213 (include)
I have no idea how I could provide the necessary flags. I am using clang.
You need llvm installed
r88 | darix | 2022-12-27 17:20:37 | e88ead9abf80455c57d19bfea724140a | 0 |
Set a proper version number and make sure that the debs also use release number handling
1 Like
JFYI: the build failures on fedora are misleadingly pointing to libatomic. the real error is:
GUI_LDFLAGS are unset. more specifically the $(shell pkg-config --libs ...) for glfw and freetype2 are failing.
okay let me try this:
approximate correspondence to darktable modules
in general vkdt uses a linear rec2020 encoding for the intermediate colour buffers, and there is pretty much no Lab code at all (except to compute delta E for display/loss). so it’s really up to the user what will be scene-referred, by default most of the modules are (but you can of course put your display transform wherever you want).
i’m skipping input/output modules because dt doesn’t work this way (dt’s input/output is more coupled to the core than to the processing pipeline).
there are also various other things like histograms/waveforms/displays/colour pickers/noise profiling/gamut checking which are implemented as modules in vkdt and thus don’t have a direct counterpart in dt as a module.
there’s an obvious difference for drawn masks (via brush strokes/pentablet in vkdt and via parametric shapes or conditional blending in dt).
dt’s snapshots probably correspond most closely to the ab module, which compares two options in a single active graph.
and of course dt has none of the 3d rendering/movie/animation/keyframing functionality. about the rest:
| darktable module | vkdt module | note |
|---|---|---|
| chromatic aberrations | ca |
different tech |
| demosaic | demosaic |
different tech, works transparently for xtrans/bayer |
| highlight reconstruction | hilite |
uses inpainting by default |
| color lookup table | colour |
uses same rbf code |
| color calibration | colour |
use cc24 presets+colour pickers |
| input color profile | colour |
can ingest DCP profiles or spectral response curves (not icc) |
| white balance | colour |
DCP dual wb, finetune via rgb sliders |
| exposure | colour, exposure |
|
| monochrome | colour |
set saturation to zero, map colours before using rbf |
| color balance rgb | grade |
|
| crop | crop |
|
| rotate and perspective | crop |
|
| sharpen | deconv, eq, contrast |
none of them is a direct match |
| denoise (profiled) | denoise |
wavelet part and noise profile application are similar (noise profiles not compatible since they are applied pre-blackpoint subtraction in vkdt) |
| lens correction | lens |
simpler model that also fits fisheye and anamorphic, no lensfun |
| contrast equalizer | eq |
overall similar wavelet approach but with different edge protection measures |
| diffuse or sharpen | eq |
for the sharpen part, only isotropic diffusion for the blurring part |
| sigmoid | filmcurv |
using jandren’s idea of applying the point process CDF, using pretty much unchanged dt UCS code by aurelien |
| graduated density | grad |
|
| local contrast | llap |
straight adaptation of the same local laplacian pyramid code (but in rgb, not Lab) |
| shadows and highlights | llap |
same functionality, disjoint tech |
| vignetting | vignette |
smoother falloff, dt’s version has a discontinuity |
| tone equalizer | zones |
uses same core tech (guided filter/luminance quantisation) |
| framing | frame |
|
| retouch | wavelet, inpaint |
|
| space invaders | quake |
(i may have to update this with links to dt and vkdt docs and update a bit in the future)
10 Likes
uhm because there’s no pkg-config on fedora? i was under the impression that there’s something odd with their way of adding default rpaths and then complaining about it later. not sure how to fix any of this from my side.
actually pkg-config is in the buildenv. and then i manually do the pkg-config lines that get called from the makefile, it also works.
[abuild@532908e83710 ~]$ pkg-config --libs glfw3 freetype2
-lglfw -lfreetype
…actually looking at the fedora logs on OBS now there are a few extra warnings switched on that i could work on.
Tumbleweed might have a few more as well 
Thanks, this is great! What about filmic rgb? Does it also map to filmcurv, or are there major differences?
conceptually filmic maps to filmcurv too, but i don’t understand enough of the technical details in filmic to be able to compare it to the display transform in vkdt.
one more update with somewhat of a breaking change for some hopefully oddball settings: i changed the 2d radial basis function in the colour module to a 3d one. originally i was following the 2d idea from a google paper, but came to the conclusion that (a) the rbf with the linear part will figure out a simple relationship and keep brightness linear and (b) not considering changes in brightness between say camera rgb and rec2020 is too much of a restriction to cover all cases.
i opted for the more general version now, i hope i won’t regret it in any case i wanted to push this before a release so i won’t have to break legacy graph configs or deal with updates.
2 Likes