<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Will <br>
<br>
supposing I subclassed vtkLinearTransform, to create a new class of
transform for which only<br>
rotation, scaling, translation<br>
were permitted. Something like vtkRestrictedLinearTransform (I can
never remember the difference between homogeneous, affine, etc
transforms, so forgive me for nomenclaure problems). The interface
would need to be simplified to prevent users doing shear operations or
manipulating lements directly.<br>
...<br>
Then subclassed vtkuniformGrid to create vtkOrientedUniformGrid, and
added/applied the transform to it.<br>
<br>
The implementations of findcell/getcell/getpoint etc would need to be
redone, but could most of the other internals be left alone?<br>
<br>
Would this idea work?<br>
<br>
JB<br>
<br>
<blockquote
cite="mid:3ae73beb0811130320r13897f6cnd81edbc2642de@mail.gmail.com"
type="cite">John-<br>
<br>
Something similar has been evolving in the ITK world for a while now.
While transforms were added to ITK's image, the problem is that many of
the algorithms are spatially sensitive (e.g., derivatives) and must be
rewritten to accommodate the transform. There is some controversy
because this slows execution down, adds complexity, and the last I
checked not everything was rewritten. But there is a chance that you
can do what you want in ITK, and in case some work has to be done there
is a potential path to accept any changes that you might make. You'll
have to deal with interfacing between VTK and ITK, the more complex
coding style of ITK, and of course contributing changes into ITK can be
harder because the community scrutinizes them more thorougly via the
Insight Journal and other processes.<br>
<br>
You'll want to check with an ITK expert like Luis Ibanez or Stephen
Aylward (and of course the mailing list) for a more accurate
description of the current ITK situation.<br>
<br>
W<br>
<br>
<div class="gmail_quote">On Thu, Nov 13, 2008 at 3:45 AM, John
Biddiscombe <span dir="ltr"><a class="moz-txt-link-rfc2396E" href="mailto:biddisco@cscs.ch"><biddisco@cscs.ch></a></span> wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I
started writing some code for a particular job yesterday and then
realized that I can't do what I want to because it is not possible to
have a non-axis aligned vtkImageData - or better vtkUniformGrid.<br>
<br>
I wonder if there is a solution to having an image-like structure that
is non axis aligned using some AMR box or heirarchical box dataset
instead. I had a quick look at the classes, but didn't see an immediate
solution. I need the dataset to be efficient like vtkImageData, but
arbitrarily orientated. I need to add a transform to a vtkImageData at
the dataset level, applying a transform to an actor would not help. The
data needs to be really transformed in space (for resampling purposes).<br>
<br>
Can anyone suggest an alternative?<br>
<br>
If not, is there any other demand for modifying vtkUniformGrid perhaps
to take a transform so that functions like findcell/getpoint/bounds etc
are routed through it? (also, would it be realistic to add this to
uniform grid, or are there too many places where assumptions are made
about voxel corners etc).<br>
<br>
thanks<br>
<br>
JB<br>
<br>
-- <br>
John Biddiscombe, email:biddisco @ cscs.ch<br>
<a moz-do-not-send="true" href="http://www.cscs.ch/" target="_blank">http://www.cscs.ch/</a><br>
CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07<br>
Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82<br>
<br>
<br>
_______________________________________________<br>
vtk-developers mailing list<br>
<a moz-do-not-send="true" href="mailto:vtk-developers@vtk.org"
target="_blank">vtk-developers@vtk.org</a><br>
<a moz-do-not-send="true"
href="http://www.vtk.org/mailman/listinfo/vtk-developers"
target="_blank">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
William J. Schroeder, PhD<br>
Kitware, Inc.<br>
28 Corporate Drive<br>
Clifton Park, NY 12065<br>
<a moz-do-not-send="true" href="mailto:will.schroeder@kitware.com">will.schroeder@kitware.com</a><br>
<a moz-do-not-send="true" href="http://www.kitware.com">http://www.kitware.com</a><br>
518-371-3971 (phone and fax)<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="78">--
John Biddiscombe, email:biddisco @ cscs.ch
<a class="moz-txt-link-freetext" href="http://www.cscs.ch/">http://www.cscs.ch/</a>
CSCS, Swiss National Supercomputing Centre | Tel: +41 (91) 610.82.07
Via Cantonale, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82</pre>
</body>
</html>