Bio Hi C Analysis Hichip Plac Loops

Version Compatibility

Reference examples tested with: FitHiChIP 11.0+, MAPS 1.1+, hichipper 0.7+, CHiCAGO 1.20+ (Bioconductor 3.18+), HiC-Pro 3.1+, diffloop 1.18+ (Bioconductor 3.18+).

Before using code patterns, verify installed versions match. If versions differ:

• CLI: <tool> --version then <tool> --help to confirm flags
• FitHiChIP: read the shipped configfile comments; parameter names and defaults change between releases
• R: packageVersion('diffloop')/packageVersion('Chicago') then ?function to check signatures

FitHiChIP is driven entirely by a key=value config file passed with -C; the loop caller, background, and bias model are set there, not on the command line. MAPS, hichipper, and CHiCAGO each expect a specific upstream format (HiC-Pro valid pairs / .allValidPairs, or HiCUP+capture design files for CHiCAGO). If a tool errors, introspect the installed version's config/help and adapt the example rather than retrying.

Protein-Directed and Targeted 3C Loop Calling

"My HiChIP/PLAC-seq/Capture Hi-C has loops anchored at CTCF/H3K27ac/promoters - which contacts are real?" -> Call loops with a method whose null jointly models the per-anchor coverage bias AND the distance-decay, not the uniform/donut background that generic Hi-C callers assume.

• CLI: bash FitHiChIP_HiCPro.sh -C config_fithichip (HiChIP/PLAC-seq); edit and run run_pipeline.sh (MAPS; it invokes MAPS.py internally) for PLAC-seq/HiChIP
• R: runChicago(...) then PIRs at CHiCAGO score >= 5 (Capture Hi-C/PCHi-C); quickAssoc()/loopAssoc() (diffloop, differential)

The Single Most Important Modern Insight -- Generic Hi-C Loop Callers Use the Wrong Null on Peak-Anchored Data

Running cooltools dots or Juicer HiCCUPS on HiChIP, PLAC-seq, or Capture Hi-C is a documented error, not a shortcut. Those callers test each pixel against a local, roughly-uniform expected background (a donut/expected neighborhood) built for a genome-wide-uniform in-situ Hi-C map. Protein-directed and capture assays violate that assumption in the most consequential way possible: the antibody (or oligo capture) enriches contacts at the factor's binding sites, so 1D coverage is wildly non-uniform - an H3K27ac anchor can carry 100x the read depth of a flanking non-peak bin. A donut null reads that coverage spike as contact enrichment and calls a "loop" at every peak. The dedicated callers exist precisely to fix this, and they all share one move: regress out the per-anchor coverage bias before testing the distance-decayed contact frequency.

Three load-bearing consequences:

1. The hard part is 3C statistics, and it lives here; the peak-calling half lives in chip-seq. FitHiChIP/MAPS/CHiCAGO each fit a significance model (spline regression on coverage + genomic distance; positive Poisson regression on bias factors; a two-component Brownian+technical background). That model - not the antibody - is the deliverable. Anchor/peak calling (where the protein binds) is chip-seq's job (-> chip-seq/peak-calling); this skill consumes those peaks and produces FDR-controlled loops.

2. Protein-targeting buys depth efficiency, so loops are called at far lower total depth than Hi-C. HiChIP/PLAC-seq concentrate reads onto a small anchored sub-space, needing ~5-10 read pairs per interaction versus ~100-1000 for genome-wide Hi-C (Mumbach 2016: >10x more conformation-informative reads, >100x less input than ChIA-PET). A 100-200M-pair HiChIP library calls loops that would need billions of pairs in Hi-C - but only at the protein's anchors, and only with the right null.

3. "Peaks from the same data" is a circularity trap. When no separate ChIP-seq exists, HiChIP-derived peaks (hichipper, HiChIP-Peaks) are used as anchors - but calling peaks and loops from the same reads couples the two error structures. Prefer an independent ChIP-seq peak set as the anchor reference when one exists; if not, use a HiChIP-native peak caller and treat anchor confidence as part of the loop's uncertainty, not a given.

Method Taxonomy

Decision Tree by Scenario

FitHiChIP - Coverage + Distance Spline Regression (default)

Goal: Call FDR-controlled loops from a HiChIP/PLAC-seq library whose anchors are defined by an (ideally independent) ChIP-seq peak set.

Approach: FitHiChIP reads valid pairs (HiC-Pro format), bins them, fits a spline regression of contact count on BOTH the genomic-distance decay and the per-bin coverage bias, then assigns each candidate contact an FDR. Everything - resolution, foreground type, background, bias model, FDR - is set in a key=value config passed with -C; the command line itself takes no analysis parameters.

# config_fithichip (key=value; comments stripped). Run: bash FitHiChIP_HiCPro.sh -C config_fithichip
ValidPairs=sample.allValidPairs.gz   # HiC-Pro valid pairs (or set Matrix=/Interval= for matrix input)
PeakFile=chipseq_peaks.bed           # anchors; prefer an INDEPENDENT ChIP-seq peak set over HiChIP-derived
ChrSizeFile=hg38.chrom.sizes
OutDir=fithichip_out/
PREFIX=sample
BINSIZE=5000                          # 5kb: standard HiChIP anchor resolution (~2.5kb effective, hichipper)
LowDistThr=20000                      # 20kb floor: below this, contacts are dominated by self-ligation/diagonal
UppDistThr=2000000                    # 2Mb ceiling: loops beyond this are rare and noise-dominated
IntType=3                             # 3=peak-to-all (loose foreground); 1=peak-to-peak (stringent)
UseP2PBackgrnd=0                      # 0=loose (peak-to-all) background; 1=stringent (peak-to-peak) background
BiasType=1                            # 1=coverage-bias regression (default); 2=ICE-bias regression
MergeInt=1                            # merge adjacent significant contacts into one loop (recommended)
QVALUE=0.01                           # FDR cutoff for significant loops

IntType sets the foreground (which candidate contacts are tested); UseP2PBackgrnd sets the background the regression is fit against. The two together encode the loose-vs-stringent choice: peak-to-all foreground + loose background maximizes sensitivity for broad marks (H3K27ac); peak-to-peak foreground + stringent background maximizes specificity for sharp factors (CTCF/cohesin). Output significant loops land under a nested OutDir/FitHiChIP_Peak2ALL_b<bin>_L<low>_U<upp>/P2Pbckgr_<0|1>/.../ tree, in <PREFIX>.interactions_FitHiC_Q<QVALUE>.bed (and ..._MergeNearContacts.bed when MergeInt=1); locate it with find OutDir -name '*interactions_FitHiC_Q*.bed'.

MAPS - Positive Poisson Regression on Bias Factors

Goal: Call PLAC-seq/HiChIP loops with an explicit regression model that removes both the generic 3C biases and the ChIP-enrichment bias.

Approach: MAPS is a two-step pipeline: first fit a zero-truncated (positive) Poisson regression of observed contact counts on effective-fragment length, GC content, mappability, and ChIP-enrichment per bin; then test each anchored bin-pair's count against the model-normalized expectation, controlling FDR. It distinguishes AND anchors (both ends in a peak) from XOR anchors (one end), reflecting the peak-to-peak vs peak-to-all distinction.

# MAPS is driven by a COPIED run_pipeline.sh with key=value bash variables, not CLI flags.
# Edit run_pipeline_sample.sh, then run it: ./run_pipeline_sample.sh
bin_size=5000                              # 5kb anchor bin
binning_range=1000000                      # max interaction distance modeled
fdr=2                                       # -log10(FDR) cutoff; 2 means FDR <= 0.01
dataset_name='sample'
macs2_filepath='chipseq_peaks.narrowPeak'  # ChIP/HiChIP anchors
organism='hg38'                            # selects the bundled effective-length/GC/mappability bias track
# run_pipeline.sh runs feather (preprocessing) then MAPS.py (positive Poisson regression) internally

The model-based design is MAPS's signature: it does not subtract a local background; it predicts each bin-pair's expected count from the bias covariates and flags positive residuals. FitHiChIP and MAPS disagree substantially on the same data (the literature reports tens-of-thousands-loop differences at matched FDR) - the model assumptions differ, so report which caller and its settings.

CHiCAGO - Two-Component Background for Capture Hi-C

Goal: Call significant promoter-interacting regions (PIRs) from Capture Hi-C / PCHi-C, where oligo capture makes the map asymmetric (baited fragment x any other-end).

Approach: CHiCAGO fits a per-bait background with two components - a Brownian (distance-dependent, negative-binomial) term and a technical-noise (distance-independent, Poisson) term, convolved as a Delaporte distribution - then scores each bait-other-end pair as a weighted -log p-value; report other-ends above the conventional score threshold.

# Reference: Chicago 1.20+ (Bioconductor 3.18+) | Verify API if version differs
library(Chicago)

CHICAGO_SCORE <- 5   # conventional PIR threshold (Cairns 2016); soft 3-5 grey zone, >=5 = called
cd <- setExperiment(designDir = 'capture_design/')         # baitmap/rmap/NPB/NBaitsPB/proxOE from the capture design
cd <- readAndMerge(files = c('sample_rep1.chinput', 'sample_rep2.chinput'), cd = cd)
cd <- chicagoPipeline(cd)                                  # fits Brownian+technical background, scores all bait x other-end
exportResults(cd, file.path('chicago_out', 'sample'), format = 'washU_text')   # PIRs at score >= CHICAGO_SCORE

Neither cooltools dots nor FitHiChIP's symmetric model applies to Capture Hi-C: the bait-vs-other-end asymmetry and the per-bait normalization are the whole point. The capture design files (baitmap, rmap, and the precomputed NPB/NBaitsPB/proxOE from makeDesignFiles.py) encode which fragments were baited and the distance-binned background normalization.