Hi,
Thanks for developing such a useful tool!
After implementing fiberhmm-call and fiberhmm-extract, I nocticed that fiberhmm-extract reports grossly inflated BED blockSizes for TF whose query interval straddles a deletion in the read's alignment. The TF recaller itself is correct the bug is purely in how _annotation_to_ref_block projects a feature's molecular (query) interval into reference coordinates: it maps only the two endpoints and takes their reference span, so any intervening D/N CIGAR gap gets absorbed into the reported length. You can find some TF footprints with suspiciously long length (e.g > 1000bp) in tf_footprints.bed from fiberhmm-extract.
I think the expected behavior would be spliting the feature into multiple reference blocks at the deletion boundary. Thanks!
Hi,
Thanks for developing such a useful tool!
After implementing
fiberhmm-callandfiberhmm-extract, I nocticed that fiberhmm-extract reports grossly inflated BED blockSizes for TF whose query interval straddles a deletion in the read's alignment. The TF recaller itself is correct the bug is purely in how_annotation_to_ref_blockprojects a feature's molecular (query) interval into reference coordinates: it maps only the two endpoints and takes their reference span, so any intervening D/N CIGAR gap gets absorbed into the reported length. You can find some TF footprints with suspiciously long length (e.g > 1000bp) in tf_footprints.bed fromfiberhmm-extract.I think the expected behavior would be spliting the feature into multiple reference blocks at the deletion boundary. Thanks!