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.

1 Like

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

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.

  1. An option to export to a directory (folder) that ties in with the ‘Project’ as defined in DxPL?

  2. 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.

  3. 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.