The folder~directory set-up on my computer showing a “dop” subfolder mixed in with other file types.įig.2 - Bridge screen shot - the “dop” folder itself also shows up if desired.įiles Sorted by Name - note the “Filter” panel at left which can isolate selected “File Types” on the fly.By default, FIP gauges files are put under the DirectOutput folder. These kinds of (flexible) capabilities makes for efficient file management. TIFF, PNG - virtually any file type - would show up too if there were any. 2 & 3) are some of its features in regard to sub-folder~directories included with your images. Bridge has the option to show files in the sub-folders of the selected “parent” folder in this case the “.dop” files which show up with the image files. For me Adobe’s Bridge is a perfect companion to my workflow with PhotoLab. The ancillary software in one’s work is critical. The backlog is significant enough without distractions such as side car sub-directories. I actually do not want to see - at this point - DXO do anything other than deliver on improvements to the core feature set of PhotoLab. But it is not rocket science.ĮDIT: I am speaking to the general philosophy here. This type of decision making is entirely left up to the content creator - and is far more complex. Not what I do - but I see no reason to artificially limit a pro level user’s workflow choices. If there was an option to create a sub-directory in the same directory as the processed images (or where ever the user chose to place the side car files) they would be responsible to maintain the association. I would expect users to be sophisticated enough to make their own choices. How would you move pictures around after processing? Moving side cars into a sub-directory would be a HUGE negative move AFAIC So after some months of useage i think i like the flexible form which DxO is using much more then the more clean version of subfolder system, because now i can create myself a subfolder to manage local backupping sidecars.īut this is just my workstyle and your mileage could be vary. (I sometime copy “difficult” images.raw in a seperate folder as “has to be done again better” as a form of practising when i have time and spirit.) Or even use filename_1, filename_2 for different backup moments of the sidecar to creates history steps of my stumbling and learning processing a image to see which approach will do best. (yes the virtual copy can do this also but its easy to make a mistake and alter the wrong one so a backup of the original sidecar is prefferable…) and when you gain by knowledge of use a better output? just copy this sidecar in the backup folder overwriting the old one done. big advantages is the easy movability just select image and sidecar and replace, the application picks up the new place reads sidecar again and no changes except the place on the folderstructure.Īnd as you copy all side cars, (when you done processing the bunch) in a sub folder in the image folder dated the copied date, then you have a local backup for when you experiment some more for different output. So the side by side yes looks a bit messy but using short by file exention does help alot. (non connected files to images)) PSE is a good example of this behaviour. (replacement outside the application is creating orphins. (first open the new folder to create a sidecar subfolder and then overwrite the new sidecars with the ones you got from the original sidecar folder.Ī central database is great for backup puposes but not that flexable at all. There is one “problem” doh, if you replace one or more images out of the folder to a new one you have to manually seek for the sidecars in the subfolder. I came from a subfolder structure and liked it too. Central data base, side car subfolder in image folder, side by side image and side car.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |