Add origin to exported ImagePlus

[tischi]

@NicoKiaru

For one of our projects it is important that we keep track of where we "cropped" the image in BDV that we export. I therefore added code here to add the origin (upper left corner of the BDV window) to the ImagePlus.

If you want we could make this optional by adding a boolean parameter to the Command.

I guess we should then also add the same functionality to the advanced version of the export Command.

What do you think? (We really need it)

[NicoKiaru]

It's actually already there: https://github.com/BIOP/bigdataviewer-biop-tools/blob/832351fd5d134ef60974c9d9d96691a97c215cca/src/main/java/bdv/util/ImagePlusHelper.java#L83

https://github.com/BIOP/bigdataviewer-biop-tools/blob/832351fd5d134ef60974c9d9d96691a97c215cca/src/main/java/bdv/util/ImagePlusHelper.java#L124

The full matrix is stored in the info field of the ImagePlus

This can probably be improved by using gson however. I didn't know how to use it at the time

[tischi]

The full matrix is stored in the info field of the ImagePlus

Yes, but this matrix is not used by the ImagePlus viewer while the imp.getCalibration().offset is actually used. See above screenshot where the upper left corner is now at a negative coordinate in the ImagePlus viewer!

[NicoKiaru]

Ok, it's just that this setOrigin would be better inside ImagePlus helper.

It's true that I removed the offset because I noticed an issue when the offset is zero:

https://github.com/BIOP/bigdataviewer-biop-tools/blob/832351fd5d134ef60974c9d9d96691a97c215cca/src/main/java/bdv/util/ImagePlusHelper.java#L102-L104

With your method there are 2 incompatible ways to store the transform. I also deal with the origin but it apparently doesn't fit your use case. So we need to figure this.

[tischi]

Ok, it's just that this setOrigin would be better inside ImagePlus helper.

I totally agree!

It's true that I removed the offset because I noticed an issue when the offset is zero:

Could you explain the issue? From what you said it feels like we can probably just add a if ( offset != zero ){ change calibration offset }?!

[tischi]

@NicoKiaru I tried the following:

            imageplus.getCalibration().xOrigin = 1;
            imageplus.getCalibration().yOrigin = 1;
            imageplus.getCalibration().zOrigin = 1;
            imageplus.getCalibration().xOrigin = 0;
            imageplus.getCalibration().yOrigin = 0;
            imageplus.getCalibration().zOrigin = 0;

And it in fact does set it back to zero; so I don't see an issue with the zero offset case. [EDIT: I realized that this was a stupid test that should of course work 😄 , so I am back to the question where you had your issues with that...]

Would it be OK for you if I added a pixelOffset( double[3] ) field to the ImagePlusSampler.Builder()?

Then one can still decide whether to use is or not, e.g. by adding a checkbox in the respective Commands.

With your method there are 2 incompatible ways to store the transform. I also deal with the origin but it apparently doesn't fit your use case.

Could you explain this? You are storing the full affine transform in the ImagePlus info, isn't it? Does this also contain information about the voxel size (if so, then already this information would be stored twice in the image...)? And could this also contain rotations and other information that cannot be captured by the normal calibration information in the ImagePlus?

[NicoKiaru]

Now I remember that the x,y,z Origin are supposed to be in pixels (https://imagej.nih.gov/ij/developer/api/ij/ij/measure/Calibration.html#xOrigin)

I guess that it's used to copy and paste a ROI from one ImagePlus to another. But if you want to store physical coordinates, then this doesn't make a lot of sense.

But ok, I saw your code and this could work in some cases. So let's try.

[NicoKiaru]

I modified spimdata-extra, I'll cut a release, and I think this will work, no modification in this repo needed anymore.

[tischi]

Now I remember that the x,y,z Origin are supposed to be in pixels

Yes, but when you hover with the mouse over the ImagePlus it'll show you the pixel origin multiplied with the calibration; so you'll actually see the correct physical coordinates (at least that I think I got when I tested it last week). In other words, in order for this to work as intended would actually need to store the origin in pixel units. Is that what you did in spimdata-extra (thanks a lot by the way ❤️ )?

[NicoKiaru]

Yes. If you activate the abba experimental update site that will work. Fyi I switched all repos to github actions and because of some adjustements the version numbers have increased. Check on maven and let me know if there s an issue with the updates.

Regarding this issue, with the modification in spimdata extras, everything should be alright, but let me know if that s not the case.

[NicoKiaru]

fixed in spimdata extras