- Chimera-users - RBVI Mailing Lists

Re: [Chimera-users] Red-cyan stereo
by Greg Couch 08 Mar '07

08 Mar '07

On March 7, Tom Goddard wrote: > I do not think Chimera produces red-green stereo, only red-cyan. Greg > Couch in our lab would know. I've sent your question to the Chimera > users groups so he can give a more definitive answer. Yes, for red-cyan stereo, chimera puts the left eye in the red channel and the right eye in the blue and green channels. This allows for stereo viewing of color images with red-cyan glasses, but there are many problems, such as red objects not having any stereo cues because they are in only one eye. You will get the best stereo effect with gray-scale images (shades of gray) and if you do use color, avoid saturated colors. You can see the red, green, and blue components of a color with chimera's Color Editor tool. The color name field can be set to any of the color names in the Actions Color menu. Other glasses, red-blue and red-green, will work well with gray-scale images, but will have greater problems with ghosting (ie., part of one eye's image appearing in the other's) in color images. Ghosting will always be present to some degree unless the glasses are perfectly matched to the frequencies of light emitted by the display. So the best advice is to color your data various shades of gray. Hope this helps, Greg Couch UCSF Computer Graphics Lab

1 0

Re: [Chimera-users] copy cmd in nogui script
by Eric Pettersen 08 Mar '07

08 Mar '07

On Mar 8, 2007, at 8:21 AM, Randy Heiland wrote: > Eric, > I just got around to trying this and am told: > “You need to accept the POV-Ray end-user license in GUI mode first” > > (using the 1.2352 snapshot). > Suggestions? > -Randy Hi Randy, You are required to accept the POV-Ray license. However, once you have accepted it, Chimera will remember that and won't keep asking you. So if you start up Chimera normally and save any kind of POV-Ray image and accept the license, you will then be able to run your script in nogui mode on the same machine without the licensing request halting the script. If this is still a problem for the way you want to use the script, let me know. We still intend to make it possible to save non-ray traced images in nogui mode, but prioritizing that would depend on whether POV-Ray images are going to work as a stopgap measure or not. --Eric > From: Eric Pettersen [mailto:pett@cgl.ucsf.edu] > Sent: Friday, March 02, 2007 8:35 PM > To: Chimera BB > Cc: Randy Heiland > Subject: Re: [Chimera-users] copy cmd in nogui script > > With POVray in the latest snapshot, you can now use the "raytrace" > keyword of the copy command to get a ray-traced image in nogui mode. > > --Eric > > > On Feb 9, 2007, at 8:03 AM, Elaine Meng wrote: > > > Hi Randy, > It is my understanding that the GUI is used to render the image, thus > it is not possible to save images when in nogui mode. (Others, please > correct me if I've gotten this wrong!) > Best, > Elaine > > On Feb 9, 2007, at 7:46 AM, Randy Heiland wrote: > >> What cmd should I invoke in a --nogui script to copy the rendered >> image >> to a file? >> >>> From the interactive viewer cmd line, I can successfully execute >>> 'copy >> file foo.png png'; however, when trying to execute the following: >> >> % chimera --nogui cmd:dostuff >> where 'dostuff' is: >> open 1yc4 >> color byelement #0 >> copy file foo.png png >> >> I get: >> Fetching 1yc4 from web site www.rcsb.org >> Done fetching 1yc4; verifying... >> Opening 1yc4... >> 1 model opened >> Opened 1yc4 containing 1 model, 1890 atoms, and 427 residues >> Rendering high resolution image...Error while processing cmd:dostuff: >> AttributeError: '_chimera.NoGuiViewer' object has no attribute >> 'pilImages' >> (see reply log for Python traceback info) >> Traceback (most recent call last): >> File "/home/heiland/chimera/build/share/__main__.py", line 59, in ? >> value = chimeraInit.init(sys.argv) >> File "CHIMERA/share/chimeraInit.py", line 298, in init >> prefixableType=1) >> File "CHIMERA/share/chimera/__init__.py", line 1217, in open >> File "CHIMERA/share/Midas/ChimeraExtension.py", line 28, in func >> # lswdir = os.path.split(thisdir)[0] >> File "CHIMERA/share/Midas/midas_text.py", line 91, in >> processCommandFile >> File "CHIMERA/share/Midas/midas_text.py", line 60, in makeCommand >> File "CHIMERA/share/Midas/midas_text.py", line 542, in doCopy >> File "<string>", line 1, in ? >> File "CHIMERA/share/Midas/__init__.py", line 795, in copy >> File "CHIMERA/share/chimera/printer.py", line 705, in saveImage >> AttributeError: '_chimera.NoGuiViewer' object has no attribute >> 'pilImages' >> >> >> thanks, Randy >> >> _______________________________________________ >> Chimera-users mailing list >> Chimera-users(a)cgl.ucsf.edu >> http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users > > _______________________________________________ > Chimera-users mailing list > Chimera-users(a)cgl.ucsf.edu > http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users >

1 0

View scale and brix output
by Tom Goddard 08 Mar '07

08 Mar '07

Hi Christopher, If I understand your request you want to be able to easily return to a standard view magnification for making figures. There are 3 parameters that determine the apparent size of models seen in the Chimera window: the distance of the models from the eye position, the angular field of view, and the scale parameter which relates the screen pixels to physical units (Angstroms). With orthographic projection only the scale parameter matters. Chimera can use orthographic projection (activated in Camera tab of Side View dialog) but the default is perspective projection where all 3 parameters matter. Assuming you don't change the distance between the eye (i.e. camera) and the models, and you don't change the field of view then setting the scale alone would be sufficient to return to standard magnification settings. In the Side View dialog (menu entry Favorites / Side View) under the Camera tab there is an entry field for the scale factor. It gives the current absolute scale factor and can be changed to whatever value you like. It starts out as 1.0 in a new Chimera session. But if you open a session file it is set to whatever it was in the original session. If you open a session for a figure, then modify it, changing the scale as you go, then want to return to the original session scale factor you could use the command "reset session-start". This not only resets the scale but also the positions and orientations of all the models. Maybe that is not what you want because the new figure is perhaps showing the models from a different direction (e.g. rotated by 90 degrees). So perhaps you need a command like "resetscale session-start". That resetscale command does not exist but I could probably add it if you think it is what you need. Regarding writing BRIX map files, I agree it would be handy if Chimera could output more map formats. I think BRIX format is well enough documented that it could be done (writing files requires better understanding of the format than reading them). That format only saves unsigned 8-bit data values though. So going from float values in MRC to BRIX will lose information. Maybe Chimera would issue a warning about that. Tom Christopher Akey wrote: > Tom- > > A few more issues that have come up for user friendliness. > > 1. It would be useful to have a box where the user can specify the > absolute scale for the session, the first time it is opened, this > could be set at 1.0 for example after loading a ribosome map and the > atomics and putting them to a good size. > > Then the program should keep track of the changes made during the > session using the scale command (I guess you can't track changes made > with the mouse so one generally would avoid this, or even better one > should be able to turn off the mouse scale feature!). > > This way one could always look at the pull down for the current scale > value when you capture a particular view for a figure. > > One could then return to the original scale of 1.0 at the end of > session or write down the current scale value, which could be kept in > the ssesion. So upon reopening the session at a later date, one can > always get back to the correct scale to recapture a panel for a > figure. This is currently a real problem, as far as I can tell. > > 2. We often want to import a brix file with aligned pdbs, since we > dock and look at them in 'O', which is better in some ways for looking > at these maps, but not so good as Chimera for figure making > obviously....then in Chimera we may continue to trim or segment a map, > and then we want to take it back out, presumably as an MRC file, to be > converted into a brix by a conversion program (for us its SPIDER). > Then one can do another cycle of docking in 'O' using the > refined/cleaned up sub map from Chimera. > > While I can think of one way to do this without losing the relative > origins and thus, the map alignments, it is pretty tedious. If one > could write the zoned or volume erased brix volume back out as a new > brix file, with the correct dimensions and origin, relative to the > brix file brought into Chimera, this would allow you to cycle back and > forth using the best of both programs. > > > cheers C Akey >

3 2

RMSD fit of an object to atom
by Navnit Kumar Mishra 08 Mar '07

08 Mar '07

Dear folks; Is there any simple way in chimera to do rmsd fitting of the object to the atom. I would like to measure the rmsd of an density peak with the atom. Could someone give the detail, how can I do it. And one another thing, how can I get rid of the problem with " At least four atoms should be selected", I am interested to do 'match' for two atoms. Thanks a lot, Navnit

4 5

another snapshot
by Eric Pettersen 07 Mar '07

07 Mar '07

We just put out another snapshot (1.2352). It fixes some problems in the previous snapshot, including the scaling in the side-view window not matching the scaling in the main graphics window, and phylogeny support in Multalign Viewer not working. --Eric Eric Pettersen UCSF Computer Graphics Lab pett(a)cgl.ucsf.edu http://www.cgl.ucsf.edu

1 0

Chimera to O and back again
by Tom Goddard 07 Mar '07

07 Mar '07

Hi Christopher, Ok, I see, you convert your MRC map to BRIX for working in O but then bring the PDB model that was adjusted in O back into Chimera and realign it with the original MRC. It sounds like the painful part of this process is that the BRIX map does not align with the original MRC map when viewed in Chimera. That is a problem with the SPIDER conversion from MRC to BRIX losing or interpreting differently the origin information. If the BRIX map actually had the correct origin so it aligned perfectly with the MRC map in Chimera then it would save you a bit of trouble. One solution is of course to have Chimera write out the BRIX file so it gets the positioning correct. I'm not sure when I would find time to write that code. Perhaps another solution is to figure out how the SPIDER conversion messes up the origin. That might allow choosing an MRC origin in Chimera such that the SPIDER BRIX map will align with the MRC map. My guess is that Chimera is using the MRC 2000 xorigin, yorigin, zorigin header fields while SPIDER is using the ncstart, nrstart, nsstart header values which Chimera sets to zero when it writes an MRC 2000 format file. If this theory is correct, the BRIX map might align with the MRC map if you change the MRC origin to (0,0,0) using the Chimera volume dialog Features / Origin and Scale panel. You could save this MRC map and work with it to avoid the BRIX/MRC misalignment problem. Tom Christopher Akey wrote: > Tom- > > As to our problem with getting files back into O without degradation of > information. Here is what we found that works. > > You have an original image in mrc format(1.mrc)=> convert to brix (we > use SPIDER) > > Then in O one can dock pdbs & do modeling etc. So now one has a brix > file and pdb modeled in approximately the right area. However, you want > to see if you can improve this difficult modeling. > > So you take the brix file and the pdb into Chimera. > > You write out the brix file as a new mrc file, ie 2.mrc, without any > transformations. > > You then read in the original (1.mrc) and move 2.mrc relative to 1.mrc > using local movements with mouse and then the the map vs map fitting. > > You then transform the fitted pdb file into the original 1.mrc using > "transform as" following the changes to the 2.mrc file. > > You can now do a zone or zone followed by a step of volume erase around > the pdb file using the 1.mrc file, they are in the same relative > orientation now. > > Finally, you write out a zoned/ve map, 1_zone_pdb.mrc, using the 1.mrc > map, so no loss of resolution here. > > Then you can convert 1_zone_pdb.mrc to a brix file and look at in O with > the pdb and it will now be docked in the correct way, ie one won't have > lost the correct origin/alignment of the pdb to the zoned map. > > ------ > > At this point in O, one can adjust the modeled pdb in the zoned density, > then bring the brix file and new modeled pdb files back into Chimera to > make a figure with a better fit of the modeled pdb file. > > This is obviously only needed when you have two structures interacting > and need to segment them vary carefully, to try and improve the local > fit of a loop or whatever. > > Did this make sense? > > It is a way to work in Chimera then transfer back > into O to visualize and work there and even to cycle between them. > > > cheers C Akey

1 0

Re: [Chimera-users] View scale and brix output
by Eric Pettersen 07 Mar '07

07 Mar '07

Just to clarify some of the things that Elaine was unsure of: if a model gets closed that was involved in saved positions then it will simply be ignored when the position is restored. If some new model gets the same ID and sub-ID # as the closed model then that model will be positioned as if it were the closed model (except for per-model clip planes). --Eric On Mar 7, 2007, at 12:24 PM, Elaine Meng wrote: > Hi Christopher, > As long as you save the session after using savepos the positions > should be there. However, as you suspected the model numbers are > important - the individual transformations for the models are restored > based on those model numbers. I think it will restore the positions > of whichever models are there, despite complaining that some are > missing (it's been a while, I'd have to try it to make sure). If you > closed model 0 and opened a new model 0 it might try to put it in the > position the old model 0 was in. Also not sure about that one. When > I use saved positions for my own work, I don't delete/add models > between saving and restoring the positions. > > I can't really envision how positions could be saved without using the > model numbers. The only other thing I can think of is data file name, > but frequently one will have the same data file opened as more than > one model at a time, with different transformations. > ----- > Elaine C. Meng, Ph.D. meng(a)cgl.ucsf.edu > UCSF Computer Graphics Lab and Babbitt Lab > Department of Pharmaceutical Chemistry > University of California, San Francisco > http://www.cgl.ucsf.edu/home/meng/index.html > > > On Mar 7, 2007, at 12:15 PM, Christopher Akey wrote: > > Elaine - > > yeah,that does seem to work nicely within a session, lets see what > happens when I close and reopen it. However, is the savepos option > sensitive to things like deleting one object from the session before > closing, then opening and adding a new object (now the numbering of > the objects may vary and this seems to screw up matrices that are > saved cause they depend on the numbers). I would hope that savepos > doesn't depend on numbered objects? > > cwa > > > Meng wrote: >> Hi Christopher, >> Tom did mention "reset," but I thought I'd expand on that topic a >> bit. You can actually save multiple named positions, which will >> then be included in a single saved session. When I make a set of >> figures that differ in view and scale but with basically the same >> display/coloring setup, I use the "savepos" command to save the >> position for each figure, and then save the session. It doesn't >> matter what position everything is in when you save the session, >> because you will still be able to get back to any of those saved >> positions with "reset." >> The saved positions include scale. If you really only want to >> restore scale, currently you could note the value shown in the >> Camera tool (as mentioned by Tom), and later type that into the >> Camera tool to restore it. >> more about savepos and reset: >> http://www.cgl.ucsf.edu/chimera/1.2304/docs/UsersGuide/midas/ >> savepos.html >> http://www.cgl.ucsf.edu/chimera/1.2304/docs/UsersGuide/midas/ >> reset.html >> Elaine >> ----- >> Elaine C. Meng, Ph.D. meng(a)cgl.ucsf.edu >> UCSF Computer Graphics Lab and Babbitt Lab >> Department of Pharmaceutical Chemistry >> University of California, San Francisco >> http://www.cgl.ucsf.edu/home/meng/index.html >> Christopher Akey wrote: >>> Tom- >>> >>> A few more issues that have come up for user friendliness. >>> >>> 1. It would be useful to have a box where the user can specify the >>> absolute scale for the session, the first time it is opened, this >>> could be set at 1.0 for example after loading a ribosome map and the >>> atomics and putting them to a good size. >>> >>> Then the program should keep track of the changes made during the >>> session using the scale command (I guess you can't track changes made >>> with the mouse so one generally would avoid this, or even better one >>> should be able to turn off the mouse scale feature!). >>> >>> This way one could always look at the pull down for the current scale >>> value when you capture a particular view for a figure. >>> >>> One could then return to the original scale of 1.0 at the end of >>> session or write down the current scale value, which could be kept in >>> the ssesion. So upon reopening the session at a later date, one can >>> always get back to the correct scale to recapture a panel for a >>> figure. This is currently a real problem, as far as I can tell. >>> >>> 2. We often want to import a brix file with aligned pdbs, since we >>> dock and look at them in 'O', which is better in some ways for >>> looking >>> at these maps, but not so good as Chimera for figure making >>> obviously....then in Chimera we may continue to trim or segment a >>> map, >>> and then we want to take it back out, presumably as an MRC file, to >>> be >>> converted into a brix by a conversion program (for us its SPIDER). >>> Then one can do another cycle of docking in 'O' using the >>> refined/cleaned up sub map from Chimera. >>> >>> While I can think of one way to do this without losing the relative >>> origins and thus, the map alignments, it is pretty tedious. If one >>> could write the zoned or volume erased brix volume back out as a new >>> brix file, with the correct dimensions and origin, relative to the >>> brix file brought into Chimera, this would allow you to cycle back >>> and >>> forth using the best of both programs. >>> >>> >>> cheers C Akey >>> >> _______________________________________________ >> Chimera-users mailing list >> Chimera-users(a)cgl.ucsf.edu >> http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users > > > -- > cheers C Akey > > ------------------------------------------------------------------ > STRUCTURAL ELECTRON MICROSCOPY & CRYSTALLOGRAPHY GROUP > ------------------------------------------------------------------ > Christopher W. Akey, Professor > Physiology & Biophysics > Boston Univ. School of Medicine > 700 Albany St. > Boston, Mass. 02118-2526 > > off: 617 638 4051 lab: 617 638 4088 > fax: 617 638 4041 > cakey(a)bu.edu > http://biophysics.bumc.bu.edu/faculty/akey/index.html > ------------------------------------------------------------------ >

1 0

Re: [Chimera-users] Red-cyan stereo
by Tom Goddard 07 Mar '07

07 Mar '07

Hi Jean-Francois, I do not think Chimera produces red-green stereo, only red-cyan. Greg Couch in our lab would know. I've sent your question to the Chimera users groups so he can give a more definitive answer. Tom jean-francois menetret wrote: > > Hi Thomas, > > I have tried the red-cyan stereo option of Chimera with red-green glasses > (I couldn't find red-cyan glasses). One gets the stereo effect but > there is a > shadow from the cyan image that the red filter doesn't stop completely. > Is it possible to change the cyan to green ? > > Jean-Francois

1 0

Re: [Chimera-users] md movie amber issue
by Elaine Meng 05 Mar '07

05 Mar '07

Hi Tom, Recording a movie uses the screen resolution. In contrast, image saving uses "supersampling": a bigger image is saved initially and then sampled back down to the requested size, and that gets rid of jagged edges. Currently, movie recording cannot save the image frames with supersampling, but we plan to add that in the future. If you are recording a trajectory in MD Movie, use the "recording" feature in MD Movie. There is no advantage to using Movie Recorder (under Utilities) or the command "movie" because they use exactly the same underlying mechanism to save frames and assemble them into a movie, and are subject to identical resolution issues. All the same flags that can be used with the "movie" command can be entered in the recording dialog called from MD Movie. The difference is (as you noted) the Movie Recorder is not synchronized well with trajectory playback. See http://www.cgl.ucsf.edu/chimera/docs/ContributedSoftware/movie/ movie.html#recording and the "encode" options in: http://www.cgl.ucsf.edu/chimera/docs/UsersGuide/midas/movie.html In neither case would you have to assemble the individual frames yourself (unless you wanted to for some reason) - on Movie Recorder, clicking the "Make movie" button encodes the saved frames into a movie file. Settings that affect the final movie appearance are Chimera window size (adjust this before saving image frames) and the encoding options mentioned above. I hope this helps, Elaine ----- Elaine C. Meng, Ph.D. meng(a)cgl.ucsf.edu UCSF Computer Graphics Lab and Babbitt Lab Department of Pharmaceutical Chemistry University of California, San Francisco http://www.cgl.ucsf.edu/home/meng/index.html On Mar 4, 2007, at 4:20 AM, Thomas Caulfield wrote: > Hi again Elaine, > > (I) > So I have a MD movie trajectory working (NAMD style, not AMBER), but > my question now goes to rendering a movie. I noticed that under the > MD trajectory window (which plays the frames), that the net resolution > afterward is pretty low (whether I choose MPEG-1/2/4 or > quicktime.mov). But when I do renderings of images the quality is > amazing. > (II) > I also went to Utilities under tools and movie recording, where it > seems some preferences are listed (like resolution etc.), but when I > hit record under that option the trajectory doesn't play, so It starts > taking high-resolution screenshots into a folder with the name > qui*blah-1,2,3,4,... and so on. If this were to play the trajectory > that would be fine, because I could use graphic converter to make a > movie of that. When I tried to do it manually and the make the movie, > it was better resolution, but jerky skipping tons of frames at a time. > > Is there an easier way to do it in (I) and set some preference to the > desired resolution (it looked all bitmappy and fuzzy by the end), > rather than trying to take 1000+screeshots from method (II)? > > Thanks again. > > -Tom > > PS I will try getting this to that other email you gave before thanks. > > On Mar 3, 2007, at 1:26 PM, Elaine Meng wrote: > >> Hi Tom, >> For some reason the mail came to me and not Eric! It may be because >> his address was typed with a one instead of an ell (should be cgl not >> cg1) - but no harm, I've forwarded it to him. He will have to address >> the first question, but I'll tackle the other. >> >> In single-PDB input, the frames should be indicated with MODEL and >> ENDMDL records. For an example, see any NMR structure in the PDB >> that has more than one set of coordinates (1plx is a nice small >> example). >> Best, >> Elaine >> ----- >> Elaine C. Meng, Ph.D. meng(a)cgl.ucsf.edu >> UCSF Computer Graphics Lab and Babbitt Lab >> Department of Pharmaceutical Chemistry >> University of California, San Francisco >> http://www.cgl.ucsf.edu/home/meng/index.html >> >> >> >> >> On Mar 3, 2007, at 1:06 AM, Thomas Caulfield wrote: >> >>> Hi Eric, >>> >>> I wanted to know about using Amber prmtop with Chimera movie md >>> traj. I used it and my initlal frame looks fine, but then it starts >>> bouncing out of camera and back, and my final molecule looks a mess. >>> But in VMD it looks just fine. I'd rather use Chimera for >>> rendering since everything looks so nice in it, however I don't know >>> why it is doing this. >>> >>> I also tried using a series of PDBs instead (to circumvent this >>> issue), but I cannot load it as a single PDB (with multiple frames >>> in it), since the program complains there is only 1 structure in the >>> file. I removed all END and added numbers between the files to try >>> and get it to realize there were frames. >>> >>> What can I do to fix this? >>> >>> Thanks a bunch! >>> >>> -Tom >>> >>> _____________________________ >>> Tom Caulfield, Ph.D. Candidate >>> School of Chemistry & Biochemistry >>> Cherry Emerson Bldg., RM 329 >>> Georgia Institute >>> of Technology >>> Atlanta, GA 30332-0400 >>> Harvey Laboratory: >>> http://rumour.biology.gatech.edu >>> _____________________________ >>> >>> >>> >> > >

2 1

copy cmd in nogui script
by Randy Heiland 02 Mar '07

02 Mar '07

What cmd should I invoke in a --nogui script to copy the rendered image to a file? >From the interactive viewer cmd line, I can successfully execute 'copy file foo.png png'; however, when trying to execute the following: % chimera --nogui cmd:dostuff where 'dostuff' is: open 1yc4 color byelement #0 copy file foo.png png I get: Fetching 1yc4 from web site www.rcsb.org Done fetching 1yc4; verifying... Opening 1yc4... 1 model opened Opened 1yc4 containing 1 model, 1890 atoms, and 427 residues Rendering high resolution image...Error while processing cmd:dostuff: AttributeError: '_chimera.NoGuiViewer' object has no attribute 'pilImages' (see reply log for Python traceback info) Traceback (most recent call last): File "/home/heiland/chimera/build/share/__main__.py", line 59, in ? value = chimeraInit.init(sys.argv) File "CHIMERA/share/chimeraInit.py", line 298, in init prefixableType=1) File "CHIMERA/share/chimera/__init__.py", line 1217, in open File "CHIMERA/share/Midas/ChimeraExtension.py", line 28, in func # lswdir = os.path.split(thisdir)[0] File "CHIMERA/share/Midas/midas_text.py", line 91, in processCommandFile File "CHIMERA/share/Midas/midas_text.py", line 60, in makeCommand File "CHIMERA/share/Midas/midas_text.py", line 542, in doCopy File "<string>", line 1, in ? File "CHIMERA/share/Midas/__init__.py", line 795, in copy File "CHIMERA/share/chimera/printer.py", line 705, in saveImage AttributeError: '_chimera.NoGuiViewer' object has no attribute 'pilImages' thanks, Randy

3 2