Although SEG-Y is a very useful standard data interchange format, it is not optimised for performance, and as a result, Insight does not address SEG-Y files directly. They must first be converted from SEG-Y to our proprietary DUGIO format using Insight's SEG-Y Loader tool.  Once converted, the original SEG-Y files are no longer required and may be archived.

The DUGIO format consists of a directory with a name that ends in ".dugio". We recommend a consistent approach to the naming of volumes so that it is easy to match each volume to its correct survey. Best practice is to include the survey, data type and description, i.e. SurveyName_PSTM_near-stack.dugio.

Insight requires no specific directory structure, and users working on projects with many volumes and surveys may also find it helpful to create per-survey subdirectories inside the 100sei directory.

Within the dugio directory, there are one or more index files (ending in .idx) and data files (ending in a number). By default, data files are split so that no single file is larger than 4 GB, which means it can be stored easily on any filesystem including FAT32. For 2D volumes, there will be an index and at least one data file for each line.

The dugio directory may also contain additional .dugio directories inside for Inline-, Crossline-, and Z-slice-optimised volumes. These are essentially a way for the user to trade disk space for improved performance, and are created by Insight or the SEG-Y Loader upon request.  You should NOT create, move, or delete these manually.

In some cases, you may want to split projects across multiple directories on different file systems, e.g. to store small project data on the shared network disk, and large bulk data locally for improved performance. It is not necessary to do anything special to achieve this, as Insight will let users import a dugio volume from any directory, even one outside the project hierarchy. However, if you want to change the default location for where dugio volumes are written and selected, you can change the "volumes" line of the dug.project file (see How do I change Insight's default directory?).

Like volumes, horizons are now stored in their own individual binary files in the 120hors directory. Unlike volumes, these files are inextricably linked to the project itself and cannot reside elsewhere. They are named automatically based on their database ID and must NOT be renamed.

Horizon data can be exported to and imported from text files via the Insight control panel.

Insight 4 uses a file-based database that is completely managed by Insight (the project.dugprj file). It requires no separate hardware, no server software, and no administration. It is created automatically by virtue of creating the project, which any user can do without assistance.

Because the database resides in a file, it is extremely important that the filesystem on which it is stored is reliable, particularly if multiple users will be accessing the project simultaneously. If the filesystem does not honour its commitments to isolate user activity, the project database will become corrupted and some or all of the project's data may be lost (see Network/Multi-User).

Insight does not yet provide any form of data security. It delegates this responsibility to the operating system and filesystem, which already have robust and well-understood security models.

In other words, if you do not want a user to have access to a given Insight project, you should not give them access to the directory in which it resides.

Because the Insight project databases contains user sessions, including in-progress sessions that have not been formally saved, users must be able to write to both the database file itself and the directory in which it resides. It is not currently possible to open an Insight project that resides in a directory that is entirely read-only.

DUGIO volumes may be individually controlled, however, and do not require write permission. If a user attempts to open a dugio volume for which they do not have permission, it will fail gracefully. In this way, you are able to write-protect major project data to prevent accidental deletion, as well as segregate volumes between different classes of users (e.g. in a data-room situation).