bamCoverage --normalizeUsing RPKM does the normalization using a constant bin size. Afaik, the standard normalization using RPKM uses the length of the specific gene (not constant).
So does --normalizeUsing RPKM really represent the standard RPKM normalization (done with the gene length)? What is it purpose, if not?
The problem is that "classic" RPKM starts from a count matrix so you have a single value per gene (or transcript, region, whatever you measure). Bigwigs are interval-based so you have many values for a gene, at most it is at base-pair resolution or you bin the signal. In any case, you cannot meaningfully (I guess) apply a single constant (e.g. a gene length denominator) to the signal.
Tbh I never really got what the binning is good for in bigwigs oper basepair or binther than saving disk space (and making the browser tracks clunky and ugly). Back in the day when I used deeptools I always used bin sizes of one, but since this (using RPKM) would divide the value by 0.001 (because binsize 1 is 0.001kb) it gives unintitively large values, therefore the CPM rather than RPKM is probably a more intuitive choice. In any case these per-million scalings are flawed by design as they do not correct for composition, see for example:
and a potential alternative to scale your tracks:
Use of this site constitutes acceptance of our User Agreement and Privacy Policy.
version 2.3.6
In "classic" RPKM the gene length varies from gene to gene, doesn't it? Whereas in Bigwig normalization the bin size is constant (and many short bins can be included with one gene).
So the bottom line is that the RPKM (and CPM) does not really represent the "classic" RPKM/CPM, right?
CPM does represent the standard approach I think, as it simply divides by total depth and multiplies by a million.