citeseq count is returning negative count values about cite-seq-count HOT 6 CLOSED

Hello, I think I found the cause of the negative numbers. Int overflow. I noticed that the maximum values of hashtags were suspiciously close to 32768, (as you can see on the table below) which is the maximum value supported by numpy int16: https://het.as.utexas.edu/HET/Software/Numpy/reference/generated/numpy.iinfo.html

I did a quick search on the repo scripts, and I think I found the offending lines, 250 and 251 on processing.py:

If you change them to use dtype=int32 that should fix the issue

from cite-seq-count.

Hello @Munfred and thanks for the catch!
I think this might also be linked to the other major issue that hangs the umi correction. I'm working on an update that should come out this week that will include the 16->32 fix and probably the umi correction issue fixed.

from cite-seq-count.

Hi, I just wanted to give you an update I forgot to do earlier

The reason why I was running CITE-seq-Count on the cell hashing dataset is because I wanted to compare it's results with a different demultiplexing approach that uses kallisto.

from cite-seq-count.

Hey @Munfred,
thanks for the heads up and the poster.
Happy to see that results are matching nicely :)

Is this the new "sircel" or is it totally different from this project?

from cite-seq-count.

Hi, sorry for the delay.

This is unrelated to sircel, was a result of the new kallisto bus feature that let's kallisto process single cell datasets from various technologies.

More info about the BUS format can be found here: https://bustools.github.io/

Some example workflows in python for processing single cell datasets are here: https://github.com/BUStools/BUS_notebooks_python

from cite-seq-count.

This is interesting. I might look into it and use it for dropSeqPipe!

Thanks for the heads up :)

Closing this as the bug was fixed

from cite-seq-count.