Export to Projects

I propose that PhotoLab should be enriched with a possibility to

Export to a Project

  • the target project can be defined in the export dialogs
  • target projects include
    a) existing projects
    b) new projects

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?

1 Like

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.


Me neither, at least no issues I’m aware of. I just would like to understand the benefit of the feature.

1 Like

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.

1 Like

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!?