My take on RawTherapee

Software
1

TL;DR: I have forked RT (no, it’s not for the name…), the code is at https://bitbucket.org/agriggio/ART/

Longer version:

I have been maintaining my own custom branch of RawTherapee for a while. This was meant to be a sort of playground to try out new ideas, and submit some of them upstream as pull requests when ready.
However, it eventually became increasingly difficult to stay compatible with the main branch (and its planned features) while doing experiments at the same time. So, soon after version 5.5 was released, I decided to forget about compatibility and go my own way instead. The result is ART (yes, the name sucks :-).
Although at a first sight it is still quite similar to RT, the number of changes is big enough that IMHO it deserves to be called with a different name (though with a clear relationship with its parent).
Here is a list of the most user-visible differences, loosely sorted by importance:

  • A “Local editing” tab, with tools supporting fully parametric masks (HCL curves and “area” masks)

  • Significant restructuring of the processing pipeline, with many tools removed (especially all the “Advanced” ones), some new tools added (log encoding, tone equalizer, film grain, guided smoothing) and several tools rewritten and/or refactored

  • A new automatic perspective correction tool (stolen from darktable)

  • No more batch editing (too cumbersome and somewhat incompatible with local editing)

  • Metadata handling via exiv2, with (optional) support for reading and writing XMP sidecars

  • Snapshots are now permanent, saved in the processing profiles

  • Processing profiles have “.arp” extension instead of “.pp3”, to avoid conflicts with RT

  • it is now possible to preview the effects of denoise also at zoom levels <100% (set in preferences → performance)

  • improved quality in the “fast export” pipeline

  • something else I probably forgot…

Finally, here is a video showing some of the new functionalities:

https://drive.google.com/file/d/18hTShRBN6KLi_Gb93ztbsPzzsixDcZAb/view?usp=sharing

Feedback is welcome!

24 Likes
2

Wow that sounds pretty cool! Congrats on taking it public :slight_smile:

3

Thanks for all your hard work, and sharing it with the rest of us.

While I respect decision, and even understand the reasoning behind it, it pains me as user to see this happen. As a hobbyist photographer I barely have time to teach myself mastery of RT (there are still many tools I have not yet explored). I really don’t see myself long term being able to stay with both forks. I can only hope that there is a lot of ‘cross pollination’ of advancements that are made.

Best of luck with your new project.

4 Likes
4

I can see how some of these changes can be hard to integrate, when they drastically change UI behavior. The sidecar support would be really nice to have in RT though.

Do you plan to pull-in some (future) RT features, if possible?

5

bug fixes and such, yes. New modules, I don’t know. It depends. I haven’t taken a look yet at the most recent additions, to be honest.

6

The one I am most looking forward to is capture sharpening. Quick question on RT Richardson–Lucy implementation

1 Like
7

That video is what I call an “edge aware” mask :grinning:

Is it possible to make a color and/or luminosity mask , based on the same method ?

8

Some words from me:

  1. I absolutely understand that someone forks RT to improve it and also simpilfy its usage.

  2. There are reasons the original RT can not do what Alberto did (Removing tools, removing batch edit and so on) as there are a lot of people which still rely on some of the features and having the same features as an elder RT (for example 5.4 or whatever) for their workflow is important to them.

  3. Alberto introduced a bunch of good features into RT (auto-matched tonecurve, local contrast, dehaze, softlight …). A great thank you for that, Alberto !!!

  4. four eyes see more than two…

9 Likes
9
  • so when are you going to merge again?
  • what can we do to speed up the development process so that branches like his dont have to be maintained for such a long time?
  • how much work is needed to be at least as customizable as darktable?
10

That’s not a branch. It’s a fork where some things may be used in RT and ART, not more, not less…

11

? What’s the relation of this question to this topic?

12

@agriggio First of all thank you for all the development you did for RT. I also understand that you had the will and capabilities to change, remove and add things to RT at such a pace that the original RT could not follow. So it’s very natural that you made your own fork.
Kudos for making it public.
I hope there will be some cross-pollination between RT and ART.

2 Likes
13

Where does one download this forked version from? I am very interested in local adjusments and denoise previews at zooms <100%.

14

Get the source from the bitbucket link.

15

I can’t code and or build from source. I’m a peasant, I need a .deb or a .appimage.

1 Like
16

I would guess that given the similarity to RT my automated builds (Appimage and Win64) should work for ART as well… @agriggio: any interest?

5 Likes
17

Thanks for all the feedback! Here are some answers/comments:

sharpening in ART already happens in “scene” linear RGB space, not in Lab. So you might already see some differences wrt. standard RT sharpening (though I didn’t make a comparison with capture sharpening yet).

you can combine “area” masks with channel-based ones (hue, chromaticity and lightness), which you control with a curve. Is this what you were asking?

Exactly. That’s why I decided to fork. RT has a loyal user base and a lot of legacy it has to carry around, and backwards compatibility is obviously very important and valuable. But it’s also a big constraint…

well, never say never… but never :slight_smile:

Like @heckflosse wrote, this is not a branch that is supposed to be merged back. Rather, it’s me putting at work the fourth essential freedom of free software. So, I hope there’s nothing you can and/or want to do about it.

I have no idea. How much work is needed to make darktable as customizable as photoflow?

I hope so too! the main reason why I made this public is in the hope that some pieces might be deemed useful enough that somebody ports them to RT.

Producing either is way beyond my skills, sorry.

well, I build from source :wink: But seriously, if there are people interested, I definitely welcome this, thanks! (technically, ART depends also on exiv2, and I would also strongly encourage to link against tcmalloc rather than using the OS’s memory allocator, as that gives a nice performance boost. Incidentally, this is true also for plain RT, and doesn’t require any change of code)

18

An automatic perpective correction and film grain would be great… not to mention some simplified local adjustments :slight_smile: Thanks @agriggio for your work on RT!

19

Thanks for all your work for RT!

I like your aproach on ART it is basically some of the things I’d like to have in RT.

Will ART be available as a program someday so simple users can …use it…, or just as code?

20

I have neither the expertise nor the energy/time to provide and maintain binary packages, sorry.
However, here’s what @Carmelo_DrRaw wrote:

so, you can try asking him :slight_smile: