I propose that PhotoLab should be enriched with a possibility to
Export to a Project
Other functionality as with folders: position target project
a) to an existing project group
b) to an existing project (as a subproject)
Other ideas welcome!
I donât understand the point of exporting RAWs as JPGs or TIFs to projects within a rather poor DAM? Especially when the database ocassionally gets deleted because of some malfunctions or whatever reason. So the projects would also be lost?
I understand that for many the database seems to be an issue. For what itâs worth, I have been using PhotoLab almost every day since Version 1 in 2017 and I have never had any significant issues related to the database.
Mark
Me neither, at least no issues Iâm aware of. I just would like to understand the benefit of the feature.
Iâve yet to use projects (the dependence on the database has no small role in holding me back). However, I understand the value of them and was surprised to find out that an exported image file has to manually be added post-export to the project one is working in. So this gets my vote.
So, do you usually export JPGs or TIFs into the genuine RAW folders? Iâm just asking because I keep exported files and RAW archive strictly separated. That way I can always delete the exports (if itâs just the base of panoramas, timelapses, focusstacks and therefore just another intermediate step).
Yes, for now I do all of my work in folders, where I collect all files related to a particular set of photos: RAWs, sidecars, and all exports (from intermediate processing stages and the final output files). When Iâm done with the set, I use a file browser to copy the final exports to a collection on another drive and then move the whole work folder to an archive on a third drive. Iâm not presently using a DAM, either.
Thatâs the beauty of projects or collections or albums or whatever their name might be: We can put images in whatever folders we like and collect a bunch in a project without duplicating images. I used to strictly work with projects because I found them to be more snappy, but exports always vanished from the projects and had to be looked for and reassembled.
I often open or vote for a feature request, even though I donât necessarily profit from them directly. Itâs about looking beyond the tip of oneâs nose and about what could make sense for a increasingly well-rounded product for a userbase that should grow ever happier with DPL.
Only as an option: good idea!
In my usage, it would be a sub-project.
This is indeed only worthwhile if PL evolves further into a proper DAM.
Regarding the database, there is a backup option.
@platypus the real export option that is required is out of the database entirely to secure projects externally, with the ability to restore them of course. At least one user lost a lot of project data during the PL4 to PL5 upgrade when PL5 âlost the plotâ for some users. DxO support eventually had a virtual meeting with the user and managed to fix the problem (restore the lost projects)!?
But my suggestion for offline copying is not a trivial exercise because âProjectsâ are linked to âProjectsItemsâ which are linked to âItemsâ (Images) which are linked to âFoldersâ which are linked to âSourcesâ on Win 10 and the equivalent (I suspect) on the Mac.
So to copy a project to an external store the related entries from 5 linked structures would need to be copied (I think) but (I believe) that the pointers will ultimately point via âFoldersâ and âSourcesâ to the image on disk so they are pointing back to the source of all âwisdomâ the image and its DOP!
A simpler âautomaticâ alternative @Musashi would be to store âprojectâ data in the DOP, i.e store names of the 'âProjectsâ to which an image belongs (potentially more than one) so that it could automatically be returned âhomeâ in the event that it becomes detached!
I suddenly thought that it might already do that!? Any idea what the Albums field in the DOP is/was for�
I have been caught out by the same issue @platypus, i.e. exports are not automatically linked to the project/external selection of the original image(s) but when using âExternal sourcesâ. When I launch DxPL from another application with a chosen image or images (the latter can be from multiple directories) and DxPL creates a âProjectsâ entry with a âProjectTypeDiscriminatorâ value of EFDOPExternalSelectionâ.
No exports are added to the project and the focus of the project or external selection is solely upon the images in the project, i.e. not on any images whatsoever except those in the project.
So for the options I would add
c) same project as source (or original or âŚ)
Why do I appear to have âgainedâ a project name which is not in the âPROJECTSâ list nor on the database but is being offered as an option @sgospodarenko? It appears to have remembered a name I used or was going to use but then never assigned an image, which is no longer in the âProjectsâ structure but ârememberedâ somewhere and survived a restart?
âŚand there is always the mysterious âAlbumsâ tag on line 8 of the .dop sidecarâŚ
It does not reflect a project, and changing it with an editor does not bring anything back to DPLâs GUI. You could check the database thoughâŚ
@platypus I did and there is nothing obvious that ties in
Is it a remnant from the past or an idea that went nowhere or âŚ
It was just that I saw it while thinking about projects and wondered what it was for and was puzzled!?
Ran a few tests with DPL 7 and still think that exporting to a project should be added as a feature. At least, an âadd to original projectâ should be implemented.
Without that feature, I have to find the destination folder and files and add them back to the project. Lots of annoying actions imo, specially in relation to a simple select on export.
Exactly what do you mean e.g.
An option to export to a directory (folder) that ties in with the âProjectâ as defined in DxPL?
An âautomaticâ or simple manual command that allows a âProjectâ in the database to be updated with references to any images exported as âProjectâ images.
Any images exported to a âProjectâ are automatically added into the âProjectsâ structure as part of the export.
I would suggest that the problem is that either an entire directory exists in DxPL or not at all, i.e. individual images cannot exist alone in the database with the current architecture. The scheme works on the principle that when a user opens a directory all images in the directory are âdiscoveredâ and automatically imported.
Then a user is free to select images from any directory and add them to a âProjectâ regardless of the original directory they âbelongâ to.
The âProjectsâ do not exist without an image entry in the database but then exist only as a notional collection of images that are held in one or many directories. Their physical location has no relationship to/with their participation in one or many âProjectsâ.
My original linkages in an earlier post in this topic were slightly inaccurate! So the âProjectsâ entry is related to one or more pointers that point to the image entries in âItemsâ which point to the associated âSourcesâ entry (one âSourcesâ entry per image in âItemsâ) which points to the âFoldersâ structure.
There are no âProjectsâ pointers currently pointing directly to any physical items on disk only via the Tables that describe and point to the actual image file.
However, it would be an easy enough task to add a field to the âProjectsâ structure that could point to âFoldersâ to hold the directory name for a project.
An âExport Projectâ command could then be added to the product to export all images that belonged to a project to a specified directory. To that could also be added an âExport to Projectâ export option for individual image exports.
These export options would enable the internal âProjectsâ structure to have an external representation.
The issue of recreating the internal âProjectsâ structure would still need work but at least âProjectsâ could have a physical representation outside the database which would survive any database loss, deliberate or accidental.
Export of an image present in a project appears in said project without further ado.
