new build current master + filmicRGB v4: darktable-3.1.0+1604~g10c48a427.dmg
plain current master:darktable-3.1.0+1599~g7600fb842.dmg
1 Like
zurdo
May 15, 2020, 10:53am
82
Current master + filmic is working nicely on OSX 10.13.6. Thank you
Again same problem with your latest build current master + filmicRGB v4: darktable-3.1.0+1604~g10c48a427.dmg, film roll shows my folders and number of pics in the folder in bracket but when I click on it no images are shown in lighttable
My current working version is 3.1.0+1319~g2a013f90ba with filmicrgb v4 on OSX 10.15.4
What is happening ? why each new version wants to update the database?
can I somehow see some error what is going wrong?
Launch from the terminal.
you wrote - you recovered your database from a backup - so the database update is done again.
Iâll try both the suggestions and inform what happens.
I got it to work by @MStraeten suggestion of change the view rating to all and then it works.
Thanks!
new build curent master + filmic RBGv4 +new Channelmixer + new whitebalance UX: darktable-3.1.0+1809~g8df34cf39a.dmg
plan current master: darktable-3.1.0+1753~gab53df608.dmg
both requires a database update so backup your .config/darktable directory first
2 Likes
where can I get details about the new channel mixer?
new build current master + filmic RBGv4 +new Channelmixer + new whitebalance UX + some performance pr (5204,5205, 5213): darktable-3.1.0+1871~g5cca49fed1.dmg
keep in mind that the additional stuff is work in progress âŠ
1 Like
eyedear
May 29, 2020, 6:48am
92
How can I compile the 1871 version for windows. I just clone the dark table git yesterday and the version i can build is 1753. I find that compiling from source give me the best performance. The version that you provided felt slower on my i9 MacBook Pro vs my dell i7700 notebook.
johnny-bit
May 29, 2020, 7:33am
93
Martin integrated some PRs in build, thatâs why version number is 1871 in his case, while you get 1753 when building from master.
eyedear
May 29, 2020, 7:45am
94
that mean I have to wait until master reaches 1871. by the way how do we know the currently available build on GitHub Master.
Maybe OpenCl is not activated.OSX: compiling kernels for opencl for packaged darktable.app needs several attempts · Issue #2810 · darktable-org/darktable · GitHub to ensure that all opencl kernels are built properly - it might take several starts until all kernels are built when using these development builds.
MStraeten
May 29, 2020, 12:58pm
96
1 Like
MStraeten
June 5, 2020, 11:18am
98
new build plain current master darktable-3.1.0+1932~g5609f84cea.dmg:
current master + filmic RBGv4 +new Channelmixer + new whitebalance UX + some performance pr darktable-3.1.0+2037~g5a08cf8833.dmg:
darktable-org:master â johnny-bit:temperature_ux
opened 11:35PM - 24 Feb 20 UTC
Loads of work went here, so to sum up this PR:
- [x] sections of wb ui to sho⊠w important things in nice structure
- [x] hides coefficients since most people won't use them (but still are easily accessible)
- [x] adds possibility to enable colored sliders (3 modes: no color, blackbody and effect emulation. users will love effect emulation one!) (fixes #4479)
- [x] hides finetuning slider for internal functions and camera presets which don't have finetuning
- [x] makes finetuning slider obey preset finetuning ranges (no constant -9..9 mired, it now accepts whatever's in wb_coeffs.c so -12..12 if fine as well as -3..3)
- [x] sections off settings combo so app functions/camera presets are distinctly separated
- [x] adds buttons for even easier access to internal presets/functions (#2459)
- [x] renames/relabels/moves several terms/items to match what they are called in other apps
- [x] adds tooltips for better discoverability
- [x] adds posibility to use accel for user setting (ref #4676)
This is how "previously" white balance module looked:
with this PR default look is:
however the recommended (image effect mode) is:
with everything expanded and camera preset with finetuning active, this is how it looks:
And here's how wb setting combo looks:
This is fully usage ready so I invite you all to test and comment :)
I'll try to keep it up to date with master, rebasing as needed
<details><summary>older info</summary>
This introduces option for enabling colored sliders in white balance module.
(previously disabled via compile flag)
Also introduces option for temperature slider color gradient: default is "black body radiation", so technically color of scene light. If user finds it confusing, one can enable "inverse", that makes it similar to other tools with colored temperature slider (eg. Lightroom)
Additionally - enables tooltips which apparently everybody loves.
//Edit!
This is how "normally" white balance module looks:
This is after enabling colored sliders with temperature slider being default blackbody radiation color:
And for those that find blackbody radiation confusing - there's opposite (sorta Lightroom-like) look:
//EDIT:
Fixes #4479
</details>
darktable-org:master â aurelienpierre:steroid-filmic
opened 04:40PM - 23 Apr 20 UTC
* add a new desaturation method based on spectral purity of the light emission, ⊠independent of XYZ space, and a basic gamut mapping in pipeline RGB space following the same strategy,
* change the default saturation strategy : 0% and 100% luminance bounds are forced to 0% saturation, but the midtones are resaturated instead.
* add an highlights reconstruction method in wavelet space, bounded to the scene white value, to bloom highlights or recover details with 3 different strategies.
* hide the middle-grey settings by default, and set them to 18.45% instead. AÂ box needs to be checked in "options" tab to get them back. These have confused too many users and overlap with exposure setting anyway.
* make the display gamma auto-adjustment optional (checkbox in "options" tab).
* allow 2 different curvatures for the filmic curve toe and shoulder : hard (4th order polynomial), with more tonal compression, and soft (3rd order polynomial), with less tonal compression.
NOTES:
* v3 algos (dt 3.0-3.0.2) are still available as an option.
WARNINGS:
* older presets are **NOT** imported at this time,
* OpenCL kernels are **NOT** available at this time for the v4 color science and highlights recovery.
DEMO (no additional highlight reconstruction or color adjustments):
filmic v3 (2019):
filmic v4 (2020):
filmic v4 without highlights reconstruction:
filmic v4 with highlights reconstruction:
filmic v4 without highlights reconstruction:
filmic v4 with highlights reconstruction:
darktable-org:master â aurelienpierre:reboot-channelmixer
opened 06:28PM - 07 May 20 UTC
This started as a rewrite of channel mixer because the previous one clips RGB at⊠100%, which causes problems with scene-linear workflow. It also allows to normalize channels to 1 so brightness is (sort-of) preserved (sort-of, because we don't compensate for Helmholtz-Kohlrauch effect).
I don't think there is a clean way to upgrade the current channel mixer while preserving decent performance. Also, the HSL variant makes zero sense, since the channel mixer is a matrix dot product that already contains a hue rotation as part of the linear map/vector base change it performs.
So, let's start clean.
## What does it do ?
Same as before: R / G / B mixing. But not only.
Colorfulness and brightness adjustments are backported from the new color science in #4800, so come from the same norm vs. ratio demodulation, without having to use shitty HSL.
But since we are already in LMS, why not use it for what is was originally designed : chromatic adaptation transform (CAT), aka white balance adjustment ? The current white balance adjustment in dt is very primitive, inaccurate and rather messy.
So I added an `illuminant.h` library that :
1. computes accurately the correlated color temperature from the white point chromaticity,
2. computes accurately the white point chromaticity from the color temperature.
3. contains the whole list of CIE standard illuminants (fluorescent, incandescent, DEL, daylight and black body):
It clips the negative pixels after white balancing as a brute-force gamut-mapping to deal with imaginary colors (especially in blue).
## How does it works ?
This channel mixer works in LMS cone space, a special kind of RGB adjusted for homogeneous chromatic adaptation. That makes the balancing more even, while still preserving the scene-referred connection, since we go from pipeline RGB to XYZ to LMS only by matrice dot products.
The white balance is initialized with the WB coefficients read from the RAW image. Those can be retrieved anytime using "illuminant" -> "compute from cameraâŠ". If the WB coefficients lead to a chromaticity close to the planckian locus (< 0.1% error), the UI switches in daylight mode:
If not, the UIÂ switches to the custom mode, where users are presented the exact x and y chromaticity coordinates for emergency damage-control:
Here is a comparison between classic dt white balance using camera default (left), and the Bradford transform in the CAT tab of channel mixer, also using camera default (right):
Notice that you need to set the old white balance to "camera neutral" if you want to use the Bradford CAT instead (don't disable the old white balance, we still need the default D65 coefficients).
I have also added the ability to perform gamut mapping and to clip negative RGB to sanitize files shot under blue LED and weird illuminants. These situations happen a lot to events and concert photographers.
Before gamut mapping:
After:
There is also a "machine-learning" WB auto-adjustment that doesn't try to make the whole image grey when you have legitimate colours.
Current dt detected WB with the spot tool (on the whole image):
"machine-learning" auto-detected WB (on the whole image):
WB as shot (detected by the camera):
## More screenshots
Collection of standard CIEÂ illuminants:
The color patch shows the color of the current illuminant, the CCT on the left is an approximation of the color temperature for any illuminant (but keep in mind it's meaningful only if the illuminant is close to daylight).
## WIP
What remains to be done:
* ~~auto-adjust white balance~~
* turn the 3Ă3 params settings in R / G / B tab into a 3Ă2 rotation and scaling parameter as an alternative GUI.
* OpenCL.
darktable-org:master â ralfbrown:wavelets_speedup
opened 12:40AM - 26 May 20 UTC
Some small speedups from optimization, and a larger relative speedup at higher t⊠hread counts by parallelizing a formerly single-threaded computation. Note that this code generates a slightly different result than the old single-threaded version. I have verified that the difference is due to numerical instability in the old code and that the new version is in fact more accurate (the fourth commit adds some code to demonstrate; see the full commit comment, and feel free to leave it out of any merge).
Timings with default parameters in Denoise(profiled) on the integration-test image:
Threads / Old / New (delta%)
1 / 11.712 / 11.342 (-3.1%)
2 / 6.108 / 5.814 (-4.8%)
4 / 3.306 / 3.068 (-7.2%)
8 / 1.944 / 1.691 (-13.0%)
16 / 1.181 / 0.969 (-18%)
32 / 0.759 / 0.556 (-26%)
64 / 0.611 / 0.371 (-39%)
darktable-org:master â ralfbrown:dwt_speedup
opened 08:28AM - 26 May 20 UTC
The discrete wavelet transform code was running essentially single-threaded, and⊠what multithreading that did happen was basically burning CPU cycles for no gain.
This PR speeds up single-threaded performance by about 10% on SSE-capable systems, and multithreaded performance by more than a factor of two with eight or more threads. (Test was retouch module with 6 wavelet scales and a "pencil" brush on one of the scales.)
darktable-org:master â ralfbrown:atrous_speedup
opened 05:06AM - 27 May 20 UTC
Optimized an innermost-loop function on the SSE codepath for >10% speedup. Veri⊠fied to produce pixel-identical output on mire1.cr2.
Using "clarity" preset on the integration-test image:
Threads / Old / New (delta%)
1 / 6.343 / 5.398 (-14.8%)
2 / 3.275 / 2.757 (-15.8%)
4 / 1.705 / 1.493 (-12.4%)
8 / 0.886 / 0.763 (-13.8%)
16 / 0.494 / 0.433 (-12%)
darktable-org:master â ralfbrown:nlmeans_speedup2
opened 06:25PM - 24 May 20 UTC
(cleaned-up version of #5169 )
I've been rewriting the non-local means denois⊠ing code. Here is the result, with both scalar and SSE implementations for both the Denoise (non-local means) and Denoise (profiled) iops. I also refactored the CL code paths, but that is **completely untested** as I do not have OpenCL [1], and is therefore disabled by default. Change USE_NEW_IMPL_CL at the top of src/iop/nlmeans.c and src/iop/denoiseprofile.c, respectively, to try out the refactored OpenCL code paths.
[1] video card is unsupported. I did try installing pocl, but even after I forced dt to use it, it failed to compile kernels with a "common.h: file not found" error, despite that file being in the directory pointed at by the -I flag....
Per-thread memory use the same as before, though I have added a couple of KB of housekeeping data. Speed is better single-threaded, and much better with large numbers of threads. Results will differ slightly from the previous CPU implementation, but should be closer to the OpenCL code, as the interval between fully recomputing the patch statistics is shorter, allowing less of a buildup of rounding errors.
**ETA**: rewrote the code to use tiles small enough to fit in L2 cache, with active parts small enough to fit in L1, which now gives a 21-27x speedup with 32 threads and much better single-thread performance with scattered patches as used by denoise(profiled). Timings below are for git master (old), the first version of my code (new), and the revised version of my code (newer).
Timings with the default parameters on the mire1.cr2 image from the integration test suite:
Denoise(profiled)
Threads / old time / new time / newer
1 / 25.735 / 22.532 / 14.275
8 / 3.483 / 3.055 / 1.914
16 / 1.889 / 1.595 / 0.982
24 / 1.556 / 1.118 / 0.708
32 / 1.641 / 0.856 / 0.662
Denoise(non-local means)
Threads / old time / new time / newer
1 / 7.516 / 6.194 / 6.166
8 / 1.435 / 0.854 / 0.799
16 / 1.395 / 0.435 / 0.434
24 / 1.438 / 0.371 / 0.292
32 / 1.437 / 0.238 / 0.298
(I get 0.232 with 30 threads and 0.227 with 31 for the newest code, so the 0.298 with 32 may be an artifact of an uneven split in the tiles.)
Timings using the image and .xmp from the discuss.pixls.us thread "darktable speed (in general, and when using two monitors)"
Denoise (non-local means)
Threads / old time / new time / newer
1 / 14.346 / 11.655 / 12.165
4 / 4.174 / 3.124 / 3.130
8 / 2.783 / 1.589 / 1.568
16 / 2.735 / 0.853 / 0.811
24 / 2.806 / 0.608 / 0.553
28 / 2.853 / 0.605 / 0.486
32 / 2.862 / 0.897 / 0.447
darktable-org:master â johnny-bit:activate_duplicate
opened 05:58PM - 30 May 20 UTC
gui reset is no longer needed since toast for hidden controlls are
moved to acc⊠el handling
fixes #4796 by essentially reverting fc92a41e28e140dc42bf951d674d4194468af1f7
darktable-org:master â ralfbrown:bilat_speedup
opened 09:49PM - 01 Jun 20 UTC
By precomputing as much as possible, we can remove 48 conditionals and 20 multip⊠lications per pixel from the innermost loop. This produces a quite noticeable speedup in all of the iops which use the bilateral filter (-25% runtime on the faster ones such as lowpass, monochrome, and local contrast; same absolute but percentage-wise smaller gains on the slower ones like global tonemapping and shadows/highlights).
Requires #5222 (whose commits you see included below as the first three), but posted now so I don't forget about it.
darktable-org:master â ralfbrown:bilat_fix_speedup
opened 06:54AM - 29 May 20 UTC
As mentioned in #5221, there is a data race in the bilateral filter, which cause⊠s images to differ from run to run. Because multiple threads are writing to the same area of memory, there is also a performance issue due to cacheline bouncing; on my system, beyond 8 threads, wall time remains constant even as CPU time scales with the number of threads.
This PR fixes both issues by using a separate buffer for each thread and combining the results at the end. As with some other recent updates, this one has slightly different results depending on the number of threads, because the results become numerically more accurate with more threads (due to summing fewer items at once).
darktable-org:master â aurelienpierre:improve-icons
opened 11:44PM - 04 Jun 20 UTC
- move boilerplate code to macros and ensure Cairo coordinates are reset after e⊠ach icon,
- ensure line width is the same no matter the icon size,
- improve some icons (mask brush, display, preference wheel, color-picker, etc.)
Before:
After:
Bonus: color-picker have a true droplet (powered by bloody trigonometry)
Bonus 2: preferences have a real gear wheel
eyedear
June 5, 2020, 12:19pm
99
Thanks @MStraeten I will try it. There was a compile error on my windows compile I tried to do this morning.
MStraeten
June 5, 2020, 12:46pm
100
Unfortunately a successful build on osx doesnât imply a successful windows build âŠ