[vtkusers] vtkAppendPolydata - wrong extents on multiple inputs
Dan Lipsa
dan.lipsa at kitware.com
Wed Aug 19 22:43:37 EDT 2015
Hi Nigel,
Indeed this is a bug in vtkAppendPolyData. I'll have a fix merged in soon:
http://www.vtk.org/Bug/view.php?id=15662
Dan
On Fri, Aug 7, 2015 at 2:14 PM, Dan Lipsa <dan.lipsa at kitware.com> wrote:
> Nigel,
> I don't see anything wrong in your script. Do you mind sharing your data
> so that I can debug this?
>
> On Fri, Aug 7, 2015 at 7:48 AM Nigel Mcfarlane <Nigel.Mcfarlane at beds.ac.uk>
> wrote:
>
>> Dear Dan,
>>
>> I’m sorry, but I was too hasty in declaring that my problem was fixed –
>> removing my AddScalars filter did not help after all, and neither did
>> replacing it with vtkPolyDataNormals. I have now stripped down the code to
>> its simplest configuration. The resulting scene has isosurfaces which are
>> mispositioned and broken in a manner consistent with the images being read
>> with the wrong dimensions. Furthermore, if the readers are not manually
>> updated, the program crashes.
>>
>>
>>
>> There is also an error message:
>>
>> ERROR: In
>> C:\VTK\VTK-6.2.0\Common\ExecutionModel\vtkStreamingDemandDrivenPipeline.cxx,
>> line 857
>>
>> vtkCompositeDataPipeline (0132A818): The update extent specified in the
>> information for output port 0 on algorithm vtkMetaImageReader(01321E58) is
>> 0 67 0 72 0 9, which is outside the whole extent 0 69 0 58 0 10.
>>
>>
>>
>> The results are ok if only one image is fed to appendPD. If I update the
>> dmcubes[i] manually, the results are also ok.
>>
>>
>>
>> It looks as if the base of the pipeline only remembers one set of
>> extents, which it then demands incorrectly from all the inputs. Have I
>> missed anything important in the code below?
>>
>>
>>
>> // Set filenames
>>
>> *std*::*string* dirname = CHICVIS"/ForthLungCropped20150703";
>>
>> *std*::*string* fname[3];
>>
>> fname[0] = dirname + "/2505ct/Tumor1Big/lesion2505-1mm.mhd";
>>
>> fname[1] = dirname + "/3108ct/Tumor1Big/lesion3108-1mm.mhd";
>>
>> fname[2] = dirname + "/170957ct/Tumor1Big/lesion1709-1mm.mhd";
>>
>>
>>
>> // Create array of image readers
>>
>> vtkMetaImageReader **reader;
>>
>> reader = new (vtkMetaImageReader *[3]);
>>
>> for (int i = 0; i < 3; i++)
>>
>> reader[i] = vtkMetaImageReader::New();
>>
>>
>>
>> for (int i = 0; i < 3; i++){
>>
>> reader[i]->SetFileName(fname[i].*c_str*());
>>
>> reader[i]->Update();
>>
>> }
>>
>>
>>
>>
>>
>> // -----------------------
>>
>> // Create the VTK pipeline
>>
>> //
>>
>> // image0 image1 image2
>>
>> // dmcubes0 dmcubes1 dmcubes2
>>
>> // \ | /
>>
>> // vtkAppendPolyData
>>
>> // mapper/actor
>>
>> // renderer
>>
>> // -----------------------
>>
>> vtkDiscreteMarchingCubes **dmcubes;
>>
>> dmcubes = new (vtkDiscreteMarchingCubes *[3]);
>>
>> for (int i = 0; i < 3; i++){
>>
>> dmcubes[i] = vtkDiscreteMarchingCubes::New();
>>
>> dmcubes[i]->SetInputConnection(reader[i]->GetOutputPort());
>>
>> dmcubes[i]->SetNumberOfContours(1);
>>
>> dmcubes[i]->SetComputeGradients(0);
>>
>> dmcubes[i]->SetComputeScalars(0);
>>
>> dmcubes[i]->SetComputeNormals(1);
>>
>> dmcubes[i]->SetValue(i, 255);
>>
>> }
>>
>>
>>
>> vtkAppendPolyData *appendPD = vtkAppendPolyData::New();
>>
>> for (int i = 0; i < 3; i++)
>>
>> appendPD->AddInputConnection(dmcubes[i]->GetOutputPort());
>>
>>
>>
>> vtkPolyDataMapper *mapper = vtkPolyDataMapper::New();
>>
>> mapper = vtkPolyDataMapper::New();
>>
>> mapper->SetInputConnection(appendPD->GetOutputPort());
>>
>>
>>
>> vtkActor *actor = vtkActor::New();
>>
>> actor->SetMapper(mapper);
>>
>>
>>
>> Renderer->AddActor(actor);
>>
>>
>>
>> // -------------------------------
>>
>> // Reset the camera and initialize
>>
>> // -------------------------------
>>
>> Renderer->ResetCamera();
>>
>> RWI->Initialize();
>>
>> RWI->Start();
>>
>>
>>
>>
>>
>>
>>
>> Thank you
>>
>> Nigel McFarlane
>>
>> University of Bedfordshire UK
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> *From:* Dan Lipsa [mailto:dan.lipsa at kitware.com]
>> *Sent:* 06 August 2015 22:21
>> *To:* Nigel Mcfarlane <Nigel.Mcfarlane at beds.ac.uk>; vtkusers at vtk.org
>> *Subject:* Re: [vtkusers] vtkAppendPolydata - wrong extents on multiple
>> inputs
>>
>>
>>
>> > This request is propagated upstream and stops if a filter has its
>> inputs older than its output.
>>
>> I meant downstream. It has to check all filters as their properties might
>> change which will affect the final result.
>>
>>
>>
>> On Thu, Aug 6, 2015 at 5:12 PM Dan Lipsa <dan.lipsa at kitware.com> wrote:
>>
>> Nigel,
>>
>> The pipeline executive compares the modification time (
>> vtkObject::GetMTime()) for the output of a filter against each of its
>> inputs. If any of the inputs is newer, the filter is updated. It may be
>> that your filter does not update the time of its output properly. This
>> request is propagated upstream and stops if a filter has its inputs older
>> than its output. I would setup a breakpoint and look at the first update
>> for your filters.
>>
>>
>>
>> On Thu, Aug 6, 2015 at 9:20 AM Nigel Mcfarlane <
>> Nigel.Mcfarlane at beds.ac.uk> wrote:
>>
>> Dear vtkusers,
>>
>>
>>
>> I am creating a visual pipe in vtk 6.2.0 and I am having problems
>> connecting vtkAppendPolyData to multiple inputs which start from images of
>> different dimensions. The visual pipe converts a set of input images into
>> isosurfaces, adds scalars for colour and transparency, then merges them
>> into one polydata mesh so they can be depth sorted before rendering. Its
>> structure looks like this:
>>
>>
>>
>> //
>>
>> // image1 image2 image3
>>
>> // | | |
>>
>> // DMCubes1 DMCubes2 DMCubes3
>>
>> // | | |
>>
>> // AddScalars1 AddScalars2 AddScalars3
>>
>> // \ | /
>>
>> // \ | /
>>
>> // \ | /
>>
>> // vtkAppendPolyData
>>
>> // |
>>
>> // vtkDepthSortPolyData
>>
>> // |
>>
>> // Mapper/Actor
>>
>> // |
>>
>> // Renderer
>>
>> //
>>
>>
>>
>> The images are produced by vtkMetaImageReader, the “DMCubes” filters are
>> vtkDiscreteMarchingCubes, and the”AddScalars” filters are my own code.
>>
>>
>>
>> The problem is that this produces an image in which the
>> dimensions/extents of two of the images have clearly been set incorrectly.
>> I don’t know much about the way the vtk pipeline works, but I suppose that
>> an information request for the extents of the images travels up and back
>> down the pipeline, so the extents get set to that of the last input, and
>> then applied to all the inputs. The problem disappears if the input
>> branches are first independently updated by calling a manual Update() on
>> each of the AddScalars filters, but it returns if one of the DMCubes
>> filters is modified, which triggers another general update cycle.
>>
>>
>>
>> Is there any way to set up this pipeline so that it does not require a
>> manual update when the image inputs are modified?
>>
>>
>>
>> Nigel McFarlane
>>
>> University of Bedfordshire
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at:
>> http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtkusers
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20150819/05ecda73/attachment.html>
More information about the vtkusers
mailing list