[Insight-users] Bug in CastImageFilter?
Miller, James V (Research)
millerjv@crd.ge.com
Mon, 10 Feb 2003 11:27:28 -0500
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
------_=_NextPart_001_01C2D121.4D585C8A
Content-Type: text/plain
The issue is one of how high up the pipeline you need to search to determine the input has changed.
We see this problem alot with lengthy pipelines attached to a reader at the source. A user changes
the filename on the reader (to a file that is a different size), and the pipeline doesn't produce the
expected result because Update() is updating the "same" RequestedRegion that it updated the last
time. In this case, the input objects do not change (in that an input is a pointer to a different
data object). Rather, internally the memory was reallocated/reorganized to be a different size.
Thus the pipeline, cannot simply look to see if a filter has a different input. (Though I agree that
should also force a full update. I think, however, that is just part of the solution.)
> -----Original Message-----
> From: Mark Hastenteufel [ mailto:M.Hastenteufel@dkfz-heidelberg.de
<mailto:M.Hastenteufel@dkfz-heidelberg.de> ]
> Sent: Monday, February 10, 2003 10:18 AM
> To: Miller, James V (Research); ITK Users
> Subject: Re: [Insight-users] Bug in CastImageFilter?
>
>
> Hi Jim,
>
> you're right. When calling UpdateLargestPossibleRegion()
> everything works fine.
>
> Isn't it possible to check in the Update() method
> if the input has been changed and calling
> UpdateLargestPossibleRegion() internally?
>
> Mark
>
>
>
> "Miller, James V (Research)" schrieb:
> >
> > This is a standard problem in the pipeline mechanism.
> >
> > The issue is when Update() is called the first time, no
> > RequestedRegion is set in the pipeline so it defaults to
> > setting the RequestedRegion to the LargestPossibleRegion.
> >
> > When you swap the input to the CastImageFilter and call
> > Update() a second time, the pipeline (incorrectly) assumes
> > that you want to update the same RequestedRegion that you
> > asked for (implicitly) the first time. But you did not want
> > to update the same RequestedRegion, but rather, you wanted to
> > update a "new" RequestedRegion that matches the size of the image
> > coming from the pyramid.
> >
> > The quick fix is to change the call to Update() in your loop
> > to UpdateLargestPossibleRegion().
> >
> > Basically, there is currently no way for the pipeline to know
> > that the upstream data is not the same size as it used to be.
> >
> > I hope to add some type of "flush" mechanism which will return
> > a pipeline to its initial state so a user can change a input
> > upstream, flush the pipeline, and have an Update() do what a
> > user would expect.
> >
> > Jim
> >
> > > -----Original Message-----
> > > From: Mark Hastenteufel [ mailto:M.Hastenteufel@DKFZ-Heidelberg.de
<mailto:M.Hastenteufel@DKFZ-Heidelberg.de> ]
> > > Sent: Sunday, February 09, 2003 1:11 PM
> > > To: insight-users@public.kitware.com
> > > Subject: [Insight-users] Bug in CastImageFilter?
> > >
> > >
> > > Hi!
> > >
> > > I've found a strange behaviour in itk::CastImageFilter. I've
> > > implemented a simple program which produces an image
> > > pyramid.
> > > The images on the respective level are written out to disk. The
> > > images are converted from float (internal type of PyramidFilter)
> > > to short using an ikt::CastImageFilter.
> > >
> > >
> > > Typedef's:
> > >
> > > typedef itk::Image<short,2> TInputImage2;
> > > typedef itk::Image<double,2> TOutputImage;
> > > typedef itk::MultiResolutionPyramidImageFilter<
> TOutputImage,
> > > TOutputImage > PyramidType;
> > > typedef itk::CastImageFilter< TOutputImage,TInputImage2 >
> > > CastFilterType;
> > >
> > >
> > > If using the following code:
> > >
> > >
> > > myPyramid->SetNumberOfLevels(noLevels);
> > > myPyramid->SetInput( image );
> > > myPyramid->UpdateLargestPossibleRegion();
> > >
> > > CastFilterType::Pointer myCaster = CastFilterType::New();
> > > for (int i=0 ; i<noLevels ; i++)
> > > {
> > > myCaster->SetInput( myPyramid->GetOutput(i) );
> > > myCaster->Update();
> > >
> > > char s[100];
> > > sprintf(s,"level%d.pic",i);
> > > Pic2itk::saveImage<TInputImage2>(s,myCaster->GetOutput());
> > > }
> > >
> > >
> > > just the image on the coarsest level is OK! The others
> are corrupted.
> > > This seems due to CastImageFilter. If declaring a cast-filter
> > > inside the for-loop, everything is OK!
> > >
> > > myPyramid->SetNumberOfLevels(noLevels);
> > > myPyramid->SetInput(myCaster2->GetOutput() );
> > > myPyramid->UpdateLargestPossibleRegion();
> > >
> > > for (int i=0 ; i<noLevels ; i++)
> > > {
> > > CastFilterType::Pointer myCaster = CastFilterType::New();
> > > myCaster->SetInput( myPyramid->GetOutput(i) );
> > > myCaster->Update();
> > >
> > > char s[100];
> > > sprintf(s,"level%d.pic",i);
> > > Pic2itk::saveImage<TInputImage2>(s,myCaster->GetOutput());
> > > }
> > >
> > >
> > > It seems, that the CastImageFilter doesn't work if SetInput is
> > > called more than one time. Is this a bug or did I made something
> > > wrong?
> > >
> > >
> > > Mark
> > > _______________________________________________
> > > Insight-users mailing list
> > > Insight-users@public.kitware.com
> > > http://public.kitware.com/mailman/listinfo/insight-users
<http://public.kitware.com/mailman/listinfo/insight-users>
> > >
>
> --
> Mark Hastenteufel
> Deutsches Krebsforschungszentrum (German Cancer
> Research Center)
> Div. Medical and Biological Informatics H0100 Tel: (+49)
> 6221-42 2353
> Im Neuenheimer Feld 280 Fax: (+49)
> 6221-42 2345
> D-69120 Heidelberg e-mail
> M.Hastenteufel@DKFZ.de
> Germany
http://www.dkfz.de/mbi/people/markh.html <http://www.dkfz.de/mbi/people/markh.html>
------_=_NextPart_001_01C2D121.4D585C8A
Content-Type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE></TITLE>
<META content="MSHTML 6.00.2715.400" name=GENERATOR></HEAD>
<BODY>
<P><FONT size=2>The issue is one of how high up the pipeline you need to search
to determine the input has changed.</FONT></P>
<DIV><FONT size=2>We see this problem alot with lengthy pipelines attached to a
reader at the source. A user changes the filename on the reader (to a file
that is a different size), and the pipeline doesn't produce the expected result
because Update() is updating the "same" RequestedRegion that it updated the last
time. In this case, the input objects do not change (in that an input is a
pointer to a different data object). Rather, internally the memory was
reallocated/reorganized to be a different size. Thus the pipeline, cannot
simply look to see if a filter has a different input. (Though I agree that
should also force a full update. I think, however, that is just part of
the solution.)</FONT></DIV>
<DIV><FONT size=2><FONT color=#0000ff></FONT> </DIV>
<P><BR><BR>> -----Original Message-----<BR>> From: Mark Hastenteufel [<A
href="mailto:M.Hastenteufel@dkfz-heidelberg.de">mailto:M.Hastenteufel@dkfz-heidelberg.de</A>]<BR>>
Sent: Monday, February 10, 2003 10:18 AM<BR>> To: Miller, James V (Research);
ITK Users<BR>> Subject: Re: [Insight-users] Bug in
CastImageFilter?<BR>><BR>><BR>> Hi Jim,<BR>><BR>> you're right.
When calling UpdateLargestPossibleRegion()<BR>> everything works
fine.<BR>><BR>> Isn't it possible to check in the Update() method<BR>>
if the input has been changed and calling<BR>> UpdateLargestPossibleRegion()
internally?<BR>><BR>> Mark<BR>><BR>><BR>><BR>> "Miller, James
V (Research)" schrieb:<BR>> ><BR>> > This is a standard problem in
the pipeline mechanism.<BR>> ><BR>> > The issue is when Update() is
called the first time, no<BR>> > RequestedRegion is set in the pipeline so
it defaults to<BR>> > setting the RequestedRegion to the
LargestPossibleRegion.<BR>> ><BR>> > When you swap the input to the
CastImageFilter and call<BR>> > Update() a second time, the pipeline
(incorrectly) assumes<BR>> > that you want to update the same
RequestedRegion that you<BR>> > asked for (implicitly) the first
time. But you did not want<BR>> > to update the same
RequestedRegion, but rather, you wanted to<BR>> > update a "new"
RequestedRegion that matches the size of the image<BR>> > coming from the
pyramid.<BR>> ><BR>> > The quick fix is to change the call to
Update() in your loop<BR>> > to UpdateLargestPossibleRegion().<BR>>
><BR>> > Basically, there is currently no way for the pipeline to
know<BR>> > that the upstream data is not the same size as it used to
be.<BR>> ><BR>> > I hope to add some type of "flush" mechanism which
will return<BR>> > a pipeline to its initial state so a user can change a
input<BR>> > upstream, flush the pipeline, and have an Update() do what
a<BR>> > user would expect.<BR>> ><BR>> > Jim<BR>>
><BR>> > > -----Original Message-----<BR>> > > From: Mark
Hastenteufel [<A
href="mailto:M.Hastenteufel@DKFZ-Heidelberg.de">mailto:M.Hastenteufel@DKFZ-Heidelberg.de</A>]<BR>>
> > Sent: Sunday, February 09, 2003 1:11 PM<BR>> > > To:
insight-users@public.kitware.com<BR>> > > Subject: [Insight-users] Bug
in CastImageFilter?<BR>> > ><BR>> > ><BR>> > >
Hi!<BR>> > ><BR>> > > I've found a strange behaviour in
itk::CastImageFilter. I've<BR>> > > implemented a simple program which
produces an image<BR>> > > pyramid.<BR>> > > The images on the
respective level are written out to disk. The<BR>> > > images are
converted from float (internal type of PyramidFilter)<BR>> > > to short
using an ikt::CastImageFilter.<BR>> > ><BR>> > ><BR>> >
> Typedef's:<BR>> > ><BR>> >
> typedef
itk::Image<short,2> TInputImage2;<BR>> >
> typedef
itk::Image<double,2> TOutputImage;<BR>> >
> typedef
itk::MultiResolutionPyramidImageFilter<<BR>> TOutputImage,<BR>> >
> TOutputImage > PyramidType;<BR>> >
> typedef
itk::CastImageFilter< TOutputImage,TInputImage2 ><BR>> > >
CastFilterType;<BR>> > ><BR>> > ><BR>> > > If using
the following code:<BR>> > ><BR>> > ><BR>> >
> myPyramid->SetNumberOfLevels(noLevels);<BR>> >
> myPyramid->SetInput( image );<BR>> > >
myPyramid->UpdateLargestPossibleRegion();<BR>> > ><BR>> >
> CastFilterType::Pointer myCaster =
CastFilterType::New();<BR>> > > for (int i=0 ;
i<noLevels ; i++)<BR>> > > {<BR>> >
> myCaster->SetInput( myPyramid->GetOutput(i)
);<BR>> > > myCaster->Update();<BR>> >
><BR>> > > char s[100];<BR>> >
> sprintf(s,"level%d.pic",i);<BR>> >
>
Pic2itk::saveImage<TInputImage2>(s,myCaster->GetOutput());<BR>> >
> }<BR>> > ><BR>> > ><BR>> > > just
the image on the coarsest level is OK! The others<BR>> are corrupted.<BR>>
> > This seems due to CastImageFilter. If declaring a cast-filter<BR>>
> > inside the for-loop, everything is OK!<BR>> > ><BR>> >
> myPyramid->SetNumberOfLevels(noLevels);<BR>> >
> myPyramid->SetInput(myCaster2->GetOutput() );<BR>>
> > myPyramid->UpdateLargestPossibleRegion();<BR>> >
><BR>> > > for (int i=0 ; i<noLevels ; i++)<BR>>
> > {<BR>> > >
CastFilterType::Pointer myCaster = CastFilterType::New();<BR>> >
> myCaster->SetInput( myPyramid->GetOutput(i)
);<BR>> > > myCaster->Update();<BR>> >
><BR>> > > char s[100];<BR>> >
> sprintf(s,"level%d.pic",i);<BR>> >
>
Pic2itk::saveImage<TInputImage2>(s,myCaster->GetOutput());<BR>> >
> }<BR>> > ><BR>> > ><BR>> > > It
seems, that the CastImageFilter doesn't work if SetInput is<BR>> > >
called more than one time. Is this a bug or did I made something<BR>> >
> wrong?<BR>> > ><BR>> > ><BR>> > > Mark<BR>>
> > _______________________________________________<BR>> > >
Insight-users mailing list<BR>> > >
Insight-users@public.kitware.com<BR>> > > <A
href="http://public.kitware.com/mailman/listinfo/insight-users"
target=_blank>http://public.kitware.com/mailman/listinfo/insight-users</A><BR>>
> ><BR>><BR>> --<BR>> Mark Hastenteufel<BR>> Deutsches
Krebsforschungszentrum (German
Cancer<BR>> Research Center)<BR>> Div. Medical and Biological Informatics
H0100 Tel: (+49)<BR>> 6221-42 2353<BR>> Im Neuenheimer
Feld
280
Fax: (+49)<BR>> 6221-42 2345<BR>> D-69120
Heidelberg
e-mail <BR>>
M.Hastenteufel@DKFZ.de<BR>>
Germany <BR><A
href="http://www.dkfz.de/mbi/people/markh.html"
target=_blank>http://www.dkfz.de/mbi/people/markh.html</A><BR></P></FONT></BODY></HTML>
------_=_NextPart_001_01C2D121.4D585C8A--