aurelienpierreeng / ansel Goto Github PK

Whenever I open an image in darkroom I have this warning message:

(base) aadm@psion:~ $ ansel
[get_output_profile] called with ICC type -1
[colorspaces] Trying to fetch embedded profile.
image 56154
embedded color profile NOT found
embedded matrix NOT found
[colorspaces] could not fetch the profile.
[colorspaces] WARNING: no colorspace found, sRGB will be tagged in final exported file. Colors may be inconsistent

I'm simply not sure about all these warnings. Is there a problem? Why does it say "no colorspace found"? These are all raw files. The fact that the output will be tagged sRGB is not a problem (I think) because that's the default you want to send out to a printing service for example.

• version : this is ansel c5a7bb6
• OS : e.g. Linux - Ubuntu 22.04.01 LTS, Gnome version 42.5, X11 Windowing system
• Memory : 32 Gb
• Graphics card : Nvidia GeForce RTX 2070 Mobile
• Graphics driver : latest?
• OpenCL installed & activated: yes

extra information

I also have issues with my display profile as I also get an error from ansel-cmstest:

(base) aadm@psion:~ $ /opt/ansel/bin/ansel-cmstest 
ansel-cmstest version c5a7bb6
this executable was built with colord support enabled
ansel itself was built with colord support enabled

primary CRTC is at CRTC 0
CRTC for screen 0 CRTC 1 has no mode or no output, skipping
CRTC for screen 0 CRTC 2 has no mode or no output, skipping
CRTC for screen 0 CRTC 3 has no mode or no output, skipping
CRTC for screen 0 CRTC 4 has no mode or no output, skipping
CRTC for screen 0 CRTC 5 has no mode or no output, skipping
CRTC for screen 0 CRTC 6 has no mode or no output, skipping

DP-0	the X atom and colord returned different profiles
	X atom:	_ICC_PROFILE (724 bytes)
		description: sRGB built-in
	colord:	"/home/aadm/.local/share/icc/SW2700 #1 2022-12-15 10-00 120cdm² D6500 2.2 F-S XYZLUT+MTX.icc"
		description: SW2700 #1 2022-12-15 10-00 120cdm2 D6500 2.2 F-S XYZLUT+MTX

Better check your system setup
 - some monitors reported different profiles
You may experience inconsistent color rendition between color managed applications

The profile for my monitor was made with DisplayCAL which then proceeds to install it; it seems like colord sees it but then I have this warning message about X atom and colord diverging. I don't know what is X atom and how would I "change" it to load the correct profile. This has probably nothing to do with the above issue though but I thought better to mention it.

The information overlays that should be seen on the lighttable thumbnails are missing.

The raw chromatic aberration module has disappeared, even from manage preset

darktable version : Last R-Dt
OS : xfce 22.04/linux 5.15
Linux - Distro : Ubuntu Studio 22.04
Graphics card : Geforce 1050 Ti
Graphics driver : 470
OpenCL installed : y
OpenCL activated : y

I like to be confident I have an XMP to match my output (eg jpeg) and not risk accidentally losing it by making further edits.
I always add some kind of subject words to my output file name. I make an XMP with exactly the same file name as the output, outside dt. How about having the option in dt to do this automatically? That is, no need to affect the current "default" XMP file name or its processing/usage. But in addition output an extra XMP named like the main output. If it already exists, just overwrite it?
I guess it would be necessary to turn this on or off per user in Preferences or in the Output module.

Issue

According to the recent poll I ran (https://github.com/aurelienpierreeng/ansel/discussions/46), the value range of the chroma sliders in the 4-ways tab is too large, making it difficult for users to quickly and precisely pick their desired value.

Over 80% of participants in the survey don't use the top quarter in any of the four sliders on a regular basis. Moreover, only 15% of participants use the shadows lift chroma slider between its middle and maximum value.

Expected behavior

Users are able to pick values quickly and effortlessly. I suggest a 25% decrease of the current value range for each slider, potentially more for the shadows lift chroma.

The borders allowing to collapse panels (side, top, bottom) have been removed to free more real estate. But now panels can only be collapsed from keyboard.

Solution : add a contextual menu appearing on right click (anywhere but on sliders, which already have their right-click thing), with a "display" menu, and one show/hide entry per panel, plus filmstrip etc. Also : remove the stupid cycling between headers and footers options. Hide or show, period.

Future : in lighttable, the contextual menu could be extended to perform typical file management (delete, group, export) over the current thumbnails selection. You know, like… any fucking file manager.

Manjaro/Arch/Current git/XFCE
This may be connected to my use of XFCE! I have a panel located across the lower part of the screen which is supposed to function 'intelligently'.
When I run dt the application frame is always 'locked' in the Maximize condition regardless of the tab being used.
With r&dt whenever I move from the darkroom to the lighttable the application frame changes to the Minimize mode.and the lower part of the frame is cut off and cannot be reset to Maximize.
I would like the frame size to remain as Maximize without regard of the tab being used.

I understand that you're revamping the stars rating approach. Your forked version (as of 3.9.0+1781~gb8cdc71b6-dirty on Windows 11) seems to have disabled the keyboard shortcut for ratings. For example, I select an image and type a "3" then a message will pop-up stating "3 not applied". I don't know if this is intentional, but the keyboard shortcut was a bit of a time saver. Good luck with your efforts!

Rawspeed doesn't apply a Quadrant Correction to IIQ Phase1 P65+ files. I submitted the problem in 2019.

I tried IIQ files with differents softwares which use Libraw (Rawtherapee, ART, Ufraw, Rawdigger/fastrawviewer) without the problem.

Libraw is implemented into Darktable but it seems not used to open the IIQ P65+ files.

Is it possible make Libraw used to open IIQ P65+ files?

What is the current problem you are facing ?

Target middle-grey stays the same when changing target white luminance inside the display tab of filmic when preparing images for printing on Instax printer. Ideally for my usecase it would automatically adjust relative to the target white luminance.

EDIT: after thinking some more about it, my real issue is fitting my picture into the DR of my printer easily, while being able to save that as a preset. How that's done is not very important to me.

Where in your workflow does your problem occur ?

Let me start by saying that I'm not sure if this is the right way to go about what I want to do. If not, please let me know what the best way to deal with this is, although it seems like this is what filmic is for, compressing the DR to fit the target medium.

Let me elaborate, I have an instax printer that I like to use for printing candid shots with family and friends. It's a lot of fun, but the DR of the film is not huge, and I need to compress it quite a bit to make it fit (not blow the highlights on the film). I've been handling this via tone equalizer, at first, although I've recently tried the display tab inside filmic, lowering the target white luminance as needed, which seems like the way to go. The problem: the target middle-grey stays the same.

I can easily figure out what the target middle grey should be relative to the target white luminance, although it would be nice if this could be automatic.

My instax workflow:

Edit my picture as usual. Lower target white luminance. Figure out target middle-grey value. Change contrast in highlights and shadows from hard to safe so they don't overshoot.

ansel built from source, liblua 5.4 installed, lua support gets recognized and built-in during compile.

At first launch with brand new config lua support is present, I can install scripts no problem, but then at second launch the lua menu disappears. Lua support used to be working correctly until a few commits ago (mid-december I think, can't remember the commit id unfortunately).

The output color profile module in darkroom has a color space parameter that can be set by the user. However, this will get overridden by :

• the display profile, for previews and thumbnails,
• the export profile, for exports.

There is a slightly deviant way of using it, though, by using the "image setting" option in the export box "profile" setting. But this is mostly unused, since there is no way to know what this image setting actually is at export time, and it is impractical to check it for batch export.

That is to say that the in-module profile is at best useless, and at worst misleading to less experienced users.

Solution:

• remove the color output profile from darkroom's GUI,
• rename the "image settings" option of the export box "same as original",
• make the "same as original" option use the embedded profile of the original image if any, else default to sRGB. This will be useful for example to resize or crop a batch of images using different color spaces without rewriting their color space.

Check list:

• : RAWs (non-DNG) exported with "same as original" should export as sRGB
• : DNG with embedded matrix exported with "same as original" should export with their original matrix (in linear RGB, expect posterization in shadows if using 8 bits) and have it embedded,
• : JPEG / PNG / TIFF exported with "same as original" should use the same color space as the original space.
• : RAWs exported with any color space should work as previously.

How to check color profiles:

1. open the pictures in Gimp or Krita, output should look the same,
2. Using exiv2 -g ColorSpace test.jpg, should return:

Exif.Photo.ColorSpace                        Short       1  sRGB

for sRGB exports, or for any other space:

Exif.Photo.ColorSpace                        Short       1  Uncalibrated

3. Using exiftool -icc_profile:* test.jpg should return various useful info, like the color space name:

Device Model Desc               : Adobe RGB
Device Mfg Desc                 : darktable

or the color matrix of the color space embedded in the file:

Profile Description             : Adobe RGB (compatible)
Profile Copyright               : Public Domain
Media White Point               : 0.9642 1 0.82491
Chromatic Adaptation            : 1.04788 0.02292 -0.05022 0.02959 0.99048 -0.01707 -0.00925 0.01508 0.75168
Red Matrix Column               : 0.60974 0.31111 0.01947
Blue Matrix Column              : 0.14919 0.06322 0.74455
Green Matrix Column             : 0.20528 0.62567 0.06087

you can compare it with the color matrix of your original file if any.

What is the current problem you are facing ?
It would be good if Ansel development and stable release could released in the snapstore. This would enable users to quickly install the packages to test the unstable and stable version on their Ubuntu systems.

Additional context
Darktable has already been packaged as snap. This bug only relates to setting up and publishing ansel packages to the store.
https://snapcraft.io/darktable

ubuntu 20.04 R&Dt 3.9.0+1647~gebb12ab06 color EQ branch
i7 NO GPU

To reproduce - increase a slider for saturation or brightness, see the graphic change, click reset, slider resets, graphic doesn't.

.

Ansel-0.0.0+8~gc4cb3fcb0-x86_64_6c2f24e5738add7be1670543827a4036.AppImage is missing Lens Correction Module.

Too many Linux distros ship outdated Lensfun libs. Users will need to run lensfun-data-update but most of them are not aware of that.

https://lensfun.github.io/manual/latest/dbsearch.html shows how to use a custom directory to load the data. The database should be loaded at building time, then CMake should be configured to install it somewhere like /opt/ansel/share/lensfun so the nightly packages are always up-to-date.

To my humble opinion the color picker and the previews and the image display
in scaled (non-100%) darkroom edit mode do the wrong RGB calculations
(non-linear RGB instead of linear RGB).

I do not want to copy all details from pixls and github again here.
May be Aurelien can have a view on this:
https://discuss.pixls.us/t/rgb-calculation-color-picker-and-display-wrong-exposure-module-solved/34204

Here is also my simple checkerboard test file, which should stay for all zoom ratios with perceived
and color picker light yellow (188,188,128) and NOT with light red(188,128,128):
darktable-org#12310 (comment)

In addition I found, that also the JPG export of scaled down images is wrong in DT.
May be Ansel is more sensitive to correct such annoying limitations of RGB processing.

Thank you very much
Rudy

I appreciate all the work you've done on the technical side of Darktable and taking the time to clean up the UI for this fork. Can you clarify if the current commit is current with the upstream 4.0 release? I'm a little confused as GitHub hows this as forked from another fork of Darktable.

I guess this is somewhat specified in the wiki, but for more concreteness, will you make a release (or a tag) for a version that is a modified Darktable 4.0? Will you continue updating such a version or do you plan to always be based on the current git version of Darktable (or maybe maintain 2 branches, one for current Darktable release and one for git version)?

Thanks!

PS: For anyone using GNU Guix as a distro or package manager, I was able to build this fork with guix build darktable --with-git-url=darktable=https://github.com/aurelienpierre/R-Darktable or even better, run it directly with guix shell darktable --with-git-url=darktable=https://github.com/aurelienpierre/R-Darktable -- darktable. It just works.

Applying an image style to an original photo applies the style and expands seemingly random modules. (Most often, "color balance rgb")

This issue is unique to R&Darktable, since in Darktable only one module can be expanded at a time.

While this isn't a severe issue, but if a style contains a stack of color balance rgb modules, with masks, the module list becomes and endless stream of expanded color balance rgb modules.

The workflow becomes:

1. Click on an original image
2. Apply a style
3. Scroll/Aim for a module name (any) and Shift+click to collapse all, except for the selected module.
4. Hope that the focused module isn't "color balance rgb" since it take the whole height of the screen anyway
5. Shift+Click on the module you want to work on.

Whereas the workflow should be:

1. Click on an original image
2. Apply a style
3. Shif+Click on a collapsed module in the stack to modify the values

To Reproduce

1. Create a development with 5-6 "color balance rgb" modules
2. Create a style and include all the "color balance rgb" modules (collapse them all, or don't, doesn't matter)
3. Select any original photo
4. Apply the style from the Darkroom view (bottom left corner)
5. Should result in too many modules expanded.

Expected behavior
...
...
4. Apply the style from the Darkroom view (bottom left corner)
5. Style applied with all modules collapsed (ideally)

Screencast
https://www.youtube.com/watch?v=cFaKLzjJLaw
(don't know what happened to the mouse pointer)

Which commit introduced the error
R&Darktable 3.9.0+1641~g63deb9862

Platform
_Please fill as much information as possible in the list given below. Please state "unknown" where you do not know the answer and remove any sections that are not applicable _

• darktable version : 3.9.0+1641~g63deb9862
• OS : Win11 Build 22000

When working with HDRs, I like to combine the source pictures and the result into a group. When I have grouped n pictures and select the following m pictures in order to make a second group, I end up with one large group of n+m pictures, UNLESS I first collapse the first group, which is annoying. (This may have been an issue with the original darktable, at least it does occur in version 4.0.1.)

DxO's Pure Raw 2 produces rather nice DNGs that can be processed further in R&Darktable. However, when exporting to JPEG (or PNG), the results look much darker than exporting from the original CR3s (from my Canon R5), even though in R&Darktable both versions look quite similar (except for denoising and geometry corrections). Actually, I just copied the development stack from the DNG to the CR3.

This happens on a Gentoo Linux system, Kernel 5.15.59. I've compiled R&Darktable myself according to your instructions. I do not know if DNGs generated with other software exhibit the same problem.

Unfortunately, when trying to attach sample images, I get an error message: "Something went really wrong, and we can't process that file.", both on firefox and on Google Chrome.

I had noticed that jpeg, i exported from dng in r-darktable has some color artifacts.
Jpg:

200% to see it more clearly

Screenshot from phone. Image looks broken

I used same xmp-file to repeat this in Darktable 3.8.1, but there is no artifacts:
Jpg:

200%

Screenshot from phone.

I haven't tried testing it on upstream darktable though.
I use up to date r-darktable 3.9.0+1730~g16aa4bf6b-dirty on Fedora 36 x86_64

broken_image.tar.gz

Describe the bug/issue
I first build Darktable 4.2 following the instructions written in packaging/macos/BUILD.txt. After installing all dependencies I could compile and install. DT 4.2 is running up.

Following the same instruction I could build Ansel. Compiler ran into one issue by compiling src/osx/osx.mm. Replacing through the one of DT 4.2 did the trick. Then I ran in two issues during install (using "cmake --install ."): Install wanted to install the executable "darktable-curve-tool-helper" but "ansel-curve-tool-helper" has been created. The same happened with "darktable-gen-noiseprofile" ("ansel-gen-noiseprofile" has been created). After manually renaming the executable file names in the cmake install scripts, all ran through.

Ansel is now running: Few pictures loaded and "developped" with standard settings: No issue so far.

To Reproduce

• Follow instruction of (DT 4.2) packaging/macos/BUILD.txt by installing dependencies
• git clone ansel
• run cmake to create configurations
• run make
• compiler stops by compiling src/macos/osx.mm
• run cmake --install .
• cmake stops by installing darktable-curve-tool-helper and darktable-gen-noiseprofile

Expected behavior

• Compile runs through without error
• Install runs without error

Platform

• ansel version : master (8/1/2023)
• OS : MacOS Monterey 12.6.2 Intel
• Linux - Distro :
• Memory : 24GB
• Graphics card : Radeon RX 580 8 GB
• Graphics driver : Native
• OpenCL installed : yes
• OpenCL activated : yes
• Xorg : n/a
• Desktop : n/a
• GTK+ : macports 3.24.34
• gcc : Apple clang version 14.0.0
• cflags :
• CMAKE_BUILD_TYPE : cmake .. -DCMAKE_OSX_DEPLOYMENT_TARGET=10.14 -DOpenMP_C_INCLUDE_DIR=/opt/local/include/libomp -DOpenMP_CXX_INCLUDE_DIR=/opt/local/include/libomp -DCMAKE_LIBRARY_PATH=/opt/local/lib/libomp -DBINARY_PACKAGE_BUILD=ON -DRAWSPEED_ENABLE_LTO=ON -DBUILD_CURVE_TOOLS=ON -DBUILD_NOISE_TOOLS=ON -DDONT_USE_INTERNAL_LUA=OFF

Describe the bug/issue

To Reproduce
Please provide detailed steps to reproduce the behaviour, for example:

1. Open ansel
2. Click on Display Metadata on the right side

Expected behavior

Window do not expand, all things in screen

Actually happened

Window becomes larger even in maximize state, thumbnails bar is out of screen, and cannot shrink window in vertical if it's not maximized.

Screencast

Which commit introduced the error

Not sure

A bisect is much appreciated and can significantly simplify the developer's job.
HowTo: https://github.com/darktable-org/darktable/wiki#finding-bug-causes and https://www.youtube.com/watch?v=D7JJnLFOn4A

Platform
_Please fill as much information as possible in the list given below. Please state "unknown" where you do not know the answer and remove any sections that are not applicable _

• darktable version : this is ansel 459c476
• OS : 6.1.4-arch1-1
• Linux - Distro : Arch Linux
• Memory : 32G
• Graphics card : NVIDIA RTX 2070 Super
• Graphics driver : nvidia
• OpenCL installed : y
• OpenCL activated : y
• Xorg : Wayland
• Desktop : GNOME
• GTK+ : 3.24.36
• gcc : 12.2.0
• cflags :
• CMAKE_BUILD_TYPE : Release

Additional context
Please provide any additional information you think may be useful, for example:

• Can you reproduce with another darktable version(s)? not sure
• Can you reproduce with a RAW or Jpeg or both? both
• Are the steps above reproducible with a fresh edit (i.e. after discarding history)? yes
• If the issue is with the output image, attach an XMP file if (you'll have to change the extension to .txt)
• Is the issue still present using an empty/new config-dir (e.g. start darktable with --configdir "/tmp")? yes
• Do you use lua scripts? NO

Unlike with the most recent "stable" version of darktable 4.0.1 , I can't get CR3 raw files coming from the EOS R7 to work with the master branch of R&Darktable.

Building the version works fine for me, but unlike Raws from R5 and R6, which seem to work, CR3 raws from R7 are nit working with the recent master.

Color labels can be defined by keyboard shortcuts (F1 to F6 by default), or by selecting the thumbnails then travelling all the way to the bottom of the screen to click on the right labels. This is non-ergonomic (too much travel).

Solution : have clickable color labels on thumbnails (like the stars), then remove the labels from the bottom bar and make some room.

It is currently impossible to accurately set a constant border for two or three sides. Most used case: constant border on top and sides, but larger border at the bottom.

The map, printing and slideshow views are niche features used only by a minority of users. Problem is, they are still enabled for all users. Gtk widgets are drawn and therefore computed as soon as they are declared in UI, no matter if they are visible or not for the end-user. That's CPU cycles lost for everyone. Especially for the map view, which might be loading map tiles from the internet (or not).

Solution: make map, printing and slideshow views available only optionaly. If disabled, they will not even be declared and initialized in UI (will require a restart).

After update, the time remains empty

• kernel 5.15.0-41
• Linux - Distro :Ubuntu 22.04 studio
• Memory : 32Gb
• Graphics card : 2x Geforce
• Graphics driver : 470
• OpenCL installed : Y
• OpenCL activated : Y
• Xorg :
• Desktop : xfce
• GTK+ :
• gcc :
• cflags :
• CMAKE_BUILD_TYPE :

I previously reported that I was having problems with the Maximize window setting when in the darkroom mode. I thought that the problem was solved when I changes a setting for font scaling in my settings manager. However the problem has surfaced once again and following system and program upgrades it is now apparently worse.
The lighttable window is fine .... I can maximize/minimize and scale the window in both directions. The problem is only seen in the darkroom window.
In the darkroom window maximize simply does not work and the window fails to scale in the vertical direction so that 1/4 of the screen is not available.
I am running R&D on an older laptop (Lenovo W530) with Manjaro/Arch/XFCE ..... nothing fancy.
As a test this morning I switched over to the regular dt to try and determine if this was a system related situation .... regular dt functions correctly.

Describe the bug/issue
In Darkroom, if I select multiple pictures from the filmstrip and then use keyboard shortcuts to perform operations only the opened picture is affected.

To Reproduce

1. Open Picture A with darktable
2. Select other pictures in the filmstrip (Alt+click or Shift+click)
3. Use shortcuts to do something (Ctrl+V, 0 - 5, F1 - F4)
4. Only picture A is affected

Expected behavior
All the pictures in the selection are affected.

Platform
running appimage0.0.0+53~g664c527d3 on Ubuntu 22.04

Additional comments
I believe at some point darktable had a 'select on hoover' behavior that could also be used to affect pictures other than Picture A (not a huge fan, but better than nothing).

Since we are at it, I would like to point out that I find the Filmstrip kind of awkward to use (I must say I used to like it before the 'one click selects the image' behavior was introduced, sometime in 2020).

My wish: I am using darktable on a Desktop with mouse and keyboard, I mostly do light edits to batches of pictures to be shared with friends (no fine-art). My ideal workflow is:
1- edit one picture,
2- copy-paste the edits to the nearby pictures that look somewhat similar to have a starting point,
3- do finer tuning and decide which pictures look best,
4- make the pictures I am not satisfied with disappear by degrading/rejecting them.

I used to be able to do all of this without leaving the Darkroom, which was nice. For steps 2 and 4 I find it very convenient to use the Filmstrip, rather than jumping back and forth between Darkroom and Lighttable.

My problems:

• with the current behavior I have to open the images one by one to make the modifications, which is way more inconvenient.
• I find it confusing that the open picture always counts as selected. More in general, when multiple pictures are selected I never quite know what will happen if I copy or paste the history stack (copy from where? Paste on which pictures?). I think that old darktable (pre 2020) was more transparent in these aspects.
• I am not sure I see the logic in making the selected pictures of the filmstrip agree with the selected pictures of Lighttable. In my mind the former should just be a quick selection tool to do very basic operations, the latter selects which pictures to export, tag etc...

One comment: it seems a waste that the right click on Filmstrip does not do anything. Intuitively, I would expect it to raise a menu from which I can select copy/paste and be 100% sure that I am copy/pasting from/to the right picture.

If the answer is that I am using Ansel wrong and there is a better way, I am willing to accept it (but I do not think styles are the answer: these are usually travel pictures that require always different edits).

Since version from 2023.01.06. some pictures are black. See attached screenshot.
It had not been like this in older versions.

The History Panel is empy. Running Ansel 0.0.0.0 on Win10...

Any other information needed?

PS: I am not shure if I should place my bugs here. Is this the right place (Github Issues)?

Perhaps it would be good to use some kind of metrics system to collect data about crashes using tools like Sentry.io or something similar.

AFAIK it should be possible to hook up tools to report data and sentry does provide a free tier for open source projects.

Additional context

https://sentry.io/for/open-source/
https://sentry.io/for/c-plus-plus/

Investigate darktable-org/dtdocs#520

Likely a side effect of the work you are doing and you likely know .... Color picker seems to show the right color selected and represented in the patch and reports values for Lab and LCh but not the other options... Observed after building Win version tonight...

What is the current problem you are facing ?

The snapshot sliding overlay view works great for comparing before and after changes, but is cumbersome when working with reference images.

Where in your workflow does your problem occur ?

After watching your last video on recreating the "film look" in darktable, I couldn't help but remember my struggles when using snapshots as a reference. The problem as I see it is that this view is not the right tool for the job. It involves so much sliding, rotating, readjusting the view, and thus, clicks.

My workflow is as follows, I open the reference image (in darktable), take a snapshot, go to the image I intend to work on, enable the snapshot, and start matching that look (adjusting the snapshot view every time).

Additional context

Ideally, I'd love to do the same thing, but without all the clicking. Meaning, create a snapshot, go to the new image, enable it, and just work on the image, not fight the snapshot view.

The definition for "raw" is unprocessed linear file. Back in 2010, that also implied mosaiced RGB files. darktable was coded around the idea that raw was both mosaiced and unprocessed linear. But Leica monochrome sensors forced to re-evaluate this definition.

The implementation of monochrome pictures is buggy because they are not flagged as "raw", which means they don't get the default scene-referred defaults, that check for the "raw" flag.

The raw flag needs to be split into a "mosaiced" and an "RGB" flag to properly handle modules enabled by default.

It would be nice to have yellow as a specific colour to make changes to (saturation, hue and brightness), in addition to those already catered for.

It would also be nice to apply a hue to grey areas. (And change brightness too maybe)

I can get more detailed if needed but basically the build process is throwing an error saying it can't find GTK libraries... Gtk 3.24 is installed.... not sure it this is just something weird?? I can build DT fine and no such error. I had started from a fresh clone and then cleared the build dir a couple of times...Can't build with the script or manual commands...

I will pursue this further if someone else has the same issues...

Running WIn11... and previously have built R-Darktable a few times??

Did I miss something? I pick a region bright or obscure, the rectangle input in spot exposure mapping remains the same (black). The target strip & lightness cursor follow the picker. The spot mode is on correction.

• darktable version : Last R-Dt
• OS : xfce 22.04/linux 5.15
• Linux - Distro : Ubuntu Studio 22.04
• Graphics card : Geforce 1050 Ti
• Graphics driver : 470
• OpenCL installed : y
• OpenCL activated : y

Describe the bug/issue
I can’t import '.CR3' in Ansel because they do not show in the import dialog.

To Reproduce

1. Click on 'Open from disk...'
2. Select a folder containing '.CR3' files
3. '.CR3' files are not displayed

Platform

• Ansel version : Ansel-0.0.0+27~gd09679b3f-x86_64.AppImage
• OS : 6.1.3-arch1-1
• Linux - Distro : Arch Linux
• Memory : 32GB
• Graphics card : NVIDIA GeForce GTX 1060 6GB
• Graphics driver : official nvidia drivers 525.78.01
• OpenCL installed : opencl-nvidia 525.78.01
• OpenCL activated : yes
• Xorg : 21.1.6
• Desktop : AwesomeWM
• GTK+ : 3.24.36

Additional context

• If I copy a '.CR2' file in the folder, only it is shown as present.

More of a question than a FR, since perhaps there is an option for this hidden somewhere in the settings. I have always been somewhat frustrated by darktable's scrolling behaviour, and this carries onto R&Darktable. If there is a reason for this I apologize in advance for raising the question. It seems like said behaviour is not logical. Scrolling on the image preview in the darkroom works as expected (zoom in/out). On the side panels however, instead of scrolling up/down, like we have come to expect in every webpage and most other applications, it changes the values of whatever slider you happen to be hovering on. I'd expect ctrl+scrollwheel to alter values, instead of simple scroll. In fact, at the moment we have three different modifiers which affect the speed at which the values change: scrollwheel, ctrl+scrollwheel, alt+scrollwheel, ctrl+shift+scrollwheel. If I want to scroll up or down, I have to hover exactly over the scrollbar (at a very slow speed). If I miss (and I often miss), values are changed to my frustration.

My proposal:

• Simple scrolling on all panels should scroll the panel up or down
• Ctrl+scroll (or whichever other modifier you prefer) actually changes slider values.
• Shift+scroll, alt+scroll and/or ctrl+alt+scroll for precision value changes if we still need three scrolling speeds.
• The current shift+scroll behavior I find useless. For large value changes we can simple click or click and drag on the slider, and for incredibly precise value changes we still have right click with the tail thingy.

Should I try and take this upstream, @aurelienpierre or leave this here?

Salut Aurelien,
i played little bit with Ansel to find that it crashes rather quickly using the exposure module. Anyhow as i am no softwaredeveloper in any kind i hope my crash report will help you to make Ansel a good software:

Ansel 0.0.0.0.zip

All the Best

martin

Describe the bug/issue
I get the following message each time I start Ansel-0.0.0+53~g664c527d3-x86_64.AppImage:
Gtk-Message: 17:18:35.117: Failed to load module "canberra-gtk-module"

To Reproduce
Just run the AppImage

Platform

• Ansel version : Ansel-0.0.0+27~gd09679b3f-x86_64.AppImage
• OS : 6.1.3-arch1-1
• Linux - Distro : Arch Linux
• Memory : 32GB
• Graphics card : NVIDIA GeForce GTX 1060 6GB
• Graphics driver : official nvidia drivers 525.78.01
• OpenCL installed : opencl-nvidia 525.78.01
• OpenCL activated : yes
• Xorg : 21.1.6
• Desktop : AwesomeWM
• GTK+ : 3.24.36

Additional context

• I did not get this message when running darktable 4.0.1, nor do I get it with darktable 4.2.0 (can’t test with 4.0.1 any more because of an updated dependency preventing it from starting)

In version 5db60ce (just compiled) the button to collapse groups in the lighttable (first icon, upper right)
seems to have disappeared. Double clicking on the group leader doesn't collapse the group either.
The previous version was compiled two days ago.

Ansel compiled under Gentoo Linux 5.15.88 with gcc 11.3.1_p20221209 and glibc 2.36-r5; lua 5.1.5-r200

Both lighttable and darkroom have some tools in the top bar and some in the bottom bar. That was cute when there were only a couple of ones, but now it's spanning too wide and the splitting top/bottom is kind of arbitrary. Also, the icons of the buttons are not terribly explicit and those icons get redrawn all the time, leading to a perf bottleneck. See darktable-org#11836 for details.

Solution:

1. after #17 is done, the color labels tool from the lighttable bottom bar (left) will go. Use that freed space for the lighttable-centric tools (overlays, grouped images). These will need to be quickly accessed so they need a direct access.
2. In top bar, on the right, group all the common and particular tools under a hamburger menu. All tools will have a textual name, clearer and more efficient than the present cute icons. Common tools will go first, then each view will populate the rest of the list with its own stuff.

As mentioned in #11, scrolling step is too small.

Solution 1: map the scrolling step to the equivalent height of, say, 5 text lines (fetching the actual font size with DPI factor/high-res scaling factor).

Solution 2: (only if the previous one fails) give up and make it user-defined (more prefs, yay \o/).

@StudioPetrikas & @pedrorrodriguez : what is your OS/desktop environment ? (Please don't say Mac OS).

ubuntu 20.04 R&Dt 3.9.0+1647~gebb12ab06 color EQ branch
i7 NO GPU

To reproduce - increase e.g. blue brightness, see artefacts.
E.g. in image below, blue brightening has affected the clouds.

Changing bauhaus slider values seems to trigger a pipeline recompute first, then a GUI redraw. For heavy edits, this introduces a noticeable lag between user action and GUI feedback.

GUI elements need to be redrawn before recomputing pipe. But it is possible that the lag is also caused by thread mutex locks.

To investigate.

Hello,

in module Import from camera, there is some missing fields in English as you can see in the screenshot :

In a specific language like French, the fileds are the same like this :

I have seen the same in spanish but with a different name in fields

I continue the review
Thank you