Hi,
I have some mrc files on a 64 bit linux machine (linux version 2.6.9-42.0.8.ELsmp, x86_64) and the chimera on that machine displays the volume data fine with a range from 3 to 255 and a histogram centered around 120 and the 3D structure shows up very well with a threshold of 108. But after I transfer these data to a mac os x 10.4.10 and use the chimera on the mac, the data range becomes -128-127 with the histogram splitted into two halves close to each end of the data range. What's worse, I can not get a good threshold to show my 3D structure. Can you please tell me what is possibly wrong and how to fix this?
Thank you very much.
Zhiheng
Hi Zhiheng, The trouble with displaying your MRC files with Chimera is that the files contain unsigned 8-bit data values (0-255 range) and that format is not supported by the MRC standard. Only signed 8-bit data values (-128 to 127) is supported by MRC. So why does it work on your 64-bit linux Chimera and not the Mac Chimera? I believe that is because your Linux Chimera is an old version of Chimera. About one year ago (September 19, 2006, Chimera version 1.2290) I changed Chimera to follow the MRC standard and use signed 8-bit whereas earlier versions incorrectly assumed unsigned 8-bit values. Your Mac version of Chimera is probably newer and your Linux version older. The MRC file header gives no indication that the values should be unsigned 8-bit as that value type is not supported. But some software programs ignore that, use unsigned 8-bit values and set the MRC header field to indicate signed 8-bit. They rely on software to ignore the MRC standard. I added a way to work around this problem in newer versions of Chimera (Nov 29, 2006, version 1.2315). You open then MRC map then use the keyboard shortcut "u8" to reinterpret it as unsigned 8-bit. Then you will need to save the map with the volume dialog menu entry File / Save map as... if you want to avoid using u8 every time you open the map. Saving a map which is unsigned 8-bit will automatically use the signed 16-bit MRC mode. You probably should not overwrite your original file but instead make a new file. To use this u8 shortcut you first have to turn on shortcuts with Chimera menu entry Tools / General Controls / Accelerators On. Then you can type u8 in the main Chimera window. It operates on the map currently shown in the volume dialog so you can switch maps and apply it to other maps as well. You may also be interested in shortcut "Im" which inverts the map, mapping the range value v to (255-v). Tom
Hi Tom I believe the MRC specification was changed recently from unsigned 8bit to signed 8bit to make it more compatible with the CCP4 map format. However, this leaves a lot of programs out there that still follows the unsigned convention (including IMOD), as well as a lot of old image files with this convention. I would suggest having a more explicit handling of this issue in Chimera when reading an MRC file. On Sep 7, 2007, at 2:33 PM, Tom Goddard wrote:
Hi,
I have some mrc files on a 64 bit linux machine (linux version 2.6.9-42.0.8.ELsmp, x86_64) and the chimera on that machine displays the volume data fine with a range from 3 to 255 and a histogram centered around 120 and the 3D structure shows up very well with a threshold of 108. But after I transfer these data to a mac os x 10.4.10 and use the chimera on the mac, the data range becomes -128-127 with the histogram splitted into two halves close to each end of the data range. What's worse, I can not get a good threshold to show my 3D structure. Can you please tell me what is possibly wrong and how to fix this?
Thank you very much.
Zhiheng
Hi Zhiheng,
The trouble with displaying your MRC files with Chimera is that the files contain unsigned 8-bit data values (0-255 range) and that format is not supported by the MRC standard. Only signed 8-bit data values (-128 to 127) is supported by MRC. So why does it work on your 64-bit linux Chimera and not the Mac Chimera? I believe that is because your Linux Chimera is an old version of Chimera. About one year ago (September 19, 2006, Chimera version 1.2290) I changed Chimera to follow the MRC standard and use signed 8-bit whereas earlier versions incorrectly assumed unsigned 8-bit values. Your Mac version of Chimera is probably newer and your Linux version older.
The MRC file header gives no indication that the values should be unsigned 8-bit as that value type is not supported. But some software programs ignore that, use unsigned 8-bit values and set the MRC header field to indicate signed 8-bit. They rely on software to ignore the MRC standard.
I added a way to work around this problem in newer versions of Chimera (Nov 29, 2006, version 1.2315). You open then MRC map then use the keyboard shortcut "u8" to reinterpret it as unsigned 8-bit. Then you will need to save the map with the volume dialog menu entry File / Save map as... if you want to avoid using u8 every time you open the map. Saving a map which is unsigned 8-bit will automatically use the signed 16-bit MRC mode. You probably should not overwrite your original file but instead make a new file. To use this u8 shortcut you first have to turn on shortcuts with Chimera menu entry Tools / General Controls / Accelerators On. Then you can type u8 in the main Chimera window. It operates on the map currently shown in the volume dialog so you can switch maps and apply it to other maps as well. You may also be interested in shortcut "Im" which inverts the map, mapping the range value v to (255-v).
Tom
_______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users
Bernard Heymann, Research Fellow Rm 1515, 50 South Dr., MSC 8025, NIAMS, NIH Bethesda MD 20892-8025 Tel. 301-451-8241, Fax. 301-480-7629
Hi Bernard, Thanks for the info on the history of signed versus unsigned 8-bit MRC files. I see that CCP4 clearly uses signed 8-bit and most MRC used for EM data uses unsigned. Is there any definitive specification for MRC format? I just made up that bit about an "MRC standard". I'm not aware of anyone publishing a standard. The Chimera change was motivate by the EM Databank using CCP4 for their maps. A possible more explicit handling as you suggest is to assume signed 8-bit for file suffixes ".ccp4" and ".map" (used by EMDB) and unsigned 8-bit for the file suffix ".mrc" -- basically distinguish CCP4 from MRC format in Chimera. I'm not sure if the ".map" suffix used by EMDB to mean CCP4 is in use by other EM labs to mean MRC. Tom
Tom The key problem is that people keep changing the "standard" for the MRC format. Here is the current official version: http://www2.mrc-lmb.cam.ac.uk/image2000.html So it is not so simple any more, as the software from the MRC and associated packages now probably adhere to the new standard, while other packages and old MRC format files still use the unsigned 8bit form. The suffix ".mrc" is used for both, so that cannot be used as a distinguishing mechanism. Also, there are significant differences between the CCP4 (suffix ".map") and MRC formats, so you cannot substitute the one for the other. I'm still figuring out how to handle it in Bsoft. On Sep 7, 2007, at 4:11 PM, Tom Goddard wrote:
Hi Bernard,
Thanks for the info on the history of signed versus unsigned 8-bit MRC files. I see that CCP4 clearly uses signed 8-bit and most MRC used for EM data uses unsigned. Is there any definitive specification for MRC format? I just made up that bit about an "MRC standard". I'm not aware of anyone publishing a standard. The Chimera change was motivate by the EM Databank using CCP4 for their maps. A possible more explicit handling as you suggest is to assume signed 8-bit for file suffixes ".ccp4" and ".map" (used by EMDB) and unsigned 8-bit for the file suffix ".mrc" -- basically distinguish CCP4 from MRC format in Chimera. I'm not sure if the ".map" suffix used by EMDB to mean CCP4 is in use by other EM labs to mean MRC.
Tom
Bernard Heymann, Research Fellow Rm 1515, 50 South Dr., MSC 8025, NIAMS, NIH Bethesda MD 20892-8025 Tel. 301-451-8241, Fax. 301-480-7629
participants (2)
-
Bernard Heymann -
Tom Goddard