I reread the text with the addition of @Thanatomanic (WIP release noe), it is really a remarkable presentation.
I think we should add as @priort pointed out, a reference to the excellent videos of @Andy_Astbury1
In conclusion the best presentation of Rawtherapee I have ever seen .
Jacques
Hello, I don’t mean to go off topic, but I’d like to make a suggestion on this. A person who might be good to inform regarding the team’s work and the upcoming release of RT 5.9 is Roger Clark, a scientist and photographer who has written many articles on astrophotography and has highly praised RT in comparison to Adobe Camera Raw. I am pointing out this person, for two reasons:
a) he is not just a random astrophotographer, he is a person that has done a lot of scientific research on the subject (ClarkVision.com: about R. N. Clark) and
b) he has written an extensive article (Astrophotography with RawTherapee, Clarkvision.com) on the use of RT for astrophotography, demonstrating his method and results. I consider him a person who has the ability to demonstrate and communicate to the public the advantages that RT has in this genre of photography over other raw processors.
Roger Clark has pointed out in his article two characteristics of RT that considers to be disadvantageous and that need to be addressed:
a) Dark-frame and flat-field subtractions use a single raw file, instead of an average from multiple exposures and writes that “This is a real limitation that needs to be corrected.”
b) Secondly, he mentions the way that images are exported via the queue: “Personally, I find this very non-intuitive and inhibits a new user from understanding how to do these things”.
I agree that the second could be a point of discussion for future releases. Many new users will probably try at first to figure things out and might be discouraged if they need to refer to the documentation for a task so simple like an image export. This forms a false first impression, as the rest of the program’s layout works out easy enough (for me).
I apologize if this is considered off-topic, but I think that that these suggestions from this person should be taken into account and I didn’t find a thread regarding suggestions for future RT releases.
Which is why we create Master Flats and Master Darks as I have pointed out in videos/articles before, and is common practice when using Starry Landscape Stacker.
This is why, in theory, you should shoot your sequence of dark frames immediately after your light frame exposures, as in reality, dark frames are used to combat thermal noise more than shot noise - they are time and temperature dependent.
Flats are more to combat vignetting and so are not ‘in situ’ dependent.
I’d concur with his observations on ‘the queue’
But neither are (imo) are of as great an importance as getting 5.9 on stable cross platform public release. Get it out there and leave the immediate teaching to people with an audience of interested users - hell, it’s the way Adobe work with Photoshop!
I think this is not the right place to mention this but I think there is a bug jn the latest dev build: highlight reconstruction breaks if local adjustments/color&light (I am not 100% sure about the name) is activated. The brightest parts of the image get an ugly grey color or so. Even if the spot does not include reconstructed zones. I think this was not present in the dev build of approx. 4 months ago. I cannot post this on github right now because I have no proper computer. But I will in a few days. It probably has to do with module order.
Probably better to move to a new thread. I couldn’t reproduce yet, I hope I understood correctly.
Andy, thank you for mentioning Master Flats and Master Darks, I had never heard of such practice, I always shot darks and instead of flats I trusted the lens’ profile. I’ll look it up both via search engines as well as on your channel.
Regarding R. Clark’s points that I mentioned, I didn’t suggest them to be looked into right now, but for some future release. I agree (and probably most people will as well) that a stable release of RT 5.9 would be more beneficial in many ways for the RT community.
Sorry if this went off topic, I’ll stop now (but happy to talk via pm if anyone wants to)
@Thanatomanic - these edits look great, thank you for taking the time to do them! It is much appreciated.
In markdown, double spaces at the end of a line add a hard line break (for the “main developers” and “main contributors” lines to be in the same paragraph but to retain a hard line break. I’m going through the rest of your patch now (thank you so much!).
Got a link by chance? Or maybe the man himself @Andy_Astbury1 could provide me one? I can tweet it via the RT twitter account as well, or even follow up a post immediately afterwards (or for other social output).
Speaking of social output, thanks for the recommendation @Zahtar - I’ll reach out to Roger Clark (would you happen to have contact info for him handy you can send me?).
I’m thinking we can publish either this weekend or wait until Monday. (I usually wait until Monday to not bury the news over the weekend, but this isn’t really “traditional” publishing in that sense and our audience, RT users, might like having the news to peruse with their free time on the weekend… 
).
I’m doing a last look now and will try to push it out tomorrow morning (US Central time - UTC-0500).
Part 1
Part 2
Might be one or two more…EDIT…
Andy has a great collection for RT…perhaps his play list should or could be included somewhere…
Not sure what the correct url would be…it goes to the first video in the playlist…
Hello
This is “normal” because the “LA” process is after reconstruction.
It is explained how to solve this problem in the case of “Log Encoding”, but it is exactly the same for all processes that will touch the reconstructed areas
https://rawpedia.rawtherapee.com/Local_Adjustments#Log_Encoding_and_Highlight_Recovery
for me, the simplest is “excluding spot”.
jacques
Ok, thanks.
I know a lot of working commercial togs who shoot flat frames all the time in the studio and on location - and the come in handy for removing dust spots too!
You can read more about master flats and darks over on Ralph Hill’s website Starry Landscape Stacker - Using Starry Landscape Stacker Version 1.9
thanks, I’ll take a look!
Aaand we’re live!
Pushing was a royal PITA as I couldn’t connect via SFTP (or SSH) to the webhost.
I finally managed to get the site uploaded (but my local ISP is having issues at the moment and i couldn’t see it - I spent a good 15 minutes in a panic that I had broken the site…).
Thank you all for getting this post up! I’ll try to reach out to some places soon to spread the word (if anyone has ideas or accounts in other communities to let them know - please do!).
Looks great, Pat!
I posted on DP Review:
And of course the Twitter account:
I’ll write something up to post over at opensource.com as well later.
I suppose I should also head over to reddit as well…
Reddit and dpreview? You’re a glutton for punishment.
I’m spending time on the 3D printing subreddits, and it seems to have about a 24hr memory. The same questions come up every couple of days…
Has anybody compiled RT on an ARM processor such as a Raspberry Pi? I compiled it on a newish Samsung tablet inside Andronix and it seems to run well. Maybe I should get a Raspi and create a package or so… anyway I would think that darktable or vkdt would not run well on ARM hardware, so that only leaves RT and ART.
Hi Anna,
No, but I regularly build and run it on a PowerPC32 VM, which es even more special than ARM, because it’s big-endian and has an unsigned char type. RT is pretty portable. 
Best,
Flössie
yep, we do! On openSUSE we provide compiled binaries for x86_64, arm and ppc64le (Show graphics / rawtherapee - openSUSE Build Service)