- Chimera-users - RBVI Mailing Lists

colormap -and- opacity functions for voxels
by Andrew Jewett 01 Mar '05

01 Mar '05

Hi. I've asked a lot of questions, and I keep getting these long thoughtful and technical replies. Thanks. It's nice to get these replies However don't feel obligated to reply at all, at least when I post a question. The other features I mentioned are more important to me at least. I don't want you to be kept busy replying to emails. The question is: why not have a simultaneous independent opacity-map and color-maps for voxel-rendering? (...and I suppose, why do they have to be linear functions? Is piecewise linear hard to implement?) It seems unnecessary that the voxel values should only determine the opacity of the voxel. It seems reasonable to allow the color to be determined by the volxel value in addition to the opacity (for example, a cold-to-warm-to-hot color scheme). It looks like some kind of colormap user interface has been implemented in chimera. (Nice T4-phage slab image, by the way..) Would this be hard? This way, one could distinguish the DNA inside the T4 phage from the within capsid shell. Currently, 3-D volumetric rendering is cool, but it needs ...something. Since the demand for voxel rendering is probably low, I would understand if you choose to delay to ignore these issues. Andrew ------- That's the end of my question, but I included ------- some pictures at the end, for comparison. ------- You can skip this part. ------- They are not in color, but they do look ...pretty. ------- I wonder what they are doing? http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F5 http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F19 http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F13A http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F13B http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F8B http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F16A http://radiographics.rsnajnls.org/cgi/content/full/19/3/745/F17 Probably the main reason it looks so nice I think is because their data is manifestly much less bumpy than electron microscopy data. Also I'm suspect that increadibly expensive 3-D hardware doesn't hurt either. However there is something else interesting going on in these pictures. It seems that what appear to be fully opaque objects have a range of brightnesses/colors. In chimera, fully opaque objects are solid white (or blue or whatever color is set by the user) and they have no features except their somewhat fuzzy silhouette. The source of these pictures is a paper published at: http://radiographics.rsnajnls.org/cgi/content/full/19/3/745 One thing they talked about in the article was that they use separate brightness and opacity functions as a function of voxel value. They also use more general piecewise-linear functions instead of linear ones ("percentage classification"). The combination of those two features might explain something. Anyway, I wonder what they are doing. No need to reply. I'd rather you work on other stuff right now. Cheers! Andrew

1 0

per-model-clipping needs "all models" option
by Andrew Jewett 01 Mar '05

01 Mar '05

Hi. Please forgive me for sending this message twice. In the first version, I forgot to include a subject line, so I'm sending it again. --------------- On Fri, 25 Feb 2005, Thomas Goddard wrote: > chimera-users(a)cgl.ucsf.edu When using the Per-Model-Clipping tool and selecting which model to apply the clipping to, there should be an option "All Models", and it should be the default option. Without this feature, some unintended results can happen. Suppose the user generates a surface either with MSMS or multiscale. If the user then uses the menu to select Tools->Graphics->Per-Model-Clipping The default model is the one with the atoms and bonds, not the surface model. When the user moves the clipping plane it will seem like nothing is hapenning. The user has to be quite attentive to realize that they have to select the surface model from the list. It would be better to have an "all models" option that is the default. Thanks Cheers! Andrew

3 4

by Andrew Jewett 25 Feb '05

25 Feb '05

On Fri, 25 Feb 2005, Thomas Goddard wrote: > chimera-users(a)cgl.ucsf.edu When using the Per-Model-Clipping tool and selecting which model to apply the clipping to, there should be an option "All Models", and it should be the default option. Without this feature, some unintended results can happen. Suppose the user generates a surface either with MSMS or multiscale. If the user then uses the menu to select Tools->Graphics->Per-Model-Clipping The default model is the one with the atoms and bonds, not the surface model. When the user moves the clipping plane it will seem like nothing is hapenning. The user has to be quite attentive to realize that they have to select the surface model from the list. It would be better to have an "all models" option that is the default. Thanks Cheers! Andrew

1 0

Re: pdb parsing problem-- hydrogen as mercury
by Josh Tasman 18 Feb '05

18 Feb '05

Eric and Greg, Thanks for your comments and help. Eric, thanks especially for the concise script. Dealing with the variety of non-standard-format PDB files is truly maddening, and I appreciate the help. Josh

1 0

pdb parsing problem-- hydrogen as mercury
by Josh Tasman 18 Feb '05

18 Feb '05

I'm getting errors on reading PDB files containin hydrogens added by TRIPOS SYBYL. For example, the atoms 1677-1679 are parsed as Mercury (HG): ATOM 1674 HD11 ILE A 107 4.939 -2.338 17.094 1.00 0.00 ATOM 1675 HD12 ILE A 107 6.613 -2.979 16.971 1.00 0.00 ATOM 1676 HD13 ILE A 107 5.703 -3.133 18.512 1.00 0.00 ATOM 1677 HG21 ILE A 107 4.770 -2.095 20.141 1.00 0.00 ATOM 1678 HG22 ILE A 107 6.235 -1.314 20.827 1.00 0.00 ATOM 1679 HG23 ILE A 107 4.630 -0.527 21.006 1.00 0.00 ATOM 1680 H ILE A 107 5.291 0.799 16.773 1.00 0.00 ATOM 1681 N TYR A 108 3.267 1.810 19.498 1.00 21.63 Accoring to the table at http://www.bmrb.wisc.edu/ref_info/atom_nom.tbl There are descrepencies between PDB-like file formats, and we see that the official PDB format would specify "1HG2" instead of "HG21". Does anyone know of a quick way to deal with this? I can write a perl search/replace script if need be. Thanks, Josh

3 2

Re: [Chimera-users] Percent done
by Greg Couch 09 Feb '05

09 Feb '05

On February 7, 2005, David Belnap wrote: > It would be useful to have a percent done displayed when the image is being > rendered. I have a very large job that has been running for two days. I > think it is still progressing so I have not stopped it. For slower > machines or large jobs, it would be nice to know how far along jobs are. > > Thanks. I'm enjoying Chimera. I'm going to assume that you're having problems when you save images and you'd like an indication of how far along it is. That will slow down the image saving, but probably not very much. I'll look into it. I am really curious about how large a job you're running. The only way it could take two days is if you don't have enough physical memory and the system is paging memory to and from the disk. Some operating systems are better at handling programs that need more memory than is physically available than others (ie., BSD Unix and Linux), but all do poorly. Any system that doesn't exhaust memory, should be saveable in minutes. So, you should get some more physical memory for your computer if at all possible. We are working on making chimera more memory efficient, but that work won't be done until May or so. Thank you for using chimera, Greg Couch UCSF Computer Graphics Lab gregc(a)cgl.ucsf.edu

1 0

Percent done
by David Belnap 07 Feb '05

07 Feb '05

It would be useful to have a percent done displayed when the image is being rendered. I have a very large job that has been running for two days. I think it is still progressing so I have not stopped it. For slower machines or large jobs, it would be nice to know how far along jobs are. Thanks. I'm enjoying Chimera. David ============================================ David M. Belnap Department of Chemistry and Biochemistry Brigham Young University Provo, Utah 84602 USA Phone: 801-422-9163 FAX: 801-422-0153 David_Belnap(a)byu.edu ============================================

1 0

Re: [Chimera-users] Getting an extension handle
by Elaine Meng 07 Feb '05

07 Feb '05

> How would I get get a handle on a running instance of an extension? > Specifically, I want to be able to associate my own structures to > sequences in the MultAlignViewer. Hi Charlie, If I understand you correctly, this is something you can do this in the user interface (without dealing with code). Your structures should automatically associate with the sequences when opened in Chimera, if the structure's sequence and the sequence in the alignment match well enough. Even if they don't, you can "force" the structure to associate using Multalign Viewer's menu option Structure... Associations This option brings up a dialog in which you can specify which of the structures open in Chimera should be associated with a sequence in the alignment. I hope this helps, Elaine --- Elaine C. Meng, Ph.D. meng(a)cgl.ucsf.edu Computer Graphics Lab and Babbitt Lab Department of Pharmaceutical Chemistry University of California, San Francisco http://www.cgl.ucsf.edu/home/meng/index.html

3 3

Getting an extension handle
by Charles Moad 07 Feb '05

07 Feb '05

How would I get get a handle on a running instance of an extension? Specifically, I want to be able to associate my own structures to sequences in the MultAlignViewer. Thanks, Charlie

1 0

re H-Bonds in ViewDock
by Vidana.Epa＠csiro.au 02 Feb '05

02 Feb '05

Hi Chimera users, I've started to use Chimera recently. When using ViewDock it struck me that it would be very useful, after loading a .mol2 file of ligands and computing H-bonds between them and the receptor, to be able to list the number of H-bonds as a column in the ViewDock ListBox. Or, is it somehow possible to do this already? (One way to fix this might be to have a script that will write the number of H-bonds computed for each molecule in a new .mol2 file, and then read in this modified .mol2 file .... Has anybody done something in this fashion?) Thanks very much. Cheers, Vidana. Vidana C. Epa CSIRO, Division of Health Sciences & Nutrition, 343 Royal Parade, Parkville, Victoria 3052, AUSTRALIA. tel.: (61) - 3 - 9662 - 7345 fax.: (61) - 3 - 9662 - 7347 email: Vidana.Epa(a)csiro.au

2 1