Here is a proposed grid class (I haven't even tried to compile it). It can map between real space and voxels.
The differences from the grid used in EMBed are: - The voxel index is actually a triple if ints. This makes computing a point in a voxel fast without the large tables used in EMBed. I think this is the right choice speed wise, but we can always test (and it is trivial to change). - the names are changed to be more consistent with IMP - the voxel data is a template argument - it is copyable - currently there is no resize function and I don't really know what would be meant by it and the obvious things involve lots of moving of data around.
On Feb 4, 2008, at 3:28 PM, Daniel Russel wrote:
> Here is a proposed grid class (I haven't even tried to compile it). > It can map between real space and voxels. > > The differences from the grid used in EMBed are: > - The voxel index is actually a triple if ints. This makes computing > a point in a voxel fast without the large tables used in EMBed. I > think this is the right choice speed wise, but we can always test > (and it is trivial to change). The reason we had it as single array in EMBed is for consistency with external programs like fttw, EMAN. I think that we should keep it like that. > > - the names are changed to be more consistent with IMP > - the voxel data is a template argument > - it is copyable I agree for these 3 changes > > - currently there is no resize function and I don't really know what > would be meant by it and the obvious things involve lots of moving > of data around. We need it for correlating maps of different sizes and to interact with the external utilities. > > <Grid3D.h> > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
>> >> The differences from the grid used in EMBed are: >> - The voxel index is actually a triple if ints. This makes computing >> a point in a voxel fast without the large tables used in EMBed. I >> think this is the right choice speed wise, but we can always test >> (and it is trivial to change). > The reason we had it as single array in EMBed is for consistency with > external programs like fttw, EMAN. > I think that we should keep it like that. It still has that. Just the index type is different. It also makes it easier to iterate over the whole thing.
Daniel Russel wrote: >>> The differences from the grid used in EMBed are: >>> - The voxel index is actually a triple if ints. This makes computing >>> a point in a voxel fast without the large tables used in EMBed. I >>> think this is the right choice speed wise, but we can always test >>> (and it is trivial to change). >>> >> The reason we had it as single array in EMBed is for consistency with >> external programs like fttw, EMAN. >> I think that we should keep it like that. >> > It still has that. Just the index type is different. It also makes it > easier to iterate over the whole thing. > just to add the reason for storing voxels in a 1d array rather than 3d: in image processing, all computations are typically done in loops, i.e. neighboring voxels are accessed in succession. therefore, it should be faster in that case, and every program i know of (at least in the em community) handles it this way. if you refer to the grid as the coordinates a specific voxel corresponds to: it might well be that it is done sub-optimally done in EMbed. just test it with a reasonably large map (e.g. 100x100x100 voxels). if you result in a speed-up, changes are always welcome. > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev >
On Feb 6, 2008, at 11:49 PM, Friedrich Foerster wrote:
> Daniel Russel wrote: >>>> The differences from the grid used in EMBed are: >>>> - The voxel index is actually a triple if ints. This makes >>>> computing >>>> a point in a voxel fast without the large tables used in EMBed. I >>>> think this is the right choice speed wise, but we can always test >>>> (and it is trivial to change). >>>> >>> The reason we had it as single array in EMBed is for consistency >>> with >>> external programs like fttw, EMAN. >>> I think that we should keep it like that. >>> >> It still has that. Just the index type is different. It also makes it >> easier to iterate over the whole thing. >> > just to add the reason for storing voxels in a 1d array rather than > 3d: > in image processing, all computations are typically done in loops, > i.e. > neighboring voxels are accessed in succession. therefore, it should be > faster in that case, and every program i know of (at least in the em > community) handles it this way. >> Its ok. The data is still stored in 1d, the voxel index is used only for iterating - and you can still just loop over the 1d array.
participants (3)
-
Daniel Russel -
Friedrich Foerster -
Keren Lasker