What units are the origin in when calculating a reconstruction.

[odinsbane]

I have an image setup that I can create a fusion with the following setup.

The ImagePlus window that opens up has the origin "in pixels".

If I change the downsampling factor, then the resulting image has half as many pixels, and takes up the same 'real unit' volume. The origin does not change though. My issue is, what are the "pixels" used for the origin. Would they be equivalent to the non-binned origin?

It seems like the origin should be using the pixel size of the fused image. Is this a bug, or am I thinking of it wrong.

[odinsbane]

I would to add, that if I check my bounding box (x, y, z, w, h, d) is in pixels. After I perform the fusion my origin becomes (-x * pixelWidth, -y*pixelHeight, z*pixelDepth). I don't know if this is a general rule or there is something in my setup that is causing this.

[odinsbane]

I'm moving this comment from the other issue.

I have a dataset that has been prepared for me and I want to make a fusion. When I make the fusion with the following bounding box.

Bounding Boxes: Tile_7 (dim=265x260x373px, offset=156x258x159px)

If I don't use any binning. Then the resulting image has

voxel 0.175um x 0.175um x 0.175um dimension(px) 265, 260, 373 origin(?) -27.16,-44.91,-27.68

If I use downsampling 2, then the resulting image is voxel 0.35um x 0.35um x 0.35um dimensions(px) 133, 131, 187 origin -13.58,-22.46,-13.84

From the looks of it, the origin is a scaled unit. ie the x coodinate is 0.175*156. Except it scales with downsampling as though it is in pixels?

[tpietzsch]

I think you're right. This doesn't seem right. The origin should be either the same for both versions (if its unit is um), or it should be (156, 258, 159) and (78, 129, 79.5) if its unit is px.

[StephanPreibisch]

Hi @odinsbane, could you please use BigStitcher? SPIM_Registration is simply an outdated version of it that we do not support anymore ... could you please check if it maybe simply works there?

[odinsbane]

Hello @StephanPreibisch I get the same results going through the big stitcher plugin. Should I move this issue to the BigStitcher repo?

[StephanPreibisch]

Hi, yes, please just refer to this one there … I am traveling later and will have a look, hopefully fix it right away! Thanks so much!!

[StephanPreibisch]

@tpietzsch I think it would be weird to make the offset dependent on what type of units is being used (that is a user-defined string at the end). I think we can either scale the origin or not scale it. My feeling is that not scaling is the right thing to do - it is smaller but starts at that point in space. This means the origin/offset is in full scale/resolution. What do you think?

[odinsbane]

Consider two images exported from bounding boxes. If I had a point in one of them, could I use the geometry in the images to find the same point in the other image?

If the origin is always in full resolution pixels, then I don't think I would have enough information since the origin would be not be in pixels of the exported image. I would need to know how much the image had been down-sampled.

If the origin scales with pixel size, then the real world units are readily accessible, and the transformation is pretty simple.

Also, https://github.com/imagej/ImageJ/issues/155#issuecomment-1134712487 imagej now scales the origin when the image scales so that the real-world units are consistent.

ImageJ and BigStitcher seem to handle the origin a bit differently:

• If I have an image and I crop a section, then the origin are positive values. Implying that the "origin" is the location of this image's origin in a larger context.

• When I make a fusion the origin is negative, implying that the origin is the location of the origin in the current images coordinates.

Thank you for looking at this.

[tpietzsch]

@StephanPreibisch @odinsbane

I think it would be weird to make the offset dependent on what type of units is being used (that is a user-defined string at the end). I think we can either scale the origin or not scale it.

If the origin scales with pixel size, then the real world units are readily accessible, and the transformation is pretty simple.

That sounds good to me: the origin should be in pixel units, and it should be scaled (i.e. "the same pixels as the size").