Suspicious change of origin

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Suspicious change of origin

Panagiotis Foteinos
Hello Slicers.

I am creating an itkImage with ITK of origin (0.2, 0.2, 0.2) and I
save it to the disk. Before I save it to the disk, I verify that the
origin is the correct, i,e, (0.2, 0.2, 0.2).

However, when I load the image to Slicer, the origin (under Info)
becomes (0.2, 0.2, -0.2) which is scary.  I am assuming that this is a
direction issue, but since I did not have to specify any direction
when I initially created the image in ITK, why would I have to specify
it in Slicer. Is this a bug in Slicer?


Best,
Panagiotis Foteinos
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: Suspicious change of origin

Julien Finet
Hi Panagiotis,

Thanks for your report,
Julien.

On Wed, Jun 6, 2012 at 1:06 PM, Panagiotis Foteinos <[hidden email]> wrote:
Hello Slicers.

I am creating an itkImage with ITK of origin (0.2, 0.2, 0.2) and I
save it to the disk. Before I save it to the disk, I verify that the
origin is the correct, i,e, (0.2, 0.2, 0.2).

However, when I load the image to Slicer, the origin (under Info)
becomes (0.2, 0.2, -0.2) which is scary.  I am assuming that this is a
direction issue, but since I did not have to specify any direction
when I initially created the image in ITK, why would I have to specify
it in Slicer. Is this a bug in Slicer?


Best,
Panagiotis Foteinos
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject


_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: Suspicious change of origin

Murat Maga
In reply to this post by Panagiotis Foteinos
Hi Panagiotis

I don't know if this related to your issue, but I noticed when an nrrd file
is resaved in Slicer, it changes the coordinate system from RAS to LPS in
the saved volume. In my case I have created a detached nhrd header that
loads a raw volume with explicitly specified in RAS space with space
directions (1,0,0) (0, 1, 0) (0,0,1). When I save the volume in slicer, it
compresses it and updates the header with LPS space and space directions
with (-1,0,0) (-1,0,0) (1,0,0). Perhaps you have a similar issue, although
it did not alter the origin in my dataset.

M



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Panagiotis
Foteinos
Sent: Wednesday, June 06, 2012 10:07 AM
To: [hidden email]
Subject: [slicer-users] Suspicious change of origin

Hello Slicers.

I am creating an itkImage with ITK of origin (0.2, 0.2, 0.2) and I save it
to the disk. Before I save it to the disk, I verify that the origin is the
correct, i,e, (0.2, 0.2, 0.2).

However, when I load the image to Slicer, the origin (under Info) becomes
(0.2, 0.2, -0.2) which is scary.  I am assuming that this is a direction
issue, but since I did not have to specify any direction when I initially
created the image in ITK, why would I have to specify it in Slicer. Is this
a bug in Slicer?


Best,
Panagiotis Foteinos
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email]
with unsubscribe as the subject


_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: Suspicious change of origin

Julien Finet
Yes origin and spacing are currently broken.
j.

On Wed, Jun 6, 2012 at 1:34 PM, Murat Maga <[hidden email]> wrote:
Hi Panagiotis

I don't know if this related to your issue, but I noticed when an nrrd file
is resaved in Slicer, it changes the coordinate system from RAS to LPS in
the saved volume. In my case I have created a detached nhrd header that
loads a raw volume with explicitly specified in RAS space with space
directions (1,0,0) (0, 1, 0) (0,0,1). When I save the volume in slicer, it
compresses it and updates the header with LPS space and space directions
with (-1,0,0) (-1,0,0) (1,0,0). Perhaps you have a similar issue, although
it did not alter the origin in my dataset.

M



-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Panagiotis
Foteinos
Sent: Wednesday, June 06, 2012 10:07 AM
To: [hidden email]
Subject: [slicer-users] Suspicious change of origin

Hello Slicers.

I am creating an itkImage with ITK of origin (0.2, 0.2, 0.2) and I save it
to the disk. Before I save it to the disk, I verify that the origin is the
correct, i,e, (0.2, 0.2, 0.2).

However, when I load the image to Slicer, the origin (under Info) becomes
(0.2, 0.2, -0.2) which is scary.  I am assuming that this is a direction
issue, but since I did not have to specify any direction when I initially
created the image in ITK, why would I have to specify it in Slicer. Is this
a bug in Slicer?


Best,
Panagiotis Foteinos
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email]
with unsubscribe as the subject


_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject


_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: Suspicious change of origin

Panagiotis Foteinos
Hello all.

I observed this inconsistency with ITK's native image format (mha) and
.nii format. Both Slicer-3.4  and Slicer-4.0.1 have the same problem.

Panagiotis

On Wed, Jun 6, 2012 at 2:09 PM, Julien Finet <[hidden email]> wrote:

> Yes origin and spacing are currently broken.
> j.
>
>
> On Wed, Jun 6, 2012 at 1:34 PM, Murat Maga <[hidden email]> wrote:
>>
>> Hi Panagiotis
>>
>> I don't know if this related to your issue, but I noticed when an nrrd
>> file
>> is resaved in Slicer, it changes the coordinate system from RAS to LPS in
>> the saved volume. In my case I have created a detached nhrd header that
>> loads a raw volume with explicitly specified in RAS space with space
>> directions (1,0,0) (0, 1, 0) (0,0,1). When I save the volume in slicer, it
>> compresses it and updates the header with LPS space and space directions
>> with (-1,0,0) (-1,0,0) (1,0,0). Perhaps you have a similar issue, although
>> it did not alter the origin in my dataset.
>>
>> M
>>
>>
>>
>> -----Original Message-----
>> From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Panagiotis
>> Foteinos
>> Sent: Wednesday, June 06, 2012 10:07 AM
>> To: [hidden email]
>> Subject: [slicer-users] Suspicious change of origin
>>
>> Hello Slicers.
>>
>> I am creating an itkImage with ITK of origin (0.2, 0.2, 0.2) and I save it
>> to the disk. Before I save it to the disk, I verify that the origin is the
>> correct, i,e, (0.2, 0.2, 0.2).
>>
>> However, when I load the image to Slicer, the origin (under Info) becomes
>> (0.2, 0.2, -0.2) which is scary.  I am assuming that this is a direction
>> issue, but since I did not have to specify any direction when I initially
>> created the image in ITK, why would I have to specify it in Slicer. Is
>> this
>> a bug in Slicer?
>>
>>
>> Best,
>> Panagiotis Foteinos
>> _______________________________________________
>> slicer-users mailing list
>> [hidden email]
>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
>> To unsubscribe: send email to
>> [hidden email]
>> with unsubscribe as the subject
>>
>>
>> _______________________________________________
>> slicer-users mailing list
>> [hidden email]
>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
>> To unsubscribe: send email to
>> [hidden email] with unsubscribe as the
>> subject
>
>
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: Suspicious change of origin

Jim Miller
In reply to this post by Panagiotis Foteinos
I believe this is the expected behavior of Slicer. It is a tricky issue.

Slicer uses a RAS coordinate system.  When data is loaded into Slicer, the coordinate system of the data is modified to be RAS.

When Slicer writes out data, the writers write out the data into ITK's coordinate system, which is LPS.

So if you load data into Slicer and then write it back out, the coordinate system and the associated origin and direction cosines will be modified. 

Note that the image will still sit in the same physical position. If you were to load the data back in, it should be appear in the same spot in the world as it was originally.  But if you use tools outside of Slicer that ignore the direction cosines and origin, this could cause an issue.

We have no current facility in Slicer to track the "original coordinate system" of data.  One could argue that if an image is loaded and then saved, it should be written in the coordinate system of the original data.

But that is not a real use case.  What really would happen is that you load data, run some operation on the data, and then write a new image.  In this case, what coordinate system should one write out the data?  You could track all the operations applied while in Slicer so that you would know the original coordinate system and use that.  But what if an operation to generate the data is based on two datasets that had different original coordinate systems? What coordinate system should be used for output? 

Should ever convince ourselves to tackle the provenance issue, we may be able to improve on how we handle this situation.

Jim


On Wed, Jun 6, 2012 at 1:06 PM, Panagiotis Foteinos <[hidden email]> wrote:
Hello Slicers.

I am creating an itkImage with ITK of origin (0.2, 0.2, 0.2) and I
save it to the disk. Before I save it to the disk, I verify that the
origin is the correct, i,e, (0.2, 0.2, 0.2).

However, when I load the image to Slicer, the origin (under Info)
becomes (0.2, 0.2, -0.2) which is scary.  I am assuming that this is a
direction issue, but since I did not have to specify any direction
when I initially created the image in ITK, why would I have to specify
it in Slicer. Is this a bug in Slicer?


Best,
Panagiotis Foteinos
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject


_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: Suspicious change of origin

Panagiotis Foteinos
Hello Jim.

My understanding is that any software should respect and comply with
the initial format given. Because, as you pointed out, if I am to use
both the original data and the output data I will run into issues.
Considering the fact that the output is a part of a much larger
pipeline, where outside-Slicer code is involved and maintained by many
people, this reality can cause hard to detect problems. Let alone that
tracking the changes that Slicer made is counter productive.

When it comes to your argument regarding the user giving 2 input
images of different coordinate system, well, this is not a valid use
case in my opinion. It is a misuse and a user's fault.

Best,
Panagiotis

On Wed, Jun 6, 2012 at 3:22 PM, Jim Miller <[hidden email]> wrote:

> I believe this is the expected behavior of Slicer. It is a tricky issue.
>
> Slicer uses a RAS coordinate system.  When data is loaded into Slicer, the
> coordinate system of the data is modified to be RAS.
>
> When Slicer writes out data, the writers write out the data into ITK's
> coordinate system, which is LPS.
>
> So if you load data into Slicer and then write it back out, the coordinate
> system and the associated origin and direction cosines will be modified.
>
> Note that the image will still sit in the same physical position. If you
> were to load the data back in, it should be appear in the same spot in the
> world as it was originally.  But if you use tools outside of Slicer that
> ignore the direction cosines and origin, this could cause an issue.
>
> We have no current facility in Slicer to track the "original coordinate
> system" of data.  One could argue that if an image is loaded and then saved,
> it should be written in the coordinate system of the original data.
>
> But that is not a real use case.  What really would happen is that you load
> data, run some operation on the data, and then write a new image.  In this
> case, what coordinate system should one write out the data?  You could track
> all the operations applied while in Slicer so that you would know the
> original coordinate system and use that.  But what if an operation to
> generate the data is based on two datasets that had different original
> coordinate systems? What coordinate system should be used for output?
>
> Should ever convince ourselves to tackle the provenance issue, we may be
> able to improve on how we handle this situation.
>
> Jim
>
>
> On Wed, Jun 6, 2012 at 1:06 PM, Panagiotis Foteinos <[hidden email]>
> wrote:
>>
>> Hello Slicers.
>>
>> I am creating an itkImage with ITK of origin (0.2, 0.2, 0.2) and I
>> save it to the disk. Before I save it to the disk, I verify that the
>> origin is the correct, i,e, (0.2, 0.2, 0.2).
>>
>> However, when I load the image to Slicer, the origin (under Info)
>> becomes (0.2, 0.2, -0.2) which is scary.  I am assuming that this is a
>> direction issue, but since I did not have to specify any direction
>> when I initially created the image in ITK, why would I have to specify
>> it in Slicer. Is this a bug in Slicer?
>>
>>
>> Best,
>> Panagiotis Foteinos
>> _______________________________________________
>> slicer-users mailing list
>> [hidden email]
>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
>> To unsubscribe: send email to
>> [hidden email] with unsubscribe as the
>> subject
>
>
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: Suspicious change of origin

Andrey Fedorov
Panagiotis,

I understand your frustration, but as Jim pointed out in his response

> Note that the image will still sit in the same physical position. If you
> were to load the data back in, it should be appear in the same spot in the
> world as it was originally.  But if you use tools outside of Slicer that
> ignore the direction cosines and origin, this could cause an issue.
>

So perhaps you could consider that the issue you are observing could
be due to your outside-Slicer code using image IO tools that ignore
the direction cosines and origin as specified in the image file saved
by Slicer.

AF


On Wed, Jun 6, 2012 at 4:26 PM, Panagiotis Foteinos <[hidden email]> wrote:

> Hello Jim.
>
> My understanding is that any software should respect and comply with
> the initial format given. Because, as you pointed out, if I am to use
> both the original data and the output data I will run into issues.
> Considering the fact that the output is a part of a much larger
> pipeline, where outside-Slicer code is involved and maintained by many
> people, this reality can cause hard to detect problems. Let alone that
> tracking the changes that Slicer made is counter productive.
>
> When it comes to your argument regarding the user giving 2 input
> images of different coordinate system, well, this is not a valid use
> case in my opinion. It is a misuse and a user's fault.
>
> Best,
> Panagiotis
>
> On Wed, Jun 6, 2012 at 3:22 PM, Jim Miller <[hidden email]> wrote:
>> I believe this is the expected behavior of Slicer. It is a tricky issue.
>>
>> Slicer uses a RAS coordinate system.  When data is loaded into Slicer, the
>> coordinate system of the data is modified to be RAS.
>>
>> When Slicer writes out data, the writers write out the data into ITK's
>> coordinate system, which is LPS.
>>
>> So if you load data into Slicer and then write it back out, the coordinate
>> system and the associated origin and direction cosines will be modified.
>>
>> Note that the image will still sit in the same physical position. If you
>> were to load the data back in, it should be appear in the same spot in the
>> world as it was originally.  But if you use tools outside of Slicer that
>> ignore the direction cosines and origin, this could cause an issue.
>>
>> We have no current facility in Slicer to track the "original coordinate
>> system" of data.  One could argue that if an image is loaded and then saved,
>> it should be written in the coordinate system of the original data.
>>
>> But that is not a real use case.  What really would happen is that you load
>> data, run some operation on the data, and then write a new image.  In this
>> case, what coordinate system should one write out the data?  You could track
>> all the operations applied while in Slicer so that you would know the
>> original coordinate system and use that.  But what if an operation to
>> generate the data is based on two datasets that had different original
>> coordinate systems? What coordinate system should be used for output?
>>
>> Should ever convince ourselves to tackle the provenance issue, we may be
>> able to improve on how we handle this situation.
>>
>> Jim
>>
>>
>> On Wed, Jun 6, 2012 at 1:06 PM, Panagiotis Foteinos <[hidden email]>
>> wrote:
>>>
>>> Hello Slicers.
>>>
>>> I am creating an itkImage with ITK of origin (0.2, 0.2, 0.2) and I
>>> save it to the disk. Before I save it to the disk, I verify that the
>>> origin is the correct, i,e, (0.2, 0.2, 0.2).
>>>
>>> However, when I load the image to Slicer, the origin (under Info)
>>> becomes (0.2, 0.2, -0.2) which is scary.  I am assuming that this is a
>>> direction issue, but since I did not have to specify any direction
>>> when I initially created the image in ITK, why would I have to specify
>>> it in Slicer. Is this a bug in Slicer?
>>>
>>>
>>> Best,
>>> Panagiotis Foteinos
>>> _______________________________________________
>>> slicer-users mailing list
>>> [hidden email]
>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
>>> To unsubscribe: send email to
>>> [hidden email] with unsubscribe as the
>>> subject
>>
>>
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to [hidden email] with unsubscribe as the subject
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject
Reply | Threaded
Open this post in threaded view
|

Re: Suspicious change of origin

Andras Lasso
Panagiotis,

If a file format allows the definition of the origin, spacing, and direction cosines in different orientations (RAS, LPS, etc.) then there are multiple valid representations to store the same information. The software that writes the file can choose any representation. The software that reads the file must be able to deal with any valid representations.

Nevertheless, there is indeed a bug in Slicer when reading/writing metafiles (MHA and MHD images): the image orientation (AnatomicalOrientation) tag is ignored. See more details in http://www.na-mic.org/Bug/view.php?id=2173.

Andras


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Andriy Fedorov
Sent: Wednesday, June 06, 2012 4:34 PM
To: Panagiotis Foteinos
Cc: [hidden email]
Subject: Re: [slicer-users] Suspicious change of origin

Panagiotis,

I understand your frustration, but as Jim pointed out in his response

> Note that the image will still sit in the same physical position. If
> you were to load the data back in, it should be appear in the same
> spot in the world as it was originally.  But if you use tools outside
> of Slicer that ignore the direction cosines and origin, this could cause an issue.
>

So perhaps you could consider that the issue you are observing could be due to your outside-Slicer code using image IO tools that ignore the direction cosines and origin as specified in the image file saved by Slicer.

AF


On Wed, Jun 6, 2012 at 4:26 PM, Panagiotis Foteinos <[hidden email]> wrote:

> Hello Jim.
>
> My understanding is that any software should respect and comply with
> the initial format given. Because, as you pointed out, if I am to use
> both the original data and the output data I will run into issues.
> Considering the fact that the output is a part of a much larger
> pipeline, where outside-Slicer code is involved and maintained by many
> people, this reality can cause hard to detect problems. Let alone that
> tracking the changes that Slicer made is counter productive.
>
> When it comes to your argument regarding the user giving 2 input
> images of different coordinate system, well, this is not a valid use
> case in my opinion. It is a misuse and a user's fault.
>
> Best,
> Panagiotis
>
> On Wed, Jun 6, 2012 at 3:22 PM, Jim Miller <[hidden email]> wrote:
>> I believe this is the expected behavior of Slicer. It is a tricky issue.
>>
>> Slicer uses a RAS coordinate system.  When data is loaded into
>> Slicer, the coordinate system of the data is modified to be RAS.
>>
>> When Slicer writes out data, the writers write out the data into
>> ITK's coordinate system, which is LPS.
>>
>> So if you load data into Slicer and then write it back out, the
>> coordinate system and the associated origin and direction cosines will be modified.
>>
>> Note that the image will still sit in the same physical position. If
>> you were to load the data back in, it should be appear in the same
>> spot in the world as it was originally.  But if you use tools outside
>> of Slicer that ignore the direction cosines and origin, this could cause an issue.
>>
>> We have no current facility in Slicer to track the "original
>> coordinate system" of data.  One could argue that if an image is
>> loaded and then saved, it should be written in the coordinate system of the original data.
>>
>> But that is not a real use case.  What really would happen is that
>> you load data, run some operation on the data, and then write a new
>> image.  In this case, what coordinate system should one write out the
>> data?  You could track all the operations applied while in Slicer so
>> that you would know the original coordinate system and use that.  But
>> what if an operation to generate the data is based on two datasets
>> that had different original coordinate systems? What coordinate system should be used for output?
>>
>> Should ever convince ourselves to tackle the provenance issue, we may
>> be able to improve on how we handle this situation.
>>
>> Jim
>>
>>
>> On Wed, Jun 6, 2012 at 1:06 PM, Panagiotis Foteinos
>> <[hidden email]>
>> wrote:
>>>
>>> Hello Slicers.
>>>
>>> I am creating an itkImage with ITK of origin (0.2, 0.2, 0.2) and I
>>> save it to the disk. Before I save it to the disk, I verify that the
>>> origin is the correct, i,e, (0.2, 0.2, 0.2).
>>>
>>> However, when I load the image to Slicer, the origin (under Info)
>>> becomes (0.2, 0.2, -0.2) which is scary.  I am assuming that this is
>>> a direction issue, but since I did not have to specify any direction
>>> when I initially created the image in ITK, why would I have to
>>> specify it in Slicer. Is this a bug in Slicer?
>>>
>>>
>>> Best,
>>> Panagiotis Foteinos
>>> _______________________________________________
>>> slicer-users mailing list
>>> [hidden email]
>>> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
>>> To unsubscribe: send email to
>>> [hidden email] with unsubscribe as
>>> the subject
>>
>>
> _______________________________________________
> slicer-users mailing list
> [hidden email]
> http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
> To unsubscribe: send email to
> [hidden email] with unsubscribe as the
> subject
_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject


_______________________________________________
slicer-users mailing list
[hidden email]
http://massmail.spl.harvard.edu/mailman/listinfo/slicer-users
To unsubscribe: send email to [hidden email] with unsubscribe as the subject