Is it possible to make reordered modules a default? I can point out at least one error in current module order: retouch module shall go before transformations. With current order if you try to retouch an image that was rotated (to align a horizon, for instance) the retouched spots appear in the wrong position. Moving the module solves the issue. But it’s very annoying to move it for each image…
You can open up feature request for that, just to have retouch in “right” place.
I did raise a request to move retouch after crop/rotate (Move 'Crop & Rotate' after 'Spot Removal' and 'Retouch' · Issue #4018 · darktable-org/darktable · GitHub) but was closed as ‘not a fault’. There will be the ability to set module order in a style coming in a future version (Currently looks like it’s flagged for v3.2): po/change iop order by TurboGit · Pull Request #3908 · darktable-org/darktable · GitHub
1 Like
Actually I left a comment about it in an open issue with no result. Also few my other issues were left totally unattended, some of them were automatically closed due to no activity. The bugs are still there…
PS: as a side note, I’ve been using DT since v0.6 or so. V3.0 is the buggiest version ever, a lot of things that worked just fine before are broken. Yet a lot of bug reports are orphans.
Human power is limited and triaging bugs is droll work.
2 Likes
Oh, I’m aware of it and take it into consideration. As well as that it’s FOSS and it’s free (as a beer))). However, I may say that bug situation went out of control (or getting closer and closer). Even since v3.0 I see breakages and regressions, and expect that a “bugfix” 3.0.1 release will introduce more bugs that would be fixed. Which scares me a bit, because all my workflow is based on DT and I see no reasonable alternative to it.
I ended up moving on to master to get a couple of bug fixes I couldn’t live without. Unfortunately, it was only after doing a bunch of edits that I realised there’s no way back to a ‘stable’ 3.0.x version because there are changes in master that are now part of my edit history, and that probably won’t get into a stable version until 3.2 (I think the curved gradient shape was the biggie for me).
In terms of 3.0.1 I get the impression that the developers are fairly careful about what goes into bug fix releases, so I think the chances are that it will be in a better state than 3.0.0.
1 Like
Yeah, I was trapped the same way. I used git versions of DT before, and the experience was all positive… until now. I effectively lost most of my early edits due to messed database after going 3.0.
I hope for this. Yet I filed a handful of bug reports and haven’t seen any progress on them (maybe they’ll be silently fixed). Some of them are quite annoying, like segfaults, or mess with the database, or using CPU when OpenCL is available which slows down the things like x3 (the last one was introduced after 3.0, BTW). At the moment using DT is not fun anymore, and I regret it.
I was more talking about the lower likelihood of introducing new bugs in 3.0.1.
Investigating and fixing bugs is often a very time consuming and not very exciting thing to do. Bugs do get fixed but with people contributing their own time to development, new features sometimes understandably get more attention.
1 Like
TBH I love hunting bugs (and maybe fixing them too)! If I see some sensible bug and I have time, I try to help by at least investigating and narrowing down root cause or trying to replicate.
Huh, now that I think of it, fur “feature request” might’ve been misunderstood by @Pascal_Obry since what you describe isn’t really a feature request but it’s a bug in at least roi calculation. Changing order of those 2 modules uncovered it. Judging from the description I’d move the affected modules just to avoid bugs and in the mean time fix invalid roi calculation.
2 Likes
There were a lot of changes in 3.0, so in a way this isn’t that surprising. Sometimes you have to be persistent in your bug reports, make sure you’ve attached as much information as possible, and maybe even learn how to install GDB to get the backtrace. Also if the bug isn’t 100% reproducable, then it’ll be more difficult.
There isn’t much you can do except get more involved.
1 Like
Just trying to be polite))) If no one’s interested, so be it… And yes, I understand that major rework DT is suffering now will lead to some (temporary) inconveniences. Just the amount of them was a surprise)))
It’s there already, specifically for DT. It also seems I’ve to enable core dump feature for that purpose (which I normally disable not to clutter the FS. Anyways, except DT a core dump is not a frequent case). However, if nobody reacts on the bug reports, it’s just a waste of time… or not? TBH currently I don’t feel it will be of any use, because most of my recent reports were orphaned. I quit programming some 25 years ago, and all I can really help with is reporting bugs and participate somehow in debugging by providing a relevant info. But nobody asks for it…
Most of them are as such, otherwise they’d be wiped out at early stages))) Which doesn’t mean they shall stay forever…
The real situation is even worse. A lot of bugs sit there quietly and show up only under some specific conditions, e.g. on specific graphic card… that may not be at dev’s disposal at all…
That’s the worst. It’s most likely either bad drivers or actually faulty core on card. I think whole slew amd cards require ROCm update since it “overoptimizes” some routines causing bad effects in one of modules.
Hey, I’m usually asking (ever since I started wanting to help more) 
Point me to your bugs and I keep them active 
The most annoying are these two, for starters. Others seem to be resolved or somehow cared now, or closed in favor of related issues, or of lesser importance.
Not mine, but I suffer from it, too. Didn’t know how to reopen it. My comment seems to be lost. (I also learned the lesson that I shall open separate bugs instead of commenting on other, even if it’s completely relevant to the discussion. Except for clear dupes of open bugs. Much higher possibility the comment will be lost in comparison with a separate bug report, even on active discussion).
Also, I’m suffering from segfaults on my last git build, but haven’t reported it yet. I need to rebuild the DT up-to-date to see if the issue is still there and enable core dump in fstab to catch the fault. Then I’ll be able to report it.
Thanks for getting involved!
1 Like
I’ve also experienced the second issue - though when changing exposure via a dynamic shortcut rather than via the histogram. I’ve added a comment to the issue.
Well, the life seems to be getting better)))
Since this turned into a bit of “support thread” my advice to anyone building their darktable:
If you experience crashes while having custom, optimized compiler flags, disable ALL of them and build with debugging symbols enabled.
-Og is great 
I think i’ve seen couple reports on gcc that using -funroll-loops produces code that runs slower than expected etc 
additionally - if you compile with clang it may be also break-prone (more than gcc). So - specifying compiler and compiler flags in error reports coming from self-built darktable with custom flags and/or compiler is a must!
1 Like
I noticed that -fipa-pta breaks latest DT code (there was my report on github). Up to 2.6.X (inclusive) it was fine with all the optimizations I use, rock solid. So I believe that DT shall build and work with all of optimizations as other 1000+ packages of my system do, and if it fails with optimizations, there is a bad code or a bug there, most probably some undefined behavior (-O3 just loves to manifest UBs). But as a temporary measure, sounds very reasonable. However I don’t think it’s related to OpenCL regression somehow))) BTW it’s quite fresh, v3.0 worked just fine.
@johnny-bit, saw your comment on github, will provide all the info you requested. Thanks again!
imho -O3 being not solid is a myth. RawTherapee uses -O3 since a while (some years) without issues.
-Ofast is bad …
My recommendation stands - If you have optimized flags, you should disable them if program is displaying weird behaviour. Enabling them step-by-steps allows developers to see which part of code might create problems and alter it.
There’s nothing wrong with -O3, nor with any other flag.
3 Likes