Weird edges after filmic's highlight reconstruct

If you are responding to @kofa…I think he is just suggesting a way to not have to reinstall but to check things out with a new fresh database and config files…

There are a slew of command line options you can add when you run DT … one is --configdir “path” if you run this you can use it to 1 specify where your config files live instead of the default location… B run DT and point it to a new clean folder and it will create fresh brand new config files…this can be good to test for an issue with corruption… or you can use this to run multiple versions of DT on the same machine… directing each to its own config folder… most common would be when you have the release version install and also you check out the current master code and or any PR that you are interested in testing…

It answers the question:

:slight_smile:

Uninstalling darktable, at least on Linux and Windows, does not remove those files, so if you think your issue is due to corrupted configuration, reinstalling won’t help (if Mac behaves the same way). It would only help in case darktable itselft were damaged (due to file system corruption, for example).

See the files mentioned here:
https://docs.darktable.org/usermanual/4.2/en/special-topics/program-invocation/darktable/
.config/darktable/library.db
.config/darktable/darktablerc

The most important files:

  • darktablerc: configuration (the stuff you can adjust from darktable 4.2 user manual - Preferences & Settings, as well as some hidden settings, default mask opacities and the like)
  • data.db: tags, styles, presets, locations
  • library.db: editing history of imported images

I get what you’re saying. However, I’ve renamed the whole darktable directory to invoke the creation of a new one and the issue persists. Could it be a system compatibility problem with the M1 Pro chip? Anyone else having this problem?

I doubted it was due to a preference. You should probably file a bug report:

1 Like

Thanks for the support over the past few days Kofa. I’ll probably do it in the next week or so since I’m pretty busy with other work too and I’m also not too familiar with Github yet :sweat_smile:

One thing maybe worth trying, (although I’m far from an expert) if you have OpenCL available, might be to try disable it, or enable it if it’s available but turned off. Edit… wonky grammar sorry! At least on Windows it’s in the preferences here: “activate OpenCL support”.
OpenCL utilizes the GPU to speed up processing, and at least on some modules it uses a different processing path I think.

Steven, thank you so much for the suggestion. It fixed my problem!

Just out of curiosity, is there why the OpenCL and larger resource limit helps to eliminate such artifacts? Is it something to do with the computer having sufficient computing power to finish all required calculations within the processing modules?

Its explained pretty will here including the options…

https://docs.darktable.org/usermanual/4.2/en/special-topics/mem-performance/

2 Likes

I don’t think those tuning params should influence correctness.

I’ve tried with different settings (OpenCL on/off, resources = large & small), but was unable to reproduce the issue. I’m glad it works for you, but it’d be good if you could provide an XMP and the darktable settings that recreate the issue, and opened a bug.

I think it actually indicates a bug in darktable, as @kofa was saying. It’s interesting! I suggested it as I’ve seen one or two unrelated issues before which behaved differently with OpenCL off/on, so I thought it worth trying.
Thanks for attaching the Raw, it would be useful if you could also upload the xmp file from the image, i.e. the “sidecar file” that darktable produces alongside the RAW file. It would need to be with settings applied that cause the issue (or caused it when you had OpenCL off). If you have dt set to not write XMPs you can hit this button in lighttable to write one.
image

Well you could run the xmp in both cases and see if one invokes some cpu or tiling and perhaps that is not handled correctly on the machine/OS if the resources are too low??

Yes, that’s an option.
@Damian_Liew : I may have missed the XMP, have you shared it?
If you run darktable 4.2 with -d tiling (and the settings that trigger the red line), do you get any error indications?

I was thinking about even running it in the two resource configurations and then look at the processing and see how it differs if at all??

I’ve already done that, but have not been able to reproduce it locally. However, the profiles are relative to the installed memory; small taking 20%, default taking 60% and large taking 75% of RAM. I’m lucky to have 64 GB, so for me those would be ~13 GB, 38 GB and 48 GB, but on an 8 or 16 GB machine those numbers would be rather different.

Let me give it a shot sometime this week when I’m free. I’ll share the xmp and settings that allow me to reproduce this issue. Really appreciate all the help and support I’m getting. Thanks guys!

Funny story. It didn’t take that long :sweat_smile: Here’s the .xmp. It’s reproducible with all default settings on my device (see screenshot). Bug report might take a while; I’ll ask some of my friends how to navigate Github haha…

DSC00057.ARW.xmp (5.0 KB)

Hi @kofa, just posted a bug report on Github. Perhaps you can have a look at it there and I’ll try my best to help you. Quick question, how do I launch darktable from the CLI? Is there a binary file I’m supposed to open or is darktable itself the command? It says for me that the darktable command is not recognised. My version was downloaded from Homebrew so not sure if that’s a possible issue.

I’m just a user, so I won’t be able to fix this for you. :slight_smile:

Yes, darktable is the binary itself (under Windows: darktable.exe, Linux: darktable, Mac: no idea).
See darktable 4.2 user manual - darktable

I think I fixed the underlying issue with the red line after reproducing. Fix already merged in master.

If there are remaining issues let me know…

3 Likes