Pattern Syntax Reference
This reference guide documents the custom pattern syntax used in Flywheel's Bulk Import and Export filtering and mapping rules. This syntax provides a simpler, more intuitive alternative to full regular expressions for most common use cases.
Overview
Flywheel's pattern syntax is designed to be familiar to users of shell glob patterns while providing powerful filtering capabilities. The system supports multiple types of patterns:
- Simple patterns: Basic string matching with wildcards
- Field-based patterns: Filter specific metadata fields
- Glob-like patterns: File path matching with wildcard support
- Regular expressions: Full regex support when needed
Understanding Metadata
Before using metadata fields in patterns, it's helpful to understand how metadata works in Flywheel. See Understanding Metadata in Flywheel for a comprehensive overview of metadata types, structure, and usage.
Complex Configurations: Rule Files
For complex import/export scenarios with multiple sets of rules, see Rule Files to learn how to define rules in a reusable YAML format.
Basic Pattern Structure
All filter expressions follow this structure:
For example:
Operators
The following operators are supported:
| Operator | Description | Example |
|---|---|---|
= | Exact match (case-insensitive) | name=patient01 |
!= | Does not match | name!=temp |
< | Less than | size<10MB |
> | Greater than | size>1GB |
<= | Less than or equal | depth<=3 |
>= | Greater than or equal | depth>=2 |
=~ | Pattern match (glob-like) | path=~*.dcm |
!~ | Does not match pattern | path!~*temp* |
Wildcard Patterns
The pattern syntax supports several wildcard characters that are simpler than full regular expressions:
Single Asterisk (*)
Matches any sequence of characters except forward slashes (/). This is ideal for matching filenames or single directory levels.
Examples:
*.dcm- Matches any file ending in.dcmpatient*- Matches any string starting withpatient*001*- Matches any string containing001
Double Asterisk (**/)
Matches any sequence of characters including forward slashes. This allows matching across multiple directory levels.
Examples:
**/*.dcm- Matches.dcmfiles at any depthdata/**/images- Matchesimagesdirectory anywhere underdata
Literal Dot (.)
In patterns, dots are treated as literal characters (not regex wildcards).
Examples:
file.txt- Matches exactlyfile.txt*.dcm- Matches files ending in.dcm
Optional Sections ([...])
Square brackets make parts of the pattern optional.
Examples:
patient[_001]- Matchespatientorpatient_001scan[/series]*- Matchesscan*orscan/series*
DICOM UID Matching (\uid)
Special pattern for matching DICOM UIDs with optional modality prefixes.
Examples:
\uid- Matches valid DICOM UIDs like1.3.6.1.4.1.14519.5MR.\uid- Matches modality-prefixed UIDs likeMR.1.3.6.1.4.1.14519.5
Field Types
Different field types support different operators and value formats:
String Fields
Supported operators: =, !=, <, >, <=, >=, =~, !~
String matching is case-insensitive by default.
Examples:
Numeric Fields
Supported operators: =, !=, <, >, <=, >=
Examples:
Boolean Fields
Supported operators: =, !=
Accepts true/false, 1/0 (case-insensitive).
Examples:
Size Fields
Accepts human-readable size formats with units.
Supported units: B, KB, MB, GB, TB, PB
Examples:
Date/Time Fields
Supports ISO date/time formats and partial dates.
Examples:
Set/Array Fields
For fields containing multiple values (arrays), operators check if ANY value matches.
Examples:
Regular Expression Mode
For advanced users, full regular expression support is available by appending !r to the pattern:
Case-insensitive regex matching can be enabled with !i:
These can be combined:
Field Names
These are fields available for use in import and export rules:
File System Fields
path- Full file pathname- File name onlyext- File extension (e.g.,png,dcm)dir- Parent directory namedepth- Directory depth at which the file is locatedsize- File size in bytesctime- File created timestampmtime- File modified timestamp
Flywheel Metadata Fields
Applicability:
- Import Operations:
- Filters: Cannot use Flywheel metadata fields (only file system fields available)
- Mappings: Cannot use Flywheel metadata fields directly, but can use:
- File system information (
path,name,size, etc.) - DICOM headers (read directly from files during import)
- Previously-derived values from earlier mapping rules (see Recursive Mappings)
- File system information (
- Export Operations:
- Filters: Can use all Flywheel metadata fields listed below
- Mappings: Can use all Flywheel metadata fields for constructing destination paths
Important: During imports, files are not yet in Flywheel, so Flywheel metadata does not exist. During exports, file contents are not read, so only metadata already stored in Flywheel can be used.
For a comprehensive understanding of how metadata works in Flywheel, see Understanding Metadata in Flywheel.
Project Fields
project._id- Project unique identifierproject.label- Project name
Subject Fields
subject._id- Subject unique identifiersubject.label- Subject identifiersubject.firstname- Subject first namesubject.lastname- Subject last namesubject.sex- Subject sexsubject.mlset- Machine learning dataset designationsubject.info.*- Custom metadata (use specific keys, e.g.,subject.info.study_group)subject.tags- Subject tags
Session Fields
session._id- Session unique identifiersession.uid- Session UID (e.g., Study Instance UID)session.label- Session identifiersession.age- Subject age at time of session (in seconds)session.weight- Subject weightsession.operator- Session operator namesession.timestamp- Session timestampsession.info.*- Custom metadata (use specific keys, e.g.,session.info.scanner_model)session.tags- Session tags
Acquisition Fields
acquisition._id- Acquisition unique identifieracquisition.uid- Acquisition UID (e.g., Series Instance UID)acquisition.label- Acquisition nameacquisition.timestamp- Acquisition timestampacquisition.info.*- Custom metadata (use specific keys, e.g.,acquisition.info.protocol)acquisition.tags- Acquisition tags
File Fields
file.name- File namefile.type- File type (e.g.,dicom,nifti)file.modality- File modalityfile.size- File size in bytesfile.info.*- Custom metadata (use specific keys, e.g.,file.info.quality_check)file.tags- File tagsfile.classification- File classification objectfile.classification.*- Specific classification fields (use specific keys)
DICOM Metadata
For Import Operations:
During imports, DICOM headers can be read directly from DICOM files as they are being processed. Import mapping rules can reference DICOM tags using their standard names (e.g., PatientID, StudyDescription, Modality).
For Export Operations:
Exports cannot read file contents directly. To use DICOM metadata in export filters, the DICOM headers must first be extracted into Flywheel metadata by running the File Metadata Importer gear.
- Extraction Location: The File Metadata Importer gear stores DICOM headers at
file.info.header.dicom.* - Gear-Dependent: The exact metadata keys depend on the gear's logic and may vary across gear versions
- Not Native: Flywheel does not natively extract DICOM headers; this must be done via gears
Common DICOM Fields Available After Extraction:
The following list shows commonly-used DICOM fields as they appear in Flywheel after extraction by the File Metadata Importer gear:
file.info.header.dicom.PatientID- Patient IDfile.info.header.dicom.PatientName- Patient Namefile.info.header.dicom.StudyInstanceUID- Study Instance UIDfile.info.header.dicom.SeriesInstanceUID- Series Instance UIDfile.info.header.dicom.Modality- Imaging modality (MR, CT, etc.)file.info.header.dicom.SeriesDescription- Series descriptionfile.info.header.dicom.StudyDescription- Study descriptionfile.info.header.dicom.AcquisitionDate- Scan datefile.info.header.dicom.ImageComments- Image comments
Learn more about DICOM metadata extraction
Flywheel Hierarchy Fields
Flywheel hierarchy fields are available for use with filters only in Exports and not in Imports. These fields are available for use with mappings in Imports.
project.label- Project namesubject.label- Subject identifiersession.label- Session identifieracquisition.label- Acquisition name
Escaping Special Characters
To match literal special characters, escape them with backslashes:
Examples:
Recursive Mappings (Previously-Derived Values)
In import mappings, you can create intermediate values that can then be referenced in subsequent mapping rules. This allows you to build complex metadata values step by step.
How It Works:
- Create a custom key by assigning a value in one mapping rule
- Reference that custom key in later mapping rules using the same
{keyname}syntax
Example:
In this example:
{myCompositeKey}is calculated asMR_20240315_scan001.dcmacquisition.labelbecomesMR_20240315_scan001.dcm_Brain Protocolfile.info.myCompositeKeystores the intermediate value for future reference
Use Cases:
- Building complex labels from multiple DICOM fields
- Normalizing data across different naming conventions
- Creating reusable intermediate values for cleaner mapping rules
- Storing derived metadata alongside source metadata
Execution Order
Mapping rules are evaluated in the order they are specified. Ensure you define a custom key before referencing it in subsequent rules.
Pattern Examples
Basic File Filtering
Directory Structure Patterns
DICOM-Specific Patterns
For Export Operations (using extracted DICOM metadata):
For Import Mappings (reading DICOM headers directly):
Complex Combinations
Export Filter Examples:
Best Practices
- Start simple: Begin with basic patterns and add complexity as needed
- Test patterns: Use the test or dry-run modes to verify patterns match expected files
- Use specific patterns: More specific patterns improve performance and accuracy
- Escape when needed: Remember to escape literal special characters
- Consider case sensitivity: String matching is case-insensitive by default
- Use appropriate operators: Choose the right operator for your data type
Pattern Testing
Before running imports or exports, test your patterns using the test or dry-run modes.
For imports, the import test command shows exactly how the patterns will be applied and what metadata will be extracted.
For both imports and exports, the --dry-run option shows a preview of how the patterns will be applied to a small subset of the data. Dry-run mode performs a simulated import or export without making any actual changes, then presents a summary report of how the data would be processed. Dry-run mode does not process the full dataset but only a small subset.