What is the library?

Support
1 
# +----------------+
# |  originalsDir  |
# +----------------+
#
# This is the directory that PhotoStructure uses to store original images when
# "copyAssetsToLibrary" is enabled. Absolute paths are supported. Relative
# paths are evaluated from your libraryPath. This setting defaults to ".",
# which is the same as your PhotoStructure library directory.
#
# If you open your PhotoStructure library on a different computer, and that
# computer doesn't have access to your originals volume, full-screen zoom
# won't work, and non-transcoded videos will not play.
#
# This system setting needs to be set appropriately on different computers (it
# won't be set automatically!)
#
# If you have a large library and want to use an SSD, we recommend you set
# your libraryPath to your SSD, and use this setting to store your originals
# on a larger volume, rather than using the "previewsDir" setting.
#
# PS_ORIGINALS_DIR="."

I still have difficulty understanding what the PS library is. Is it the location where my assets are? Is it the location where PS config files and caches live?

originalsDir stores images when “copyAssetsToLibrary” is enabled, but it is separate from libraryPath. But libraryPath stores images, too, right?

If you open your PhotoStructure library on a different computer, and that computer doesn't have access to your originals volume...
If the library is a storage of configs and caches, how can you open it on another computer? Doesn’t it live wherever you are serving PhotoStructure from? And if the library is a storage of your assets, then how can a directory have access to another directory (your originals volume)?

**System settings are specific to a computer.** Examples include what paths to scan, where to save logfiles, and what percent of the CPU can be used during imports.
I’m running PS under Docker, so maybe my understanding of what is/should be where, is biased by this format (or by my limited understanding even of that!). But how does this work? Can I host PS on serverA, and access it via PhotoStructure running on computerB, and separately access it via PhotoStructure running on computerC? If so, can computerB have a settings file saying “scan /mnt/photos” and computerC also have a settings file saying “scan /mnt/photos” but computerB’s /mnt/photos is a different directory than computerC’s /mnt/photos? And if that works, then when I run Photostructure from computerB, will I see the photos that were “imported” into the “library” from computerC’s /mnt/photos

I want to say that your documentation is fabulous, from your questions and explanations on this Forum, to the comments in the settings files, to the support posts on your website. I’m just having trouble understand the concept of the library.

2

I just separated the library from the originals folder myself (by default, they are all stored in the library folder: originals, thumbnails, database, etc). So from what I can tell, once you do that the only thing in the library folder is a hidden sub-folder (.photostructure) which contains the sqllite database, and preview files (3 different size thumbnails) for everything photo.

I guess it doesn’t matter much, but in my opinion the terminology is backwards. I would consider the library to be the curated, de-duped and organized set of pictures that goes into originalsDir, whereas the .photostructure folder is just the database and UI-supporting thumbnails.

3

Thanks for that explanation. I agree using “library” for where .photostructure lives is confusing, and I wonder what PhotoStructure calls the directory(ies) where your original asset files live. “Scan paths?”

But that’s just terminology. If you’re going to host your asset files in a directory that’s not the “library,” then all you do is add your asset-file directory(ies) to PhotoStructure’s “scan these paths” setting and you can have as many as you want?

4

In case you missed it:

Simply stated, a “library” is a self-contained, single directory that can be moved or mounted on different computers running different OSes and everything should “just work.”

This premise is what drove the following decisions for where to store the directories that PhotoStructure needs to do work:

  1. Where to copy original assets

This is typically the root directory of the “library” but can be configured to live elsewhere

  1. Where to store web-sized previews and transcoded videos

This is typically “hidden” in .photostructure/previews but can be configured to live elsewhere

  1. Where to store the library database

This is typically “hidden” in .photostructure/models. If the library is found to be on a remote filesystem, SQLite can’t handle that, so PhotoStructure copies the DB file to your /ps/tmp volume (which is why it must be a local filesystem)

  1. Where to store library-specific settings

See PhotoStructure | PhotoStructure's advanced settings

  1. Where to store logs and system-specific settings

This directory needs to be stable without configuration, so the default is specific to the current operating system.

Calling the originals directory a “library” is the terminology used by many commonly used DAMs, but there are hundreds of image gallery apps out there, and many happily muddle existing definitions.

Some DAMs and image organizers don’t store metadata alongside the originals, but most that I’ve looked at, do.

5

That’s a great explanation, and I guess I did miss it. :frowning:

6

No worries: this is all a work-in-progress, and discoverability of existing docs is hard to do.

I’d really recommend scanning the getting started pages, though!