Add option to Build Signal Track about chipseq

[drpatelh]

@tiagochst I am currently rewriting the chipseq pipeline and I have been thinking whether its worth implementing this feature. I am generally reluctant to generate "IP - Input" tracks because you lose all the information about local biases that are only apparent by visualising the IP and Input tracks simultaneously. An extreme example of this is below,

If you were to just visualise the "IP - Input" fold-enrichment tracks then this bias/library prep issue wouldnt be apparent. To me this screenshot suggests that there is something fundamentally wrong with the sample/library prep because the Input has peaks exactly where you would expect them for the IP!

At this point, the pipeline already generates read-depth normalised bigWig tracks for each sample, and I think these are sufficient. Although, I do think a crude read-depth normalisation has room for improvement in order to better capture the background signal that is more apparent for ChIP-seq datasets.

Be interested to know what you think :)

[tiagochst]

Hi @drpatelh I am not very expert on the ChIP-seq protocol, but I see your point. We normally use the tracks FE and the logLR for significance to visualize the data. As you pointed the FE would not point to the bias/library prep issue you highlighted, but I am not sure if logLR would be able to control this bias.

However, I believe it would be useful if the pipeline had the option to create the pileup.bdg files required to create these tracks, then users could create those signal tracks manually later if they want. But I don't believe creating those tracks would be required since you could visualize the data like you did. Do you think that would be feasible ? The last time I was doing it I manually changed the nextflow macs2 code to create the pileup.bdg files and then applied another Rscript calling macs2 inside the folder to create all tracks.

Out of curiosity, those samples with bias/library prep issue would pass QC ?

[drpatelh]

Thanks for the reply @tiagochst ! I believe the logLR tracks will also mask this effect because you would still be comparing the signal back to the input:
macs3-project/MACS#156 (comment)

Youre right, its a good idea to have it as an optional parameter, and then it can be used as required downstream. Ill add it in 👍

Yes, they did pass QC! Everything looked as it should. I even done motif analysis on the samples and the top hits were as expected. If I hadnt looked at the data in IGV I wouldnt have know any better!

[drpatelh]

Added in #76