Call for testing: RawTherapee 5.4-rc2

[panomies]

is there a summary of changes?

[HIRAM (Richard E Barber)]

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

[Morgan_Hardwood]

@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.

[shreedhar (Shreedhar Inamdar)]

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.

[zurdo]

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

[Jacal]

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.

[Morgan_Hardwood]

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

[floessie (Flössie)]

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

[Jacal]

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.)

[Jacal]

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.

[Hombre (Jean-Christophe)]

@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);
     }
 }

[floessie (Flössie)]

@Hombre

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

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

[Carmelo_DrRaw]

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):

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

[agriggio (Alberto)]

@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

[Carmelo_DrRaw]

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

[agriggio (Alberto)]

Here:

[Morgan_Hardwood]

Related:

Verbose feedback user warning if PP3 does not apply as expected

[Carmelo_DrRaw]

@agriggio @Morgan_Hardwood - I installed the CLUTs and restarted RT, but I still had to select the CLUT manually after loading the .PP3 file. After exporting the result, the new .PP3 shows

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

So there seems to be some path delimiter issue when exchanging files between Windows and *nix. Should I open a new issue?

[Morgan_Hardwood]

@agriggio

Fujifilm XTrans III\Fuji XTrans III - Acros+G.png

@Carmelo_DrRaw please do.

[PanoMeister]

Call for testing; here is my reply!

First of all: good work guys (girls?). Since 5.3 a lot of fine tuning seems to be done.
I’ve been clicking around with Branch: 5.4-rc2/Commit: 042c49d34 and at first glance everything seems to be working fine. No crashes so far.

Some remarks:
-As regarding to the RT speed on my Win64-bit system (i7 980X @ 4GHz, 24GB RAM + R9 270x GPU). Startup time is fast (about 2 seconds). Preferences window opens almost instantaneously.
-Conversion speed while processing D800E NEF (RAW files) → 8bit TIFF files (each about 106Mb); it takes about 10 minutes to process 100 files.
Just a pity to see that there is still no GPU support/usage as to accelerate certain functions.
-When using the file selector options/windows I notice some ‘strange’ (e.g. non standard Windows) behavior. E.g. when I want to select a directory to store the output of the conversion queue, I’ve noticed some delays when you click (or try to click?) on the directory/file open icon. And the file/directory browsing behavior is rather different then the ‘normal’ in Windows Explorer. Also you must click on ‘Open’ while (I think) ‘Select’ should be more appropriate.
-Preferences Setting: most options have ‘hoover over’ info text, but not all of them. Sometimes you put the mouse cursor on an item, but nothing happens… Especially the ones you might expect info, there is no info…

I hope this helps in getting the final 5.4 release ready!
Any additional questions? Just ask.