There is a way to build pdf if you look at https://github.com/elstoc/dtdocs. You need to clone from git and install a couple of packages but it’s not too complicated. When we release dtdocs officially we will produce a pdf as well. If you want us to look in to a “print from page” option please raise a feature request and we’ll look into it.
After playing with “auto enable chromatic adaptation defaults” setting and reverting back to legacy. All my images now have the wrong white balance settings when setting to “As shot” white balance.
All images now default to “user modified” settings in the white balance module. And seem to have the settings that “As shot” setting should have had.
“As shot” setting doesn’t work anymore. Every channel coefficient is set to 1.
Is this a bug or a feature that I missed?
Looks like https://github.com/darktable-org/darktable/issues/6926, which was fixed a few hours ago
Thanks! I tested the update. It’s fixed now
All good I just routinely print things to pdf…easiest way for me. And I can still do this but if you want to print a topic from this as it stands now you lose a the left third of the page…I just though it might be an easy thing to employ. I print lots of webpages with banners and the like and many but not all can print without the surrounding banners boxes etc…its not a big deal just noticed it when I went to print off the new channel mixer section to have a read…A thought I have 2 or three PDF printers installed for various reasons…maybe its specific. I have noted some pdf files over the years only print correctly from Adobe and not other solutions …I’ll check but no bother either way…
I’ve raised a feature request on the project so it doesn’t get forgotten.
@paperdigits has resolved this now. If you print a page from the user manual website it should now exclude the header, sidebar, breadcrumbs and previous/next page links.
Wow thanks guys…no expectation of a fix on my part more of an observation so thanks. You are assembling such a nice resource only fair that you can output it to reflect that…thanks again….
General question for those who tested the calibration module : how do you like it so far compared to white balance ?
Better control and result
I have not played much with it. I’ve only used it as a new ‘white balance’ (but I rarely used the channel mixer previously).
It’s a bit confusing why the ‘temperature’ readings are different from the WB module (e.g. for a daylight shot I got 5527 K in the WB module (‘legacy’ mode); I get CCT = 4467 K in the ‘colour calibration’ (‘modern’ mode) and at the same time temperature = 4466 K on the slider; if I select ‘as shot’ in the ‘illuminant’ drop-down, the CCT changes slightly to 4466 K, the value previously shown on the slider. I know they’re just numbers and I don’t really care, but I do notice the inconsistencies and some may get confused (well, I’m also confused, but I just ignore it for now).
Quality-wise I don’t see a difference (I see that there is a difference, I just don’t see it as better or worse). I have not tried re-processing any shots taken under difficult lighting (mixed, LED etc.).
I have tested the module and it works pretty great. I hardly ever used the RGB mixer, and I don’t really see why I should now. But for the white balancing through CAT part I find that things are pretty much spot on in many (most?) cases. However, in some situations I get a worse white balancing results than by simply using the white balance module. This has probably to do with the CAT. But if someone can tell me how I can improve this with the color calibration module, I look forward to learn. (My minor gripe with this poorer result is that the module is called ‘color calibration’ which implies things should be very / more accurate).
Source file: _DSC2866.DNG (20.7 MB) (original author unknown)
Using default scene-referred and white balancing area on the third grey spot:
_DSC2866_01.DNG.xmp (17.9 KB)
Using default scene-referred, white balancing to camera reference, color calibration with CIECAM16 and selected area on the third grey spot (* Bradford does virtually the same). This gives an unexpected blue tint to the white patch.
_DSC2866_02.DNG.xmp (20.5 KB)
As long as camera auto-wb was correct, the old white balance module gave decent results. But I found its control sliders not so good, so wb adjustments were a bit of luck.
The new color calibration module is lot more useful, especially to control faulty wb. But even with the initial settings I often find that my pictures look better regarding colors. Without calibration the images often have a tiny green-ish look. With calibration module the images look more neutral and a bit brighter. Here is a short comparison (left = wb, right = calibration) with auto-settings:
Regarding CAT adjustments I find that the color picker works really well, whereas “(AI) detect from image surfaces…” always detects a temperature of 5002K! Is this a bug?
A shiny diamond is the new channel mixer. I have some pictures with highly saturated colors in direct sunlight. With the new channel mixer I can prepare those pictures to fit better into the small gamut of sRGB / JPEG files, and retain a bit of texture without clipping these channels.
I like the fact that it is maskable, it allows me to fix situation with mixed lighting.
The auto AI feature works well too.
In general I have the feeling it performs better under difficult light.
Like others, I am a bit puzzled with the temperature K readings, they looks different from the ones I am used too.
Also, the camera WB presets (Daylight, Cloudy, Shade, etc.) are gone, any chance to replicate those in the new module ?
The gamut compression is nice, but I would like to have more range in the slider, to fix led blue lights etc.
The masking feature is fabulous. During confinement I’ve been taking a lot of photos of street scenes with brightly-lit buildings and deeply shaded streets and lower stories. Once figuring out general masking in DT (I don’t find the combination of drawn and parametric masks to be very intuitive), I can quickly come up with a pleasing white balance for the entire scene.
I just tried that image. The CAT relies on the usual white balance to correct the image to D65, so that the color input profile gets predictable. But for the Sony from that picture, the red white-balance coeff is 2.67, which is massive and probably wrong (most sensors are between 2 and 2.33). If you force a red coeff of 2.0 in white balance module, then retry the color calibration sampling from any grey patch, then it will work.
Problem here is we stack the color calibration on top of white balance and input color profile, so we expect/pray for anything else having been profiled properly.
I got the smell of the red factor issue because cyan is the opponent color.
All the CCT computations there are approximations. The temperature slider of color calibration computes the XYZ coordinates of the illuminant from an approximation based on temperature input. Then the CCT display tries to find the best temperature match from an approximation based on XYZ input. Having only 1 K of error in the roundtrip is actually impressive. And you get rounded to 1 K, so a visible difference of 1K could be an actual difference of 0.5 K.
Don’t even try to compare temperature readings from both modules. Again, color calibration takes an input that is already pre-corrected by white balance and input profile.
Right click on slider, input value on keyboard up to 10.
On that point, it might be time to check the WB coefficients of your camera.
If your screen is properly calibrated to D65, just display a grey gradient on it, shoot it with your camera, then open the raw in darktable and do a spot-white balance on the whole ramp in the white balance module.
Finally, compare the RGB coeffs you got with the sampling with the “camera reference” ones, and report here in case of large shift.
Would it be possible to add a warning + tooltip to the UI that warns the user and proposes this fix in case the multipliers seem fishy? We could get it in the docs, but users, so far, have not been very good at reading that.
It’s just something I noticed on one picture so far, let’s try to understand what happens first, see how frequent it is, then decide about what we do.
@aurelienpierre It’s not necessarily just the red channel coefficient. Here’s another image from the same camera with red = 2,672 when the wb is set to camera reference. But applying the color calibration does not give a cyan hue to the white patch.
Again, image is not mine and exact source is unknown.