I’d like to suggest that PL improves its management of sidecar files.
Currently, PL sidecars are saved to the host folder, holding all the raw/RGB files and that’s it. Lr also does the same, dumps its sidecars in the host folder.
Best practice, is to keep seperate file types in seperate folders. We have good examples of this from a number of OEMs, like inter alia Nikon NX Studio and Exposure Xn.
Fuji users can take their sidecar management capability to the ‘best in class’ by using RAW FILE CONVERTER EX 3.0 powered by SILKYPIX. This software will, when deleting a file or group of files, search out all sidecar files (in host folder and any sub-folders,) then ask if all such associated sidecars be deleted, (in addition to the Raw/ RGB files selected.)
The Silkypix approach is truely the ‘gold standard’. It would be grealy appreciated if this attention to detail suggestion be implemented in PL.
I keep my raw files together with the sidecar files. If I delete/move the raw file, all sidecars get deleted/moved along. All good. I do not see a problem
I’m not in favour of this proposal, unless it also comes with a user preference option for DOP files to be stored, as now, in the original image folder. When moving, copying, or selecting images already processed in PL I want to be able to move any PL created files (i.e., DOPs or XMPs) along with the RAW image. I find this easiest to do when the sidecars are in the same folder alongside the RAW file. Having to select files in two, or more, folders would increase the likelihood of mistakes or omissions in my opinion.
This request doesn’t make sense to me. Why would I ever want to keep DOP or XMP files anywhere other than right beside the original file. These represent the sum total of my PP work and they would be in much more danger of being lost if stored elsewhere.
Did your quick test reveal the effect on .nkss files, Silkypix sidecars, Exposure Xn sidecars, etc… all contained in sub-folders? Also, did your quick test delete any Fujifilm X-Raw Studio sidecar files, contained in the host image folder(s).
I’d .like to suggest you perhaps undertake a longer test, on just how much hd capacity is used up by redundant sidecars. It can be quite substantial. Inter ali, this can really slow down searches on a Window machine.
Of course not. Any files created by other software is the responsibility of that other software. Or are you saying that Nikon should also be responsible for DOP files?
Since I don’t use a Fuji camera, I don’t have any such files. And, even if I did, it is Fuji’s responsibility.
PhotoLab’s searches are carried out on its own internal database, not on the file system, so why should they have to get involved in file system searches as well?
PhotoLab is an image editing app, not a general purpose do everything, file manager. If I want to delete a file and all its associated stuff, I just go into Finder and search for the file name, including sub-folders, and delete them from the search results - it’s not rocket science and including something like that would take away valuable developer resources for the most important thing for PL, which is editing images.
This request suprises me, too. I just imagine, with the next update Affinity Photo (or C1 or any other app) decides to get in charge of all sidecar files no matter what there origin is… what a mess!
Personally, I would be annoyed if I had to consent to deleting or moving the side cars when deleting or moving their associated image files. Why would I want to leave the sidecars untouched? If a convincing reason can be given, I might consider voting for this request. Otherwise I’ll have to pass.
Besides the fact that PhotoLab already manages image files and sidecars automatically within the app, one can simply sort files by extension/type or by size in a file browser if one wants to easily separate the sidecars or otherwise “work under the hood” for some reason. My own workflow benefits from having RAW files, exports, and sidecars together. I also find this easier when there is a need to perform troubleshooting with DxO.
Unlike most of the users here, I never use PhotoLab for file management. I mostly use FastRawViewer or the Mac Finder.
FastRawViewer sees the sidecars in the same folder and deletes them with the original image.
in the Finder since all the files are in the same folder, I can easily delete any images and sidecar files together as they are grouped by name. Subfolders would be a disaster for speed and convenience when doing housekeeping.
What I would like on the other hand is the ability to export images in parallel to the RAW+sidecar original folder.
In folder 20220413 tadten vs kittsee
DCIM
DxOExports
instead of
DCIM → DxOExports
It would be much easier to keep track of exports in a parallel folder to originals (only two to five folders there) rather than hunting for the in the originals folder with potentially hundreds of other files.
Currently one is forced to create the automated export folder as a subfolder of the folder containing one’s RAW images. I propose adding an option to make the automated export folder a parallel folder. DCIM above is a placeholder for RAW images as that’s the name of the folder where most cameras store their images. The name of the folder in the chart above could just as easily be Originals or RAW.
Proposed structure: 20220413 tadten vs kittsee contains
Originals
DxOExports
instead of 20220413 tadten vs kittsee contains
Originals with subfolder DxOExports
Additional options for the export folder is a new topic. I shouldn’t have made a joke in this thread about an only lightly related feature request. I’m sorry.
I definitely do NOT support this proposal … t’would be a recipe for disaster; especially for those of us who depend upon sidecar/.dop files to retain correction details related to the associated RAW/source-image files, instead of the database.
That’s good news: thanks for the tip. I was looking for a drop-down option in the “Folder: Original image folder; Custom folder” menu. I didn’t realise that PhotoLab would respect Unix folder navigation conventions.
I.e. for anyone who doesn’t catch it right away is the ../ part of the folder name which could be:
../Export
../DxOExports2
../FinishedPrint
../FinishedWeb
etc…
Note to explain how this naming could help improve workflow: the genius of this is that one doesn’t have to manually set a Custom folder for export each time and that if you generally use a standard export folder name, you don’t need to change the folder settings at all when switching between projects. Even changing the actual export folder version (sometimes I export multiple versions) becomes much faster.
