So far, I’ve been using RawTherapee only on Windows. But I’m doing more and more on Linux, so I’d like to use RT there, too.
Problem: Whenever my existing .pp3 files contain a reference to an external file, e.g. a camera profile or a lens profile, these references, and, consequently, the .pp3 profiles, don’t work under Linux – for syntactic reasons, but also because the file structure is different.
I could probably come up with some script that traverses my Photo tree and re-writes all these references, but then I couldn’t use RT under Windows anymore.
Am I right in assuming that there is no current solution?
A possible solution – not for my immediate problem, but for the future – could be to define a base path for camera profiles and lens profiles in Preferences, and store relative paths in the .pp3s, just as it is done today for HaldCLUT.
A different approach could be to provide a kind of “path translation mechanism” that leaves absolute paths as they are but, e.g., would allow you to define a replacement of some path prefix with a different one.
I use a Linux desktop and a Windows tablet. Now, I do this with my own software, but I think my approach might have some applicable bits…
At home, I do my photo work either 1) on the Linux desktop against a local directory of my aggregate photo work dating back to 2004, or 2) on the Windows tablet against the same directory on the Linux desktop, as a Samba shared directory. I don’t use processing sidecars but if I did, they’d be in the same directory as my raw files.
In the field, I use my Windows tablet with a local directory. When I get home, I copy that tablet directory into my Linux desktop directory and go from there, transparently.
Really, I think the important thing is to work from a single repository of your image collection. That way, you don’t lose track of what you did, where. Ha, that might be a function of my advanced age… I haven’t used RT enough to know its behavior with respect to locations of sidecars and images, but there should be a way to organize a single place of access…
Maybe it was not clear from what I wrote; sorry about that.
The problem is not the sidecar files (.pp3 in case of RawTherapee) themselves but the fact that these sidecar files can (in my case: usually do) contain absolute references to other files.
And since the directory/file structure and -naming is different under Windows (e.g.: “E:/Photos”) and Linux (e.g.: “/media/Bezier/E/Photos”), these references work either under Linux or under Windows, but not under both.
So, say, I was doing some work on a photo under Windows and assigning a Custom Input Profile. If I subsequently want to continue my work under Linux, this Custom Input Profile won’t be found since its location is stored, in the .pp3 file, as an absolute path to a place that does not exist under Linux.
Yeah, if the sidecar is using absolute references…
When I wrote my software, one of the things I wanted to not do were sidecar files. Instead, I store the processing command string in the metadata of the image that it produced. Then I leave the determination of where a needed file might be to the installed software. Things like color profiles, lens correction database, all should be local on the particular computers. Works well for me.
RT might make a distinction between the current working directory and other places, where the former would not be referenced as a path and the others would. In that case you might have a hope…
Well, on the Windows machine you can arrange to reference a shared folder from a Linux machine as a drive number, e.g., E: Then, all the references to the Linux machine locations for that shared folder can be done as a proper Windows path, ‘E:/Pictures’ on the Windows machine might actually be /home/glenn/Pictures on the Linux machine.
That’s what I do, but I don’t use the alpha drive names. My /home/glenn/Pictures folder on the Linux box looks like ‘\\bena.local\glenn\Pictures’ on the Windows tablet.
If you’re stuck with copying stuff back and forth between machines, I think you’re not going to find a solution. A Linux shared folder would do the trick.