Due to some inconsistency between MCPcounter code and paper, I always thought MCPcounter requires raw TPM values and calculates the geometric mean internally. However, this is not the case. It relies on input data being log-transformed already, to calculate the log(geomean). See the discussion at ebecht/MCPcounter#37.
In the immundeconv docs, we write that the deconvolute function expects raw TPM and does all necessary transformations required for the respective methods internally. The consequences of untransformed data are that some signature genes may receive disproportionally high weights over others if they are more strongly expressed.
To fix this moving forward, we should log-transform the data before passing it to MCP-counter.
However, to avoid breaking changes for users who already passed log-transformed data to deconvolute to work around this issue, we should add some guardrails.
I suggest adding the following option to the deconvolute_mcp_counter function:
log_transform = c(NULL, TRUE, FALSE) which defaults to NULL.- in case of NULL it will guess if the data is log-transformed (if the max value does not exceed 50 seems a good convention. The log2(1e7) is ~25 so 50 is way more than the sum of TPM across all genes)
- in case of TRUE/FALSE assume that the data still needs or does not need to be log-transformed anymore, respectively.
- do the log transformation inside the
deconvolute_mcp_counter function. In the main deconvolute function this parameter can be accessed via ... but doesn't have to be documented there separately. The default value should be good enough for almost all use-cases.
- The function should emit a
message that the log-transformation has been inferred and point to the option of setting the value to TRUE/FALSE.
Due to some inconsistency between MCPcounter code and paper, I always thought MCPcounter requires raw TPM values and calculates the geometric mean internally. However, this is not the case. It relies on input data being log-transformed already, to calculate the log(geomean). See the discussion at ebecht/MCPcounter#37.
In the immundeconv docs, we write that the
deconvolutefunction expects raw TPM and does all necessary transformations required for the respective methods internally. The consequences of untransformed data are that some signature genes may receive disproportionally high weights over others if they are more strongly expressed.To fix this moving forward, we should log-transform the data before passing it to MCP-counter.
However, to avoid breaking changes for users who already passed log-transformed data to
deconvoluteto work around this issue, we should add some guardrails.I suggest adding the following option to the
deconvolute_mcp_counterfunction:log_transform = c(NULL, TRUE, FALSE)which defaults to NULL.deconvolute_mcp_counterfunction. In the maindeconvolutefunction this parameter can be accessed via...but doesn't have to be documented there separately. The default value should be good enough for almost all use-cases.messagethat the log-transformation has been inferred and point to the option of setting the value to TRUE/FALSE.