You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
htsjdk produces CRAM files with zero length blocks that have a compression codec listed. An empty block post-compression is valid. An empty-block in RAW (uncompressed) is also valid, but if it states it is compressed by a specific codec then the contents of the block should be a valid byte stream for that codec (even if it decodes to zero bytes).
This was tested using htsjdk 2.26.11 with build 11.0.16+8-post-Ubuntu-0ubuntu118.04.
Steps to reproduce
The easiest way to reproduce this to convert the above file back to CRAM again using SamFormatConverter. I did this to validate it still happens and it isn't just a historic problem.
Expected behaviour
Zero length blocks should ideally just not be stored, as they're not required, but if it's easier code-wise to keep them there then the method field should be RAW, so no attempt is made to uncompress them.
See zaeleus/noodles#131 for a case where this triggered an error in a spec-compliant decoder.
The text was updated successfully, but these errors were encountered:
Description of the issue:
htsjdk produces CRAM files with zero length blocks that have a compression codec listed. An empty block post-compression is valid. An empty-block in RAW (uncompressed) is also valid, but if it states it is compressed by a specific codec then the contents of the block should be a valid byte stream for that codec (even if it decodes to zero bytes).
An example from SAMEA3302751.alt_bwamem_GRCh38DH.20200922.Finnish.simons.cram view using
cram_dump
:Your environment:
This was tested using htsjdk 2.26.11 with build 11.0.16+8-post-Ubuntu-0ubuntu118.04.
Steps to reproduce
The easiest way to reproduce this to convert the above file back to CRAM again using SamFormatConverter. I did this to validate it still happens and it isn't just a historic problem.
Expected behaviour
Zero length blocks should ideally just not be stored, as they're not required, but if it's easier code-wise to keep them there then the method field should be RAW, so no attempt is made to uncompress them.
See zaeleus/noodles#131 for a case where this triggered an error in a spec-compliant decoder.
The text was updated successfully, but these errors were encountered: