hi, ChIPQC uses countOverlaps with all reads and the entire length of these read. I have doubled checked a few just now and they match with what we would see in IGV (when dupliciate filtering is off in settings) and samtools view. I guess MACs is performing a shift, centering to one base pair and removing duplicates before counting. Perhaps that is the difference. We , and some of the MACS authors now, dont believe all duplicates can be artefacts so we include them in counting. I don't recentre since sometimes fragment length estimation fails to give a sensible answer (in MACS2 and unfortunately chipqc ) and the predicted centred point is very different from a sensible centred point. I count in a way which i hope is easiest to marry to what is seen in browser. Could explain the difference you see? thank you for the question. tom On Tue, Sep 6, 2016 at 5:09 PM, cattapre [bioc] <noreply@bioconductor.org> wrote: > Activity on a post you are following on support.bioconductor.org > > User cattapre <https: support.bioconductor.org="" u="" 11119=""/> wrote Question: > Problems with double read counts on ChIPQC > <https: support.bioconductor.org="" p="" 86819=""/>: > > I have started using ChIPQC, and noticed that the read counts reported by > the ChIPQC report are consistently twice as large as counts reported by > MACS2. I looked in the ChIPQC documentation and could not find a reason > why. Likewise, I googled the issue and could not find a plausible > explanation. > > I am using the latest R and ChIPQC version (checked last Friday). My > ChIP-seq files contain single-ended reads. > > Thanks for your help. > > ------------------------------ > > Post tags: chipqc > > You may reply via email or visit Problems with double read counts on ChIPQC >