bigomics / omicsplayground

Visual self-service analytics platform for big omics data.
http://www.bigomics.ch
Other
118 stars 35 forks source link

isobaric labeling support #31

Closed prvst closed 1 year ago

prvst commented 2 years ago

Hi, any plans to add support for isobaric labeling analyses?

ivokwee commented 2 years ago

Hi can you explain a bit more? As long as the signals can be summarized to gene-based intensities, OP can handle that. You need to be a bit careful on the normalization/scale. Or do you mean SILAC with heavy/light labeling? For this we have some experience but it is not available in OP as the primary parameter is the H/L ratio.

prvst commented 2 years ago

SILAC, and isobaric labeling are different techniques, this approach is analogous to RNA barcoding, and the kits usually provide chemical labels for up to 18 samples that are processed simultaneously. A common method for normalizing the samples is to use a pool of samples, labeled with one of the reagents (or channel).

ivokwee commented 2 years ago

OK. So it is a method to multiplex multiple samples? Sounds "similar" as barcoding in single cell RNAseq. In scRNAseq we typically multiplex with thousands of samples. If this is the case, you need to demultiplex the samples before reading the data in OP with third party or manufacturers tools. After that you should have a matrix with genes vs samples, which OP can handle. Probe normalization is only important if you care about the absolute intensity values for downstream analysis.

On Mon, 10 Jan 2022 at 14:55, Felipe da Veiga Leprevost < @.***> wrote:

SILAC, and isobaric labeling are different techniques, this approach https://en.wikipedia.org/wiki/Isobaric_labeling is analogous to RNA barcoding, and the kits usually provide chemical labels for up to 18 samples that are processed simultaneously. A common method for normalizing the samples is to use a pool of samples, labeled with one of the reagents (or channel).

— Reply to this email directly, view it on GitHub https://github.com/bigomics/omicsplayground/issues/31#issuecomment-1008895697, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEVULWW2ZGG3MHVUQUNHKKTUVLQONANCNFSM5HMCMTJA . You are receiving this because you commented.Message ID: @.***>

prvst commented 2 years ago

Yes, that is correct, it's a method for multiplexing. Is it possible for loading an expression matrix that is already normalized, and skip the normalization step?

prvst commented 2 years ago

Also, I noticed that inside the data view panel, the only two options of data types are counts and logCPM, none of which represents the Intensities from modern mass spectrometry data. It appears that OP only supports spectral counts, which is not the best approach for large-scale or high-throughput data analysis performed nowadays.

ivokwee commented 2 years ago

Could you refer to some articles or R packages? At the moment we use the mass-spec intensities or LFQ values as input and treat them as "counts" as in RNAseq. We did need to scale the intensities down to about 10M total counts because the dynamic range of the intensities were very high in the raw MS intensities (I believe from MaxQuant). Scaling down the intensities also alleviates the "zero gap" problem in that the minimum detection value was at 20-24 (log value). On the other hand, we also get many times already log transformed proteomics values. At the moment internally we use CPM normalization, followed by quantile normalization. For the DEseq and EdgeR algorithms we use unnormalized counts (but in case of proteomics we downscale the intensities to the million counts region).

prvst commented 2 years ago

Hm, that's probably the reason I can't reproduce any of our proteomics analyzes using OP, that's not the best approach. I suggest you take a look at Olga Vitek's work, see for example the MSstatsTMT paper where they show a comparison between different normalization methods.

github-actions[bot] commented 1 year ago

This issue is stale because it has been open for 60 days with no activity. It will close in 14 days.

github-actions[bot] commented 1 year ago

This issue was closed because it has been inactive for 14 days since being marked as stale.