Call for testing: RawTherapee 5.4-rc2

Software RawTherapee
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:

21

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

22

@Carmelo_DrRaw please do.

23

Call for testing; here is my reply! :grin:

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… :confused:

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

24

I think at one point OpenCL was considered for some functions, as proposed by @heckflosse :
https://github.com/Beep6581/RawTherapee/issues/1678

25

I have been using dev builds for a while now because I could not wait so long for the new features which are simply great. You are doing such a great job and the program is getting better and better. I switched from Lightroom to RawTherapee when Lightroom 7 was announced and I have not started Lightroom even once since then.

However, there is an annoyance with this release candidate. I run the dev builds with the English GUI and switched to system language now, which is German (Austria). Unfortunately, that does not work anymore. I have tried to start RawTherapee with renamed configuration directories to look if there is something up with them with no effect.

I am running RawTherapee on Windows 10. To me this is just a minor annoyance, I have just switched to German manually which works perfectly fine and I am not sure what language I prefer anyway. Using the system language still worked with dev builds about two months ago when I started using dev builds, if I remember correctly.

1 Like
26

Confirmed. Fixed for de, fr, nl, es, it, pt

Thanks for reporting :+1:

3 Likes
27

Ok… but why was it never implemented?
Because it already dates back to 2015.

Just to give you an idea of how much a simple GPU can accelerate graphics processing:
When I run PTGui Pro to stitch a large panorama image, it only takes a few seconds to generate a huge output file. As long as OpenCL GPU acceleration is switched on.
But when I rely only on my CPU, the same process takes about 10-15x times longer! (i7980x CPU versus R9 270x GPU)

28

If you want to fly to the moon, sticking fins and a rocket engine on to a rusty old bus does not a good foundation make. The first step was to optimize the code and to make the most of SSE2. The next step is to unify the pipelines. Maybe OpenCL will come next.

2 Likes
29

It dates back to 2013 Reported by heckflosse@i-weyrich.de on 2013-01-24 23:20:08
At that time fast GPUs were expensive and the simpler approach was to use SSE2 code and make better use of multiple cores to speed up rt.
Additionally there are algorithms where currently no GPU solution exists. Look at the raw decoders. Most of them are still single threaded. Some of them are multi-threaded, but afaik none of them is vectorized.

30

I am impressed, I am really impressed. That was super quick. Thanks a lot!

1 Like