[vtkusers] vtkDiscreteMarchingCubes and vtkMarchingCubes do not handle sub-extents correctly

[Bill Lorensen]

Contour filter uses SynchronizedTemplates.
On Nov 26, 2015 4:01 AM, "Grothausmann, Roman Dr." <
grothausmann.roman at mh-hannover.de> wrote:

> Many thanks Bill for looking into this. I had a look at the code of
> vtkContourFilter and vtk(Discrete)MarchingCubes. My guess was that
> vtk(Discrete)MarchingCubes lacks an implementation of RequestUpdateExtent.
> However, I'm not sufficiently familiar with VTK's streaming to create an
> appropriate method, especially the changes for vtk-6.3 still confuse me.
>
> I've been wondering what is the difference between vtkMarchingCubes and
> vtkContourFilter run on an image. So far I've thought that vtkContourFilter
> runs vtkMarchingCubes when the input is an image, however the code of
> vtkContourFilter does not refer to vtkMarchingCubes at all. Still, for a
> binary image as input the results seem to be the same, aren't they?
>
> Again, many thanks for looking into this.
> Roman
>
> On 25/11/15 21:58, Bill Lorensen wrote:
>
>> Roman,
>>
>> I think that only algorithms that implement ThreadedExecute() will
>> properly work in your situation. vtkMarchingCubes and
>> vtkDiscreteMarchingCubes do not implement that method.
>>
>> I suggest using vtkContourFilter instead of vtkMarchingCubes. There is
>> no equivalent for vtkDiscreteMarchingCubes.
>>
>> Perhaps in the future I can look at DiscreteMarchingCubes.
>>
>> Bill
>>
>> On Wed, Nov 25, 2015 at 1:53 PM, Bill Lorensen <bill.lorensen at gmail.com>
>> wrote:
>>
>>> Roman,
>>>
>>> With your sample programs and my data, I can reproduce the bad results
>>> for Marching and DiscreteCubes. (without ImagePad - that is another
>>> issue).
>>>
>>> Now to find the bugs....
>>>
>>> Bill
>>>
>>> On Wed, Nov 25, 2015 at 11:27 AM, Bill Lorensen <bill.lorensen at gmail.com>
>>> wrote:
>>>
>>>> Looks like a bug. I'll take a look.
>>>>
>>>>
>>>> On Wed, Nov 25, 2015 at 9:04 AM, Grothausmann, Roman Dr.
>>>> <grothausmann.roman at mh-hannover.de> wrote:
>>>>
>>>>> I just noticed that vtkDiscreteMarchingCubes and also vtkMarchingCubes
>>>>> do
>>>>> not handle sub-extents correctly. It seems both filters do not handle
>>>>> the
>>>>> translation of each sub-extent. If the result is saved in a PVTP-file
>>>>> and
>>>>> opened in ParaView, the content of each VTP-file is placed over the
>>>>> others.
>>>>> In contrast vtkContourFilter does handle the translation of each
>>>>> sub-extent
>>>>> correctly, the content of each VTP-file is positioned correctly, see
>>>>> e.g.
>>>>>
>>>>> https://github.com/romangrothausmann/VTK-CLIs/blob/9eac8644101360d18f2ff70928d457aabddbbbf0/marching-cubes_MPI.cxx
>>>>>
>>>>> On 24/11/15 14:26, Grothausmann, Roman Dr. wrote:
>>>>>
>>>>>>
>>>>>> Dear mailing list members,
>>>>>>
>>>>>>
>>>>>> Trying to cap the output of vtkDiscreteMarchingCubes by applying
>>>>>> vtkImageConstantPad on the input before does not work if running
>>>>>> vtkStreamingDemandDrivenPipeline by e.g. a vtkMPIController.
>>>>>>
>>>>>> If I run this program with the parameter for capping, i.e. employing
>>>>>> vtkImageConstantPad:
>>>>>>
>>>>>>
>>>>>> https://github.com/romangrothausmann/VTK-CLIs/blob/9eac8644101360d18f2ff70928d457aabddbbbf0/discrete_marching-cubes_MPI.cxx#L90
>>>>>>
>>>>>>
>>>>>> I get an error such as:
>>>>>> vtkImageData (0x1868190): GetScalarPointer: Pixel (0, 0, 341) not in
>>>>>> memory.
>>>>>>    Current extent= (249, 499, 0, 479, 0, 429)
>>>>>>
>>>>>> It seems that vtkImageConstantPad processes the wrong sub-extent.
>>>>>> Would
>>>>>> that be
>>>>>> a filter internal problem or of my code?
>>>>>>
>>>>>> Could the problem be related to the fact that I try to combine
>>>>>> structured
>>>>>> extent
>>>>>> (Index (IJK) based, not using ghost levels) with piece-based extent
>>>>>> that
>>>>>> uses
>>>>>> ghost levels?
>>>>>>
>>>>>> The problem even occurs when the extent is not extended at all.
>>>>>> The program works as expected if vtkImageConstantPad is avoided.
>>>>>>
>>>>>> Any help or hints are very much appreciated
>>>>>> Roman
>>>>>>
>>>>>>
>>>>> --
>>>>> Dr. Roman Grothausmann
>>>>>
>>>>> Tomographie und Digitale Bildverarbeitung
>>>>> Tomography and Digital Image Analysis
>>>>>
>>>>> Institut für Funktionelle und Angewandte Anatomie, OE 4120
>>>>> Medizinische Hochschule Hannover
>>>>> Carl-Neuberg-Str. 1
>>>>> D-30625 Hannover
>>>>>
>>>>> Tel. +49 511 532-2900
>>>>> _______________________________________________
>>>>> 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
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Unpaid intern in BillsBasement at noware dot com
>>>>
>>>
>>>
>>>
>>> --
>>> Unpaid intern in BillsBasement at noware dot com
>>>
>>
>>
>>
>>
> --
> Dr. Roman Grothausmann
>
> Tomographie und Digitale Bildverarbeitung
> Tomography and Digital Image Analysis
>
> Institut für Funktionelle und Angewandte Anatomie, OE 4120
> Medizinische Hochschule Hannover
> Carl-Neuberg-Str. 1
> D-30625 Hannover
>
> Tel. +49 511 532-2900
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20151126/1640447d/attachment.html>