Ugh, of course that was the problem. Totally forgot about that one, thanks. I guess I just accepted that partial profiles are buggy at the moment and didn’t even try to look for solutions.
So it’s only in combination with local adjustments.
1 Like
@jdc, I am thankful for all the work that you have done and find LA great to work with. Although added features would be nice, I see no reason why I can’t complete my workflow with the current release as is.
Mike
Hello, continuation of my previous message.
As we can’t put more than 10 people “@”, I add some people, sorry to the others for my omissions, I know that you are numerous to have supported me
@Lawrence37 , @paulmatth , @afre , @Entropy512, @chaimav , @Thanatomanic @paperdigits @nosle , @ilias_giarimis , etc.
Jacques
6 Likes
I am glad you have been encouraged. I do try my best to uplift people’s spirits here. 
Also keep in mind that different development teams may have very different views regarding certain aspects of the design.
That’s why ART now exists, for example - Alberto and the RT team often chat about things and pull code from each other, but Alberto also has vastly different views on certain features than the RT team does. (The first thing he did when creating ART was to remove certain features to simplify the UI and improve maintainability.)
1 Like
Isn’t ART built on LibRAW?
1 Like
That was one of Alberto’s major rearchitectures after the fork - removing RT’s heavily modified dcraw derivative and replacing it with libraw. I don’t know about more prominent RT contributors who have more say, but it is IMO one that I agree with Alberto on regarding the approach. I really don’t want to FORC3 myself to deal with Dave Coffin’s for loop macros any more when trying to track down camera-specific glitches. It’s something I’m thinking of looking into as a post-5.9 task.
If there was a situation where someone from the RT team vetoed an effort to replace the current stuff with libraw, I’m unaware of it.
1 Like
There was some discussion about moving away from dcraw (Replace dcraw with actively maintained raw decoding engine (e.g. LibRaw) · Issue #4462 · Beep6581/RawTherapee · GitHub). Switching to LibRaw makes sense to me. It’s also based on dcraw and Alberto has already done the work to integrate it into ART. I can’t imagine the switch being more work than updating the current dcraw code in RawTherapee.
3 Likes
Art doesn’t run very well on my Mac system, and some of the RT tools that were dropped were, in my opinion, very wrongly dropped!
But, opening up CR3 files for instance shows full exif due to Libraw - Libraw makes so much more sense in todays fast changing world of new sensors/cameras every 45 seconds!
4 Likes
Yeah, I’ve briefly looked through Alberto’s work.
It’s one of the examples of why I’m not a fan of merging updates from mainline into a pull request vs. rebasing them - once merged, commits wind up interspersed in history with unrelated stuff, making it harder to find the relevant ones.
Bitbucket has relevant commits going back at least to 2/25/2021, but also a HUGE number of non-relevant commits. Identifying the relevant ones becomes extremely difficult.
2 Likes
The trouble with developer releases is that they’re so strongly implied to be for, well, developers, and that users who aren’t developers should avoid them in favor of the last stable release. In fact, Rawpedia says
“Stable Releases - RawTherapee can be downloaded from our website or through your package manager. The latest release provides a stable version suitable for most users” (emphasis added)
and
“Development Builds - Use a development build if you want to test the newest features and latest changes, and if you are willing to risk potential buggy behavior and do not care that functionality may change between versions.”
To me as a non-developer user, that warning about developer builds screams “DANGER: Blinkenlights program! Fur die ‘Experten’ only! Handle with Builder’s Gloves! Avoid for your production work unless you are desperate, and maybe not even then!” So I stick to v5.8 that came out back in Feb 2020. I suspect that many other users or potential users are put off by this too.
2 Likes
Development builds are where fixes get tested. Release builds contain the caught and uncaught bugs the developers have decided can be thusly tagged with a minor version number. You’re either testing bug fixes or catching new bugs. The ‘stability’ refers to the stability of the various features’ gui and application programming interfaces used by RT, not any relative lack of bugs compared with the dev branch. The only time I will ever run a release build is to test it for release, then I hop back on to the fix testing bandwagon.
True, yes… except when so much time passes between stable releases that the feature set of the dev release becomes a virtual necessity, or at least a strongly desired thing. I think that’s kind of the situation here. I’m not a pro, but dev RT is by far good enough for me to consider it ‘functionally stable’.
Here’s my take on 5.8 vs. 5.8 Dev.
For me the release tempo was too slow during a major gui transition a few years ago, so I learned how to compile it with the help of many folks here and GH. The procedure has been further refined and committed to the repository. I still use the software, and still build and share the builds I make via the rawtherapee.com team and Direct download links to the latest RawTherapee development version.
Larger organizations can provide breakaway release teams without freezing development, whereas the smaller RT group really focuses primarily on getting a few very well-documented release candidates out to beta testers. With the Local Adjustments quantum-leap in 5.9, there is no wonder two years has already elapsed, even in the face of being already many years in developement with almost no gui!