- Chimera-users - RBVI Mailing Lists

Re: [Chimera-users] Update volume display without pressing show
by Thomas Goddard 31 Jan '07

31 Jan '07

Hi Jeff, I also wasn't able to reproduce this problem. There is probably a real problem but some step that causes it is missing. If you figure out that step let me know. Tom Jeff wrote: > sorry about the confusion, > > what I meant by 'does not work', is that once I have loaded the volume > planes tool, it appears to not allow me to select 'update display > without pressing show'. (the button is depressed in the dialog box, or > i unclick/reclick it, but it no longer toggles 'update....w/o press > show' on and off). 2318 build. > > sequence: > > 1) load map; display with solid rendering. default is 'update w/o > press show', and you can see the effect of playing with histogram > update in realtime. > > 2) start volume planes. now requires me to press 'show' to update the > display. this also includes other volumes that vol planes is not used > on, and 'update w/o show' no longer works in surface or solid mode. > > 3) close volume planes, or close session. problem persists. > > 4) restart chimera, now it allows 'update..w/o press show' again. > > so, this happened to me twice, and i figured it was just something to > do with the volume planes tool. As I am writing this, I just re-did > the sequence above, and now it works (volume plane tool updates, can > switch to surface). Because I can no longer replicate this, I should > probably be ignored. Also, I just loaded one of the sessions I was > having a problem with into a new launch of chimera, thinking there > might be some sort of 'system/state snapshot' I could send you, but > now it is working too. So, it appears to have been fixed by a restart > of chimera. Again, please ignore. > > -Jeff

1 0

Re: [Chimera-users] Update volume display without pressing show
by Thomas Goddard 31 Jan '07

31 Jan '07

Hi Jeff, I tried the volume "update show" option in combination with volume planes and did not find an problem. Can you give me step by step instructions to produce the problem? Also I don't know what you mean by "does not work". Does it always update automatically, or never update automatically? What Chimera version? With the volume planes tool, the full map is still opened -- it is just display a subregion that is 1 plane high. Use Features / Region Bounds to see and change the subregion. Or use Features / Subregion Selection and press the Full button to get back to the full map. Also the volume planes dialog always acts on the volume displayed in the volume dialog. Perhaps it should have its own menu to choose the volume you want to show planes for. Tom Jeff wrote: > even if I close the volume planes tool, > > 'update display without pressing Show' no longer works (for instance, > adjusting the volume rendering histogram, or clicking 'surface' > rendering). if I close, then re-open the volume, it still doesn't > work. bug, or my version maybe? > > also, once you start 'volume planes tool', it only keeps track of the > plane it has pulled from the volume map - what used to be a > 100x100x100 volume is now 100x100x1; the volume viewer 'renames' the > map but does not save it out that way (which is good). is there a way > to be able to keep the full volume around, but not displayed? there > are reasons you might want to do that (well, I found myself trying to > do that), without having to re-open the volume. > > i did check to see if i could open 2 copies - one first to run 'volume > planes' on, and then one to subsample but have as a volume rendering, > for example. this works, as long as i don't accidentally touch the > 'volume planes' dialog when fooling with the second opened copy of the > volume. > > mainly just curious, not asking for additional functionality, just > wanted to let you know what I was trying and why. > > -Jeff > > > > Thomas Goddard wrote: >> Hi Jeff, >> >> The volume dialog data display option "Update display without >> pressing Show" only effect volume dialog features. It does not have >> any effect on the Volume Planes tool. The Volume Planes tool does >> not allow adjusting the plane number without updating the display. >> >> Tom >> >> >> Jeff wrote: >>> hi Tom, >>> >>> I have volume planes and precomputed subsamplings going, and the >>> 'update display without pressing Show' no longer works (keep >>> toggling on and off, but it doesn't have an effect) >>> >>> is there a way for me to 'refresh' the state of buttons like that? >>> >>> -Jeff >>

1 0

Watershed segmentation of volumes
by Thomas Goddard 31 Jan '07

31 Jan '07

Hi Jeff, There is no watershed or flood-fill type of method in Chimera for segmenting volume data. This is on our (very long) list of features to develop though. Tom Jeff wrote: > tom, > > i hate to keep piling on questions, but how hard would it be to have a > feature where one places a chimera marker, and then has some sort of > algorithm expand to 'fill' the space, kind of an isosurface problem > (or does this already exist) > > i have 'voids' in some of my maps (stained sections) which i think > correspond to protein, like one sees in negative stain (the positive > values/density in the map correspond to stain; an enclosed void > (density more or less = 0 or close to it) is thought to represent the > actual protein, which was covered in stain, kind of like 'magic shell' > on ice cream - or think of dairy queen cone, dipped in chocolate that > then solidifies), and would like some way to 'grow' a blob in the void > (or at least try) > > does this already exist? i have a buddy who does level set methods who > is often looking for ways to use his library, but i thought i should > ask you first if there is some functionality like this > > -jeff

1 0

Quadro FX 1400/3450 performance
by Thomas Goddard 31 Jan '07

31 Jan '07

Hi Maya, It must be exciting and alot of work to get your lab running. Glad to hear you are making Chimera converts. Graphics benchmark scores using Chimera with the quadro fx 1400 and quadro fx 3400 are shown here http://www.cgl.ucsf.edu/chimera/benchmarks.html We don't have any numbers for the fx 3450 and I don't know if it is similar to the 3400. The 1400 and 3400 have very similar Chimera scores. The Chimera scores indicate how big a test volume can be handled at 10 frames per second. Both these cards are very fast. The one difference I see is that on the Nvidia web site they say the 1400 has 128 Mbytes of memory while the 3450 has 256 Mbytes. http://www.nvidia.com/page/qfx_mr.html http://www.nvidia.com/page/quadrofx.html (fx 3400) Maybe that info is out of date -- maybe there is a choice of memory size. On the Chimera page the fx 1400 had 256 Mb. And 128 Mbytes is small by today's standards. 256 Mbytes is common, and 512 Mbytes is available with some cards. The amount of graphics memory is most noticable if you use the Chimera "solid" rendering mode because it tries to put red,green,blue 8-bit values for the entire volume on the card. For 256^3 volume that is 48 Mbytes, or if you use Chimera 2-D textures mode (the default) it take 3 times that (144 Mbytes). It can also make a difference for very large contour surfaces -- ones you might use for making a figure but would be too slow for interactive rotating (e.g. 10 million triangles at about 18 bytes per triangle = 180 Mbytes). Regarding stereo, I'm not sure if there are any flat panel displays that can work with the LCD glasses. They don't refresh fast enough so there is too much flicker. So you either need a CRT display or maybe some special high-end flat panel. See you at the EMAN workshop. Maya Topf wrote: > Hi Tom, > > How are you? > I am slowly settling down in the UK. Lots of work and collaborations. > A few people from the EM group at birkbeck started using chimera and > they really like it! > > I have a question about graphics cards and maybe you can help me. > I am thinking about buying either NVIDIA QUADRO FX 1400 (stereo) or FX > 3450 (stereo). > Do you think that there is a big difference when I want > to visualise large maps with chimera for example? > > thanks, > Maya > > I saw that you are coming to the eman workshop so I guess I will see > you there! > Tom

1 0

ViewDock descriptors problem
by "Воронков андрей" 31 Jan '07

31 Jan '07

Dear Chimera users, I have ranked database from DOCK. I need to see energies of these structures and their ranking. I open them by View Dock, but in the field Column menu I can see only name field. Why I don't have energy field there and how can I get it? Respectively yours, Andrew PS "Descriptors can be shown in or removed from the upper panel using the Column menu." -this is from manual, but I can;t make shown any descriptos but the name of the structure

2 1

Re: [Chimera-users] using a marker file to zone a volume from python prompt
by Thomas Goddard 30 Jan '07

30 Jan '07

Hi Jeff, I added a user interface dialog for rotating and translating atom coordinates. Markers in Chimera are equivalent to atoms so it works on those. The rotation is specified in Euler angles. The new dialog, called Transform Molecule Coordinates, is available on the experimental features web page: http://www.cgl.ucsf.edu/chimera/experimental/experimental.html Tom Jeff wrote: > thanks Tom, > > much appreciated. how hard is it for me to write a dialog GUI to provide > 3 numerical inputs to the rotation script you forwarded me? (is it more > involved than a few lines? I am not familiar with Tkinter). > > don't want to bother you too much, if it is not a quick thing/response > feel free to punt, please. > > -jeff >

1 0

Update volume display without pressing show
by Thomas Goddard 30 Jan '07

30 Jan '07

Hi Jeff, The volume dialog data display option "Update display without pressing Show" only effect volume dialog features. It does not have any effect on the Volume Planes tool. The Volume Planes tool does not allow adjusting the plane number without updating the display. Tom Jeff wrote: > hi Tom, > > I have volume planes and precomputed subsamplings going, and the 'update > display without pressing Show' no longer works (keep toggling on and > off, but it doesn't have an effect) > > is there a way for me to 'refresh' the state of buttons like that? > > -Jeff

1 0

Re: [Chimera-users] Representation of volume data in memory
by Thomas Goddard 30 Jan '07

30 Jan '07

Hi Jeff, I suspect 2-byte integers are not faster to access or compute with then 4-byte floats on modern CPUs. But more of the map will fit into the CPUs cache which could improve bandwidth and could make computing a contour surface faster. But I don't think that will be significant. You would need to test it to know. Chimera keeps the native data type of the map to conserve memory when reading large maps. Tom Jeff wrote: > does this mean that a 2-byte integer format of a file will display > faster / render triangles faster than the equivalent sized 4-byte float > map? > > Thomas Goddard wrote: >> Hi Jeff, >> >> Chimera keeps volume data in memory using the same numeric value >> types that are present in the file, for example, 32-bit float, 16-bit >> integer, 8-bit integer. >> >> Volume data is copied only when necessary -- for instance, using the >> Gaussian Filter tool creates a floating point copy of the data since >> Gaussian convolution of integer data produces a floating point result. >> >> Tom >> >> >> Jeff wrote: >>> does chimera store all values as float internally (even if the >>> original map is in 2 byte integers), making the mode of the MRC file >>> irrelevant to chimera's performance? >>> >>> -jeff >>

1 0

Re: [Chimera-users] zone tool and volume rendering
by Thomas Goddard 30 Jan '07

30 Jan '07

Hi Jeff, The Chimera handling of the MRC file origin position is done in Python code chimera/share/VolumeData/mrc/mrc_format.py In summary, if it is an MRC2000 file (ie has xorigin, yorigin, and zorigin header values) then (xorigin, yorigin, zorigin) is used as the xyz coordinates of the volume index (0,0,0) unless xorigin, yorigin and zorigin are all zero in which case the xyz position of the map index (0,0,0) is calculated using integer (ncstart, nrstart, nsstart) header values times the grid spacing (defined by (xlen/mx,ylen/my,zlen/mz)). It is never the case that both (ncstart,nrstart,nsstart) and (xorigin,yorigin,zorigin) are used in positioning the map. Tom Jeff wrote: > > I often use another tool to cut out subregions, that I then load into > chimera - until you told me recently, I did not know I could pre-load > subsampled maps, or be able to keep a 'subsampled overview' present > while selecting various regions > > when using other tools to cut out these smaller areas (either IMOD or > Priism), some tools record displacements, and some don't. the Priism > 'CopyRegion' tool appears to do this by adjusting the 'start pixel' > field in the MRC header. IMOD doesn't do this. the 'copyRegion' tool > also doesn't appear to transfer well to chimera, at least in my test > case the original and subvolume do not register properly. (I don't have > any expectation that it would work properly, but I would adapt if I knew > what chimera expects.) > > I am also not sure what entries chimera uses to keep track of > displacements when it cuts out volumes (I could do that experiment right > now), whether it uses 'start pixel' or 'origin', if 'origin' is recorded > in Angstroms or pixels, etc. Also, I don't know what chimera considers > the origin of a density map - if 'start pixel' is 10,10,10, the map is > 20x20x20 pixels in dim, and the origin is (0,0,0), is the origin at the > center of the map, or at the 0,0,0 pixel coordinate of the map? I have > been assuming that 'origin' has to refer to the map's origin location in > space, but this requires defining where the origin is in the volume map > (I think). if there is a 'start pixel' entry, does this effectively > shift the origin? As an example, if the pixel res is 10 A, will the map > example above now display starting at (10 A, 10 A, 10 A)? Or, is one > (or both) of these entries ignored? Finally, if there is already an > entry in one of these fields, does chimera respect that and just > increment, or does it clobber it with the relative displacement > calculated when excising a subvolume? (this slew of questions is > probably covered by a single answer, but I thought it would be good to > elaborate) > > If I knew, I could more appropriately jump between programs. As I am > writing this, I just got an email from David at Boulder telling me that > IMOD uses the origin entries in the header (but don't know yet what it > considers to be the origin, 'far left' corner or center or something else). > > -Jeff

1 0

Precomputing subsampled map sizes
by Thomas Goddard 30 Jan '07

30 Jan '07

Hi Jeff, Yes, Chimera will complain and not allow precomputed volume subsamples if the size of the subsample grid is not what is expected. In the case you give (1434,1434,110) with subsample grid of size (358,358,26) the subsample grid size is not acceptable. Notice that 4 times the subsample size is (1432, 1432, 104) So a half size bins in the first two dimensions are left off (1434 - 1432 = 2) -- that is fine. But the third dimension is missing 1.5 bins (110 - 104 = 6). The subsample file should have size 27 in the third dimension, ie (358,358,27). I don't know why squeezevol from IMOD dropped off more than a whole bin in the third dimension. Chimera allows fractional bins to be dropped off, but does not allow whole bins to be missing. Tom Jeff wrote: > hi again, > > is there a problem with the precomputed subsamplings needing even > dimensions (I pre-cut my volume to even dimensions so that a binning of > 2 would result in a whole number for the subsampled dimensions, but it > can be hard to do this for a factor of 8 in advance). > > chimera is complaining to me about bad dimensions ('Data foo.mrc of size > (358,358,26) not a valid size for dubsamples of foo.mrc of size > (1434,1434,110). > > is there a program you use to bin / get around this problem? I use > 'squeezevol' from IMOD, I am not sure if it is completely transparent in > its output for what chimera would expect > > -j

1 0