# TransformContinuousIndexToPhysicalPoint got a different result
**URL:** https://discourse.itk.org/t/transformcontinuousindextophysicalpoint-got-a-different-result/5885
**Category:** Uncategorized
**Created:** [April 21, 2023, 3:53am UTC](https://discourse.itk.org/t/transformcontinuousindextophysicalpoint-got-a-different-result/5885 "2023-04-21T03:53:37Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@ljjiayou](https://discourse.itk.org/u/ljjiayou)
#### Post date: [April 21, 2023, 3:53am UTC](https://discourse.itk.org/t/transformcontinuousindextophysicalpoint-got-a-different-result/5885/1 "2023-04-21T03:53:37Z")
I took this line of code directly and got a different result than the world coordinates I saw in ITKsnap. Same image and index. why?
this is my code :
TransformContinuousIndexToPhysicalPoint
---
### Author:  [@zivy](https://discourse.itk.org/u/zivy)
#### Post date: [April 21, 2023, 12:56pm UTC](https://discourse.itk.org/t/transformcontinuousindextophysicalpoint-got-a-different-result/5885/2 "2023-04-21T12:56:00Z")
Hello @ljjiayou,
Your description of the problem does not include enough details to help with solving the issue. For others to provide you with useful help, you need to clearly describe the problem in sufficient detail so that it can be reproduced.
With respect to this specific question: What is the input and output of `TransformContinousIndexToPhyscialPoint`? What are the values you see in ITK-SNAP? Are you using ITK/SimpleITK, is this in C++/Python/…
---
### Author:  [@ljjiayou](https://discourse.itk.org/u/ljjiayou)
#### Post date: [April 21, 2023, 1:42pm UTC](https://discourse.itk.org/t/transformcontinuousindextophysicalpoint-got-a-different-result/5885/3 "2023-04-21T13:42:20Z")
I use this line of code in SimpleITK:
im.TransformIndexToPhyscialPoint(index)
result is (50.50642905673479, -7.472207900751755, -14.345941839162478)
In itksnap, when I look at the image, click Info, and the same index gives me different world units than I get with the code. the world units is (53.4, -9.217,-14.07) why?
---
### Author:  [@ljjiayou](https://discourse.itk.org/u/ljjiayou)
#### Post date: [April 21, 2023, 1:50pm UTC](https://discourse.itk.org/t/transformcontinuousindextophysicalpoint-got-a-different-result/5885/4 "2023-04-21T13:50:33Z")
@zivy I changed the direction of the image from ASL to LPI, but I need to determine the new index of the same anatomical position after the change, which is convenient for me to crop the image. The world units of the image before and after the change do not change, so I want to determine it according to the conversion from point to index.
---
### Author:  [@lassoan](https://discourse.itk.org/u/lassoan)
#### Post date: [April 21, 2023, 8:08pm UTC](https://discourse.itk.org/t/transformcontinuousindextophysicalpoint-got-a-different-result/5885/5 "2023-04-21T20:08:40Z")
To avoid reshuffling voxels in the memory, applications often use the same memory layout as in the file and so IJK coordinate system in the file is the same as in the application. However, in general, applications are free to choose the IJK coordinate system, as long as each voxel is mapped to the same physical location as in the image file. For example, if an image file happens to use a left-handed coordinate system for IJK then the application may choose to reorder the slices to get a right-handed coordinate system.
If you see only small errors then the difference might be due to having a non-Cartesian volume (tilted-gantry acquisition, slightly non-orthogonal axes, etc.).
Finally, if your image file is in NIFTI format then all bets are off. There is a lot of ambiguity around how to interpret image orientation in NIFTI files, so if you use this format then for some images you’ll get different coordinate mapping in different software. To avoid such issues, you can use the much better specified NRRD file format instead.
To investigate this further, you can also load the image into 3D Slicer and inspect the coordinates there. You can also save the file in NRRD format and inspect the IJK to LPS mapping directly (stored in the image header in the `space origin` and `space directions` fields in human-readable text format).