I looked into this briefly and found curious results..
Before I explain my findings, I'll say what I want.. I want to be able to create albums where the photos in them are links to originals. To preserve the way ZP works, the easiest thing would be to symlink, but in a way that maintains the file system structure that ZP uses.
.. so the results..
1. ZP doesn't specifically support server side image importing, and through standard uploading mechanism copies all images under itself.
2. Despite 1, the organization of images follows a file system structure.
Given 2, it is quite easy to sim link external image tree structures and have ZP immediately work with them. FANTASTIC.
The problem is
It's all or nothing.
a. symlink your root and publish only what you want to show or
b. you mimic your original structure and symlink individual files, leaving publishing on.
If a, publishing specific files is a PITA, because the ZP UI is not intuitive for that kind of job, nevertheless its doable now out of the box. NOTE: you'll lose your publish status if redoing the DB, and will revert to showing either all or no images if resetting (depending on the publish mode default).
If b, its took much work by hand, but you guarantee a separate virtual structure (on disk) that can be imported as is should something happen to ZP or your DB, and ideally, ZP would simlink for you by virtue of you selecting the photos you want in your albums. This is also friendly with any other image browsing software, because the virtual albums are virtual on the file system and not in a proprietary DB.
Can we either improve the UI to better navigate images / albums[folders] perhaps all as thumbnail on one page and quickly select publish/not publish
Can we add a new album creation mode where users pick images that are sim linked into ZP or a scan mode which symlinks the entire tree AND understands deletion as deletion of symlinks?
I think this feature would really entice a lot more users to take advantage of ZP.