I'm not understanding 'profiles' in dt

priort · December 12, 2021, 6:24pm

The manual is not too bad also there is a wealth of information in these discussions

github.com/darktable-org/darktable

Choice of display profile affects histogram, color picker values and overexposure indicators

opened 07:16PM - 03 Nov 19 UTC

closed 05:50PM - 02 Jan 21 UTC

flannelhead

reproduce: peculiar

**Describe the bug** It doesn't seem possible to saturate the black level to yi…eld zero RGB values. [black_level_test_file_and_xmp.zip](https://github.com/darktable-org/darktable/files/3801996/black_level_test_file_and_xmp.zip) **To Reproduce** Steps to reproduce the behavior: 1. Open a raw image with no edits (an example Olympus ORF file attached) 2. Enable the Exposure module 3. Set black level correction to 1.0 4. Enable under/overexposure indicator 5. Observe there are no parts of the image indicated as underexposed (I have the underexposure threshold set at 2% which is the default) 6. Color picker also shows a minimum value of `RGB = (6, 6, 6)`, at some point this becomes independent of the black level correction (e.g. the same result with 0.1 and 1.0) 7. Tried also doing some other adjustments (e.g. contrast, brightness) but no adjustments seemed to reduce the RGB values 8. Increasing the underexposure threshold to 3%, now most of the image is shown as underexposed **Expected behavior** Most of the image should be shown as underexposed and there should be completely black pixels (`RGB = (0, 0, 0)`) **Platform (please complete the following information):** - OS: Arch Linux x86_64 - Version a82f213ad14f17148cd5e9be3d909a372a3ad521 **Additional context** In my usual workflow I have used the over/underexposure indicators to observe clipping e.g. when doing adjustments in Filmic, but now the underexposure indication seems to be broken. I can try to find the most recent version where this worked (next week) if it is beneficial. This also doesn't seem to depend on whether OpenCL is enabled or not.

github.com/darktable-org/darktable

[RFC/WIP] Move overexposed before colorout

darktable-org:master ← flannelhead:overexposed-before-colorout

opened 05:44PM - 31 Jan 21 UTC

flannelhead

+1 -1

I'd like to propose moving the `overexposed` module before `colorout`, at least …for the scene-referred workflow. This PR is by no means complete but introduces a minimal change to observe the effects and benefits of doing it. ### Why? In the current module order, the `overexposed` module is placed after `colorout`. When editing an image, `colorout` uses the chosen display profile, which is likely to have a small gamut. If one wants to see examine e.g. the saturation clipping in a wider gamut (e.g. having linear Rec2020 RGB as the work space), the clipping indicator is not useful here (it won't show any clipping) because the image is already clipped to a smaller gamut in `colorout`. Let's have a look at an image where the saturation is exaggerated for illustration purposes (just a random image I had at hand, nothing special). The raw image and XMP are attached. [clipping_example_image.zip](https://github.com/darktable-org/darktable/files/5900275/clipping_example_image.zip) Here are the clipping settings: ![clipping_settings](https://user-images.githubusercontent.com/5001906/106392331-f26a6e80-63f9-11eb-84da-5be2fe457534.png) Clipping indications with `master`, when `system display profile` is used for display profile and `linear Rec2020 RGB` for histogram profile (profile settings are also shown in the image): ![clipping_1](https://user-images.githubusercontent.com/5001906/106392430-758bc480-63fa-11eb-93ec-69360da0650f.png) Notice no saturation clipping is shown. One can eliminate the clipping to a smaller gamut and see the real saturation clipping by setting the display profile to linear Rec2020, but then the preview image is obviously incorrect. ![clipping_2](https://user-images.githubusercontent.com/5001906/106392462-a10eaf00-63fa-11eb-8d02-2480a8c5ad4d.png) With this PR applied and `system display profile` selected as the display profile: ![clipping_3](https://user-images.githubusercontent.com/5001906/106392474-aff56180-63fa-11eb-88e4-722566ff1b92.png) The preview image and clipping indicators are both correct. Note: obviously device-specific display profiles are all different, but one can replicate these results also by selecting sRGB as the display profile. This change particularly affects the saturation clipping indicators. To me it makes more sense to observe the clipping before clipping the image to a smaller gamut, especially when almost all the selectable histogram profiles have a larger gamut than a typical consumer-grade display. This is the case particularly for the scene-referred workflow. A use case for observing saturation clipping in e.g. linear Rec2020 is to catch potential imaginary colors that could cause problems. Overall this move would make the clipping indicators behave better, independent of the chosen display profile, and less surprising. ### Pitfalls There are some modules that come after `colorout` but before `overexposed` in the current module order. For the scene-referred workflow: * `clahe` (which is deprecated) * `finalscale` (shouldn't affect the clipping as far as I can tell) To me it would seem fine here to move `overexposed` before these modules. For the display-referred workflow: * `channelmixer` * `soften` * `vignette` * `splittoning` * `velvia` * `clahe` * `finalscale` Some of these certainly have an effect on the colours and clipping. ### Open questions * What will happen to old edits? I suppose ones with an unmodified module order will be fine but what about those with custom module order? Can we force `overexposed` to move somehow also in these cases (as it is not user controllable anyway)? * What about the display-referred workflow? I realize having the `overexposed` module in different places for display-referred and scene-referred workflows may cause documentation issues. But the mindset is pretty different between these workflows anyway, and there are plenty of other differences that are already documented. * Could this be made a user preference, like the scene-referred vs display-referred and modern/legacy chromatic adaptation are now? * Minor aesthetic nitpick: the clipping indicator colours in `overexposed` could / should be given fixed XYZ coordinates, ideally well within sRGB, to make them constant even if the work profile changes.