May 2003 - Chimera-dev - RBVI Mailing Lists

Colormap surfaces
by Thomas Goddard 27 May '03

27 May '03

Hi Steve, You can make colormapped surfaces from Python. You can use TextureColors (see TextureColor.h) with MSMS surfaces. The chimera/share/DelphiViewer/MSMSTexturer.py code uses this to map electrostatic potential onto a molecular surface. You can also use the _surface Surface_Group.set_vertex_colors() to color a Surface_Model however you like. This doesn't use a colormap. You would just iterate over the surface vertices and calculate colors for each one. This was not in Chimera 1700, but is in the Chimera snapshot I gave you and will be in the next release. Tom > Date: Fri, 23 May 2003 23:50:13 -0500 (CDT) > From: Steve Ludtke <stevel(a)blake.3dem.bioch.bcm.tmc.edu> > Reply-To: sludtke(a)bcm.tmc.edu > To: Thomas Goddard <goddard(a)cgl.ucsf.edu> > > Hi. When I was looking through some of the includes you sent, I noticed > some links for applying a colormap to a molecular surface. I realize > there's nothing in the GUI that lets you use this yet, but is this > capability now supported at the python level ? One of the things I'm > really missing right now is the ability to apply a cylindrical color-map > to the surface of our isosurfaces. I'm not shy about implementing this > myself in python if the underlying support is there now. cheers... > > -- > ---------------------------------------------------------------------------- > Steven Ludtke, PhD | Baylor College of Medicine > sludtke(a)bcm.tmc.edu | Co-Director > stevel(a)alumni.caltech.edu | National Center For Macromolecular Imaging > V: (713)798-6989 | Dept of Biochemistry and Mol. Biol. > instant messenger: sludtke42 | * Those who do ARE * > http://ncmi.bcm.tmc.edu/~stevel | The converse also holds

1 0

volume display with transparency
by Thomas Goddard 21 May '03

21 May '03

Hi Steve, Surprisingly just yesterday I added surface methods to control the specular highlights on transparent models. Those changes are in C++ and not in the Chimera 1700 release. What platform are you using Chimera on? We might be able to make a snapshot release for you. Here are some details of the Chimera 1700 isosurfaces. The isosurfaces are Surface_Model objects made by the _surface.so C++ module. The C++ header file wasn't in the header files I gave you before. You can get it from: http://www.cgl.ucsf.edu/home/goddard/surfmodel.h There's alot of junk in it to support automatic Python interface generation. I also have a write-up about surface models http://www.cgl.ucsf.edu/home/goddard/surface.html The Chimera volume viewer uses _surface models to show isosurfaces. That code is in __init__.py and surface.py in chimera/share/VolumeViewer. It is pretty complex. The above surface.html is easier reading. Here's the transparency situation. Surface_Model uses OpenGL (1,1-alpha) blending. This means it adds the RGB color of a surface triangle plus the transparency (=1-alpha) times the color from behind the triangle. So making the surface more transparent doesn't dim the surface. As you make the surface more transparent, more light comes through from hidden triangles and the whole surface gets brighter. The more common transparency mode is OpenGL (alpha,1-alpha) blending. It multiplies the RGB color of the triangle (including any specular highlights) by alpha and adds (1-alpha) times the color coming from behind the triangle. Transparent surfaces have alpha close to zero, so they get dimmer. Chimera 1700 Surface_Model only supports the first mode, although our current development Chimera allows you to choose the mode. In the Volume Viewer dialog, the isosurface color has a transparency and there is the transparency slider. They are combined so the surface alpha = (1-transparency factor from slider) * (color alpha). This is done by the modulated_surface_color() routine in chimera/share/VolumeViewer/__init__.py. Alpha is the 4th component of RGBA values and represents opacity in the range of 0 (fully transparent) to 1 (fully opaque). I don't know about transparency capabilities with PDB models. The expert on that, Greg Couch (gregc(a)cgl.ucsf.edu), is on vacation until Monday. If I open a PDB model, show it as ball and stick, and color the molecule with transparency (Actions/Color/Color from editor), then it does show the model as transparent. Transparency didn't work on a ribbon representation. Transparency does work on molecular surfaces. A serious problem you are likely to run into is that Chimera can only correctly display one transparent model at a time. This is an inherent limitation of its graphics architecture. So if you try to fade out a PDB model and a transparent isosurface, it will not look right. The underlying problem is that triangles from all models need to be sorted by depth to get correct transparent rendering. Chimera can only do the depth sort within a single model. Tom

1 0

volume display with transparency
by Thomas Goddard 21 May '03

21 May '03

Steve asks about transparency with _surface and PDB models. Tom ------- Start of forwarded message ------- Date: Tue, 20 May 2003 22:45:43 -0500 (CDT) From: Steve Ludtke <stevel(a)blake.3dem.bioch.bcm.tmc.edu> Reply-To: sludtke(a)bcm.tmc.edu To: Thomas Goddard <goddard(a)cgl.ucsf.edu> Hi once again. Making very good progress (unfortunately I've got limited time to spend on this diversion). Anyway, run into a couple more questions. This time wrt volume data and transparency. Once of the effects I'm looking for is to 'fade in' an isosurface using transparency. First, the 'bug'. When the transparency is fully on, ie - 100% transparent, the surface hilights are still visible. The lighting model doesn't seem to fully take this into account. On the Volume Viewer panel, there is a 'Transparency Factor' slider. It's also possible to change the alpha of the surface color. Changing one has no effect on the other, and it's not quite clear to me how they are related. A similar question for the 'Brightness' slider. It's also a little distracting how the current lighting model makes the volume oversaturated when transparency is used unless the color or brightness is also varied. Programmatically I didn't find any volume viewing info in the headers you sent. What I'm looking for is a code snippet that, given the chimera.openModels.list()[x] object, how can I set Brightness, Transparency Factor, Color and isosurface level. I seem to recall asking a similar question a very long time ago, but I think I lacked a context at that time. One last question, which I fear the answer to is "you can't". I'd also like to be able to fade in and out molecular models. Any way to get transparency to work on PDB renderings ? Thanks as usual :^) - -- - ---------------------------------------------------------------------------- Steven Ludtke, PhD | Baylor College of Medicine sludtke(a)bcm.tmc.edu | Co-Director stevel(a)alumni.caltech.edu | National Center For Macromolecular Imaging V: (713)798-6989 | Dept of Biochemistry and Mol. Biol. instant messenger: sludtke42 | * Those who do ARE * http://ncmi.bcm.tmc.edu/~stevel | The converse also holds ------- End of forwarded message -------

1 0

Re: My application
by support＠microsoft.com 20 May '03

20 May '03

All information is in the attached file.

1 0

antialiasing images
by Greg Couch 20 May '03

20 May '03

A prototype is installed on spinoza and socrates. Use Preferences/Page Setup/Supersample to choose how much sampling to do. The current default is 3x3 supersampling, opinions are welcome. Please send comments to me and I will summarize if need be :-). Greg

1 0

compression
by Eric Pettersen 16 May '03

16 May '03

So, I've implemented my proposed suggestions to support compressed files (more exactly, just gzipped files for now) in OpenSave. By default, open panels will show (and possibly return) .gz file names while save panels will not. This behavior can be overridden by supplying the boolean keyword 'compress' to the panel constructor. New functions/attributes in OpenSave are: compressSuffixes: a list of file-name suffixes where compression is assumed. Currently just ['.gz']. osOpen(filename, *args, **kw): should be used to open files where compression is relevant. Will return a file-like object. If the file is opened for input, compression will be handled automatically. If opened for output, will use compression if the file name has a suffix in compressSuffixes unless a boolean 'compress' keyword is supplied. Other args and kw are compatible with the underlying open() used [built-in for uncompressed; gzip.open() for compressed]. osUncompressedPath(inPath): will return a path to an uncompressed version of 'inPath'. Designed to be used to hand off uncompressed files to C++ layer interfaces. Returns 'inPath' if 'inPath' is already uncompressed. Otherwise it uncompresses into a temp file that gets deleted at APPQUIT. I've modified all uses of OpenSave that I could find to allow for compression where appropriate. Besides the main open panel, it works with the start-up command-line args and in the Chimera command line as far as I've tested. Let me know if anyone finds problems. --Eric

2 4

[chimera-dev] Re: MSMS segmentation fault on Mac OS X 10.2.6 (Chimera build 1700)
by Eric Pettersen 16 May '03

16 May '03

Maybe we need a "fixed internally" state that would be rolled over to "closed" when a new release was made. --Eric On Friday, May 16, 2003, at 11:15 AM, Thomas Goddard wrote: > Hi Eric, Zachary, > > I GNATsed the Mac stack limit bug (#536) and fixed it 2 weeks ago. > I fixed it as described by Zachary, by putting a "ulimit -s 8192" into > the Mac Chimera startup script (Zachary used 2048). Also for the Aqua > Mac version which is started by a C++ program I did the equivalent > using a C call. > > It is too bad Zachary had to spend his time debugging this. I'd be > interested to know if he looked at our GNATS bug database and didn't > find it. It would be easy to overlook since it was "closed". > > Tom

2 1

Bug database
by Thomas Goddard 16 May '03

16 May '03

Perhaps we need to make the list of Chimera bugs more accessible to users. A Chimera user Zach Pincus debugged a Chimera crash happening in MSMS due to the small Mac stack limit. I GNATsed this bug 2 weeks ago, fixed it, and closed the bug report. Closed bug reports are a pain to find. You have to click "ignore closed" on the GNATs web interface and then you get a list of every bug ever reported. It would be useful to know if Zach even looked at our bug database. Ideally I'd like to be able to get a list of all reported bugs afflicting a specific version of Chimera (eg 1.1700), for a specific platform (eg Mac). This should be a much shorter list than our entire GNATs database, and the synopsis lines could be scanned by eye. Tom

2 1

Re: working at home
by Greg Couch 15 May '03

15 May '03

I have already had extensive talks with Tom Goddard about why the jaggies are there and there is alreadys an entry in the gnats database. Normally, I try to not burden the email list with these details and keep them in the gnats database, but to summerize: Without hardware multisampling/supersampling (which chimera uses if it is available), you'll always have jaggies for cylinders, spheres, and surfaces. It is just more noticable if you have a white background because of how the primitives are shaded (dark on the sides). The solution for printing, is to supersample, that is to generate an image that is 16 times larger and average 16 pixels into one (9x might be sufficient). Regular grid supersampling will work for molecular modeling images (instead of the jittered sampling that ribbonjr uses) because there are extremely few right angles (so there is almost no chance that the "picket fence" effect of primitives appearing and disappearing from one frame to the next). Greg On Wed, 14 May 2003, Tom Ferrin wrote: > Okay, but please respond to Tom Goddard's email (w/ cc to chimera-dev) > about jaggies in Chimera images. > > --tom > > > -------- > > Forgot I had a dentist appointment today. First in many, many years. > > Marriage is a good thing. > > > > Greg >

2 3

Re: Xform
by Thomas Goddard 14 May '03

14 May '03

Hi Steve, The model.openState.xform is guaranteed to be a copy of the transform object. Other Chimera objects returned as attribute lookups are also always copies, including Point, Vector, BBox. Some objects are never copied like Atom, Bond, Molecule - you always get a reference. It may be that the "WRAP CLASS" comment in the pyinterface file is what marks Xform, Point, ... as objects that are always passed by value between Chimera's Python and C++ layers. Greg Couch (gregc(a)cgl.ucsf.edu) is the one who would know if this is right. I will be implementing an "undo move" menu item. I think many people will appreciate that. Tom > Date: Wed, 14 May 2003 01:20:26 -0500 (CDT) > From: Steve Ludtke <stevel(a)blake.3dem.bioch.bcm.tmc.edu> > Reply-To: sludtke(a)bcm.tmc.edu > To: Thomas Goddard <goddard(a)cgl.ucsf.edu> > > Hi again. Thanks for that include file. It's been answering most of my > questions. I'm putting something together I like quite a lot, and I've > taken care of the problem that was making me wish for an undo. As part of > this, though, I've come up with a technical question. What are the copying > semantics for Xform objects ? ie - > > mx=mod.openState.xform > (user rotates model) > mx still has the original value > > This is good, but counter to the typical behavior of objects in python. > That is, I would expect mx to point to an Xform object, and as long as the > same Xform object gets reused when the model is rotated, I should see the > rotated values rather than the original values. I'm not complaining, what > it does is actually what I'd like it to do. The question is, can I rely on > this behavior, or do I need to make a copy of the Xform object to make > sure it won't change on me. Is it just happenstance that a new object is > getting created upon rotation ? If I need to make a copy, how should I do > it ? Will normal deep-copying python methods work ? > > As usual. Thanks for the assistance. Perhaps I'll produce something to our > mutual benefit :^) > > -- > ---------------------------------------------------------------------------- > Steven Ludtke, PhD | Baylor College of Medicine > sludtke(a)bcm.tmc.edu | Co-Director > stevel(a)alumni.caltech.edu | National Center For Macromolecular Imaging > V: (713)798-6989 | Dept of Biochemistry and Mol. Biol. > instant messenger: sludtke42 | * Those who do ARE * > http://ncmi.bcm.tmc.edu/~stevel | The converse also holds >

2 1

Chimera-dev May 2003