CamiTK Community Edition issueshttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues2023-07-28T14:58:20+02:00https://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/152MHA/MHD orientation convention combined with rotation/translation2023-07-28T14:58:20+02:00Manik BhattacharjeeMHA/MHD orientation convention combined with rotation/translation## About you
CamiTK developer
## Overview
This issue is a follow-up of issue #66
When loading and writing MHA/MHD files, geometrical transformations are applied in this order:
- transform to RAI convention
- rotation
- translation
Unf...## About you
CamiTK developer
## Overview
This issue is a follow-up of issue #66
When loading and writing MHA/MHD files, geometrical transformations are applied in this order:
- transform to RAI convention
- rotation
- translation
Unfortunately it means that we apply the rotation and translation specified in the header after changing the convention to RAI (CamiTK convention). But those rotation and translation were probably defined in the convention specified in the header file (e.g. RSA). In that case it means we apply the rotation and translation to the wrong axes.
## Steps to Reproduce
Need sample files in conventions other than RAI to be able to test this.
Finding out which software (3D Slicer ?) uses a different convention to compare how the transform is read/saved in another convention would be useful.
## Actual VS Expected Result
- The transform matrix loaded in a RSA file is saved in an RAI file with the exact same values, even though the axes are not the same
- Loading an image in RSA convention with a translation of (0,1,2) should be saved in RAI with a different translation (1 for axis S-I, 2 for axis A-P)
## Interpretation & Possible fixes
MHA/MHD MetaImage file format specs are not very precise on this issue. But I believe that rotation and translation are defined according to the specified orientation convention, and not an arbitrary one (RAI for CamiTK).
[A thread from 3D slicer](https://discourse.slicer.org/t/bug-when-reading-mha-file-with-anatomicalorientation/7038/7) about how ITK does not use this information correctly and how VTK should manage the issue:
It refers to a [merge request to solve it in VTK that was not merged](https://gitlab.kitware.com/vtk/vtk/-/merge_requests/5656) because it breaks a lot of tests, but the discussion is interesting. [In ITK, it was decided to ignore cases where ITK reader fails](https://github.com/InsightSoftwareConsortium/ITK/issues/1017) because they focus on other image formats.
After reading this we should take our own decision in how to interact with this format.
I suggest:
- read the orientation
- consider the image is encoded in that orientation
- consider the matrix is expressed in the specified orientation and use it accordingly
For the write part, multiple choices:
- we save in any orientation we want (e.g. RAI, current way), specify it in the header, and write the matrix accordingly. The most logical way !
- we save in LPS (used by ITK and other software for MetaImage format), increasing compatibility with other software. We specify the orientation and the matrix in LPS. This would be ok but, there is a problem: it seems that most software just ignore orientation when they read, but use the matrix in their own orientation without adapting it (e.g. 3D Slicer loads the image as LPS, converts to RAS, and considers the matrix as being in RAS...)
## CamiTK Version
CamiTK 5.1.dev.develop.c3d59664
---
**please do not remove anything below this line**Manik BhattacharjeeManik Bhattacharjeehttps://gricad-gitlab.univ-grenoble-alpes.fr/CamiTK/CamiTK/-/issues/65Unexpected image behaviors in Viewers2023-05-15T15:59:39+02:00Emmanuel PromayonUnexpected image behaviors in Viewers## About you
Bug filed on Bugzilla by @jaffarda on 2016-04-22
## Overview:
> when looking at an image in 2D viewer (axial for exemple)
> - pb1/ border voxels are only half-sized (both in 2D and in 3D)
> - pb2/ border...## About you
Bug filed on Bugzilla by @jaffarda on 2016-04-22
## Overview:
> when looking at an image in 2D viewer (axial for exemple)
> - pb1/ border voxels are only half-sized (both in 2D and in 3D)
> - pb2/ border box does not adjust to displayed image
> - pb3/ picking is not possible a all places inside pixels
> - pb4/ picking is possible outside the image
> - pb5/ picking actor (crossing bars are not always visible)
> attached images are very small in number of voxels for a better view
> provided:
> - testImage.bmp (the expected visble result)
> - testData.raw (raw file for 2D images)
> - testData3D.raw (raw file for 3D image)
> - test1.mhd ( image 5x5x1 black & white grid, spacing 10x10x1)
> - test2.mhd ( image 5x5x1 black & white grid, spacing 1x1x1)
> - test_3D.mhd ( image 5x5x5 black & white grid, spacing 1x1x1)
[testImages.zip](/uploads/dbdae0b5992f6f646f9f890d03bd277e/testImages.zip)
## Steps to Reproduce
> - step 1/ Load test1.mhd in camitk
> - step 2/ click on centralViewer and press I (to toogle off image interpolation)
> - step 3/ open axial viewer (ctrl + 2)
> - step 4/ Pick a point (ctrl + click) close to the middle of a pixel
> - step 5/ Pick a point (ctrl + click) close to the border of a pixel
> - step 6/ Pick a point (ctrl + click) close to the middle of a pixel but on the outside of the displayed image
> - step 7/ Load test2.mhd, open axial viewer, toogle off interpolation
> - step 8/ Pick a point (ctrl + click) close to the middle of a pixel
## Actual VS Expected Result
> - at step 2/ we see pb1 all the pixels are not the same size but they should
> - at step 3/ we see pb1 all the pixels are not the same size but they should
> - at step 3/ we see pb2 the border does not match the image but should
> - at step 5/ we see pb3 picking works close to centre of pixel but nowhere else
> picking should be available everwhere
> - at step 6/ we see pb4 it is possible to pick a point outside the image,
> it should not
> - at step 8/ we see pb5 when picking works (see with pb3) the actor (small lines) are not visible, it should
## Relevant logs and/or screenshots:
See [testImages.zip](/uploads/dbdae0b5992f6f646f9f890d03bd277e/testImages.zip)
## Interpretation & Possible fixes:
> - pb1/ maybe miss set of dimensions?
> - pb2/ probably linked to pb1 the boxing seems to be the good size if pixels were correctly displayed
> - pb3/ maybe bad use of pixel size?
> - pb4/ probably linked to pb1 the selection box should be in pixel if pb1
> - pb5/ no ideas
## CamiTK Version:
Filed for CamiTK 3.6, but confirmed still on 4.1.develop