Bigwig generation, Normalization by input leads to strange result

[Beatriz Cardoso de Toledo]

Good Afternoon,

    I recently started using the deeptools to analyze ChIP-seq data, and just generated bigwig files from it (I    downloaded SRA available data and processed it). My goal is to generate heatmaps and profile plots from it using deeptools, and compare different cell types. I always read it is important to normalize ChIP-seq data by the input. But the data I generated makes me wonder if indeed I should normalize my data by the input, or if I should just normalize by the depth. I already searched online for information but I could not get a clear answer.

I tested to generate the bigwig file using either bamCoverage tool or the bamCompare tool, in this case normalizing by the input. And I compared the data I generated to the bigwig file of the original group available in the GEO. The bigwig file generated from bamCoverage (line 3, not normalized by the input) is very similar to the one generated by the group (line 2, not normalized by the input). But I was surprised by the fact that the peak you can observe in this two cases "disapears" when I normalize by the input using bamcompare (line 1). Moreover, the data becomes much more dirty. Doesn't look at all like ChIP-seq data we generally observe in papers.

Therefore I am not sure if I should generate the profile plot and the heatmaps using the bigwig file from bamCoverage or bamCompare. Bellow are the codes I used to generate the data if the picture

bamCoverage --numberOfProcessors 12 --ignoreDuplicates --normalizeUsing RPKM --extendReads 200 --minMappingQuality 30 --binSize 10 --effectiveGenomeSize 2308125349 --blackListFileName mm10-blacklist.v2.bed -b ChIP_N_H3K4me3_merged_rmdup_sortposition.bam -o ChIP_N_H3K4me3_merged_rmdup_log2.bw

bamCompare --operation log2 --ignoreDuplicates --scaleFactorsMethod None --normalizeUsing RPKM --extendReads 200 --minMappingQuality 30 --binSize 10 --effectiveGenomeSize 2308125349 --blackListFileName mm10-blacklist.v2.bed -b1 ChIP_N_H3K36me3_merged_rmdup_sortposition.bam -b2 ChIP_N_Input_merged_rmdup_sortposition.bam -o ChIP_N_H3K36me3_merged_rmdup_log2ratio2.bw

[Devon Ryan]

Can you include the input track (just make a bigwig of it)? The reason for normalizing to input is that you get rid of random aberrant peaks due simply to accessibility changes or assembly issues. If the peaks go away when normalized you’re input then they’re likely not real. 

Devon

Sent from my iPhone

On 23. Oct 2019, at 16:43, Beatriz Cardoso de Toledo <beatriz.card...@tu-dresden.de> wrote:



--
You received this message because you are subscribed to the Google Groups "deepTools" group.
To unsubscribe from this group and stop receiving emails from it, send an email to deeptools+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/deeptools/1571841817848.24831%40tu-dresden.de.

<Screen Shot 2019-10-23 at 15.38.01.png>

[Beatriz Cardoso de Toledo]

Good evening,

I generated new images of other regions. One thing I noticed was that the files were not in the same scale. My impression is that the command is considering that the files have the same scale (but the input is less intense than the IP). I suspect that it is important for me to use the scalling factor command. But I am not managing to make the python code work (

https://github.com/deeptools/deepTools/blob/master/deeptools/SES_scaleFactor.py).

Do you think this is the reason why my "peak" decreasing? It is important to note that the normalized file is quite different from the image showed in the paper.

DTop: Figure of the paper

Line 1: Input I analyzed

Line 2: Chip-seq I analyzed

Line 3: log2fc I analyzed

Line 4: Chip-seq paper

Line 5: Chip-seq Paper

Thank you

Beatriz

---

From: Devon Ryan <dpry...@gmail.com>
Sent: Wednesday, October 23, 2019 19:07
To: Cardoso de Toledo, Beatriz
Cc: deep...@googlegroups.com
Subject: Re: Bigwig generation, Normalization by input leads to strange result