bypassing in vtkImageFilter's

[Charles Law]

<x-flowed>Ken,

I belive I know what is happening:

When ByPass flag is turned on, a shallow copy is performed from input to 
output (they actually point to the same data.  When ByPass is turned 
off,  the output should release its data and create a new array.  Instead, 
it tries to be too smart.  It sees it has data of the correct size so it 
reuses the data array.  This effectively writes over the input.  Since the 
input never thinks it has to re execute, the mathematics filter gets 
applied over and over again.

Although removing the logic to reuse data would be easy,  the bypass 
mechanism has changed since VTK2.4.

I will add a regression test that switches bypass on and off (with updates) 
a couple of times.

Charles.



At 12:49 AM 12/6/99 -0800, you wrote:
>Hi,
>
>I'm having a rather confusing problem with an imaging filter, and I
>was wondering if anyone might be able to shed some light on my
>situation.  I have a simple pipeline which looks like this (this is
>using the official 2.4 release):
>
>
>           vtkImageReader
>                 |
>           vtkImageMathematics (do a 1-input operation)
>                 |
>           vtkImageToStructuredPoints
>                 |
>           vtkExtractVOI (extract slice)
>                 |
>           vtkTexture
>                 |
>          .... continue to texture map to plane
>
>
>This pipeline has been working well for me for a while now.  Yesterday
>I introduced vtkImageMathematics to do some simple stuff, and I want
>to be able to toggle that processing on or off.  So I use the BypassOn
>/ BypassOff methods in vtkImageMathematics which are inherited from
>vtkImageFilter.
>
>However, these really aren't working quite the way I expect.  If I
>initialize with BypassOn, then the texture mapped plane is as
>expected: not processed by my simple operation in vtkImageMathematics.
>When I turn BypassOff, here again I see the expected result: the
>processed image.  But, if I now call BypassOn once again, I don't get
>the original image back.  Any methods based on vtkSetMacro should
>update modification time, right?  So a change to the Bypass ivar
>should cause the pipeline to update when a request comes along, right?
>Calling Update directly on the image filter, preceding such a call
>with an explicit call to Modified, and generating update requests from
>the end of the pipeline with Render's and mouse manipulations do not
>seem to cause the vtkImageMathematics filter to update (i.e. the
>rendered image does not update).
>
>In fact, I'm seeing something rather stranger, which is that each call
>to BypassOn seems to lead to *further* processing of the image (as
>opposed to a reversion to the original state).  I'm having trouble
>understanding this, since the filter constants (ConstantC and
>ConstantK) are unchanged, and the reader source is also unchanged.
>Nor is the scalar range on my mappers changed, so the rendered
>differences are not the result of differences in color mapping.
>
>So while this question is superficially about something perhaps
>relatively unimportant (i.e. bypassing in image filters, which could
>always be dealt with by reconfiguring the pipeline directly I
>suppose), I fear I may be suffering from some deeper, much more
>fundamental problem with imaging pipelines in general.  Does anyone
>have any advice?
>
>Thanks,
>Ken
>
>
>------------------------------------------------------------------------
>Kenneth C. Wang                 E-mail: kenwang at stanfordalumni.org
>Electrical Engineering Dept.    Voice:  (650) 725-0458
>Stanford University             Fax:    (650) 725-7731
>CIS 214, Stanford, CA 94305     Web:    http://www.stanford.edu/~kenwang
>------------------------------------------------------------------------
>
>
>-----------------------------------------------------------------------------
>This is the private VTK discussion list.  Please keep messages on-topic.
>Check the FAQ at: <http://www.automatrix.com/cgi-bin/vtkfaq>
>To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
><majordomo at gsao.med.ge.com>.  For help, send message body containing
>"info vtkusers" to the same address.     Live long and prosper.
>-----------------------------------------------------------------------------



-----------------------------------------------------------------------------
This is the private VTK discussion list.  Please keep messages on-topic.
Check the FAQ at: <http://www.automatrix.com/cgi-bin/vtkfaq>
To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
<majordomo at gsao.med.ge.com>.  For help, send message body containing
"info vtkusers" to the same address.     Live long and prosper.
-----------------------------------------------------------------------------

</x-flowed>