Open 98zhenyu opened 3 months ago
I have found the key to the problem and recommend that you use sitk
when reading ref and get spcing
, origin
, direction
, etc., otherwise there will be problems in the coordinate conversion.
I have found the key to the problem and recommend that you use
sitk
when reading ref and getspcing
,origin
,direction
, etc., otherwise there will be problems in the coordinate conversion.
Hi 98zhenyu, sorry for the late reply. I'm gonna implement what you say, and get back to you. Best, Vicent
Hi @98zhenyu, I've made changes implementing what you've mentioned, could you try out wether the issue is fixed?
You still have two problems with your code. First, you need to set ref_origin = refnii.getorigin ()
instead of(0,0,0)
to align with ref.nii
's coordinate system.
In addition, there is no need to rotate the label_array
, becausesitk
reads the nii to preserve the original coordinate system, so you only need to save the relevant parameters origin,spacing,direction
the same as ref
when saving label.nii
by sitk
.
According to the above changes in my data performance is good, I hope it can help you!
Hi 98zhenyu
,
I had initially tried what you comment, since it's the logical way, but it generates empty masks in my case. Furthermore, on lines 91 to 100, when I load the nifti file again to rotate it, I set the origin to refnii.getorigin ()
as you mention. But to generate the initial nifti file with pol2stenc
, I need to set the origin to (0, 0, 0)
.
Best, Vicent
The situation you mentioned is very interesting. Logically, if you create stl and ref.nii
in the same coordinate system, then your origin
should not be set to (0,0,0), but should be the same as ref.nii.
In what coordinate system do you create the stl
file? There is origin displacement between the ref.nii
file coordinate system and the world coordinate system.
In addition, the python plug-in of 3D slicer
can also implement the functions of stl2nii
. I compared the results of my modified code with slicer
, and the two are consistent. I think the key is whether thestl
andref.nii
files use the same coordinate system, otherwise the origin
and the direction
is not consistent, which explains why you need to do the extra rotation.
Or maybe I got it wrong, but so far my data format conversion is working!
Hi 98zhenyu
,
Thanks for your reply. The thing is, I have no idea how my stl files are generated, since I don't do it. What I'm gathering is that, there is something in my stl file generation that messes up the conversion process which, as you say, should be pretty straightforward, just matching the reference nifti file properties.
Since it's pretty clear that it's my use case that is weird here, I'll implement a flag to activate the weird behavior, and leave the default code as you suggest. Please, since I'm a novice at coding, if you could help me validate that the behavior as you've been doing until now, I would greatly appreciate it. I'll implement what I'm talking about ASAP.
Best, Vicent
I've only made simple changes to your initial code. It is worth noting that I did not use rotate_stl
, I hope it can help you!
HI @98zhenyu , I think I've implemented the changes that you have pointed out in the last two commits, but thank you for your suggestions.
Best, Vicent
Nice work! But when I try to use your
_main_.py
to convert my .stl file to .nii,the result .nii is all empty. Could you help me see what the problem is? I have sent the corresponding documents to your email, I hope you can try it in your busy schedule.