well it would be weird if you clicked on ‘cancel’ and the options got saved anyway, wouldn’t it?
1 Like
IMHO, no! The text says save Now, it does not say “now after clicking okay also” But I know, that all the other options are saved on “okay”. So may be that is just personal taste 
Now I did more testing with the ToolPanelsExpanded.
I reinstalled the official 5.3 in an empty folder. I manually removed the line ToolPanelsExpanded from the options file using Notepad++. Then I run RawTherapee and enabled just the following tool panels (if i closed one, I did not care for subtools): Exposure, Retinex, Sharpening, Noise Reduction, White Balance, Film Simulation, Crop, Lens/Geometry, Rotate, Sensor with Bayer Matrix, Demosaicing.
This resulted in
ToolPanelsExpanded=1;1;0;0;0;0;1;0;0;0;1;0;0;0;1;0;0;0;0;0;1;0;0;0;1;0;1;1;1;0;0;0;0;0;0;1;1;0;0;0;1;1;1;0;0;0;0;1;1;1;1;1;1;1;1;1;1;
Now I reinstalled 5.4-rc2 into the same folder und run it. Now the following tool panels are open: Exposure, ToneMapping, Sharpening, Contrast by Detail Levels, White Balance, HSV Equalizer, Color Management, CIE Color Appearance Model 2002, Wavelet Levels (as already said this one insists in being open), Crop, Resize, Post Resize Sharpening, Dark Frame, Flat Field.
I changed the settings the way it was in 5.3 and saved.
This resulted in
ToolPanelsExpanded=1;1;0;0;0;0;1;0;0;0;0;1;0;0;0;0;1;0;0;0;0;0;1;0;0;0;1;0;1;1;1;0;0;0;0;0;0;1;1;0;0;0;1;0;0;0;0;0;0;1;1;1;1;1;1;1;1;1;1;
I do not agree non this statement. Well I did something similar like upgrading from 5.3 to 5.4 and I expect that my settings are kept. The new settings may of course have some default setting. If this would have been a real dev version, then may be okay… that’s way I didn’t say anything before
sorry I didn’t understand this was the case. I agree that upgrading from official releases should work
Be aware that for the W64 builds:
- for 5.3 stable build, option file is located in
%LOCALAPPDATA%\rawtherapee - for 5.4-rc2 build, option file is located in
%LOCALAPPDATA%\rawtherape5-devas for development bulds.
@Morgan_Hardwood should’nt be better to locate the release candidates config folders in ..\rawtherapee?
@gaaned92 release candidates are not stable releases, they are meant for testing, not for production use, so I’m inclined to say “no”.
According to RawPedia I can use an environment setting
RT_SETTINGS= LOCALAPPDATA\RawTherapee
which I did a long time ago.
In my opinion this still works as the correct path is used …
Concerning LTO: This is not RT’s but binutils’ fault. CMake uses stock /usr/bin/{ar,ranlib} and those don’t use the LTO plugin, so the relevant sections get lost. To compile with LTO, employ these CMake arguments:
-DWITH_LTO=ON -DCMAKE_AR=/usr/bin/gcc-ar -DCMAKE_RANLIB=/usr/bin/gcc-ranlib
@Morgan_Hardwood We could add this to the CMake logic or should at least document it. Adding it to CMakeLists.txt would make LTO GCC specific (but is that a problem?).
HTH,
Flössie
@floessie does that apply to MSYS2 only?
I just compiled dev with -DWITH_LTO="ON" in Sabayon and it worked (for the first time ever)!
sys-devel/binutils-2.29.1-r1
sys-devel/gcc-6.4.0-r1
dev-util/cmake-3.10.2
What will LTO make faster in RT?
I read that newer binutils pick up the LTO plugin correctly, so that might already be the case with your setup. I’m not referring to MSYS2 (I’m Linux only).
Hm, we had a LTO vs. non-LTO shootout in a GitHub issue years ago, and LTO was some percent faster. This is mostly due to better inlining and de-virtualization at link time, I guess. This does not compete with Ingo’s optimization, but adds some speed-up on top.
@floessie something like this?
diff --git a/CMakeLists.txt b/CMakeLists.txt
index cb45c573..f73cf77b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -334,6 +334,16 @@ if(WITH_MYFILE_MMAP)
endif()
if(WITH_LTO)
+ # Using LTO with older versions of binutils requires setting extra flags
+ SET(BINUTILS_VERSION_MININUM "2.29")
+ execute_process(COMMAND ar --version OUTPUT_VARIABLE BINUTILS_VERSION_DETECTED)
+ string(REGEX REPLACE ".* ([0-9.]+)\n.*" "\\1" BINUTILS_VERSION_DETECTED "${BINUTILS_VERSION_DETECTED}")
+ if("${BINUTILS_VERSION_DETECTED}" VERSION_LESS "${BINUTILS_VERSION_MININUM}")
+ SET(CMAKE_AR "/usr/bin/gcc-ar")
+ SET(CMAKE_RANLIB "/usr/bin/gcc-ranlib")
+ message(STATUS "Binutils version detected as less than " ${BINUTILS_VERSION_MININUM} " - setting CMake parameters to enable LTO linking:\n CMAKE_AR=\"" ${CMAKE_AR} "\"\n CMAKE_RANLIB=\"" ${CMAKE_RANLIB} "\"")
+ endif()
+
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -flto")
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -flto")
SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -flto")
1 Like
Looks good. 
I’ve had two (now three) crash issues thus far. My system:
i7 3630
Nvidia 635m
16gb ram
Samsung EVO 850 256gb main drive
128gb Msata as a second drive (my images are here for testing)
Windows 10, most recent patch
Installed 5.4 RC2 along side 5.3.
5.4 definitely opens faster than 5.3!
Navigating to a folder of images that were edited in 5.3, 5.4 crashed.
Reopened, navigated to same folder, crashed again.
Investigating, I found that removing all pp3 files from suspect folder alleviated the crashing. So I added all of them back. This caused the same crash.
So I decided to remove one pp3 at a time to see if one of them was at fault. To my delight, first file removed and 5.4 no longer crashes while navigating to this folder. So I put that pp3 back to verify the issue. Now all seems fine. Removing the file, adding it back, it doesn’t crash any more. I was going to go through the bug logging process, but i can no longer replicate it
By the way, I have other folders with pp3s and no issues.
Second problem, I was editing a photo and experienced a crash:
Applied RCD demosaicing
Exposure panel
Shadows/highlights
tone mapping
HDR tone mapping
Went to details and applied
Impulse
And Luminance. While adjusting this setting, including Detail Recovery, RT crashed. I’ll try to recreate this issue and provide a bug report.
As I was writing this, I opened RT again and tried double clicking an image but was greeted with a window saying that there was an issue accessing something and there was a runtime error. I tried to grab a screen shot, but when I did, my computer screen went black (I’m sure this is a related issue as I have never seen this with my system before) I had to force reboot the system to recover.
Besides running in rawtherapee-debug.exe and recreating an issue to grab a log, is there no other log of any kind created after random crashes?
Thanks. I’ll do what I can to continue to report these issues.
2 Likes
So I worked the RC really hard last night with dozens of images in that troubled folder. And damned if I can replicate any of the problems I mentioned before.
Not sure how to provide any more helpful info. How much longer is the RC open? I’ll continue to try to replicate the aforementioned problems and look for new ones.
The only thing I’ve noticed so far is that it runs really slow on both my Intel i5-2300 2.8GHz with 16GB of RAM machine & my AMD FX-8130 3.4GHz with 32GB of RAM machine. Both of them have SSDs as the main drive & 7200 RPM drives as the secondary drives. Both are running Windows 64bit Professional & have no bloatware. Version 5.3 also ran really slow on both of them.
It takes a few seconds to react to anything. Doing something as simple as saving a PP3 files takes forever. When I click the save button for a PP3 file, it takes a few seconds for the window to open up, takes a few seconds to navigate to the directory, & then it takes a few seconds to save the PP3 file after I hit the save button. Any other adjustments takes forever to load. It’s like it pauses a few seconds every single time I do anything. None of that happens in version 5.2. It’s all instant. I’m still using 5.2.
@The_Squirrel_Mafia
Which 64bit Windows are you using?
I’m on Windows7/64 Professional and can’t confirm your issues.
That’s smells a bit like the Floppy drive A: bug
After building both geeqie and rawtherapee from test sources, on linux amd64 Mint Sylvia,
,…the following was useful in .bashrc
alias geeqie="/home/sandy/programs/geeqie/bin/geeqie"
alias rawtherapee="/home/sandy/programs/rawtherapee/rawtherapee"
To get the new qeeqie to spawn the new rawtherapee from geeqie’s plugins menu I had to edit
/usr/share/appications/rawtherapee.desktop so the Exec line read:
Exec=/home/sandy/programs/rawtherapee/rawtherapee %f
Seems to work fine.
It’s Windows 10. I disabled the floppy in the BIOS for the Intel i5 machine, but it still lags a bit.
Funny thing is that 5.2 works extremely well. Version 5.3 was too slow & I was hoping for 5.4 to have fixed that, but it still lags.
Does that mean, it’s still same speed as before disabling the floppy in BIOS or is it a bit faster now (if so, how much faster)?