There’s some potential to optimize Only edges sharpening which currently is quite slow.
I already checked for the bottlenecks and found some. @floessie Are you interested in another fun optimization session? I would open an Issue then and share my first results.
I’ve removed 03 for the final release… I don’t know why - maybe because to keep recommendations from final readme file. My ‘unstable’ branch is compiled with 03. Well, I will add this again to stable branch - expect new compilation in few hours.
Before @Dariusz_Duma adds it and we potentially end up with variously optimized builds - @heckflosse@floessie what is the verdict on this? Should it be -o2 or -o3?
@RawConvert it’s not “zero-three” it’s “oscar-three”.
FYI! RT5 on Xubuntu 16.04, 64 bit, I3 with 16GB ram… Doing anything seemed a little sluggish. When I tried to adjust the white balance temperature, it worked for 3 to 4 seconds and then RT crashed. I went back to the unstable version. I’ll try Dariusz Dumas updated version when I see it available.
I tried Dariusz Dumas new version in his PPA (5.0-2dhor~xenial). The interface seems less sluggish. But I can still make RT5 crash. Load any jpg file and adjust the white balance temperature up and down a large amount repeatedly and it will eventually crash. I will do what I can to enter a bug report on github. As far as I know there are no debug builds available.
@heckflosse Why, yes! I guess we’re all waiting for @Morgan_Hardwood to start the development branch so that we have a base for the coming feature branches.
Sure. And preferably with a capital “Oscar”. And please no-Ofast, because that enables -ffast-math again.
I opened a jpg with RT5 (have not updated yet, version as at weekend) and moved the white balance back and forth lots, and quickly, but it wouldn’t crash.
@RawConvert Actually, my two computers use UEFI and were up to date when I built them. The motherboard manufactures website showed compatibility with my CPU and ram. Considering how stable these two machines have been, I have no reason to believe that the UEFI is at fault.
I’m thinking the problem may be with GTK3. I have used many versions of rawtherapee-unstable from Dariusz Dumas PPA and have not had a failure. The unstable packages appear to be built on the Master branch which appears to use GTK2.
Since you are using a newer release of Ubuntu, your shared libraries may be updated. This could be another reason.
perhaps GTK2 shouldn’t get dropped in RawTherapee 5 until most distros are able to deal with it properly. I’ve never has a GTK3 version work fast on my system …but that’s cause mine doesn’t count being Debian and outdated but if even the Ubuntu avant gardes are having issues I think it’s settled
I can confirm that gtk3 builds of rt need more time to start (I’m on Win7/64 gtk 3.18). But the processing speed (measured in queue processing) is not different to gtk2 builds. Also, once an image is opened in editor I see no difference in speed between gtk2 and gtk3 when changing processing parameters
I do sadly. then again i run debian with gtk2 …not sure about gtk3 support on it. but can confirm things run slow; from loading of images to applying changes maybe its just a matter of debian getting things together