Extent along z axis

[tischi]

Hi @martinschorb,

Do you know how thick (z-axis) the em overview, low-mag and high mag EM should be, respectively?

[martinschorb]

The sections/tomograms usually have 300 nm thickness. The volumes are isotropic, so their z-extent will give you a decent estimate.

[tischi]

Can you find out the exact z-extent of the high-res and low-res tomograms? Right now in BDV they appear to have a different extent.

[martinschorb]

When you reconstruct a tomogram, you back-project the individual tilt projections into a virtual space. The resulting volume can have any size. Typically, you limit it to the volume where there is variation in intensity which should roughly correspond to the physical section (everything else is vacuum anyway). This trimming of the volume is done individually, so the resulting volumes can have a slightly different thickness. We could either crop them to be the same or use the larger one.

[tischi]

OK, so I guess we should check the xml to see what's up here.

[martinschorb]

The XMLs look good to me. Could it be the additional transforms from elastix that somehow screw up the third dimension? Or do you strictly limit them to be 2D?

[tischi]

there are no elastix transforms. just translations. but do the voxel sizes look good to you?

one issue I saw is that the high res are right now not aligned with the low res along the z-axis. it would be great to fix this somehow.

[martinschorb]

The XML transforms look correct. Are the volumes interpolated by elastix? Could something have happened to the z-voxel size there?

[tischi]

i will check the algorithm later. there is no elastix!

[martinschorb]

Ah. OK. At one point the matching of the different EM mags was done in elastix. What have you used instead? CC-based matching? Or BigWarp?

[tischi]

CC

[martinschorb]

And then just translations, no scaling or rotation. Cool...

[tischi]

yes.

so, could it be that the z-extend of the high-mag is less than the low-mag tomogram at the same location?

if that is the case we need to also find a way to align them along the z-axis.

currently alignment is only done in x & y.

[martinschorb]

If the voxel sizes are correct (which they should be), then they should match. The only thing that could have happened would be the other way round. That during the acquisition of the highmag (before the lowmag) the section has undergone beam-induced shrinking. But LM>HM cannot happen...

[tischi]

Here LM > HM, isn't it? (looking from the side).

Could you plase check the corresponding XMLs?!

[martinschorb]

Do you know where the raw data is? I checked Giulia's folder and could not find it. I guess the pixel sizes (XY) are correct, otherwise the CC-matching would not have worked. And the reconstructions should be isotropic and thus are the XMLs.

[martinschorb]

Have you checked whether the mismatch between the LM and HM tomograms in Z is a scaling issue or just an offset? The size and extent of the volumes makes sense. From the XMLs you would expect the LM to be thicker. The question is whether the actual voxel data matches or not. I will try with BDV-PG whether it is just a shift or indeed a different scaling.

[tischi]

Do you know where the raw data is?

I am using the data from S3; not sure where the local copy is. @constantinpape, could you please point @martinschorb to the data on the file system.

[constantinpape]

@K-Meech gave me the original data, you can find it here: /g/schwab/Kimberly/From_Giulia The MoBIE project with the converted n5 data is here: /g/kreshuk/pape/Work/mobie/yeast-clem-datasets

[martinschorb]

I checked the n5 in BDV-PG and it clearly looks like it's just a shift in Z. Could you run your CC based on a z-slice (or a subvolume) also in that direction?

[martinschorb]

Or here are the shifts (done manually). 26_hm:

        <affine>0.0012546000480651855 0.0 0.0 51.49522195483865 0.0 0.0012546000480651855 0.0 0.0 0.0 0.0 0.0012546000480651855 0.16893845483876374</affine>

[martinschorb]

25_hm:

        <affine>0.001254600048065185 0 0 55.34654383163453 0 0.0012546000480651855 0 47.12710153290881 0 0 0.0012546000480651855 0.1404753674470605</affine>

[tischi]

Thanks!

I think for simplicity we should just change the shift manually in the xml.

I can do it on the github repo.

I think there were a few more hm? Could you please have a look?

And, for the record: LM>HM, isn't it?

[martinschorb]

30_hm:

        <affine>0.0012546000480651853 0.0 0.0 63.65810649982968 0.0 0.0012546000480651853 0.0 61.11762943371748 0.0 0.0 0.0012546000480651853 0.17404735695267484</affine>

not 100% as accurate as a proper 3D CC match, but OK for now, I guess. There is a tiny discrepancy in scale at least in this one. Maybe I did not check the other ones that thoroughly.

• What's your opinion, should we do it properly?

[martinschorb]

31 seems to be the same as 30 but somewhat located in a wrong position, can you confirm that?

[martinschorb]

LM>HM yes, it seems that the trimming of the volume was done much more rigorously for the hm data. This makes sense because the resolution but also tilt sampling is much higher. Therefore there are less artificial reconstruction fringes appearing in the empty vacuum space that are picked up as "signal" and then kept in the final volume.

[martinschorb]

31 seems to be the same as 30

I'd remove 31_hm and keep 30 as it contains more cellular volume.

[tischi]

thanks! Have to go now. Will work on this tomorrow morning.

[tischi]

• I deleted 31_hm and 31_lm
• I added the offsets to the xml

[tischi]

@martinschorb looks much better now!

about the overview image:

1. Is that transmission EM?
2. I know the image itself is 2D but what's the thickness that it covers, I guess the thickness of the physical slice? Because then we could adjust the voxel size in z to represent this.
3. What's the thickness that is covered by the LM?

[martinschorb]

Yes, that's a 2D TEM image. I would make it the same "fake" thickness as the fluorescence image. Something slightly bigger than the largest tomographic volume. (1µm should be thick enough) We could also shift all tomograms/sources to be centered around z=0. That way the slice at the origin will always contain useful information from all sources.

[tischi]

We could also shift all tomograms/sources to be centered around z=0. That way the slice at the origin will always contain useful information from all sources.

I think this would be great. Would you like to play around with this? I could update MoBIE-beta and then you could further optimize the xml in the remote folder of the spec-v2 branch: https://github.com/mobie/yeast-clem-datasets/tree/spec-v2/data/yeast/images/remote

Alternatively you could also find out the right voxel size and affineTransforms in bdv-playground and then let me know what we have to change here on github.

I would make it the same "fake" thickness as the fluorescence image. Something slightly bigger than the largest tomographic volume. (1µm should be thick enough)

Right now it is 2 um: https://github.com/mobie/yeast-clem-datasets/blob/86d71cb2e238dd0f9fc11da7f7fafe1b525095d3/data/yeast/images/remote/em-raw-overview.xml#L16

[martinschorb]

I am working on it... One thing:

• why is a volume with size 1.0 µm and affine shift -0.5 not centered around 0? There is no other transform... https://github.com/martinschorb/yeast-clem-datasets/blob/spec-v2/data/yeast/images/remote/em-raw-overview.xml

[tischi]

why is a volume with size 1.0 µm and affine shift -0.5 not centered around 0? There is no other transform...

I have no idea! I would agree that I would think it should be centered around zero! Maybe play around a bit more and otherwise we have to ask... now that I am writing this I think I remember that there was a discussion in gitter about some issues about how BDV places 2D sources along the z-axis (@NicoKiaru, do you remember?)...

[tischi]

why is a volume with size 1.0 µm and affine shift -0.5 not centered around 0?

but, wait, why a -0.5 shift? I would expect a 0.0 shift centers it around 0.0. Does it?

[martinschorb]

I thought top-left-lowest corner is the center of the coordinates? Is this different in z?

[martinschorb]

OK it seems that indeed 0 shift is needed to center it.

I will apply that and also center the tomograms.

[martinschorb]

will it also place 3D sources to their center in z?

[martinschorb]

OK, I think I also know how to place the tomograms...

[tischi]

will it also place 3D sources to their center in z?

I guess not; you have to find the center of them and shift them.

[martinschorb]

Have you updated the Beta channel? I seem to not be able to properly superimpose the sources (occluding, opacity etc..). This makes it hard to check their relative orientations.

[constantinpape]

Have you updated the Beta channel?

What do you mean by beta channel?

I seem to not be able to properly superimpose the sources (occluding, opacity etc..)

I have set all tomograms to occluding. You can change this via the context menu and setting "projection mode" to "sum", not that this will change the settings for all visible sources under the cursor.

[martinschorb]

I have set all tomograms to occluding.

OK, It is early sources first. I thought the occluding source that is added last would be on top...

[martinschorb]

And segmentations don't seem to work with other occluding sources. Is this because they occlude as well?

[constantinpape]

Ok, @tischi can you look into this?

[tischi]

And segmentations don't seem to work with other occluding sources. Is this because they occlude as well?

MoBIE-beta may not be updated; I will do it now....

[tischi]

@martinschorb I updated MoBIE-beta.

It works for me now:

[martinschorb]

updated all tomograms.

https://github.com/mobie/yeast-clem-datasets/pull/8