Catalogs vs Folders vs Collections: How to Organize a Photo Library

Three layers of one library

Consider a photographer looking for a coastal portrait to include in a portfolio. The photograph was made during a commission, later shortlisted for a print, and is now relevant to a different project. Those facts can all be true without giving the original three competing homes on disk.

Physical storage, recorded information and working membership are different layers. Software sometimes displays them with similar folder-shaped icons, which makes the distinction easy to miss. The useful question is what changes when you act: the file location, the catalog record, or the photograph’s membership in a group?

Folder: a storage location

A directory groups files on a storage volume. A path identifies the route to an item, such as Archive/2025/Coast/Originals/DSC_1842.JPG. Moving a file to a different directory changes that route.

Catalog: recorded information and relationships

A catalog can hold a photograph’s reference, recorded file information, previews, ratings and organizational decisions. Its exact contents depend on the application. It is not safe to assume that the catalog contains the full original.

Collection: membership for a purpose

A virtual collection groups catalog entries. A photograph can belong to a commission, a print shortlist and a portfolio review without requiring a new original for each purpose. The application may call this an album, collection or catalog set.

These are working definitions rather than a promise that every product uses the words identically. A folder in Finder, a folder containing albums in Photos, and a catalog set drawn with a folder icon may represent different things. Before reorganizing important work, identify which layer the command actually affects.

One photograph, several relationships

Here is a hypothetical library record, simplified to show the relationships. The labels are educational; they are not a screenshot or a description of Lightbox Pro’s internal database schema.

One image fileArchive / Coast / DSC_1842.JPG

One catalog recordLocation, recorded facts, rating and relationships

Coastal commissionWhich job made it?

Print candidatesWhat might be printed?

Portfolio reviewWhere might it be used next?

The storage path answers a location question. The three memberships answer three editorial questions. Changing your portfolio does not require renaming the original commission. Removing a print candidate does not imply that the original should disappear from the archive.

Apple’s Photos album documentation supplies a familiar concrete example: photographs can belong to more than one album, and removing one from an album leaves its other memberships intact. That behavior illustrates virtual organization; use the documentation of your own application for its precise commands.

This is often described as a many-to-many relationship: one group contains many photographs, and one photograph can belong to many groups. You do not need database expertise to use it. You need to know that membership and physical duplication are separate actions.

Managed and referenced describe where the originals live

A managed library commonly copies imported originals into storage controlled by the application. A referenced library commonly leaves originals in folders you manage and records how to reach them. Some applications support both models within one library. The import option matters more than the product category on the box.

With managed storage, preserve the library in the form the application expects. Browsing inside a library package and moving individual components can disturb relationships that the interface normally manages for you. With referenced storage, preserve both the catalog and the source folders. Copying just the database is not a transfer of all the photographs.

Apple documents both imported and referenced files in Photos. Its referenced originals remain outside the library and need separate backup coverage; moving them in Finder can break location tracking. Those are Apple Photos rules, not a claim that all referenced applications have the same recovery controls.

Neither model is inherently a complete backup system. A managed library on a failed disk can be lost together with its originals. A referenced catalog can survive while its source drive is unavailable. A dependable plan describes where every required component resides and how a separate recovery copy is obtained.

A library is not necessarily a single file

In everyday speech, “my photo library” may mean the entire photographic archive. In an application, “library” may mean a particular package or database. That ambiguity matters when someone says they copied the library. Ask whether the copy includes original media, adjustment records, previews, companion files and application-specific organization.

Write a short inventory before making storage decisions. For each component, record the application that owns it, its location and whether it can be rebuilt. A preview cache may be replaceable when intact originals remain available. A collection membership list or an edit recipe may be unique work with no equivalent elsewhere.

Collections, hierarchies and filters answer different questions

A manually maintained collection is an explicit selection. You decide which photographs belong. This suits a client’s agreed print list, an editing handoff or a portfolio considered at a particular date. It is useful when membership should record a decision rather than follow changing criteria.

A saved query or smart collection, where supported, describes a rule: perhaps a date range and a minimum rating. Its result can change when records change. Raising a photograph’s rating may add it to the view without an explicit “add to collection” action. A changing view is valuable for ongoing work but may be unsuitable as the sole record of what a client approved last month.

A temporary filter is another view of the current records. Hiding unrated photographs does not erase them. Before concluding that files or decisions are missing, clear filters and confirm the current catalog, set and sort order. A reassuring count is meaningful only when you understand what is being counted.

Nested groups are not automatically nested folders

A collection called Portfolio may contain Coast and Portraits. That hierarchy makes the interface navigable. It need not create a directory called Portfolio on disk, and changing the hierarchy need not move any original pixels. Conversely, creating a folder in Finder does not automatically create an equivalent virtual collection in every application.

Keep nesting shallow enough that you can retrieve work without remembering an elaborate classification. Use stable job names for provenance and a small set of purpose-based groups for reuse. If a group only duplicates a filter you already use, ask whether maintaining both will create conflicting answers later.

Scroll across to read all columns.

What each operation changes

The word “remove” is incomplete without an object. Remove from a group, remove from a catalog, delete a derivative and delete a camera original are materially different intentions. Read the actual command and confirmation rather than inferring consequences from a keyboard key used elsewhere.

Scroll across to read all columns.

Imagine removing DSC_1842 from Print candidates because another frame is preferable. A collection operation is sufficient. Moving the JPEG to a folder called Rejected would instead change a physical reference and may confuse an editor or another catalog. Physical storage should not have to follow every provisional judgment.

There are valid reasons to copy or move files: separate working storage, a collaborator’s delivery or retiring a disk. Make those actions explicit projects with verification. They should not happen accidentally while rearranging an editorial shortlist.

Filenames, metadata and derivatives are not interchangeable identities

A filename is useful but rarely unique across a career. Two cameras can produce DSC_1842.JPG, and camera numbering can restart. Even inside one job, a RAW and a JPEG may share a stem while containing different representations. Include the job and relative location when identifying a selection.

A catalog’s internal identifier can remain stable while a source path changes, but another application may not know that identifier. A file-content checksum can establish byte equality against a trusted earlier value; it does not by itself explain the photograph’s caption, approved crop or role in an album. Choose evidence that answers the actual question.

Metadata adds another layer. A caption might be embedded, written to a sidecar, retained only in a catalog or present in several places. Reading a field is different from editing it, searching it or writing it back. See EXIF, IPTC and XMP explained before designing an exchange that depends on all your tools interpreting the same values.

A new rendition deserves an explicit relationship

A retouched TIFF and a web JPEG may depict the same exposure while serving different purposes. Treating them as irrelevant duplicates can discard valuable work. Keep a legible relationship between source, editable master and delivered derivative, using a naming convention and job record that survive outside the catalog.

For example, Coast_1842_master_v02.tif and Coast_1842_web_v02.jpg communicate role and revision in this hypothetical workflow. They do not guarantee that an application will link the versions automatically. Document that relationship where the next person can actually find it.

Design a library around retrieval, not maximum classification

Start with three questions you regularly ask. A commercial photographer might need the complete commission, the delivered selection and reusable portfolio work. An archive owner might need the original shoot, photographs with known people and images whose rights are uncertain. These questions determine useful relationships better than a universal folder template.

1. Give physical files a stable home. Preserve a successful existing job structure. If it needs change, plan that separately before cataloging around it.
2. Document the original and derivative roles. Make it possible to distinguish camera files, working masters and outputs without guessing from appearance.
3. Choose a few explicit collections. Create only groups that support a real decision or retrieval task.
4. Separate descriptive facts from working judgments. A place keyword, a rating, a retouching state and an album choice answer different questions.
5. Decide which results must be frozen. Preserve dated selection records for handoffs or approvals rather than relying solely on changing filters.
6. Protect both the files and the relationships. Record what is backed up and test a separate recovery before trusting the system.

Do this with one representative commission first. Include a photograph used in two projects, a RAW/JPEG pair, an edited master and a temporarily unavailable source. The exercise is about understanding consequences, not measuring catalog speed or forcing every archive into one structure.

The verified Lightbox Pro model

The reviewed Lightbox Pro development build 0.1.2 (60) uses native local catalogs referencing original photographs. It supports nested, overlapping catalog sets, ratings, color labels and filtering. Membership can change while the referenced source stays in its existing location. These are manual organizational controls, not automated subject classification.

Supported imported legacy descriptions, keywords and custom values are retained read-only, while current search is filename-based. Do not infer native keyword authoring, general metadata search, XMP writeback or a smart-collection engine from the existence of a catalog. Those are separate capabilities requiring separate evidence.

File tools also have distinct consequences. Transfer Copy retains source references; reference-changing transfer modes and physical moves require their own decisions. A virtual set is not a delivery folder. The referenced-file workflow explains supported local reconnection and its identity checks without treating Rebuild as a missing-file search.

A catalog preview can remain useful when an original is unavailable, but it is not the full-resolution original or its backup. Public release details and wider hardware acceptance are separate from this reviewed implementation. Product choice should follow the operations you need today, not assumptions about a generic “library” feature.

A short test that reveals whether the model is understood

On a disposable, backed-up sample, record a source file’s location. Add its catalog entry to two collections. Remove it from just one and confirm that the other membership and source remain. Close and reopen the catalog, then retrieve the photograph by the surviving group.

Next, change the rating and observe any filtered view. Confirm whether membership is explicit or rule-based. Finally, identify the separate backup containing the image and the backup containing the catalog. If any outcome surprises you, resolve it before reorganizing the main archive.

The useful result is a library whose actions are predictable: folders preserve location, the catalog preserves recorded decisions, and collections preserve purposeful relationships. Continue with a practical large-library organization session or build the protection around it with a professional photo backup strategy.