[Chimera-users] zone tool and volume rendering

[Thomas Goddard]

Hi Jeff,

   You are right that masking a filament that runs along the long 
diagonal of a box does not reduce the disk space or memory use any.  (If 
you compressed the file then it would make a big difference.  But you 
need to uncompress it to use it so that is of limited value.)

   So to achieve a space savings you need to resample the volume using a 
grid aligned with the axes of the filament.  The resampling will degrade 
the data resolution some and it might be reasonable to do it on a grid 
with half the spacing (making the file 8x bigger).  With such a 
resampled map the rotation and shift could be stored so that it can be 
placed in the original location in the full map.  We don't support that 
now but when we add resampling we will store those rotation parameters 
in the map file header (maybe in the "labels" field for an MRC file).

   The time for Chimera to display a map depends on how large the volume 
grid is because it scans the entire grid in one pass when using the 
marching cubes algorithm to compute a contour surface.  It also depends 
on how many triangles make up the contour surface.  By eliminating the 
99% of a masked file that is zeros using a new orientation and 
resampling it could compute contour surfaces faster.  And the solid 
(volumetric) rendering should be faster directly proportional to the 
file size.  That may be the more important case for your EM tomograms.

   I plan on supporting resampling on a rotated grid.  But I think in 
many real uses it will not save much space because you will want to 
resample with finer grid spacing.  But it could be convenient for 
exporting to analysis or visualization software that is limited to 
xy-planes.

	Tom


Jeff wrote:
> got it,
> 
> what you say makes sense, I can definitely workaround, especially given 
> that the zone tool does a mask upon saving.
> 
> I have been thinking about the problem I have with filaments (or 
> surfaces) spanning non-orthogonal regions of a volume, which means that 
> zoning out a long filament (or surface) that might take a much smaller 
> amount of space/memory once zoned actually takes up almost the same 
> amount currently, if I am thinking right.
> 
> as an example, say you have a volume that is 100x100x100. inside the 
> volume, you have a filament, that takes up 10x10x244 voxels (effectively 
> spanning from one corner to the mirror/opposite corner of the volume). 
> in theory, zoning out that filament could take up ~1/40th the space, if 
> rotated to line up with one of the cartesian axes. I don't know how much 
> logic it would take to do this; I also don't know how chimera reads 
> origin information from an MRC file, or how much work it would take to 
> enable it to read (and use) an euler convention from an MRC file, for 
> displaying later. This would enable cutting a whole bunch of filaments 
> out of a volume, and then displaying them all concurrently without 
> running into the problem of loading in large rectangular prisms of space 
> that are mainly zeros (if this is currently happening, I don't know). I 
> guess at that point it makes sense to consider the geometric center of 
> such a rotated object at its origin, to reduce re-displaying the 
> object/filament properly in the original orientation to just storing a 
> shift and the rotation angles (6 parameters).
> 
> the same holds true for membranes - right now, I have an entire membrane 
> that I segmented with markers, but it essentially runs along a hypotenuse.
> 
> one question that probably negates the above paragraph would be 'does 
> the masked volume (with mostly zeros) display any faster / take less 
> resources than an equivalent volume without the zeros'? I have been 
> assuming this is not the case, that the zoned/masked volume still 
> entails reading in / accounting for that full rectangular prism, despite 
> the fact that it is mostly empty / full of zeros.
> 
> thanks for you help,
> 
> -Jeff