<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 >at the center< 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 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 <andreas.keil@cs.tum.edu><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
I
am
voting
for
a
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>
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>
corner
coordinates
would,
of
course,
work,
too.
However,
the<br>
interpolation
in
step
4
is
done
based
on
a
single
point
representing<br>
the
whole
pixel.
In
general,
we
don't
have
an
idea
on
how
the
box
of<br>
a
pixel
is
transformed.
We
can
just
pass
a
single
coordinate
through <br>
through
to
the
interpolator.
Keep
this
in
mind
for
now.<br>3)
Works
fine.<br>4)
Now
we
have
a
problem
with
a
corner-based
physical
point
having
been<br>
transformed:
The
interpolator
has
to
decide,
which
closest
pixels
to<br>
take
into
account
for
interpolation
(and
how
to
weight
them).
This<br>
would
be
a
problem
even
for
a
the
linear
interpolator.
How
should<br>
it
know,
which
4
pixels
(in
the
2D
case)
to
take?
The
problem
is,<br>
that
the
interpolator
has
to
estimate
the
location
of
the
backward<br>
warped
input
pixel.
This
is
never
really
possible
due
to
the
unknown<br>
transformation.
But
the
guess
of
a
center-based
rectangle
is
better<br>
than
guessing
a
corner-based
rectangle
(where
you
don't
know,
which<br>
of
the
corners
is
given).<br>
A
numerical
example
(sorry,
I
was
too
lazy
to
paint):
Let's
resample<br>
a
2D
image
with
an
input
and
output
spacing
of
1mm
x
1mm.
We
want
to<br>
interpolate
the
output
pixel
at
(0mm..1mm,0mm..1mm)
which
has
the<br>
corner
coordinates
(0mm,0mm).<br>
A)
For
a
translation
of
(0.1mm,0.2mm),
we
get
an
input
coordinate<br>
at
(0.1mm,0.2mm)
and
now
have
to
decide,
which
image
range
of<br>
2x2
pixels
to
use
for
interpolation.
Since
we
translated
a
bit<br>
in
positive
x
and
y
direction,
we
should
use
the
pixels
at<br>
(0mm..2mm,0mm..2mm).
Alright.
So
the
rule
should
be
to
round
the<br>
physical
coordinate
and
this
yields
the
lower
left
corner
of
our<br>
2x2
pixels
interpolation
region.<br>
B)
Let's
try
a
different
transformation:
A
180
deg.
rotation
around<br>
(0mm,0mm)
and
a
subsequent
translation
of
(0.1mm,0.2mm).
We
again<br>
compute
(0.1mm,0.2mm)
as
input
coordinate.
So
let's
follow
the<br>
rule
and
use
again
(0mm..2mm,0mm..2mm)
as
interpolation
region.<br>
Ups!
We
should
have
used
(-1mm..1mm,-1mm..1mm)
instead!
(You
can<br>
see
this
by
also
transforming
the
"upper-right"
corner
output<br>
pixel
which
is
(1mm,1mm)
giving
(-0.9mm,-0.8mm)
as
input
corner.<br>
Therfore,
the
output
pixel
lies
at
(-0.9mm..0.1mm,-0.8mm..0.2mm).<br>
This
input
pixel
overlaps
the
4
input
pixels
in
the
region<br>
(-1mm..1mm,-1mm..1mm)
as
stated
above.)<br><br>
Conclusion:
The
transformed
corner
coordinate
in
reality
is
no<br>
longer
a
"lower-left"
corner
but
how
should
the
interpolater
have<br>
guessed
that?
The
only
remedy
would
be
that
every
class
using
a<br>
transformation
would
not
only
transform
one
single
coordinate
per<br>
pixel
but
all
4
(in
2D)
or
8
(in
3D)
corners.
Nobody
wants
this.<br>
Guessing
an
input
region
after
having
backward
warped
a
pixel's<br>
center
is
much
easier
and
faster.
(Although
I
would
opt
for
taking<br>
circles
instead
of
rectangles
here,
but
that's
another
issue.)<br><br>Hopefully,
I
made
my
point
clear
that
a
pixel's
center
coordinate
is
the<br>more
useful
representation
for
it
than
its
corner
coordinate.
I
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
a
lot
of
classes
could
not
be
adopted
to
corner-based<br>coordinates,
I
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
a
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
a
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
a
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
I
were
discussing
about
this,
with
him
favoring<br>to
fix
the
docs
and
me
favoring
to
fix
the
implementation.
Another<br>argument
I
found
for
my
preference
is
that
the
origin
would
not
have
to<br>change
when
downsampling
an
image.
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
a
dataset
or
whether
one
has<br>to
do
voxel-wise
operations
depending
on
the
physical
coordinate.<br><br>-->
Therefore,
I
strongly
ask
other
ITK
users
and
developers
to
take
part<br>in
this
discussion
so
that
we
can
make
a
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
a
big
influence
on
reconstruction
problems.
As<br>soon
as
we
have
come
to
a
conclusion,
I
would
file
a
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
a
voxel
usually
means
that
one<br>needs
a
single
coordinate
representation
of
a
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
a
voxel.
I
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?
I
would
appreciate
a
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,
I
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
>center<
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.
I
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
I
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
I
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
a
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>