An Observatory library is a document package – an ordinary folder that is presented by macOS Finder as a single file. To gain a better understanding of what Observatory does with your images, lets take a high-level look at what is inside a library.
A library may contain the following folders:
Observatory allows you to attach files to images and albums. You can for example attach an observation log or research paper to an album, to quickly look into or open it while working in Observatory. Usually you would link the attachments, but you can also decide to embed them in the library, in which case they end up here.
This folder contains the notes of your images and albums. These notes are extracted automatically from your images when you import them (e.g. FITS
HISTORY keywords), but you can also add your own.
This folder contains the main database of an Observatory library.
This folder contains the original files you downloaded using Virtual Observatory as well as the managed masters you created when choosing Image ▸ New ▸ Master.
After they have been created, none of these files will ever be altered. Only if no image version refers it they are deleted. They are off-limits for the Image ▸ Show Master in Finder and Image ▸ Open Master menu items. You need to choose one of the File ▸ Export menu items if you wish direct access to these files. This is by design, because by enforcing immutability, Time Machine integration is much more space efficient, and you can be certain that data obtained through Virtual Observatory is unaltered.
This folder contains many small (~ 1 KB) files, one for each image version, that contain metadata. They are usually accompanied by a few helper files, but those are not relevant for this description.
When you import an image into a library, Observatory doesn’t copy the image, but extracts the metadata (dimensions, exposure date/time, exposure duration, etc), normalizes it, and stores it in the library’s database. It does this for many different types of images, including FITS, XISF (PixInsight), SBIG, DNG, NEF, CR2, TIFF, JPG, etc.
It stores this original normalized data, but also creates a first “version” of it, which is what you see and can edit in the Inspectors.
Key is that it doesn’t copy the actual pixel data of the image. It only maintains a reference to the original file. This master image is not copied, moved, or altered. It remains external to the library. The file reference is stored such that renaming or moving the master file on the same disk will usually not break the link. And if the link is broken, then you can choose Image ▸ Locate Master… to fix it.
Copying a version also doesn’t copy the master image, but only the much smaller metadata. It is therefore a very efficient operation. Changes applied to an image always are applied to a version. For example, if you rotate an image in Observatory, it doesn’t actually rotate the master image, but only adds a “prescription” to the image version.
This approach means that you can for example create one –90° rotated version of a master image, and other +90° rotated version of the same master image, and it would barely use any additional disk space. Or, you can use one version of a master image with a certain weight in one stack, and another version of the same master with a different weight in another stack.
The main difference between a master image and a managed master image, is that the former lives outside the library, while the latter is stored inside the library. A second difference of course is that a managed master cannot be altered, but by using an external editor you can alter a regular master. Observatory does detect if you do alter a master, and allows you to quickly synchronize the metadata using Image ▸ Reset Attributes….