KEA file format guide
High-throughput sequencing (HTS)
Alignment file
Alignment files contain processed sequence reads aligned to a reference genome.
SAM (Sequence Alignment/Map): A text-based format storing read alignments
BAM: The binary version of SAM. Widely used for downstream analyses and visualization
@SQ SN:chr1 LN:248956422
read001 0 chr1 10001 255 50M * 0 0 ACTG... III...
read002 0 chr1 10150 255 50M * 0 0 TGCA... HHH...Count matrix - Raw counts
A tabular file in which rows correspond to features (e.g., genes, transcripts) and columns correspond to samples. Values typically represent raw read counts.
Gene Sample1 Sample2 Sample3
TP53 120 98 110
EGFR 45 52 60
MYC 200 230 210Count matrix - Normalized
A tabular file in which rows correspond to features (e.g., genes, transcripts) and columns correspond to samples. Values typically represent normalized expression levels.
Cell barcode matrix
A matrix specific to single-cell sequencing, where barcodes represent individual cells.
Feature information matrix
A file providing metadata for features (e.g., gene annotations, genomic coordinates, functional categories).
Spatial information (e.g., spatial coordinates, images)
Files capturing spatial metadata for spatial transcriptomics experiments.
Coordinate files (e.g., CSV or parquet files containing x-y positions of spots or cells)
Histological or imaging data (e.g., H&E-stained images in JPG or TIFF format)
Browser extensible data (.bed)
BED format describes genomic regions, typically with chromosome, start, end, and optional annotation fields. Used for storing intervals or annotation tracks.
chrom - The name of the chromosome (e.g. chr3, chrY, chr2_random) or scaffold (e.g. scaffold10671). Many assemblies also support several different chromosome aliases (e.g. '1' or 'NC_000001.11' in place of 'chr1').
chromStart - The starting position of the feature in the chromosome or scaffold. The first base in a chromosome is numbered 0.
chromEnd - The ending position of the feature in the chromosome or scaffold. The chromEnd base is not included in the display of the feature, however, the number in position format will be represented. For example, the first 100 bases of chromosome 1 are defined as chrom=1, chromStart=0, chromEnd=100, and span the bases numbered 0-99 in our software (not 0-100), but will represent the position notation chr1:1-100. Read more here. chromStart and chromEnd can be identical, creating a feature of length 0, commonly used for insertions. For example, use chromStart=0, chromEnd=0 to represent an insertion before the first nucleotide of a chromosome.
The 9 additional optional BED fields are:
name - Defines the name of the BED line. This label is displayed to the left of the BED line in the Genome Browser window when the track is open to full display mode or directly to the left of the item in pack mode.
score - A score between 0 and 1000. If the track line useScore attribute is set to 1 for this annotation data set, the score value will determine the level of gray in which this feature is displayed (higher numbers = darker gray). This table shows the Genome Browser's translation of BED score values into shades of gray:
shadescore in range
≤ 166
167-277
278-388
389-499
500-611
612-722
723-833
834-944
≥ 945
strand - Defines the strand. Either "." (=no strand) or "+" or "-".
thickStart - The starting position at which the feature is drawn thickly (for example, the start codon in gene displays). When there is no thick part, thickStart and thickEnd are usually set to the chromStart position.
thickEnd - The ending position at which the feature is drawn thickly (for example the stop codon in gene displays).
itemRgb - An RGB value of the form R,G,B (e.g. 255,0,0). If the track line itemRgb attribute is set to "On", this RBG value will determine the display color of the data contained in this BED line. NOTE: It is recommended that a simple color scheme (eight colors or less) be used with this attribute to avoid overwhelming the color resources of the Genome Browser and your Internet browser.
blockCount - The number of blocks (exons) in the BED line.
blockSizes - A comma-separated list of the block sizes. The number of items in this list should correspond to blockCount.
blockStarts - A comma-separated list of block starts. All of the blockStart positions should be calculated relative to chromStart. The number of items in this list should correspond to blockCount.
Reference: UCSC Genome Browser (Taken from https://genome.ucsc.edu/FAQ/FAQformat.html#format1)
NarrowPeak (.narrowPeak)
A BED-like format used by peak-calling tools (e.g., MACS2) for sharp or narrow peaks, such as transcription factor binding sites.
chrom - Name of the chromosome (or contig, scaffold, etc.).
chromStart - The starting position of the feature in the chromosome or scaffold. The first base in a chromosome is numbered 0.
chromEnd - The ending position of the feature in the chromosome or scaffold. The chromEnd base is not included in the display of the feature. For example, the first 100 bases of a chromosome are defined as chromStart=0, chromEnd=100, and span the bases numbered 0-99.
name - Name given to a region (preferably unique). Use "." if no name is assigned.
score - Indicates how dark the peak will be displayed in the browser (0-1000). If all scores were "'0"' when the data were submitted to the DCC, the DCC assigned scores 1-1000 based on signal value. Ideally the average signalValue per base spread is between 100-1000.
strand - +/- to denote strand or orientation (whenever applicable). Use "." if no orientation is assigned.
signalValue - Measurement of overall (usually, average) enrichment for the region.
pValue - Measurement of statistical significance (-log10). Use -1 if no pValue is assigned.
qValue - Measurement of statistical significance using false discovery rate (-log10). Use -1 if no qValue is assigned.
peak - Point-source called for this peak; 0-based offset from chromStart. Use -1 if no point-source called.
Reference: UCSC Genome Browser (Taken from https://genome.ucsc.edu/FAQ/FAQformat.html#format12)
BroadPeak (.broadPeak)
A BED-like format is used to represent broad enrichment regions, such as histone modifications.
chrom - Name of the chromosome (or contig, scaffold, etc.).
chromStart - The starting position of the feature in the chromosome or scaffold. The first base in a chromosome is numbered 0.
chromEnd - The ending position of the feature in the chromosome or scaffold. The chromEnd base is not included in the display of the feature. For example, the first 100 bases of a chromosome are defined as chromStart=0, chromEnd=100, and span the bases numbered 0-99. If all scores were "0" when the data were submitted to the DCC, the DCC assigned scores 1-1000 based on signal value. Ideally the average signalValue per base spread is between 100-1000.
name - Name given to a region (preferably unique). Use "." if no name is assigned.
score - Indicates how dark the peak will be displayed in the browser (0-1000).
strand - +/- to denote strand or orientation (whenever applicable). Use "." if no orientation is assigned.
signalValue - Measurement of overall (usually, average) enrichment for the region.
pValue - Measurement of statistical significance (-log10). Use -1 if no pValue is assigned.
qValue - Measurement of statistical significance using false discovery rate (-log10). Use -1 if no qValue is assigned.
Reference: UCSC Genome Browser (Taken from https://genome.ucsc.edu/FAQ/FAQformat.html#format13)
BedGraph (.bedgraph)
The bedGraph format allows the display of continuous-valued data in track format. This display type is useful for probability scores and transcriptome data. This track type is similar to the wiggle (WIG) format, but unlike the wiggle format, data exported in the bedGraph format are preserved in their original state. This can be seen on export using the table browser.
Reference: UCSC Genome Browser (Taken from https://genome.ucsc.edu/goldenPath/help/bedgraph.html)
WIG (.wig)
Wiggle format stores continuous-valued data such as read depth. Predecessor to BigWig, human-readable but less efficient for large datasets. Wiggle files allow you to plot quantitative data as either shades of color (dense mode) or bars of varying height (full and pack mode) on the genome.
General structure
Wiggle format is line-oriented. For wiggle custom tracks, the first line must be a track definition line (i.e., track type=wiggle_0), which designates the track as a wiggle track and adds a number of options for controlling the default display. For conversion to bigWig, the most common use case, this line must not be present.
Wiggle format is composed of declaration lines and data lines, and requires a separate wiggle track definition line. There are two options for formatting wiggle data: variableStep and fixedStep. These formats were developed to allow the file to be written as compactly as possible.
> variableStep format
This format is used for data with irregular intervals between new data points, and is the more commonly used wiggle format. After the wiggle track definition line, variableStep begins with a declaration line and is followed by two columns containing chromosome positions and data values:
The declaration line starts with the word variableStep and is followed by a specification for a chromosome. The optional span parameter (default: span=1) allows data composed of contiguous runs of bases with the same data value to be specified more succinctly. The span begins at each chromosome position specified and indicates the number of bases that data value should cover. For example, this variableStep specification:
is equivalent to:
Both versions display a value of 12.5 at position 300701-300705 on chromosome 2.
Caution about sparse variableStep data: The wiggle format was designed for quickly displaying data that is quite dense. The variableStep format, in particular, becomes very inefficient when there are only a few data points per 1,024 bases. If variableStep data points (i.e., chromStarts) are greater than about 100 bases apart, it is advisable to use BedGraph format.
> fixedStep format
This format is used for data with regular intervals between new data values and is the more compact wiggle format. After the wiggle track definition line, fixedStep begins with a declaration line and is followed by a single column of data values:
The declaration line starts with the word fixedStep and includes specifications for chromosome, start coordinate, and step size. The span specification has the same meaning as in variableStep format. For example, this fixedStep specification:
displays the values 11, 22, and 33 as single-base regions on chromosome 3 at positions 400601, 400701, and 400801, respectively. Adding span=5 to the declaration line:
causes the values 11, 22, and 33 to be displayed as 5-base regions on chromosome 3 at positions 400601-400605, 400701-400705, and 400801-400805, respectively.
Note that for both variableStep and fixedStep formats, the same span must be used throughout the dataset. If no span is specified, the default span of 1 is used. As the name suggests, fixedStep wiggles require the same size step throughout the dataset. If not specified, a step size of 1 is used.
Reference: UCSC Genome Browser (Taken from https://genome.ucsc.edu/goldenPath/help/wiggle.html)
BIGWIG (.bw)
A binary, indexed format for storing dense, continuous genomic data (e.g., coverage tracks). Designed for fast retrieval and efficient visualization in genome browsers.
The bigWig format is useful for dense, continuous data that will be displayed in the Genome Browser as a graph. BigWig files are created from wiggle (wig) type files using the program wigToBigWig. Alternatively, bigWig files can be created from bedGraph files, using the program bedGraphToBigWig.
Creating a bigWig track
To create a bigWig track from a wiggle file, follow these steps:
Step 1. Create a wig format file following the directions here. When converting a wig file to a bigWig file, you are limited to one track of data in your input file; therefore, you must create a separate wig file for each data track.
Step 2. Remove any existing "track" or "browser" lines from your wig file so that it contains only data.
Step 3. Download the wigToBigWig program from the binary utilities directory.
Step 4. Use the fetchChromSizes script from the same directory to create the chrom.sizes file for the UCSC database with which you are working (e.g., hg19). If the assembly genNom is hosted by UCSC, chrom.sizes can be a URL like: http://hgdownload.soe.ucsc.edu/goldenPath/genNom/bigZips/genNom.chrom.sizes
Step 5. Use the wigToBigWig utility to create the bigWig file from your wig file:
Note that the wigToBigWig program also accepts gzipped wig input files.
Step 6. Move the newly created bigWig file (myBigWig.bw) to a web-accessible http, https, or ftp location.
Step 7. If the file name ends with a .bigWig or .bw suffix, you can paste the URL directly into the custom track management page, click "submit" and view the file as a track in the Genome Browser. By default, the file name will be used to name the track. To configure the track label or other visualization options, you must create a track line, as shown in Step 8.
Step 8. Construct a custom track using a single track line. The most basic version of the track line will look something like this:
Paste the custom track line into the text box on the custom track management page.
bigWig custom track lines can have several optional parameters, including:
Reference: UCSC Genome Browser (Taken from https://genome.ucsc.edu/goldenPath/help/bigWig.html)
Image (.jpg, .tiff)
Image files associated with the submitted study.
JPG: Compressed image format for general visualization.
TIFF: High-quality, lossless format suitable for scientific imaging.
Microarray
Raw data file
Platform-specific raw signal files directly generated by array scanners.
Affymetrix: CEL
Agilent: Agilent feature extraction result text files
Nimblegen: PAIR
Illumina: IDAT files or Matrix worksheet containing non-normalized data
Processed file
Details about the processed file are provided below.
Affymetrix: Usually, probe set summary data is generated by the primary analysis software (e.g., Expression Console, Microarray Suite 5.0, Genotyping Console, GTYPE/CNAT, GTGS, Tiling Array Software, or GeneChip-compatible/other 3rd-party software). These data may be submitted either as CHP files or a tab-delimited text file (see examples in templates below). Please submit the data used to draw the conclusions of your study. For instance, do not submit CHP files analyzed with MAS5.0 if your submission is related to a publication based on GC-RMA data. In this case, you should submit the GC-RMA probe set summary data instead of MAS5.0 CHP files. (Taken from https://www.ncbi.nlm.nih.gov/geo/info/geo_affy.html)
Agilent: Processed/normalized data used to draw the conclusions from
your study. Two-color experiments (e.g. Cy3/Cy5) will typically have log (test/control) ratios; one-color experiments will have normalized signal intensities. Processed data should be provided as a value matrix containing data for all Samples. Data can be provided in an Excel worksheet or a tab-delimited text file. The table should include the Agilent Probe Names (e.g. A_23_P158231). (Taken from https://www.ncbi.nlm.nih.gov/geo/info/geo_agil.html)
Nimblegen: A Matrix worksheet containing the processed/normalized data used to draw conclusions from your study (e.g. RMA-normalized signals, scaled log2 ChIP/Input ratios, etc.). If the processed data row count exceeds Excel's limit, please supply your Matrix as a tab-delimited, plain-text file (.txt). Alternatively, if your data were processed with Nimblescan software, the processed data may be supplied as native .gff files. (Taken from https://www.ncbi.nlm.nih.gov/geo/info/geo_nimb.html)
Illumina: A Matrix worksheet containing the final processed/normalized data used to draw the conclusions from your study (e.g. cubic spline). If the processed data row count exceeds Excel's limit, please supply your Matrix as a tab-delimited, plain-text file (.txt). If submitting a new Illumina Platform, also include Platform annotation columns. (Taken from https://www.ncbi.nlm.nih.gov/geo/info/geo_illu.html)
Classify the processed data according to the analysis purpose into one of the following categories: Abundance matrix file, Epigenomic analysis file, or Variant analysis file
Abundance matrix fileProcessed tabular data representing normalized probe or gene expression intensities across samples. Rows represent probes/genes, and columns represent samples.
Epigenomic analysis fileFiles derived from microarray-based assays measuring DNA methylation, histone modifications, or chromatin states. Examples include Illumina 450K/EPIC methylation array output.
Variant analysis fileResults from microarray platforms detecting genomic variants such as SNPs or CNVs. Typically includes variant ID, genomic coordinates, allele calls, and quality metrics.
Last updated