GNOME Bugzilla – Bug 790740
RAW file does not load
Last modified: 2018-05-24 18:46:28 UTC
Created attachment 364243 [details] Screen capture of error message When loading a .NEF file select open and then select a .NEF file the standard Tharpee/darktable error message is shown. Both RawTherapee 5.3 and darktable 3.3.0 is installed. Edit>Preferences>Image Import does not allow you to update the RAW Image Importer Plugin entry.
*** Bug 790735 has been marked as a duplicate of this bug. ***
We have had some fix in the current master code in order to find the raw editors, which indeed was broken on GIMP 2.9.6. See commit 855f2f1cbed972e82ed2e5fb9c143001cd858687. So I believe your bug is actually already fixed but you won't be able to test the fix unless you compile GIMP yourself or wait for the next development release (which should happen very soon). I suggest you try again after the update, and tell us if this is now fixed. In the meantime, I will leave this report opened.
The 2.9.8 release has been made - Richard, does anything change there?
No change to problem in 9.2.8. Still not loading RAW files.
(In reply to Jehan from comment #2) > We have had some fix in the current master code in order to find the raw > editors, which indeed was broken on GIMP 2.9.6. > See commit 855f2f1cbed972e82ed2e5fb9c143001cd858687. If the registry code there works, then this might work for darktable.exe The lookup for rawtherapee probably doesn't trigger the registry search, but that is based on only a cursory look through the utility code and how it is called from the rawtherapee-specific code. Is PATH still searched on the Windows platforms, or is this replaced by a registry-only lookup altogether?
> If the registry code there works, then this might work for darktable.exe Yeah I have no idea. I only know that something is supposed to be fixed, but I haven't tested personally or whatever. > Is PATH still searched on the Windows platforms, or is this replaced by a registry-only lookup altogether? From what I see in the code, it looks like PATH search should still work, assuming RegGetValue() did not return ERROR_SUCCESS. Also I am not sure how PATH search will work in Windows (as done by g_spawn_sync() in particular). Basically someone would need to test under Windows to make sure and fix this if the issue can be reproduced consistently.
Moving to 2.10 so that we don't lose sight of this one, though without anyone choosing to dedicate some time to the Windows platform, this can't be a blocker.
Unfortunately, I still don't have much time but I did some short research: Darktable: Seems to work on my machine. You have to install the most current Version of darktable though - older versions did create a registry key that was different from the one specified in file-darktable.c. RawTherapee: file-rawtherapee.c does not pass a registry key to file_raw_get_executable_path() so the executable can not be found via the registry. Unfortunately, RawTherapee does not register itself in Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths like darktable does. There is an entry in Computer\HKEY_CLASSES_ROOT\Applications\rawtherapee.exe\shell\open\command but the CLASSES-keys are for file type registrations ("Open with" etc.) so I don't think this key will always be there when RawTherapee is installed. It is possible to specify the path manually via the RAWTHERAPEE_EXECUTABLE environment variable or PATH but this causes a different problem: Against its promise in rawtherapee -help (" -v Print RawTherapee version number and exit"), RawTherapee does NOT exit and displays "Press any key to exit RawTherapee" in a console window when called like "rawtherapee -v". This blocks the GIMP startup process until a key is pressed. But even after that, Gimp does not recognize RawTherapee as a valid raw importer.
Hi, I am the original author of the GIMP plugin for rawtherapee (for the GIMP side of things, I heavily borrowed from the darktable's one). Unfortunately I don't have much access to windows so it might take a while before I can do some tests. However, I agree that this is pretty bad behaviour: > RawTherapee does NOT exit and displays "Press any key to exit RawTherapee" in a console window when called like "rawtherapee -v" I'll try to see what is going on. I know next to nothing about the windows registry though, so I can't be of much help there.
Regarding the Registry stuff: On Windows, "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths" (see file-darktable.c, line 35) is basically an alternative to the PATH environment variable that has some additional features like setting a custom PATH for specific programs. None of those features are used by the darktable-plugin. It just reads the content of the key's default value which is the application path and uses that to test whether darktable.exe can be run. For more info regarding this, see https://msdn.microsoft.com/en-us/library/windows/desktop/ee872121(v=vs.85).aspx Creating the respective registry key would be the task of the installer package of RawTherapee. But it is not mandatory to use the "App Paths" key - RawTherapee could as well create some other key that can be read by GIMP. We just have to find a common solution. In fact we could just use the key in HKEY_CLASSES_ROOT\Applications\rawtherapee.exe if it is guaranteed to be always there, i.e. it is created while installing RT.
Hey Upstream RT issue: https://github.com/Beep6581/RawTherapee/issues/4514 > RawTherapee does NOT exit and displays "Press any key to exit RawTherapee" in a console window when called like "rawtherapee -v" > Without showing the "Press any key to exit..." stuff, the console window would be automatically closed after writing the version information or the help when rt is not started from console. Just add -w parameter.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1237.