Add position and scaling matrix for nup84 2D EM

[tomgoddard]

nup84.cif has a reference to a 2D EM map (*.pgm) file which does not contain pixel size information or alignment to the sphere models.

[tomgoddard]

The scale is already provided in pixel_size_width and pixel_size_height of the ihm_2dem_class_average_restraint table. So only rotation and translation need to be provided using the current ihm_2dem_class_average_fitting table.

[benmwebb]

@tomgoddard, any preferred convention for this transformation? Since we don't currently have it in IMP, I may as well be consistent with whatever convention Chimera uses when I add it. (By "convention" I mean where do you place 2D images relative to 3D objects? On the xz or yz plane? Centered at the origin or origin at bottom left of the image?) @brindakv, we should state this convention in the dictionary too so there's no confusion.

[tomgoddard]

A 2D image opened in Chimera is placed in the xy plane with the lower left image corner (image pixel index 0,0) at x,y,z = (0,0,0).

[tomgoddard]

The nup84 example 2DEM fitting matrix is not aligning the map with the cluster 1 sphere model. If I transpose (or equivalently invert) the rotation then the orientation looks correct (see attached image). But nothing I tried made the translation alignment correct, typically off by about 50-300 Angstroms along each axis. The conventions are not clear in the ihm-extension.dic file but here is what I think the should be. The 2D image is scale by the pixel_size_width and pixel_size_height from the ihm_2dem_class_average_restraint table with corner pixel 0,0 being at position x,y,z = 0. Then the rotation is applied to the image grid points, and finally the translation vector is applied to the image grid points. (This implies the translation is in units obtained after pixel_size_width scaling, e.g. Angstroms.) The resulting image location should match the sphere model when projected orthogonal to that final image position. The rotation is applied by multiplying an xyz grid point column vector by rotation matrix having elements r11,r12,r13 in the first row, r21,r22,r23 in second row, r31,r32,r33 in third row (R * xyz). In the nup84 example the rotation matrix elements have only 3 digits to the right of the decimal place. This is not enough to get decent orthogonality of the matrix and it would be better to have maybe 6 digits minimum so the rotation is really a rotation to within 32-bit float precision.

[benmwebb]

The nup84 example 2DEM fitting matrix is not aligning the map with the cluster 1 sphere model

Is the code for this in ChimeraX already? Seems to me like it would be easier for me to fiddle with it at my end rather than going back and forth. And I'll double-check the transformation here. There is a test in the IMP test suite with a toy system, but possibly something weird is happening for Nup84.

The conventions are not clear in the ihm-extension.dic file

If I understand you correctly, your thoughts on what they should be match what I implemented in IMP, except that the rotation and translation are applied to the 3D model, not the image. That's presumably why you had to invert the rotation matrix. @brindakv needs to clearly state the convention in the dictionary, but of course it's easy for whoever ends up being "wrong" to invert the transformation. (My feeling is that the transformation should apply to the model rather than the image because the image is pristine input data while the model is noisy output data. Of course for viewing you can choose to transform either.)

In the nup84 example the rotation matrix elements have only 3 digits to the right of the decimal place.

No problem - I can output them with more precision. My CIF writer outputs all floats with 3 places, but I can hack it to add more precision just for these fields.

[tomgoddard]

I tried using the inverse transform on the 2d image and it came closer but still off in translation in x and y by maybe 50-100 Angstroms, image attached. The code to read the matrix (using the inverse) will be in tonight’s ChimeraX build.

[benmwebb]

FYI, looks like GitHub strips attachments if you reply to an issue by email, so nobody can see the image.

[tomgoddard]

Thanks. Thought I’d try the attachments but they are not important — the text describes the situation.

[benmwebb]

Ah, I see the problem. The transformation is correct but it's for the model as stored in the RMF file. For some reason we center the models on the origin before writing out the mmCIF file. So we could either adjust the transformation to account for that, or deposit the IMP model coordinates without centering them first. I'm inclined to do the latter since the fewer differences between what we have in our 'raw' files (e.g. trajectories) and the mmCIF, the better.

[tomgoddard]

Sounds good.

[benmwebb]

Turns out that the Nup84 trajectories are also centered, so it makes sense to leave the mmCIF output as it is. Pretty easy to invert this centering before applying the image transformation though.