[Insight-developers] from Damion

[George Stetten]

This is a multi-part message in MIME format.
--------------B6F0594FCAA1AAB3E2731A75
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------B6F0594FCAA1AAB3E2731A75
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Return-Path: <dmsst59+@pitt.edu>
Received: from mb1i0.ns.pitt.edu (mb1i1.ns.pitt.edu [136.142.185.161])
          by imap.srv.cis.pitt.edu with ESMTP (8.8.8/8.8.8/cisimap-7.2.2.4)
          ID <OAA23921@imap.srv.cis.pitt.edu> for <stetten@imap.pitt.edu>;
          Thu, 10 May 2001 14:41:15 -0400 (EDT)
Received: from engrng.pitt.edu ("port 1930"@[136.142.89.97])
 by pitt.edu (PMDF V5.2-32 #41462)
 with SMTP id <01K3EHWLSQIC004AL0@mb1i0.ns.pitt.edu> for stetten@imap.pitt.edu
 (ORCPT rfc822;stetten+2B@pitt.edu); Thu, 10 May 2001 14:41:14 EDT
Received: by engrng.pitt.edu (SMI-8.6/SMI-4.1)	id OAA21434; Thu,
 10 May 2001 14:41:12 -0400
Received: from sisterray-z.mspring.net(207.69.231.102),
 claiming to be "sisterray.mspring.net" via SMTP by civeng1.civ.pitt.edu,
 id smtpdAAAa21428; Thu May 10 14:41:01 2001
Received: from mb2i0.ns.pitt.edu (mb2i0.ns.pitt.edu [136.142.186.36])
	by sisterray.mspring.net (8.9.3/8.8.6) with ESMTP id OAA74798	for
 <george@stetten.com>; Thu, 10 May 2001 14:40:59 -0400 (EDT)
Received: from via5 ("port 4258"@[136.142.178.221])
 by pitt.edu (PMDF V5.2-32 #41462)
 with SMTP id <01K3EHVYF3IE010BL1@mb2i0.ns.pitt.edu> for george@stetten.com;
 Thu, 10 May 2001 14:40:42 -0400 (EDT)
Date: Thu, 10 May 2001 14:42:23 -0400
From: Damion Shelton <dmsst59+@pitt.edu>
Subject: itk list forward
To: George Stetten <george@stetten.com>
Reply-to: Damion Shelton <dmsst59@pitt.edu>
Message-id: <00bf01c0d980$f3d2be90$ddb28e88@via5>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.3018.1300
X-Mailer: Microsoft Outlook Express 5.00.3018.1300
Content-type: text/plain;	charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal

Hi all... having some mailing list problems so this is reaching you via a
forward....

I would like to propose the following topics for discussion tomorrow:

1) "Should images (and meshes) know how big they are?"

With itkPhysicalImage, the image knows its origin, spacing, number of
dimensions, transform, etc. but doesn't appear to know how big it is. This
info is accessible via
itkPhysicalImage::GetLargestPossibleRegion()::GetSize() but this seems a bit
counterintuitive. The (as yet unresolved) problem I was having yesterday,
with the GetLargestPossibleRegion()::GetSize() call within
ImageToImageFilter::GenerateData() returning a size of {0,0,0, got me
thinking about how image size is handled.

Perhaps (hopefully?) I'm just missing something obvious.

2) "How do we know who's done / is doing / will do what?"

I'm going back and re-examining what I'm doing in light of Vikram's
suggestion about itkImageFunction. I think this raises the larger question
of how we tell what capabilities ITK has. I see a few options:

a) An ongoing forum for posting present capabilities, current work, and
planned work
b) Emailing the list every time something new is started, to avoid
redundancy
c) Not worrying about it ;-)

In any case, despite the dramatic improvement in naming conventions, it's
still not always clear where to look in the class hierarchy to see whether
what you're interested in exists or not. For instance, I missed
itkImageFunction because I was looking under
itkImageSource/itkImageToImageFilter under the assumption that such a thing
would be part of the process pipeline.

Anyways, thoughts are welcome.

-Damion-


--------------B6F0594FCAA1AAB3E2731A75--