Trying to locate the roadmap for RawTherapee

Hello.

Is there a roadmap for RawTherapee development?

I ask because I forked the project (jeyoung/RawTherapee) and want to know whether it is worth continuing this personal effort or waiting for future versions of RawTherapee to avoid fragmentation.

So far, I have added UX improvements (e.g., progressive preview rendering, Fast demosaicing override at >=100%, separate XMP sidecar for metadata, etc.), have fixed bugs (e.g., multi-tab editor), and have added limited GPU support (e.g., OpenCL for capture sharpening, transform, etc.)

I started this work to fix the problems that I face in my editing workflow and especially caused by my modest hardware (i7-3770 w/ 16 GiB RAM) trying to keep up with 45 MP RAW images. The performance gains are in a broad range (frequently in milliseconds, sometimes in seconds), but the UX feels much more responsive. Two big wins for me are the ability to pan the image at >=100% whilst it is being processed and forcing Fast demosaicing at >=100% with a toggle button.

I am using supervised AI to help me make these changes, as I knew little of the RawTherapee code before starting this. I guess being a professional software engineer is a good defence against the inevitable AI slop claims. In any case, I have no intention of submitting PR to the upstream repository, unless the real RawTherapee developers want that.

Going back to my initial question, where can I see the roadmap for RawTherapee?

1 Like

Not sure if there is one, though I’ve seen one before for the then upcoming v5.13 if I remember well.
You can contact @Lawrence37 with your question.

1 Like

Try Milestones Ā· RawTherapee/RawTherapee Ā· GitHub

No connection with RT, I knew I had seen this before.

1 Like

Here you go: Roadmap for 5.14 Ā· Issue #7731 Ā· RawTherapee/RawTherapee Ā· GitHub
I always want to see some form of GPU acceleration for RawTherapee, but I don’t want to mess with c++ and graphic APIs which I know nothing about and could be difficult to get right, even with AI. Glad OP is taking the initiative, hope it’ll be worked on and one day become part of the official release.

2 Likes

Not sure if this is the suitable place to report, but I’ve compiled OP’s branch (apparently you need to install ā€˜mingw-w64-ucrt-x86_64-opencl-clhpp’ for OpenCL support) for a quick test:

The preview is faster, and the GUI feels more responsive as a whole, except for the curves, the curves are more laggy than the original RawTherapee. Also, equalizers are also laggy, when their associated modules are activated (when deactivated, their actions are smoother and faster than OG RawThepraee as well).

If OP wants me to report this to your Github issue, please let me know. It is refreshing to see RawTherapee operating in such a smooth manner, and I definitely appreciate it.

1 Like

That is really interesting to see 6.0 listed here. I suppose it’s been planned for years. The big thing I see happening is breaking backwards compatibility. At some point, though, an overhaul is necessary and inevitable. If and when a Win portable version becomes available, I wouldn’t mind taking it for a spin around the block.

Thank you for trying the fork and reporting these issues. You may create an issue, but I am unsure when/if I’ll be able to work on it. I appreciate the report, though. Also, I’m utterly surprised that it builds and works on Windows at all, but I guess, ā€œThanks, MingWā€ :slight_smile:

BTW, if you haven’t seen, there are additional settings under Image Processing (prefer dcraw…) and under Performance (use OpenCL acceleration, enable GPU Capture Sharpening). There is also an ugly toggle button on the top panel to force Fast demosaicing at >=100%.

I still want to highlight that the fork is meant to solve the problems I encounter in my editing workflow. I barely touch the curves these days, relying on auto-matching them to the Nikon camera’s ā€œpicture controlā€ and tweaking contrast and saturation. This is because my approach to photography has shifted to good SOOC and minimum editing, hence the need for speed.

1 Like

I forgot to mention…

As of this afternoon (UK time), I reworked the debouncing around sliders and how monitor updates are batched. The debouncing delay might not be suitable if you have a fast machine, i.e., you are waiting unnecessarily for refreshes when your hardware is capable of keeping up.

Also, a video of how curves and equalizers perform for me.

Thanks, I did notice the fast demosaicing button but has not digged into Preference settings, will see what they do (I’m surprised at how fast it already is without toggling those on). And I appreciate your fork, even if it’s tailored to your workflow, it can still benefit people who uses a different workflow since there are some all-around performance improvements. I’ll mess with it (and your new update) further to get the general picture, but so far I’m impressed.