This reflects my experience in installing RT 5.10 on Win 10.
My apologies as this is sort of a useless post because I’m not sure of exactly what I did this time and I can’t remember what I have done on previous updates and I don’t understand what gdbus does. But what I think is the situation is that the installer does not install the file gdbus.exe. I corrected this by copying gdbus from a previous install. My limited understanding is that the presence of gdbus precludes RT from opening multiple instances of itself, which I find very useful. I think it should be part of the default install and I think it was previously (but I may be mistaken on this).
Up to now I have been using RT 5.7, because RT 5.9 didn’t properly write IPTC data which I use to track where I took a photo and what it is supposed to show. And RT 5.7, although properly writing IPTC data in the UTF-8 format, does not correctly read 2 byte encoded UTF-8 characters, such as German Umlaute ä,ö and ü or French vowels é and è wich accents. Therefore, I was looking forward to RT 5.10 for fixing this problem and I am pleased that writing IPTC data to TIFF and JPEG files now works and RT 5.10 can correctly read the IPTC data from these files.
However, there appears to be a bug in RT 5.10 for pasting copied IPTC settings from the clipboard to the current image. Pasting works as expected for RAW files and for TIFF and JPEG files which already contain IPTC data. However, if I open a TIFF or JPEG file which contains no IPTC data and paste IPTC data from the clipboard into the IPTC Tab, the data will not be stored in the pp3 file on exiting the editor or when storing the image with a different file name or in a different file format, unless I make an amendment to the data after pasting them. The data are not even temporarily stored for the current image, so stepping back to the image as loaded and then forward again to changed IPTC metadata leaves the IPTC Tab empty. I suspect that RT sets a flag for amended IPTC data when data are manually entered into the IPTC Tab, but this flag is not set when IPTC data are pasted from the clipboard (and the flag is now by default set for RAW files).
I have also observed some puzzling behaviour with RAW files (Sony ARW format) which seems to be at odds with RT’s philosophy of storing edits only to the pp3 file and not amending the original file. I opened a RAW file, entered data into the IPTC Tab, changed to editing a different file (TIFF or JPEG wth different IPTC data) and then deleted the pp3 file that was generated for the RAW file. When I reopened the RAW file, the data which I had entered reappeared in the IPTC Tab, even when I exited RT after entering the IPTC data. Therefore, the IPTC data displayed upon reopening the RAW file could not be retrieved form the corresponding pp3 file or from temporary storage in RT but seem to be retrieved from the RAW file itself. If that were the case, RT would have amended the RAW file, which it should not do. I’d be happy if someone could give me an alternative explanation for what I have observed which does not involve a change to the RAW file.
@bobm I’ve looked at the history of the installer configuration and it doesn’t show that it ever included gdbus. We’ll have to look at the past installer .exes to confirm, but what version of RawTherapee did you copy gdbus from and are you sure that version was installed through via an installer? Or maybe you got gdbus from here?
@schorschbey Could you file a bug report on GitHub as described in RawPedia so that your comment doesn’t get lost and forgotten here? Regarding the ARW metadata, it would be extremely surprising if that was the case because RawTherapee doesn’t know how to write any type of raw file (in fact, RawTherapee only knows how to write a few image file types). Check your preferences and see if RawTherapee is reading/writing processing profiles in the cache and if XMP metadata synchronization is enabled.
There is now a test ready (Universal) in the shared folder below:
Here is the work in progress on this mac issue, I’ve narrowed things down to a miscompilation/config problem with homebrew on Big Sur, which notably is no longer a supported macOS version by both Apple & homebrew. The error lies in the missing baked-in macOS Software Dev Kit version number of a package component and library sub-dependency called libgomp.1. Long story short, the package already includes libomp, and all the flavors of OMP should theoretically be drop-in replacements of each other. So I’ve swapped the link in the parent dependency to point to libomp. I don’t know if the error is fixable in homebrew at this time, but it is worth looking into at some point, maybe. The appearance of the dependency calling for gomp was from a recent homebrew bump-up of the FFT components. After a couple of days in the Sierras sans screen, finally I’m getting a chance to add that hopefully final piece to the puzzle.
FYI BTW the corrected resultant omp link looks like:
otool -L RawTherapee.app/Contents/Frameworks/libfftw3f_omp.3.dylib
RawTherapee.app/Contents/Frameworks/libfftw3f_omp.3.dylib:
/Applications/RawTherapee.app/Contents/Frameworks/libfftw3f_omp.3.dylib (compatibility version 10.0.0, current version 10.10.0)
/Applications/RawTherapee.app/Contents/Frameworks/libfftw3f.3.dylib (compatibility version 10.0.0, current version 10.10.0)
/Applications/RawTherapee.app/Contents/Frameworks/libomp.dylib (compatibility version 2.0.0, current version 2.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)
Hi Richard, just tested quickly (some modification and saving NEF files to JPG) the new build on Mac intel OS 14.3.1 and it works as expected!!! Even if recently I have been using more often darktable, for some pictures I get the look that I like faster with RT. Thus, I keep following the development of RT. Great work for the small Mac community. Thank you
I am running RT on WIndows 10. Checking the last modified date for the RAW files that I have opened with RT 5.10 in Windows explorer does not show a recent change to the file. RT indeed does not touch the RAW data.
My settings in preferences are for saving the sidecar file with the picture and not in the disk cache and XMP metadata synchronization disabled. The IPTC data reappearing after deleting the pp3 sidecar file therefore do not come from the disk cache.
I did a few more checks and noticed that the same behavior occurs with RT 5.7 when a sidecar file is deleted while RT is running and that not only the IPTC data, but also other settings, such as changes to exposure, are restored when the picture for which the pp3 file has been deleted is reopened. However, if I exit RT and restart it, no settings are restored (I probably overlooked last time that RT writes a sidecar file for the currently opened picture when the program is exited). Therefore, RT appears to use a cache for edits, which contains data from files previously edited during a session, and reads settings from this cache when a file previously edited in the session but having no sidecar file is opened.
Another issue that I have come across is that opening the Metadata Tab in RT 5.10 severly slows down the opening of a new file. In RT 5.7, opening a RAW file by double clicking a thumbnail in the film strip takes 2-3 seconds on my machine and this does not change when I select different Tool Tabs. In RT 5.10, the time for opening a file the same way is 6-7 seconds and stays about the same for all Tool Tabs except the Metadata Tab. However, once the Metadata Tab is opened in RT 5.10, opening a new file will take from 35 to 45 seconds until the picture is displayed on screen, i.e. up to 7 times longer, and this delay then persists even if another Tools Tab is open when a new file is loaded. I’d like to know whether this slowing of RT also occurs with other operating systems than Windows 10, and if not, whether it can be prevented by changing a setting on my system. I really appreciate any response on this issue.
To all of those who reported issues with this version, first of all, thank you.
I noticed that when the release candidate was released there were no real issues reported, but there were several with the final version. The purpose of the release candidate is to find and quash these bugs before the final release. Now for the ask…
It would be very beneficial if everyone here could try the next release candidate when it is available and then report any issues at that time. This will enable the developers to release a much more robust final version.
@chaimav, i totally agree to your words. @schorschbey, i cannot reproduce your issue. Under Windows 10 i dont see any delay loading RAW-files after activating the Metadata-Tab, i tried this with Sony ARW and Panasonic RW2.
There is some delay activating the transform-tab the first time, after RT was started, this is a known issue since RT 5.9, which came up with restructuring the favorites.
Someone here on discuss actually generated our error above on rc1 but we were not able to determine the root cause within the test pool at that time, so to block would have been pointless. Fortunately upon release we got more good test data given the widened user base.
The point is, if you landed here because of a released bug, be instilled with the desire to return and test a non production build every once in a while?
I recently cleaned up my previous installs of RT so I can’t trace the past history. However originally I did indeed get gdbus via How do I switch from edit window to browser window? - #30 by gaaned92. That was for RT 5.8. But I don’t recall worrying about it subsequently through 5.9 and several development versions. It may well be that in fact I copied it from install to install when copying over profiles and configuration files etc. But I have no recollection of doing so and the configuration profiles are in my local app directory, not with the RT executable. So basically I don’t know, except that originally I got it externally.
However, regardless of the details of the past history, it seems reasonable that gdbus should be included in the windows installation package so that the -R option works; or if for some reason it is not appropriate to include it in the installation package, it should be documented in rawpedia.
If you think it appropriate, I can write a bug report on GitHub.
Thanks for the info, @bobm. I wanted to know where you got gdbus.exe from because what I saw indicates it was never included with the installer. I followed the development of 5.9 and 5.10 very closely and I’m positive there were no changes to the installer with respect to gdbus. So even though you don’t remember the exact details, I think we can confidently say gdbus was never there and that the exclusion was probably an oversight given how easy it is to overlook. @gaaned92opened an issue a while back, so no need for the bug report. I will add gdbus.exe to the installer (for 5.11 or whatever is next). Thanks for you help!
Thanks for submitting the issue to GitHub @schorschbey. I will take a closer look. About the delay opening images, I have heard some reports of something similar happening, but they were isolated to very few users. There’s not enough information yet to investigate since no developer has reproduced the issue (I think) and there is a thousand places to look. If you are willing and able to reproduce the problem with a debug build (available here as “RawTherapee_5.10_win64_debug.zip”, then it may be possible to capture some useful information about what RawTherapee is doing that is taking so long. If you (or anyone) is up to this task, I’ll be happy to provide detailed instructions. The process is similar to capturing a backtrace after a crash.
Hi Richard. Just wanted to confirm that I had the same issue as Carlos with v5.10 downloaded from the official site on two different Intel Macs (running 14.2.1 and 12.7.3).
On both of my Macs the issue has been resolved by installing the latest build (3/4/24) from your iCloud.
I assume it’s the March 16th one because there is no March 13 (and 13.3 refers to the macOS version). Yes, they are the same. The link provided by @beatrubi is https://rawtherapee.com/shared/builds/mac/ and the file name is RawTherapee_macOS_13.3_Universal_5.10.zip. The macOS download button on rawtherapee.com links to https://rawtherapee.com/shared/builds/mac/RawTherapee_macOS_13.3_Universal_5.10.zip, so they are the exact same.
Thanks for your effort!