Normally, DiffBind is used for ChIP-seq data, but I've seen it used for ATAC-seq as well. I don't see any issues with that. MACS can be used for the initial peak calling. However, when performing peak calling for ATAC-seq data, it is advised to adjust the default parameters so peaks are centered on the cutting sites. A common suggestion is `--nomodel --shift -100 --extsize 200` or `--nomodel --shift 37 --extsize 73`.
If the reads are adjusted for peak calling, what happens when I then pass the peaks and the BAMs to DiffBind? Wouldn't DiffBind quantify the peaks incorrectly since the BAMs and peaks do not really represent the same data?
Centering the peak on the cuttting site is good. I haven't looked specifically at ATAC data, but for what it's worth...
You can use the fragmentSize parameter of dba.count to ensure (mostly) that the reads overlap the cutting site. If the actual fragment length is on average, say, 300bp, then setting fragmentSize=300 will cause DiffBind to extend the reads (strand-specifically) to that length, so that each read *should* cover the true site.
Also, don't make the specified peak too narrow. Center it by all means, but if the peak is too narrow, then in a strong site, say, many reads may be a bit too far up- or downstream of the peak to be counted.
I can't be too clear on this answer but as I understand it MACS2 was designed for chip-seq and as such will always "shift" the reads in the 5' prime direction due to some detail in the production of the chip-seq data . We use the option --shift 100 to move ATAC-seq reads in the opposite direction so that when MACS2 moves the reads.....they are returned to their original true position. So this should not be an issue for DiffBind. However, ATAC seq data is also adjusted for TN5 insertion of 9bp adapters....in this case the question posted is valid.... "If the reads are adjusted for peak calling, what happens when I then pass the peaks and the BAMs to DiffBind? Wouldn't DiffBind quantify the peaks incorrectly since the BAMs and peaks do not really represent the same data?"