Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compression efficiency: some mmCIF files are smaller than their BinaryCIF counterparts when not gzipped #9

Open
papillot opened this issue Apr 29, 2024 · 1 comment

Comments

@papillot
Copy link

This is a question rather than an issue report.
I have downloaded the BinaryCIF file for structure 5z6y from RCSB and the corresponding mmCIF file.

format size gzipped
mmCIF 227kB 58kB
BinaryCIF 269kB 32 kB
mmtf 24kB 17kB

What surprises me is that the BinaryCIF file takes more space than the mmCIF file, even if most of the information is contained in the atom_site table which should be amenable to efficient compression.
This seems to contradict the claims of the original BinaryCIF publication.

I am wondering if there is an issue with the current implementation of the format which would use less efficient compression techniques?

@dsehnal
Copy link
Member

dsehnal commented Oct 14, 2024

Hi, sorry for the late reply, I've only noticed it now.

  • It is indeed the case that for uncompressed files the bcif size can be larger due to extra metatada present for each category (archive CIFs have a lot of categories). The benefit is that the files are more amenable for compression due to the format being column instead of row based.
  • The difference becomes much more noticeable for large structures, for examples 3j3q ~230MB vs 30MB uncompressed and ~40 vs 12MB compressed.
  • MMTF stores much smaller subset of the data than mmCIF and also has lower coordinate precision by default. It is possible to configure the BinaryCIF encoder to use reduced precision for coordinates as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants