Seismic Volumes (SEG-Y)

This guide covers loading, displaying, and tuning SEG-Y seismic data in VRGS. The seismic volume object understands the SEG-Y rev 2.1 specification, handles arbitrarily large 3D post-stack cubes through an out-of-core tile cache and a brick-paged GPU atlas, and renders inline / crossline / time-slice sections, wiggle traces, and full 3D ray-marched volume views. It can also derive seismic attributes — envelope, spectral decomposition, dip / azimuth, coherence, curvature and more — and composite spectral bands into RGB blends.

Built for big data

Real-world post-stack volumes are routinely 5–50 GB. VRGS never loads the entire cube into RAM: it scans the file once to build a small on-disk index, decodes individual traces on demand, and pages GPU-resident bricks based on what's currently in view. A 50 GB cube is no different in workflow from a 50 MB one — only the wait at first scan.

What is SEG-Y?

SEG-Y is the Society of Exploration Geophysicists' standard for exchanging seismic data. A SEG-Y file consists of:

Block	Bytes	Purpose
Textual header	3200	Free-form EBCDIC (or ASCII) survey description
Binary header	400	Sample format, sample interval, sample count, rev 2.1 extensions
Extended text headers	3200 each (optional)	Additional metadata stanzas
Trace records	240 + N×4 each	Per-trace header + sample data

The trace header carries the geometry — inline number, crossline number, CDP X/Y, scalars — that lets us position the trace in the world. Every step of the import pipeline depends on those values being where the spec says they are, which is why the byte-location override controls (described below) exist.

Importing a SEG-Y file

Use any of the standard import paths:

• Right-click the Seismic Volumes group node in the Data Tree ➝ Import. The file dialog is filtered for .sgy / .segy and supports multi-select.
• Drag-and-drop a .sgy / .segy file onto the project window
• File ➝ Import (when available)

VRGS recognises the file by extension (.sgy / .segy) and routes it to the SEG-Y importer. The importer:

1. Opens the import preview dialog (described below) so you can confirm the trace-header byte layout before any scanning happens.
2. Creates an empty Seismic Volume object in the Data Tree under the Seismic Volumes group.
3. Launches a background scan thread with the confirmed field map.
4. Returns control to you.

The import preview dialog

Real-world SEG-Y files frequently put inline, crossline, and CDP X/Y at non-standard byte positions, and a scan run with the wrong layout produces garbage geometry. The preview dialog closes that loop before the scan:

• Textual header — the file's 3200-byte C-card block, shown in a fixed-pitch font (EBCDIC is converted automatically). Acquisition shops usually document the byte layout here — look for lines like INLINE 197-200 / CROSSLINE 201-204.
• Detection summary — what VRGS auto-detected and why (see below).
• Editable byte fields — inline / crossline byte + size, CDP X / CDP Y bytes, scalar byte, pre-filled with the detected values. Correct them here if the detection or the C-cards disagree with what you know about the file.

OK starts the background scan with the confirmed layout. Cancel skips the file (nothing is added to the project). With multi-select import, the dialog appears once per file.

Field-map auto-detection

The detector guesses the byte layout two independent ways and reports both in the detection summary:

1. Documented positions — it parses the textual header's C-cards for statements like INLINE 197 4 / CROSSLINE 201 4, ignoring range lines (INLINES 1600-1900) that would otherwise mislead.
2. Empirical scoring — it samples raw trace headers spread through the file and scores candidate byte pairs on how they behave: a true crossline number resets backwards every time the inline changes (nested counters like shotpoint or CDP sequence keep climbing), inline numbers stay constant for runs of traces, and coordinate fields cluster in plausible magnitude ranges.

When both methods agree you can almost always just press OK. The same detector is available later from the Properties panel as the Auto-detect (from file) preset — useful if you imported with the wrong layout and want a second opinion without re-importing.

The scan walks every trace in the file once, building a sidecar index file that records:

• Inline / crossline grid extent and step
• The (inline, crossline) → (CDP-X, CDP-Y) affine fit (handles skewed surveys; needs only ≥3 non-collinear corner traces)
• A 512-bin amplitude histogram + p1 / p99 percentiles for default clipping
• Per-trace file offsets (for variable-length traces) or a fixed stride (for the standard fixed-length case)
• Sample format, sample interval, recording delay

The sidecar lives at:

<project folder>/SEISMIC_INDEXES/<basename>.segyidx

so it travels with the project. The original SEG-Y file is not copied — it stays where you put it. If you move the project to another machine, copy the SEG-Y alongside it (or somewhere VRGS can re-resolve the recorded path).

What you'll see while the scan runs

• The volume appears in the Data Tree immediately.
• Its checkbox is unchecked (no display yet — the geometry isn't known).
• Selecting the volume and opening its Properties shows a Status row with Scanning XX%. This refreshes when you re-click the object.

For a 5 GB cube on a fast SSD, expect the scan to finish in 30–90 seconds. The scan does two passes: the first computes geometry + amplitude min/max + mean; the second walks the histogram for accurate percentiles. If you re-import the same file later and the sidecar's recorded size + mtime still match, the scan is skipped entirely and the volume binds in milliseconds.

Z axis: time vs depth

SEG-Y files come in two flavours:

• Time files store amplitudes against two-way travel time (ms TWT).
• Depth files store amplitudes against depth (metres or feet).

VRGS infers the kind from the binary header's measurement_system field (1 = metres, 2 = feet, otherwise time). You can override this later in the Properties panel under Geometry → Z axis.

The volume renders downward in world space (sample 0 at the top, last sample at the bottom), shifted by the per-trace delay_recording_time.

Per-volume origin

Every volume carries its own (x, y, z) origin in world coordinates, defaulted to the centre of the cube during the first scan. Internally, all OpenGL math runs in origin-relative float precision, so VRGS can render surveys located 500 km from the world origin without the typical "z-fighting at depth" precision artefacts.

You normally don't need to touch the origin. If you're co-rendering multiple cubes with very disparate locations and want them all sharing one float-precision frame, set them to a common origin.

Display modes

Inline / crossline / time-slice sections

The default display. Each visible section is rendered as a single textured quad whose pixels come from a per-section R32F texture; trace amplitudes are sampled per-pixel and mapped through the active colormap.

To move a section, expand the Sections group in the Properties panel and edit the Inline, Crossline, and Time slice fields — each has a spin control that steps through the survey, and typed values snap to the nearest real line. Slices bake in the background, so the previous slice keeps showing while you scrub.

Each field is paired with a Show inline, Show crossline, or Show time slice checkbox, so you can display any subset of the three orthogonal planes — just the inline, say, or the inline and crossline without the time-slice. Hiding a section leaves its line / crossline / sample position untouched, so re-showing it brings back exactly where you were. A Show bounding box checkbox in the same group outlines the volume's extent in both renderers.

Scrub a section with the mouse wheel

You don't have to go back to the Properties panel to move a section. Hover the pointer over a section in the 3D view and hold Shift while scrolling the mouse wheel — the section under the cursor steps through the volume one survey line (or one sample, for a time-slice) per notch. When several sections overlap, the one nearest the cursor scrubs. The wheel is consumed while you're over a section, so scrubbing at the survey edge never turns into an accidental zoom.

Wiggle overlay

When Wiggle overlay is enabled, every trace on each visible inline/crossline section is drawn as a single line strip whose vertices are offset along the across-trace axis by the (gain × polarity × amplitude) at each sample. Time-slices have no time axis and are not overlaid.

• Wiggle scale — fraction of one trace-spacing the wiggle swings by; default 0.5 (max excursion = half a trace spacing). Increase for more visible wiggles; decrease in dense surveys to avoid crossover.
• Wiggle color — line colour. Default black; use white over a dark colormap.

3D volume render

Toggle 3D volume render in the Sections group to enable a full front-to-back ray-marched composite of the entire cube. The renderer is brick-paged with levels of detail: the cube is divided into 64³-voxel bricks, a fixed-size GPU atlas holds as many bricks as the budget allows, and a per-level page table maps each brick to its atlas slot. On top of the full-resolution bricks sits a pyramid of coarser levels — a level-1 brick covers 128³ source voxels decimated into one 64³ slot, level 2 covers 256³, and so on until the entire survey fits in at most 64 bricks.

That coarsest level is always kept resident, so:

• The whole cube appears within seconds of enabling the render, at overview resolution, regardless of how big the file is (a 10 GB survey's overview is ~30 MB of bricks).
• Detail streams in near the camera. Each halving of distance earns one finer level; full resolution appears where you're actually looking. Refinement is progressive — while a fine brick is still streaming, the ray-marcher falls back to the coarser data underneath it, so you never see holes.
• Moving the camera degrades resolution, not coverage. Flying to a new region shows coarse data immediately and sharpens over the next seconds as fine bricks page in; long-untouched fine bricks are evicted from the LRU while the overview stays pinned.

The ray-marcher composites front-to-back with an opacity transfer that weights strong reflectors (colormap extremes) as opaque and near-zero background as transparent, so the geology reads through the cube instead of being buried in uniform fog. Opacity, Filter min/max, and Gain all feed the transfer — tightening the colour range makes more of the cube read as "strong" and therefore opaque.

Sections and the 3D volume are independent

The section display and the 3D volume render are separate toggles. When 3D volume render is on, the composite is drawn over the section planes and can hide them. To work with the sections alone (for example while digitising a horizon), simply uncheck 3D volume render — the active inline / crossline / time-slice keep rendering on their own.

Colour, histogram & filter

Seismic volumes draw from the project colour maps — the same shared list the meshes, point clouds, and other objects use — shown with a histogram of the volume's amplitudes so you can see where the data sits and set the colour range against it. These controls live in the Display group:

• Colour Map — pick any map from the project list (each entry shows a preview swatch). A sensible default is applied automatically for the volume: Seismic for raw amplitudes, and per-attribute defaults for derived volumes (see Computing attributes).
• Filter min / Filter max — the low and high amplitude bounds of the colour range. Amplitudes at or below Filter min take the bottom of the map, at or above Filter max the top. Drag the handles on the histogram, or type the values. Defaults are derived from the index's percentiles, centred on zero for signed data.
• Scale Colours — stretch the colour ramp across the filter window (the full map spans Filter min → Filter max) rather than across the whole data range.
• Use Filter (hide) — additionally hide the samples that fall outside the filter window, instead of clamping them to the end colours. Use it to punch out a background band and show only the amplitudes of interest.
• Reverse colours — flip the colour ramp end-for-end.
• Reset colour filter — checkbox trigger; re-derives the colour range and default filter window from the data. Use when the current range looks washed out or saturated.

The remaining Display controls act on the amplitudes before the colour lookup:

• Gain — multiplier applied before the colour range. One-shot brightening without touching the filter window.
• Polarity flip — multiplies amplitudes by −1 before the colour lookup. Sometimes needed to match a different shop's polarity convention.
• Opacity — section opacity, 0–1.
• Vertical scale — display-only Z stretch. 1.0 means one world unit per millisecond TWT (or per depth unit), which towers over outcrop-scale scenes; drop it to 0.1–0.05 to compress a deep section down to something that co-renders comfortably with models and point clouds. Affects sections, wiggle, and the 3D volume render alike; the data itself is untouched.
• AGC window (ms) — automatic gain control. 0 = off. When set (typical: 250–1000 ms), every sample is rescaled by the ratio of the whole-trace RMS to the RMS over a sliding window of this width, which evens out amplitude decay with depth while keeping the trace's overall level — so your colour range stays meaningful. Applies to sections and the wiggle overlay; the 3D volume render always shows raw amplitudes. Gain is capped at 20× so dead zones can't amplify to noise.

Computing attributes

Right-click a seismic volume in the Data Tree ➝ Compute Attribute ▸ to derive a new attribute volume from a post-stack cube. The flyout offers two families of attribute, computed in different ways.

Every derived volume appears as its own node in the Data Tree, named after the source and the attribute — MyCube [Envelope], MyCube [Spectral 15 Hz], MyCube [Dip], and so on — overlaid exactly on the source geometry. Each behaves like any other seismic volume: you can scrub its sections, toggle the 3D render, and change its colour map, histogram, and filter independently of the source.

Per-trace attributes

These are computed on the fly as each trace is read — nothing extra is written to disk, and the new volume is ready to display immediately. Pick any of:

• Envelope — reflection strength (instantaneous amplitude). Sequential viridis colour map by default.
• RMS Amplitude — windowed root-mean-square amplitude.
• Instantaneous Phase — displayed with a cyclic colour map (twilight) so the ±180° phase wrap has no visible seam.
• Instantaneous Frequency.
• Sweetness — envelope divided by the square root of instantaneous frequency; highlights clean, high-amplitude, low-frequency intervals.
• Relative Acoustic Impedance — a running trace integral with a low-cut filter, shown on a diverging colour map.

Sensible per-attribute colour, histogram, and filter defaults are applied automatically, so a freshly created attribute is already reasonably displayed. Tune them in the Display group as for any volume — see Colour, histogram & filter.

Spectral decomposition

Compute Attribute ▸ Spectral Decomposition… splits the cube into a set of single-frequency bands, each showing the spectral amplitude at one frequency (a Gabor / Morlet transform). This is the classic tool for thin-bed and channel imaging, where different bed thicknesses tune to different frequencies.

Two quick prompts drive it:

1. Min frequency (Hz) and Max frequency (Hz) — the frequency range to sample. VRGS pre-fills a sensible range from the data's Nyquist frequency; adjust to taste.
2. Number of frequency bands — how many volumes to create (default 5).

VRGS then creates one per-trace attribute volume per band — for example MyCube [Spectral 15 Hz], MyCube [Spectral 25 Hz], MyCube [Spectral 35 Hz] — each a lazy per-trace attribute like the others above. Three of these bands make an ideal input to an RGB blend.

Volumetric (3-D neighbourhood) attributes

Some attributes can't be computed from a single trace — they need a small 3-D neighbourhood of traces around each sample. For these VRGS computes the whole cube and writes it out as a new SEG-Y file alongside the source, then loads that file back as a derived volume.

• Structural Dip + Azimuth… — structure-tensor estimate of the local reflector dip and azimuth. Produces two volumes, [Dip] and [Azimuth]; the azimuth uses a cyclic colour map (twilight) so compass directions wrap seamlessly.
• Coherence (Semblance)… — dip-steered coherence / semblance, which drops towards zero across faults and stratigraphic edges. Produces a [Coherence] volume (black = incoherent).
• Curvature (K+, K-, mean, Gauss)… — reflector curvature, output as four volumes: most-positive [Curvature K+], most-negative [Curvature K-], [Curvature mean], and [Curvature Gaussian].

Because these operate on a neighbourhood, they need a true 3-D cube: at least 3 inlines × 3 crosslines (curvature needs at least 5 inlines). VRGS warns and does nothing if the volume is a 2D line or too small.

Volumetric attributes run on a background thread, so the app stays fully responsive while they compute — you can keep panning, zooming, and working as normal; the main window is never disabled. A non-blocking progress indicator in the messages / status area reports how far along the computation is. When it finishes, the new volume(s) appear in the Data Tree automatically, checked on and overlaid on the source, each with a fitting colour map (dip = sequential viridis, azimuth = cyclic twilight, coherence = grayscale, curvature = diverging). Each new volume then does its own background scan / load — exactly like an imported cube — before it displays.

Only one attribute computation per source volume runs at a time. Starting another on the same cube while one is still in progress shows a "please wait for it to finish" note.

New SEG-Y files on disk

Unlike the per-trace and spectral attributes, the volumetric attributes write real SEG-Y files next to your source cube (e.g. MyCube_dip.sgy, MyCube_coherence.sgy). The seismic folder therefore needs to be writable, and these files occupy roughly as much disk as the source. Deleting the volume from the tree does not delete the file.

RGB blend

An RGB blend composites three per-trace attribute volumes of the same source cube into a single colour section. The classic use is three spectral-decomposition bands — low, mid, and high frequency — mapped to red, green, and blue, so that lateral changes in tuning (channels, thin beds) show up as colour.

To create one:

1. In the Data Tree, Ctrl-click to select exactly three per-trace attribute volumes that were all derived from the same source cube.
2. Right-click ➝ Create RGB Blend (3 selected)….

The three volumes map to Red, Green, Blue in tree order — so, for spectral bands, in ascending frequency order. VRGS creates a new RGB Blend [source] node rendered as inline / crossline / time-slice sections; the composite is consistent across all three section orientations.

A blend volume's Display group is replaced by a Blend channels group with a Red gain, Green gain, and Blue gain slider — a per-channel brightness multiplier so you can balance or boost each band in the composite (for spectral bands the label notes the band's frequency). The blend renders the baked colour composite directly, so it has no colour map, histogram, or amplitude filter of its own.

RGB blend is a section display

The RGB blend currently renders on the inline / crossline / time-slice sections (in the Vulkan renderer). It is a section composite, not a 3-D volume render — there is no ray-marched RGB block.

Trace header byte locations

Real-world SEG-Y files frequently disagree with the rev 2.1 spec on where to put inline, crossline, and CDP X/Y. The Trace header bytes group lets you tell VRGS where to look:

• Inline byte / size — where the inline number lives (rev 2.1: 189, size 4)
• Crossline byte / size — where the crossline number lives (rev 2.1: 193, size 4)
• CDP X byte / Y byte — ensemble coordinates (rev 2.1: 181 / 185)
• Scalar byte — coordinate scalar (rev 2.1: 71); positive multiplies, negative divides

A Preset dropdown fills the byte values for common conventions:

Preset	Inline	Crossline	CDP X	CDP Y
Auto-detect (from file)	detected	detected	detected	detected
Rev 2.1 standard	189	193	181	185
Legacy (5/9 inline-shotpoint)	5	9	73	77
OpendTect (9/13)	9	13	181	185

Auto-detect (from file) re-runs the import-time detector (C-card parsing + empirical header scoring) against the bound file and fills the fields with its best guess.

You can also revisit the full import preview at any time: right-click the volume in the Data Tree ➝ SEG-Y Header & Field Map… shows the file's C-cards, the detection summary, and the volume's current byte layout; pressing OK with edited values applies the new map and rescans.

After picking a preset (or hand-editing values), tick Apply field map. The volume re-scans asynchronously with the new locations; the sidecar is rebuilt.

Diagnosing wrong byte locations

If the Geometry group shows nonsense — inline range like 536870912 — 536936448, or "no traces parsed" — it's almost always wrong byte locations. Pick Auto-detect (from file) and apply; if that fails too, check the textual header C-cards for documented positions, and as a last resort open the SEG-Y file in a hex editor and inspect a few trace headers (offset 3600 + N × stride) to find where the integers look like sane inline numbers.

Memory budgets

The Memory group exposes three knobs:

• Tile cache (MB) — decoded-trace LRU cache budget. Default 64 MB. Hot sections benefit from a bigger cache; very wide cubes with rapid pan/scroll benefit from 256 MB or more.
• Volume atlas (MB) — GPU brick atlas size for 3D rendering. Default 512 MB. Capped to whole bricks per axis. Larger atlas = more of the cube resident on the GPU = less paging when you pan. Takes effect on the next 3D toggle (or after toggling the Linear atlas filter checkbox).
• Bricks per frame — cap on per-frame GPU brick uploads. Default 4 (≈4 MB / frame). Higher = faster fill but more frame stutter during heavy paging.
• Linear atlas filter — on (default) for smooth interpolated sampling. Brick boundaries are seamless: each brick stores a one-voxel shared border duplicating its neighbour's edge, so the ray-marcher's interpolation never bleeds into an unrelated atlas slot (the faint stripes older builds showed at brick edges are gone). Switch it off only if you specifically want blocky nearest-neighbour sampling.

2D lines

A 2D line — a survey where one grid axis is degenerate (a single inline or a single crossline) — gets dedicated treatment:

• During the scan VRGS records the world coordinates of every trace into the sidecar, so the line's true (possibly crooked) acquisition path is known.
• The Vulkan renderer draws the line as a curtain that follows that path — one vertical strip per trace — instead of a straight best-fit quad. Columns with no trace stay transparent, but the curtain geometry remains connected across the gap.
• Only the line section activates by default (no one-trace-wide orthogonal sliver, no 1-sample timeslice), and the 3D volume render is hidden (a single line has nothing to ray-march).
• World placement, bounds, and Navigate To use the recorded path, so the line lands at its true map position even though a collinear survey has no valid inline/crossline→world affine fit.

Lines imported before this feature carry an older sidecar with no path coordinates; VRGS detects that on the next project open and rescans the file automatically (2D lines only — 3D sidecars are reused untouched).

Horizon picking

Right-click a seismic volume in the Data Tree ➝ Pick Horizon in 3D View to digitise a horizon directly on the displayed sections:

• Each click ray-picks the volume's active sections (or the 2D-line curtain) and drops a point. The pick snaps to the strongest reflection within ±8 samples along the trace, so points land on the reflector rather than exactly under the cursor.
• A rubber-band preview tracks the cursor across the section while you digitise.
• Enter or double-click commits the points as a standard polyline in the Interpretation Tree — it renders in both renderers, persists with the project, and supports undo/delete like any other polyline. Backspace removes the last point; Escape cancels.

Picking works across multiple volumes at once (the nearest section hit wins), and on inlines, crosslines, and time-slices (time-slice picks don't snap vertically — their depth is the pick).

Digitising other objects on sections

Beyond the dedicated Horizon tool, seismic sections are now general interpretation surfaces: the standard Polyline digitise tool (and the measurement, label, and other point-placement tools) land their points directly on the displayed inline / crossline / time-slice planes, exactly as they do on a mesh or point cloud. Arm the tool from the ribbon and click on a section to drop points; double-click or Enter to commit.

The difference from the Horizon tool is snapping: Horizon picks snap to the strongest nearby reflection, whereas the general tools land the point precisely where you clicked on the section plane. Use Horizon for reflector tracking, and the Polyline tool for free-form annotation that should follow the cursor.

Horizon picking in VR

The VR Edit menu has a Horizon tool alongside Polyline: the right controller's ray aims at the seismic sections (not the outcrop meshes), the trigger drops a snap-to-peak point, and the left grip commits the horizon as a polyline — the same gesture set as the VR Polyline tool, with the live sphere-and-tube preview.

Picking & info

Click on a section in the 3D view: the volume becomes the picked object, and its Properties shows a Last pick group with:

• Inline number
• Crossline number
• Sample index
• Amplitude at that voxel
• World position

The pick goes through every visible section quad and picks the nearest hit. Time-slices, inlines, and crosslines are all pickable.

Diagnostics

The Diagnostics group shows live state:

• Tile cache — used / budget MB (count traces)
• Brick atlas — resident / total slots (atlas voxel dims) (shown when the OpenGL renderer owns the atlas; the Vulkan renderer manages its atlas per-view)
• Brick grid — number of 64³ bricks along each axis
• Indexed traces — total trace count
• Amplitudes — [min, max] p1/p99 [low, high]

A Clear tile cache trigger checkbox drops every cached trace; the next read reaches disk again. Useful when you've changed something on disk or just want to free memory for another task.

Project persistence

The volume's complete state — file path, sidecar path, origin, Z kind, field map, all display settings, memory budgets — serialises into the project database as a JSON blob. The trace data itself stays in the SEG-Y file on disk; the sidecar stays under SEISMIC_INDEXES/.

When you reopen a project containing seismic volumes:

1. The volume rows appear in the Data Tree immediately.
2. Each volume launches an async re-bind to its recorded SEG-Y path.
3. If the sidecar is still valid (file size + mtime unchanged), the bind completes in milliseconds. Otherwise a fresh scan runs.
4. If the SEG-Y file is missing, the volume becomes a "broken link" — it stays in the project but doesn't render. Open Properties to see the error. To repair, edit the SEG-Y path in the project database or re-import.

Pre-stack gathers

Files with more than one trace per (inline, crossline) cell — pre-stack gathers — are detected at scan time and displayed as a brute stack: every read averages the whole ensemble (mean of finite samples per depth), so sections, wiggle, and the 3D render show a viewable stacked image instead of an arbitrary single offset. This is not a processing-grade stack (no NMO correction is applied); it exists so a gather file is inspectable, not interpretable offset-by-offset. The Diagnostics group shows a Pre-stack fold row when a file is detected as pre-stack.

On pre-stack volumes the Sections group gains a Gather trace control: 0 (default) shows the brute stack; N shows only the Nth trace of each ensemble — flip between near and far offsets for a quick offset QC. The selection applies everywhere (sections, wiggle, and the 3D render, which re-streams its bricks with the new selection).

Limitations

• Pre-stack gathers display as a brute stack (see above) — there is no per-offset display or NMO correction.
• Trace identification codes other than "live" are ignored when building the cube.
• Wiggle on time-slices is intentionally not drawn (no time axis).

Troubleshooting

Symptom	Likely cause	Fix
Volume in tree but never renders	Bind failed — check Properties → Status for the error	Verify the SEG-Y path is reachable; re-import if missing
"no traces parsed" or absurd inline range	Wrong byte locations	Pick Auto-detect (from file), then Apply field map
Sections look uniformly grey/white	Colour range way too wide	Reset colour filter in the Display group
Create RGB Blend says "select exactly three…"	Fewer/more than three attributes selected, or they aren't per-trace attributes of one cube	Ctrl-click exactly three attribute volumes derived from the same source
Dip / coherence / curvature greyed-out effect ("needs a 3-D cube")	Volume is a 2D line or smaller than 3×3	Use a 3-D cube (curvature needs ≥5 inlines)
Deep half of a section fades out	Amplitude decay with depth	Set AGC window (ms) to 250–1000
3D render shows nothing	3D toggle off, or atlas budget hasn't allocated	Toggle 3D off and on after raising the atlas budget
Sections hidden inside the 3D volume	3D volume render is on and the composite is drawn over the sections	Uncheck 3D volume render to show the sections alone
Frame rate drops while panning	Per-frame brick upload throttle being saturated	Lower Bricks per frame, or raise the atlas budget so fewer evictions occur
Re-import scans every time	Sidecar can't be written (permissions?)	Verify the project folder is writable; check for SEISMIC_INDEXES/

Reference

• See Seismic Volumes Properties for the full per-property reference.
• See Seismic Volumes Context Menu for the right-click commands available on a seismic volume in the Data Tree.
• The SEG-Y rev 2.1 specification is the authoritative reference for byte layouts and field semantics; it's published by the SEG.