Numeric tags in BAM files interpreted incorrectly

[rsmeral]

I have a BAM file with a read with this tag (as shown by samtools view): AS:i:-8 (alignment score, 32-bit signed int, value = -8).

However, when I view the same read in IGV.js, it shows AS: 248.
I think the issue is in how IGV interprets data types of tags in BAM files.

In the BAM file, this number is represented as the c type (8-bit signed int), since "...while all single (i.e., non-array) integer types are stored in SAM as i, in BAM any of cCsSiI maybe used together with the correspondingly-sized binary integer value, chosen according to the field value’s magnitude." (as per 4.2.4. Auxiliary data encoding of the SAM Spec).

Samtools does the following:

• samtools view calls bam_aux2i – https://github.com/samtools/samtools/blob/5fcc7a4fa822bb216030b6d6803e846f99b7ad41/sam_view.c#L111
• bam_aux2i calls get_int_aux_val which then calls the appropriate conversion for each numeric data type: https://github.com/samtools/htslib/blob/22297149162411bc69215f2606152fdbb3165a0e/sam.c#L4700-L4721
• For example, le_to_i8: https://github.com/samtools/htslib/blob/9672589346459d675d62851d5b7b5f2e5c919076/htslib/hts_endian.h#L222-L224

Specifically, for conversion of a c type, it does (simplified):

le_to_i8 = (val) => 
  val < 0x80
    ? val
    : -(0xff - val) - 1

Which, when tried with 248 (0xf8), does return the proper -8, like samtools.

I see that IGV.js skips conversion for the c type, and interprets it as is, yielding the incorrect value of 248 (instead of expected -8):
https://github.com/igvteam/igv.js/blob/master/js/bam/bamAlignment.js#L149

[rsmeral]

Hi @jrobinso – is there any timeline for the 2.8.4 release?
Not trying to rush you – just curious, so that we can plan around it in my product.

Have you started work on this yet? I think I could make a PR if not.

[jrobinso]

@rsmeral Apologies, 2.8.4 was released but this is still open. If you can make a PR that would be helpful, otherwise I will get to it ASAP.

[rsmeral]

@jrobinso Thanks for the quick fix!

[jrobinso]

@rsmeral Have you tested it? I don't have any bams with "C" tags so I had to simulate it.

[rsmeral]

@jrobinso Yeah, just tested on a BAM file with a c (signed):

• in 2.7.3 – AS: 239
• in 2.8.6 – AS: -17

Thanks 👍

(Can't confirm for C (unsigned) though either).