First step should be to conduct a detailed review of the data to establish solid project expectations so you can make these sort of decisions with confidence.

Key thing we're looking to answer is:

• How much overlap can an image have between sub-projects?
• How much 'meta data' do we want to embed in the file structure vs an external storage/library file?
• How much work would we want to do by ourselves, vs how much would we rather push off onto the computer to do for us...

---

Personally I would use Windows with Lightroom as an image library management solution, but this is less than ideal if you intend to remain within a Linux ecosystem.

However tools like Lightroom are kind of a bloated option with a lot of extra features that we probably don't need for this kind of project.

In a linux environment we may be better off scripting much of the handling ourselves over relying on ready-made tools. [It is also an excellent skill building task that gives highly useful experience in data-management.]

---

Manually sorting images into folders is 'less than ideal', prone to error, and awkward to reliably correct. This is especially true if there are large overlaps in sub-projects that any given image is likely to be involved in, or if you decide a major change is required later on.

• When dealing with data, we can waste our time, or we can waste a computers time. Choose wisely.

Keywording and Database interaction is a far more robust option than getting overly complicated with folders. Unless there is effectively zero overlap in sub-projects that an image is included in, then it is far better to allow the computer to "do the sorting" for us.

Keep the core of the archive simple with a standard timestamp based file structure.

Project/Year/Month/Day/[timestamped_filename]

or even just

Project/Year_Month_Day/[timestamped_filename]

From here we are going to want either existing software that can act like Lightroom or another Image Cataloging software, or create scripts to deal with things for us.

General workflow would be:

• Import images [or their file names] into a database. [flagged as 'new']
• Keyword and add meta-data as required by project. [Once finished, remove 'new' flag. Even in something like Lightroom we want to maintain a clear indicator of whether the entry for a given image is 'finished' or if it needs more work before it is ready to move forward within the project.]
• Define 'Views' of the data based on the above keywording and metadata to select the specific images needed for a given state of the project.

Project file structure then looks like:

\Project\
-\Core Image folder\[Subfolders]
-\Library, database, or Metadata\
-\Temporary Exports or 'views' folders\ {Flexible data generated on the fly as needed}

If you are comfortable with scripting and simple databases, then it is fairly easy to build out a basic toolchain yourself to generate view folders that contain symlinks back to the original source image if you don't require robust image review/editing tools from a more complex piece of software along the lines of Lightroom.

The specifics on how to implement something like this yourself easily vary, but the heart of it would be to define your target for a specific grouping based on a database query, which you then pass through a file management script.

Select all images that had keyword Alpha to create a list, and use that list to pull copies/links into a Sub-Project View Folder without changing data stored in the Core Image Folder.

If requirements of a sub-project change, then the old folder can be deleted and a replacement generated on the fly without having to manually copy and paste files to or from folders.

---

Remember to backup your core data and metadata! Exports/views can be regenerated on the fly as needed, but you want to make sure the original data is hard to lose or corrupt.