<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">Hi Andreas,<br><br>it seems to me that the problems you indicate are related to the question: what is the co-ordinate of a pixel?<br>The way I see it, a pixel has no co-ordinate (but it has an area).<br>I could rephrase your step1 one as follows:<br><br>1. For 
the 
given 
output 
index, calculate the co-ordinate &gt;at the center&lt; of the corresponding output pixel.<br><br>Ideally, this should be performed by a helper function: IndexToPhysicalCoordinateAtPixelCenter(). Note that the output of this function depends on whether you have the origin of the image at the bottom left or center of a pixel. For a 'bottom-left' representation, the function IndexToPhysicalCoordinateAtPixelCenter(0) would return 0.5 * imageSpacing, whereas for a 'center' representation, it would be zero.<br>However, the writer of the resample algorithm will not be concerned with this, because in both cases&nbsp; IndexToPhysicalCoordinateAtPixelCenter() will return the co-ordinate at the center of the pixel, and the algorithm will perform correctly.<br><br>Best regards, and looking forward to your replies too,<br>Maarten<br><br><br><div style="font-family: times new roman,new york,times,serif; font-size: 12pt;">----- Original Message ----<br>From: Andreas
 Keil &lt;andreas.keil@cs.tum.edu&gt;<br>To: insight-users@itk.org<br>Sent: Tuesday, January 29, 2008 6:16:31 PM<br>Subject: RE: [Insight-users] ITK Image Coordinates / Problem withPhysicalPoint to Index Conversion<br><br>
Dear 
all,<br><br>let 
me 
elaborate 
why 

am 
voting 
for 

center-based 
coordinate 
system:<br><br>Let's 
consider 
the 
simple 
example 
of 
resampling 
an 
image. 
The 
resample<br>filter 
does 
the 
following 
for 
every 
output 
pixel:<br>1) 
Calculate 
the 
physical 
coordinate 
for 
the 
given 
output 
index.<br>2) 
Transform 
the 
physical 
coordinate 
by 
the 
given 
transform.<br>3) 
Calculate 
the 
continuous 
index 
for 
the 
transformed 
physical 
point.<br>4) 
Linearly 
interpolate 
the 
input 
value 
at 
the 
continuous 
index 
and<br>&nbsp; 
 
write 
it 
to 
the 
output.<br><br>Now, 
think 
about 
this 
process 
with 
corner-based 
coordinated:<br>1) 
Would 
work 
fine.<br>2) 
Transforms 
are 
there 
for 
converting 
physical 
coordinates. 
Giving 
them<br>&nbsp; 
 
corner 
coordinates 
would, 
of 
course, 
work, 
too. 
However, 
the<br>&nbsp; 
 
interpolation 
in 
step 

is 
done 
based 
on 

single 
point 
representing<br>&nbsp; 
 
the 
whole 
pixel. 
In 
general, 
we 
don't 
have 
an 
idea 
on 
how 
the 
box 
of<br>&nbsp; 
 

pixel 
is 
transformed. 
We 
can 
just 
pass 

single 
coordinate 
through <br>&nbsp; 
 
through 
to 
the 
interpolator. 
Keep 
this 
in 
mind 
for 
now.<br>3) 
Works 
fine.<br>4) 
Now 
we 
have 

problem 
with 

corner-based 
physical 
point 
having 
been<br>&nbsp; 
 
transformed: 
The 
interpolator 
has 
to 
decide, 
which 
closest 
pixels 
to<br>&nbsp; 
 
take 
into 
account 
for 
interpolation 
(and 
how 
to 
weight 
them). 
This<br>&nbsp; 
 
would 
be 

problem 
even 
for 

the 
linear 
interpolator. 
How 
should<br>&nbsp; 
 
it 
know, 
which 

pixels 
(in 
the 
2D 
case) 
to 
take? 
The 
problem 
is,<br>&nbsp; 
 
that 
the 
interpolator 
has 
to 
estimate 
the 
location 
of 
the 
backward<br>&nbsp; 
 
warped 
input 
pixel. 
This 
is 
never 
really 
possible 
due 
to 
the 
unknown<br>&nbsp; 
 
transformation. 
But 
the 
guess 
of 

center-based 
rectangle 
is 
better<br>&nbsp; 
 
than 
guessing 

corner-based 
rectangle 
(where 
you 
don't 
know, 
which<br>&nbsp; 
 
of 
the 
corners 
is 
given).<br>&nbsp; 
 

numerical 
example 
(sorry, 

was 
too 
lazy 
to 
paint): 
Let's 
resample<br>&nbsp; 
 

2D 
image 
with 
an 
input 
and 
output 
spacing 
of 
1mm 

1mm. 
We 
want 
to<br>&nbsp; 
 
interpolate 
the 
output 
pixel 
at 
(0mm..1mm,0mm..1mm) 
which 
has 
the<br>&nbsp; 
 
corner 
coordinates 
(0mm,0mm).<br>&nbsp; 
 
A) 
For 

translation 
of 
(0.1mm,0.2mm), 
we 
get 
an 
input 
coordinate<br>&nbsp; 
&nbsp; 
&nbsp; 
at 
(0.1mm,0.2mm) 
and 
now 
have 
to 
decide, 
which 
image 
range 
of<br>&nbsp; 
&nbsp; 
&nbsp; 
2x2 
pixels 
to 
use 
for 
interpolation. 
Since 
we 
translated 

bit<br>&nbsp; 
&nbsp; 
&nbsp; 
in 
positive 

and 

direction, 
we 
should 
use 
the 
pixels 
at<br>&nbsp; 
&nbsp; 
&nbsp; 
(0mm..2mm,0mm..2mm). 
Alright. 
So 
the 
rule 
should 
be 
to 
round 
the<br>&nbsp; 
&nbsp; 
&nbsp; 
physical 
coordinate 
and 
this 
yields 
the 
lower 
left 
corner 
of 
our<br>&nbsp; 
&nbsp; 
&nbsp; 
2x2 
pixels 
interpolation 
region.<br>&nbsp; 
 
B) 
Let's 
try 

different 
transformation: 

180 
deg. 
rotation 
around<br>&nbsp; 
&nbsp; 
&nbsp; 
(0mm,0mm) 
and 

subsequent 
translation 
of 
(0.1mm,0.2mm). 
We 
again<br>&nbsp; 
&nbsp; 
&nbsp; 
compute 
(0.1mm,0.2mm) 
as 
input 
coordinate. 
So 
let's 
follow 
the<br>&nbsp; 
&nbsp; 
&nbsp; 
rule 
and 
use 
again 
(0mm..2mm,0mm..2mm) 
as 
interpolation 
region.<br>&nbsp; 
&nbsp; 
&nbsp; 
Ups! 
We 
should 
have 
used 
(-1mm..1mm,-1mm..1mm) 
instead! 
(You 
can<br>&nbsp; 
&nbsp; 
&nbsp; 
see 
this 
by 
also 
transforming 
the 
"upper-right" 
corner 
output<br>&nbsp; 
&nbsp; 
&nbsp; 
pixel 
which 
is 
(1mm,1mm) 
giving 
(-0.9mm,-0.8mm) 
as 
input 
corner.<br>&nbsp; 
&nbsp; 
&nbsp; 
Therfore, 
the 
output 
pixel 
lies 
at 
(-0.9mm..0.1mm,-0.8mm..0.2mm).<br>&nbsp; 
&nbsp; 
&nbsp; 
This 
input 
pixel 
overlaps 
the 

input 
pixels 
in 
the 
region<br>&nbsp; 
&nbsp; 
&nbsp; 
(-1mm..1mm,-1mm..1mm) 
as 
stated 
above.)<br><br>&nbsp; 
&nbsp; 
&nbsp; 
Conclusion: 
The 
transformed 
corner 
coordinate 
in 
reality 
is 
no<br>&nbsp; 
&nbsp; 
&nbsp; 
longer 

"lower-left" 
corner 
but 
how 
should 
the 
interpolater 
have<br>&nbsp; 
&nbsp; 
&nbsp; 
guessed 
that? 
The 
only 
remedy 
would 
be 
that 
every 
class 
using 
a<br>&nbsp; 
&nbsp; 
&nbsp; 
transformation 
would 
not 
only 
transform 
one 
single 
coordinate 
per<br>&nbsp; 
&nbsp; 
&nbsp; 
pixel 
but 
all 

(in 
2D) 
or 

(in 
3D) 
corners. 
Nobody 
wants 
this.<br>&nbsp; 
&nbsp; 
&nbsp; 
Guessing 
an 
input 
region 
after 
having 
backward 
warped 

pixel's<br>&nbsp; 
&nbsp; 
&nbsp; 
center 
is 
much 
easier 
and 
faster. 
(Although 

would 
opt 
for 
taking<br>&nbsp; 
&nbsp; 
&nbsp; 
circles 
instead 
of 
rectangles 
here, 
but 
that's 
another 
issue.)<br><br>Hopefully, 

made 
my 
point 
clear 
that 

pixel's 
center 
coordinate 
is 
the<br>more 
useful 
representation 
for 
it 
than 
its 
corner 
coordinate. 

am 
pretty<br>sure, 
the 
original 
developers 
or 
writer 
of 
the 
docs 
had 
this 
point 
in 
mind<br>when 
the 
wrote 
the 
Software 
Guide. 
And 
since 
the 
implementation 
is 
flawed<br>anyways, 
and 
since 

lot 
of 
classes 
could 
not 
be 
adopted 
to 
corner-based<br>coordinates, 

still 
strongly 
vote 
for 
center-based 
ones. 
This 
"physical<br>point 
of 
view" 
is 
also 
more 
in 
the 
style 
of 
ITK 
than 
the 
"computer 
science<br>point 
of 
view". 
ITK 
developers 
should 
not 
think 
in 
pixels 
but 
rather 
in<br>millimeters.<br><br>Thanks 
for 
reading. 
Waiting 
for 
your 
replies,<br>Andreas.<br><br><br><br>-----Original 
Message-----<br>From: 
Maarten 
Nieber<br>Sent: 
Monday, 
January 
28, 
2008 
14:45<br>To: 
<a ymailto="mailto:insight-users@itk.org" href="mailto:insight-users@itk.org">insight-users@itk.org</a><br>Subject: 
Re: 
[Insight-users] 
ITK 
Image 
Coordinates 

Problem<br>withPhysicalPoint 
to 
Index 
Conversion<br><br>Hi 
Andreas,<br><br>I 
agree 
with 
you 
that 
this 
issue 
is 
of 
very 
high 
importance!<br><br>-- 
quote 
from 
your 
previous 
post 
--<br>I 
think 
that 
the 
personal 
preference<br>for 
one 
of 
the 
two 
options 
we 
have 
basically 
depends 
on 
whether 
one 
is<br>more 
interested 
in 
the 
overall 
dimensions 
of 

dataset 
or 
whether 
one 
has<br>to 
do 
voxel-wise 
operations 
depending 
on 
the 
physical 
coordinate.<br>-- 
end 
quote 
--<br><br>Can 
you 
explain 
why 
you 
think 

for 
doing 
voxel-wise 
operations 

it 
would<br>be 
better 
if 
the 
image 
origin 
co-incides 
with 
the 
center 
of 

pixel?<br><br>Best 
regards,<br>Maarten<br><br><br>----- 
Original 
Message 
----<br>From: 
Andreas 
Keil<br>To: 
<a ymailto="mailto:insight-users@itk.org" href="mailto:insight-users@itk.org">insight-users@itk.org</a><br>Sent: 
Tuesday, 
January 
8, 
2008 
10:37:32 
AM<br>Subject: 
RE: 
[Insight-users] 
ITK 
Image 
Coordinates 

Problem 
with<br>PhysicalPoint 
to 
Index 
Conversion<br><br>Dear 
all,<br><br>I 
would 
like 
to 
try 

restart 
of 
the 
discussion 
related 
to 
the 
definition<br>of 
physical 
coordinates 
if 
ITK 
images:<br><br>As 
mentioned 
in 
my 
earlier 
post 
(see 
below), 
the 
documentation 
and<br>implementation 
differ 
in 
this 
point. 
The 
two 
proposed 
solutions 
are 
either<br>fixing 
the 
documentation 
(ITK 
Software 
Guide, 
p. 
40) 
and 
defining 
the<br>origin 
to 
lie 
in 
the 
"lower-left(-back)" 
corner 
of 
the 
pixel 
with 
index<br>0/0(/0) 
or 
fixing 
the 
implementation 
of 
the 
respective 
methods<br>(IndexToPhysicalPoint, 
PhysicalPointToIndex, 
etc.) 
and 
defining 
the 
origin<br>to 
lie 
in 
the 
center 
of 
this 
pixel.<br><br>So 
far, 
only 
Maarten 
and 

were 
discussing 
about 
this, 
with 
him 
favoring<br>to 
fix 
the 
docs 
and 
me 
favoring 
to 
fix 
the 
implementation. 
Another<br>argument 

found 
for 
my 
preference 
is 
that 
the 
origin 
would 
not 
have 
to<br>change 
when 
downsampling 
an 
image. 

think 
that 
the 
personal 
preference<br>for 
one 
of 
the 
two 
options 
we 
have 
basically 
depends 
on 
whether 
one 
is<br>more 
interested 
in 
the 
overall 
dimensions 
of 

dataset 
or 
whether 
one 
has<br>to 
do 
voxel-wise 
operations 
depending 
on 
the 
physical 
coordinate.<br><br>--&gt; 
Therefore, 

strongly 
ask 
other 
ITK 
users 
and 
developers 
to 
take 
part<br>in 
this 
discussion 
so 
that 
we 
can 
make 

decision. 
This 
problem 
is 
really<br>of 
high 
importance 
since 
it 
is 
related 
to 
the 
core 
of 
the 
lib 
(namely 
the<br>ImageBase 
class) 
and 
it 
has 

big 
influence 
on 
reconstruction 
problems. 
As<br>soon 
as 
we 
have 
come 
to 

conclusion, 

would 
file 

bug 
report 
with 
the<br>proposed 
solution.<br><br>Thank 
you,<br>Andreas.<br><br><br><br>-----Original 
Message-----<br>From: 
Andreas 
Keil<br>Sent: 
Tuesday, 
December 
18, 
2007 
13:30<br>To: 
<a ymailto="mailto:insight-users@itk.org" href="mailto:insight-users@itk.org">insight-users@itk.org</a><br>Subject: 
RE: 
[Insight-users] 
ITK 
Image 
Coordinates 

Problem 
with<br>PhysicalPoint 
to 
Index 
Conversion<br><br>Hi 
Maarten,<br><br>thank 
you 
for 
your 
reply 
(which 
other 
list 
subscribers 
may 
find 
below). 
My<br>initial 
posting 
was 
biased 
towards 
changing 
the 
ITK 
implementation 
rather<br>than 
the 
documentation 
for 
the 
following 
reasons:<br><br>Working 
with 
the 
physical 
coordinates 
of 

voxel 
usually 
means 
that 
one<br>needs 

single 
coordinate 
representation 
of 

voxel. 
Algorithms 
relying<br>one 
this 
single 
physical 
coordinate 
would 
usually 
prefer 
the 
center 
of 
a<br>voxel 
for 
their 
space-related 
computations.<br><br>Moreover, 
ITK 
images 
only 
reflect 
the 
spacing 
between 
voxels 
which 
is 
not<br>necessarily 
equal 
to 
the 
width 
of 

voxel. 

am 
pretty 
sure 
that 
there 
are<br>cases 
where 
the 
voxel 
width 
is 
smaller 
than 
the 
spacing 
(in 
CT 
for<br>example). 
In 
this 
case, 
the 
term 
"spacing" 
would 
also 
be 
ambigious 
if 
it<br>would 
not 
refer 
to 
the 
distance 
between 
adjacent 
voxels' 
centers.<br><br>What 
do 
others 
think 
about 
this? 

would 
appreciate 

clearification 
as<br>the 
definitions 
of 
image 
origin 
and 
spacing 
really 
matter 
for 
my<br>application 
in 
3D 
reconstruction. <br><br>Thank 
you,<br>Andreas.<br><br><br><br>-----Original 
Message-----<br>From: 
Maarten 
Nieber<br>Sent: 
Tuesday, 
December 
18, 
2007 
10:11<br>To: 
Andreas 
Keil<br>Subject: 
Re: 
[Insight-users] 
ITK 
Image 
Coordinates 

Problem 
with 
Physical<br>Point 
to 
Index 
Conversion<br><br>Hi 
Andreas,<br><br>I 
agree 
with 
you 
that 
according 
to 
the 
software 
guide, 
mapping 
(0.6, 
0.6)<br>should 
yield 
an 
index 
of 
(0,0).<br>On 
the 
other 
hand, 

think 
that 
the 
definition 
of 
origin 
in 
the 
software<br>guide 
is 
not 
intuitive.<br>It 
says 
"the 
image 
origin 
is 
associated 
with 
the 
co-ordinates 
of 
the 
first<br>pixel 
in 
the 
image". 
Probably, 
it 
would 
be 
more 
accurate 
to 
say 
that 
the<br>image 
origin 
is 
associated 
with 
the 
&gt;center&lt; 
of 
the 
first 
pixel 
in 
the<br>image. 
However, 
by 
using 
this 
definition, 
the 
extent 
of 
an 
image 
with<br>origin 
(0,0) 
contains 
negative 
co-ordinates. 

would 
find 
it 
more<br>intuitive 
if 
the 
extent 
of 
such 
an 
image 
is 
something 
like 
(0,0) 

(size1,<br>size2). 
This 
would 
be 
the 
case 
if 
the 
origin 
of 
the 
image 
is 
associated<br>with 
the 
bottom-left 
corner 
of 
the 
first 
pixel.<br><br>If 
in 
the 
itk 
code, 
the 
origin 
of 
an 
itk 
image 
co-incides 
with 
the 
bottom<br>left 
corner 
of 
the 
first 
pixel, 
then 

would 
prefer 
to 
change 
the 
software<br>guide 
and 
not 
the 
code.<br><br>Best 
regards<br>Maarten 
Nieber<br><br><br><br>----- 
Original 
Message 
----<br>From: 
Andreas 
Keil<br>To: 
<a ymailto="mailto:insight-users@itk.org" href="mailto:insight-users@itk.org">insight-users@itk.org</a><br>Sent: 
Friday, 
December 
14, 
2007 
6:10:25 
PM<br>Subject: 
[Insight-users] 
ITK 
Image 
Coordinates 

Problem 
with 
Physical<br>Point 
to 
Index 
Conversion<br><br>Hi,<br><br>I 
think 

have 
discovered 
an 
inconsistency 
between 
the 
ITK 
Software 
Guide<br>(p.40) 
and 
the 
implementation 
of 
itk::Image 
(all 
the 
methods 
taking<br>physical 
points 

continuous 
indices 
as 
arguments):<br><br>The 
trunctation 
of 
continuous 
index 
coordinates 
to 
integers 
does 
not 
yield<br>the 
correct 
pixel 
coordinates 
as 
expected 
by 
looking 
at 
the 
definition 
in<br>the 
software 
guide.<br><br>A 
simple 
example 
is:<br>Image 
spacing: 
1mm<br>Image 
origin: 
0mm/0mm<br><br>The 
pixel 
with 
index 
(1/1) 
would 
(according 
to 
the 
software 
guide) 
have<br>the 
following 
extents:<br>0.5mm/0.5mm 
to 
1.5mm/1.5mm<br><br>However, 
the 
physical 
point 
0.6mm/0.6mm 
gets 
mapped 
to 
the 
index 
0/0 
by<br>the 
method 
TransformPhysicalPointToIndex.<br><br>The 
solution 
would 
be 
to 
check 
those 
conversion 
methods 
as 
well 
as 
others<br>(like 
IsInside) 
and 
replace 
integer 
truncations 
with 
rounding.<br><br>If 
my 
reasoning 
is 
correct, 
I'll 
file 

bug 
report. 
However, 
I'd 
like 
to<br>have 
some 
confirmation 
first.<br><br>Thanks,<br>Andreas.<br><br>_______________________________________________<br>Insight-users 
mailing 
list<br><a ymailto="mailto:Insight-users@itk.org" href="mailto:Insight-users@itk.org">Insight-users@itk.org</a><br><a href="http://www.itk.org/mailman/listinfo/insight-users" target="_blank">http://www.itk.org/mailman/listinfo/insight-users</a><br></div><br></div></div><br>
      <hr size=1>Looking for last minute shopping deals? <a href="http://us.rd.yahoo.com/evt=51734/*http://tools.search.yahoo.com/newsearch/category.php?category=shopping"> 
Find them fast with Yahoo! Search.</a></body></html>