No subject

http://www.itk.org/Doxygen/html/classitk_1_1ChainCodePath2D.html#_details

-----------------------------------------------------------------------------------------
* This class is intended to represent sequences of connected indices in a 2D
 * image plane.  It does so by storing the offset of each index from its
 * immediately preceeding, connected, index using a standard Freeman code
 * (1=up, 2=up to the right, and so on proceeding clockwise to 8=up
 * to the left).  The only image index stored directly is thatof the first
 * index.
-----------------------------------------------------------------------------------------


I couldn't compare this against the paper that your posted,
given that it is not from an Open Access Journal, and therefore
its content is not available to the public.

Looking at the translation of codes that you posted, it looks like
your image is simply flipped vertically (reflected on the X axis),


ITK Encoding

8   1   2
7   X   3
6   5   4


      ^
Up  |


Your Encoding

4   3   2
5   X   1
6   7   8


The two system seem to be a reflection on the diagonal
line that goes up and to the right.

....

Which lead me to suspect that the problem is actually
one of visualization, and not one of processing.


Please note that ITK uses a mathematical coordinate system
where the +Y axis is actually pointing Up, as opposed to the
coordinate systems that is commonly used in computer graphics
where the +Y axis is pointing down.

If you use the ImageViewer application from InsightApplications,
you will be able to see the images in their correct coordinate
system.


That said,...
I can't explain the horizontal reflexion...



        Regards,


             Luis


---------------------------------------------------------------------------------------
On Sun, Mar 21, 2010 at 10:38 AM, Constantine Zakkaroff
<mnkz at leeds.ac.uk> wrote:
> Hello ALL.
>
> I attempted to read a 2D Freeman-encoded myocardial contour into a
> itk::ChainCodePath2D path from a file produced by QMass MR 6.2.1 and
> discovered that I had to remap encoded steps while reading them from the
> contour file before inserting them into the path object like this:
>
> case '1': step = 3; break;
> case '2': step = 2; break;
> case '3': step = 1; break;
> case '4': step = 8; break;
> case '5': step = 7; break;
> case '6': step = 6; break;
> case '7': step = 5; break;
> case '8': step = 4; break;
> case '0': step = 3; break;
>
> So it appears that in itk::ChainCodePath2D step encoding varies from the
> original paper "On the encoding of arbitrary geometric configurations", H.
> Freeman; IRE Trans. Electron. Comput, 1961.
> <http://ieeexplore.ieee.org/iel5/4037753/5219177/05219197.pdf>.
>
> Was the choice in itk::ChainCodePath2D implementation geared towards some
> particular Freeman coding version/application?
>
> Thanks,
> Constantine
>
>
>
> _____________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Kitware offers ITK Training Courses, for more information visit:
> http://www.kitware.com/products/protraining.html
>
> Please keep messages on-topic and check the ITK FAQ at:
> http://www.itk.org/Wiki/ITK_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.itk.org/mailman/listinfo/insight-users
>