turonova
commented
2 months ago Hi,
em format cannot store information on pixel size - thus there is no bug in the code, it is simply not possible to store this information in the header.
As for GAPSTOP(TM) inputs - you can simply use directly mrc format for both templates and masks (see https://bturo.pages.mpcdf.de/gapstop_tm/user_manual/req_inputs.html for more information on inputs).
You can even output mrc format directly using vol_ext parameter as described here: https://bturo.pages.mpcdf.de/gapstop_tm/user_manual/tm_params.html.
Note, that resulting mrc files will most likely also have pixel size set to 1, regardless of the actual pixel size stated in the parameter file. This can be easily fixed in ChimeraX by setting the voxel size in volume coordinates tab and saving into new mrc map. Btw. this can be also done for the em files - you simply add the information on pixel size in volume coordinates tab and save as mrc format.
Taken together, there is no need to work with em format at all.
Last note on pixel size - in GAPSTOP it is used only to filter the template to the desired resolution, otherwise it is ignored and what matters are the actual dimensions of the volumes. This is similar to the most softwares, the pixel size is used for FSC computation or visualization (ChimeraX) but internally dimensions of voxels are used.
Hope that helps.
Hi,
The software is indeed attractive for particle picking. However, some "GAPS" are "STOPping" us. Specifically, the "em" format is difficult to handle since Chimerax and Relion cannot output it, making it challenging for us to create masks for template matching as "em" is required.
Furthermore, there is a logical bug when using Cryocat to convert "mrc" to "em": the resulting "em" file has an incorrect pixel size, which we are unable to correct, preventing us from outputting it in the "em" format.
Could you please address this "GAPs"? The ability to directly read MRC format would be very useful for users. We would greatly appreciate it! Thank you!