Re: [IMP-dev] IMP-dev Digest, Vol 13, Issue 9
Actually, on second thought, what I am working on is not necessary a Matrix in 2D or 3D as Keren has wrote in her class. I am working in a template array able to store different types of data and then access to them in a 1D, 2D or 3D fashion. It is the way images and volumes are treated in Xmipp, and it is very efficient. Your point of view, guys, is more of storing points, and therefore compatible with what I am doing.
J
Javi - I think that there is some confusion here. The Matrix3D is a rotation matrix, maybe we should rename the class to RotationMatrix3D for clarity. It has nothing to do with grids for storing data. Today we store the image as a one array with access function for specific voxels depending on the grid dimensions. Are you going to change this basic representation now or just have an access class for Xmipp? On Nov 12, 2008, at 7:32 PM, Javier Ángel Velázquez Muriel wrote:
> Actually, on second thought, what I am working on is not necessary a > Matrix in 2D or 3D as Keren has wrote in her class. I am working in a > template array able to store different types of data and then access > to them in a 1D, 2D or 3D fashion. It is the way images and volumes > are treated in Xmipp, and it is very efficient. Your point of view, > guys, is more of storing points, and therefore compatible with what I > am doing. > > J > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
2008/11/12 Keren Lasker kerenl@salilab.org: > Javi - I think that there is some confusion here. > The Matrix3D is a rotation matrix, maybe we should rename the class to > RotationMatrix3D for clarity.
Yesssss!
> It has nothing to do with grids for storing data. > Today we store the image as a one array with access function for specific > voxels depending on the grid dimensions.
Yes, that's what we do in EMBed is for 3D. But now I need the 2D version, that needs tons of specifics.
> Are you going to change this basic representation now or just have an access > class for Xmipp?
I am NOT changing anything, just building the 2D version compatible with Xmipp.
> On Nov 12, 2008, at 7:32 PM, Javier Ángel Velázquez Muriel wrote: > >> Actually, on second thought, what I am working on is not necessary a >> Matrix in 2D or 3D as Keren has wrote in her class. I am working in a >> template array able to store different types of data and then access >> to them in a 1D, 2D or 3D fashion. It is the way images and volumes >> are treated in Xmipp, and it is very efficient. Your point of view, >> guys, is more of storing points, and therefore compatible with what I >> am doing. >> >> J >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > >
Why would we want to have a matrix class which is restricted to rotation matrices or is anything less than a full matrix?
On Nov 12, 2008, at 11:44 PM, Keren Lasker wrote:
> Javi - I think that there is some confusion here. > The Matrix3D is a rotation matrix, maybe we should rename the class to > RotationMatrix3D for clarity. > It has nothing to do with grids for storing data. > Today we store the image as a one array with access function for > specific voxels depending on the grid dimensions. > Are you going to change this basic representation now or just have an > access class for Xmipp? > On Nov 12, 2008, at 7:32 PM, Javier Ángel Velázquez Muriel wrote: > >> Actually, on second thought, what I am working on is not necessary a >> Matrix in 2D or 3D as Keren has wrote in her class. I am working in a >> template array able to store different types of data and then access >> to them in a 1D, 2D or 3D fashion. It is the way images and volumes >> are treated in Xmipp, and it is very efficient. Your point of view, >> guys, is more of storing points, and therefore compatible with what I >> am doing. >> >> J >> _______________________________________________ >> IMP-dev mailing list >> IMP-dev@salilab.org >> https://salilab.org/mailman/listinfo/imp-dev > > _______________________________________________ > EMBED-dev mailing list > EMBED-dev@salilab.org > https://salilab.org/mailman/listinfo/embed-dev
You mean we should have Matrix3D as a general 3X3 matrix? It is currently used mainly for rotation matrices. I will anyway add the is_rotation function. We can leave it as a general 3X3 matrix but at least need to change the name as Javi thought is it N*M*L matrix. On Nov 12, 2008, at 7:55 PM, Daniel Russel wrote:
> Why would we want to have a matrix class which is restricted to > rotation matrices or is anything less than a full matrix? > > > On Nov 12, 2008, at 11:44 PM, Keren Lasker wrote: > >> Javi - I think that there is some confusion here. >> The Matrix3D is a rotation matrix, maybe we should rename the class >> to >> RotationMatrix3D for clarity. >> It has nothing to do with grids for storing data. >> Today we store the image as a one array with access function for >> specific voxels depending on the grid dimensions. >> Are you going to change this basic representation now or just have an >> access class for Xmipp? >> On Nov 12, 2008, at 7:32 PM, Javier Ángel Velázquez Muriel wrote: >> >>> Actually, on second thought, what I am working on is not necessary a >>> Matrix in 2D or 3D as Keren has wrote in her class. I am working >>> in a >>> template array able to store different types of data and then access >>> to them in a 1D, 2D or 3D fashion. It is the way images and volumes >>> are treated in Xmipp, and it is very efficient. Your point of view, >>> guys, is more of storing points, and therefore compatible with >>> what I >>> am doing. >>> >>> J >>> _______________________________________________ >>> IMP-dev mailing list >>> IMP-dev@salilab.org >>> https://salilab.org/mailman/listinfo/imp-dev >> >> _______________________________________________ >> EMBED-dev mailing list >> EMBED-dev@salilab.org >> https://salilab.org/mailman/listinfo/embed-dev > > _______________________________________________ > IMP-dev mailing list > IMP-dev@salilab.org > https://salilab.org/mailman/listinfo/imp-dev
participants (3)
-
Daniel Russel -
Javier Ángel Velázquez Muriel -
Keren Lasker