Call for testing: RawTherapee 5.4-rc2

Software RawTherapee
1

We are very close to releasing RawTherapee 5.4. You can help with the last step.

rt-logo-large

Here are builds of RawTherapee 5.4-rc2. These are not the final builds yet, but they might become the final ones if everything works well. “rc2” means “release candidate 2” - they are candidates for a final release if they perform well. Else they get shot.

  • Download for Windows (clean)
  • Download for macOS (clean)
  • Linux, several options:
    • Check your package manager as described on our Downloads page,
    • Or use an AppImage,
    • Or compile 5.4-rc2 yourself by following this simple guide. If you follow the automatic way, then after running the script the source code is cloned into ~/programs/code-rawtherapee, so you should:
      cd ~/programs/code-rawtherapee
git checkout 5.4-rc2
~/scripts/build-rawtherapee -b
      Or if you follow the manual way, then in the “Choose a branch” step do git checkout 5.4-rc2, then compile.

Get it, run it, test it, and if you find a bug, report it!

This is also the last chance to update the interface translation in your language - see here for info on how to do that: Localization - How To Translate RawTherapee and RawPedia

7 Likes
2

Thanks to all the developers for their hard work. Excellent work!
I’ve noticed one thing on my Windows 10 computer with the RT 5.4-rc2 that when I open a new raw, even if it has never been processed with RT it opens as last saved in the processing profiles window instead of neutral. The picture is in fact neutral, but the processing profile claims it to be “Last saved” . In preferences I have the open in neutral option selected.
Again thanks to all the hard work, it seems really nice in the little bit I’ve played with it.

3

In a clean installation, it should open using the “Auto-Matched Curve - ISO Low.pp3” profile (see Preferences).
It will show as “Last saved” in the combobox - that’s a known issue: Newly opened images show processing profile as "Last saved" · Issue #4414 · Beep6581/RawTherapee · GitHub

4

is there a summary of changes?

5

This handy list of closed issues that had been tagged with the 5.4 milestone are some indication there were hundreds of changes:
https://github.com/Beep6581/RawTherapee/milestone/4?closed=1

1 Like
6

@panomies

  1. You saw the release notes the first time you ran 5.4-rc2, they list a summary of changes relevant to photographers.
  2. There is the v5.4 milestone.
  3. There is the git log.
7

Thanks for this update. Works great. I tried LAB, Wavelet, Defringe, Lens Correction, Exposure tone curve the new HDR Tone mapping, HALDCLUT, RGB curves, Desaturation and they all work fine. Right clicking on a photo and opening with RT is cool and what makes it better is that it opens with file browser too, not just in editing mode! Thanks for these improvements.

I had scaling problem for the UI though with the default (for me) 10pt size for the RawTherapee Theme, which went away when I chose TooWaBlue (Dark) theme at 7pt font. Any larger font makes some of top (and bottom) panel buttons disappear. I am OK with 7pt font so it is not a big deal for me.

I am on Win 10 (64 bit) system.

1 Like
8

Working with no problems on mac running OSX 10.11.6. Thank you to all developers for a great job on this program.

9

I was feeding words with haček/caron letters to metadata to test the unicode support. Everything works perfectly with Windows version, but I see a silly problem on Ubuntu (last from PPA, 1:5.3-git20180228-827~ubuntu17.10.1). In Exif:UserComment, part of the inserted texs gets eaten away. Inserted
všečna številka is properly written to pp3 file, but the actual comment in the exported jpeg is
všečna štev.
všečna žaba šviga; teštiram, če delaž becomes
všečna žaba šviga; tešt.
No problems with ascii-only comments, and, as said, no problems on Windows.

1 Like
10

@Jacal is there anything unusual about that “i”, i.e. is it the same as the ASCII “i”?
Ping @Hombre

11

This fixes it for me, could you test?

diff --git a/rtexif/rtexif.cc b/rtexif/rtexif.cc
index b6a60bbd8..ff5607b02 100644
--- a/rtexif/rtexif.cc
+++ b/rtexif/rtexif.cc
@@ -1948,8 +1948,8 @@ void Tag::initUserComment (const Glib::ustring &text)
         memcpy(value, "ASCII\0\0\0", 8);
         memcpy(value + 8, text.c_str(), valuesize - 8);
     } else {
-        wchar_t *commentStr = (wchar_t*)g_utf8_to_utf16 (text.c_str(), -1, nullptr, nullptr, nullptr);
-        size_t wcStrSize = wcslen(commentStr);
+        glong wcStrSize = 0;
+        gunichar2 *commentStr = g_utf8_to_utf16 (text.c_str(), -1, nullptr, &wcStrSize, nullptr);
         valuesize = count = wcStrSize * 2 + 8 + (useBOM ? 2 : 0);
         value = new unsigned char[valuesize];
         memcpy(value, "UNICODE\0", 8);

HTH,
Flössie

1 Like
12

Should be a “normal” i, the only non-ascii letters in my language are č,š,ž.
(Borrowed in 19th century by happy nationalists from the very rich Czech alphabet, just to throw out some German letters. So we have to live with win-1250 now.)

13

I’m sorry, I can’t try now, having a birthday in family, red roses, restaurant and stuff. Tomorrow I’ll do what I can.

1 Like
14

@floessie You patch makes things cleaned, but I don’t really understand what’s going on here.

@Jacal I’d be curious to see the debug output of this patch with your test case. I get the same size when using special chars in EXIF.UserComment.

diff --git a/rtexif/rtexif.cc b/rtexif/rtexif.cc
index b6a60bb..ec220e5 100644
--- a/rtexif/rtexif.cc
+++ b/rtexif/rtexif.cc
@@ -1949,7 +1949,10 @@
         memcpy(value + 8, text.c_str(), valuesize - 8);
     } else {
         wchar_t *commentStr = (wchar_t*)g_utf8_to_utf16 (text.c_str(), -1, nullptr, nullptr, nullptr);
-        size_t wcStrSize = wcslen(commentStr);
+        size_t wcStrSize2 = wcslen(commentStr);
+        glong wcStrSize = 0;
+        gunichar2 *commentStr2 = g_utf8_to_utf16 (text.c_str(), -1, nullptr, &wcStrSize, nullptr);
+        printf("String length: Unpatched: %d  /  Patched: %d\n", wcStrSize2, wcStrSize);
         valuesize = count = wcStrSize * 2 + 8 + (useBOM ? 2 : 0);
         value = new unsigned char[valuesize];
         memcpy(value, "UNICODE\0", 8);
@@ -1971,6 +1974,7 @@
 
         memcpy(value + 8 + (useBOM ? 2 : 0), (char*)commentStr, wcStrSize * 2);
         g_free(commentStr);
+        g_free(commentStr2);
     }
 }
15

@Hombre wchar_t is 32b in Linux, while in Windows it’s what you expected (16b).

16

I am testing the 5.4-rc2 version for Mac.

Using the .NEF file from the Everything frozen PlayRAW and the PP3 from @shreedhar, my processed image looks different from what was posted (the posted image is darker and has some more contrast):

18
181919×1152 877 KB

This could be either due to a non-matching .PP3 file, or maybe to some problem with the Mac version?

17

@Carmelo_DrRaw do you have the used film simulation installed? Note that the pp3 uses forward slashes, which is probably (part of) the culprit:

[Film Simulation]
Enabled=true
ClutFilename=Fujifilm XTrans III\\Fuji XTrans III - Acros+G.png
Strength=100
1 Like
18

Thanks! That’s probably the issue. I most likely don’t have the Fujifilm CLUTs, where should they be installed under OSX?

19

Here:

44
441386×898 116 KB

1 Like
20

Related: