[vtkusers] going from binary images to 2D contours

Bill Lorensen bill.lorensen at gmail.com
Fri Mar 2 17:56:37 EST 2012 

David,

I agree with your solution.

Bill

On Fri, Mar 2, 2012 at 5:39 PM, David Gobbi <david.gobbi at gmail.com> wrote:
> I think the best thing would be for the default MaximumLength to be
> VTK_INT_MAX.  The current default of 1000 is arbitrary, does anyone
> know why it was chosen?  Maybe because of an old graphics hardware
> limit?
>
> Warning if the maximum length is exceeded doesn't work for people who
> set MaximumLength to a small number on purpose.  For example, when
> generating triangle strips for rendering, I usually set MaximumLength
> to 10 because a higher number degrades the performance of the
> CellPicker and CellLocator.
>
>  - David
>
>
> On Fri, Mar 2, 2012 at 3:08 PM, Bill Lorensen <bill.lorensen at gmail.com> wrote:
>> Perhaps we should warn the user if the maximum length is met. A
>> warning certainly would have saved Mark some time.
>>
>> Bill
>>
>> On Fri, Mar 2, 2012 at 12:11 AM, David Gobbi <david.gobbi at gmail.com> wrote:
>>> You can set MaximumLength as high as you need to.  The only
>>> downside is that some filters are less efficient when the input data
>>> has really long polylines or really long triangle strips.  These filters
>>> include several you are familiar with: vtkCutter, vtkClipPolyData,
>>> vtkLinearExtrusionFIlter.  But unless you are applying these filters
>>> after vtkStripper, there is no downside at all.
>>>
>>>  - David
>>>
>>>
>>> On Thu, Mar 1, 2012 at 9:50 PM, Mark Roden <mmroden at gmail.com> wrote:
>>>> Hi David,
>>>>
>>>> It seems that the culprit was the Maximum Length variable; when that
>>>> got set to 10000, instead of the default of 1000, the resulting masks
>>>> work quite well.  The resulting masks look like the marching squares
>>>> output, but the response from the rest of the program are much faster.
>>>>
>>>> I'm just curious-- are there any other consequences of changing that
>>>> variable that you're aware of?
>>>>
>>>> I've also seen the double/float problem, but I'm not sure it's
>>>> entirely relevant (yet).
>>>>
>>>> Thanks for your help,
>>>> Mark
>>>>
>>>> On Thu, Mar 1, 2012 at 7:44 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>> The stripper is the only VTK filter for joining line segments
>>>>> together, it is the appropriate filter to be using here.  It's failing
>>>>> because it is getting bad input.  Here's what I think is happening:
>>>>>
>>>>> I'm guessing that you're images have very high resolution.  The
>>>>> vtkMarchingSquares filter uses single-precision floats, which have
>>>>> an epsilon of around 1e-7.  Because of this rather large epsilon,
>>>>> together with the shortness of the line segments that result from
>>>>> having a high-res image, the point locator in vtkMarchingSquares is
>>>>> sometimes going to merge points that it shouldn't, giving rise to tiny
>>>>> degenerate loops in the output that confuse the vtkStripper.
>>>>>
>>>>> For my own code for generating contours (the code I linked earlier),
>>>>> I wrote my own marching squares algorithm that uses double precision.
>>>>> So failures due to accidentally merged points are still possible, but
>>>>> are a billion times less likely due to the increased precision.  If you
>>>>> have compiled your own VTK, you could just edit the line in
>>>>> vtkMarchingSquares that reads vtkPoints::New() and change it to
>>>>> vtkPoints::New(VTK_DOUBLE) instead, it might make the problem
>>>>> go away.
>>>>>
>>>>> (As an aside, one of the problem with VTK, in general, is that it
>>>>> relies too much on floating-point comparisons for many of its
>>>>> algorithms),
>>>>>
>>>>>  - David
>>>>>
>>>>> On Thu, Mar 1, 2012 at 6:52 PM, Mark Roden <mmroden at gmail.com> wrote:
>>>>>> Hi David,
>>>>>>
>>>>>> It appears that the big time cost is that the marching squares output
>>>>>> is several thousand line segments, each with three points.  The
>>>>>> stripper bounces the number of line segments down to 38, and that
>>>>>> makes the rest of the program much faster.
>>>>>>
>>>>>> Is there a vtk filter, other than the stripper, that can 'linearize'
>>>>>> all of those lines into a single line, if they are in fact continuous
>>>>>> (as they are in this case)?  A joining filter or the like?  I can
>>>>>> write something on my own that attaches the line segments, one to
>>>>>> another, but if the solution already exists, I'd like to go with
>>>>>> what's tested.
>>>>>>
>>>>>> Thanks,
>>>>>> Mark
>>>>>>
>>>>>> On Thu, Mar 1, 2012 at 10:13 AM, Mark Roden <mmroden at gmail.com> wrote:
>>>>>>> Hi David,
>>>>>>>
>>>>>>> You're right, removing the stripper removed those errors.
>>>>>>>
>>>>>>> The program is now quite a bit slower-- I suspect that the stripper
>>>>>>> was causing some other code to be able to run faster.  That will
>>>>>>> probably be my next question, once I get a profiler attached to this.
>>>>>>>
>>>>>>> Thanks!
>>>>>>> Mark
>>>>>>>
>>>>>>> On Thu, Mar 1, 2012 at 7:44 AM, Mark Roden <mmroden at gmail.com> wrote:
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> Sorry, I made a mistake earlier; I'm using marching squares, not
>>>>>>>> cubes-- but I am following it with the stripper, which I'll try
>>>>>>>> removing now.  And if that doesn't work, I'll check the stripper
>>>>>>>> output for single polylines per contours.
>>>>>>>>
>>>>>>>> Thanks for the starting point,
>>>>>>>> Mark
>>>>>>>>
>>>>>>>> On Wed, Feb 29, 2012 at 9:03 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>>>> From the image, the problem looks fairly obvious: the contour points
>>>>>>>>> aren't in order, so when you draw lines between the points, you get
>>>>>>>>> extra lines that cross the image.  So probably the most important
>>>>>>>>> question is, what do you do, if anything, to make sure that the points
>>>>>>>>> in the contours that you produce from the binary image are correctly
>>>>>>>>> ordered?
>>>>>>>>>
>>>>>>>>> In your other email you mentioned vtkMarchingSquares, and in this
>>>>>>>>> email you say you use vtkMarchingCubes (followed, I'm guessing, by
>>>>>>>>> vtkCutter).  Then maybe you're using vtkStripper to try to get the
>>>>>>>>> points into the correct order before saving them?  If you are using
>>>>>>>>> vtkStripper, it looks like it is producing multiple polylines per
>>>>>>>>> contour, when it should just be producing one polyline per contour.
>>>>>>>>> This could be the result of numeric precision issues in vtkCutter
>>>>>>>>> (given the choice, you should use vtkMarchingSquares on each slice,
>>>>>>>>> rather than vtkMarchingCubes followed by cutter).
>>>>>>>>>
>>>>>>>>>  - David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, Feb 29, 2012 at 9:17 PM, Mark Roden <mmroden at gmail.com> wrote:
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> Maybe I should just send you my data :)  I don't think that my problem
>>>>>>>>>> has to do with being near boundaries, as my objects are away from the
>>>>>>>>>> edges of the image (but not in z-- that's solved that by padding the
>>>>>>>>>> image by a plane in either direction in z).
>>>>>>>>>>
>>>>>>>>>> The problem I'm having is that, somewhere along the way, the contours
>>>>>>>>>> are being transformed from 'proper' contours, in the case of the
>>>>>>>>>> larger mask, to ones with extra connections.
>>>>>>>>>>
>>>>>>>>>> The binarization is done via the process we discussed on the other
>>>>>>>>>> thread; that is, the contour is binarized by first following that
>>>>>>>>>> function to translate polygons to lines, then
>>>>>>>>>> vtkPolyDataToImageStencil, then vtkImageStencil.  The reverse, from
>>>>>>>>>> binary to contour (which actually appears on the image), is done by
>>>>>>>>>> vtkMarchingCubes.  This output has extra lines.
>>>>>>>>>>
>>>>>>>>>> I would love to be able to intercept the binary mask in transit, but
>>>>>>>>>> unfortunately, some way that I have vtkImageViewer2 set up isn't
>>>>>>>>>> allowing me to see it.  However, you can see the body mask from the
>>>>>>>>>> contour image 'body lines.png' I've attached, and then from the second
>>>>>>>>>> overlay image 'body with strange lines.png' the extra lines on a
>>>>>>>>>> single plane when overlaid with the data.
>>>>>>>>>>
>>>>>>>>>> Have you seen this kind of behavior before in either method?  That
>>>>>>>>>> this behavior appeared either when I ran the old extrusion method or
>>>>>>>>>> with the new line-based method suggests to me that it's a problem with
>>>>>>>>>> the marching squares approach.  Hence my original question.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Mark
>>>>>>>>>>
>>>>>>>>>> On Wed, Feb 29, 2012 at 4:10 PM, David Gobbi <david.gobbi at gmail.com> wrote:
>>>>>>>>>>> My own experience is that vtkMarchingSquares is the best way to
>>>>>>>>>>> contour a 2D image.  It is the only 2D contouring filter I'm aware of
>>>>>>>>>>> that correctly orients the contours, i.e. so that you can be sure what
>>>>>>>>>>> is "inside" and what is "outside."
>>>>>>>>>>>
>>>>>>>>>>> But vtkMarchingSquares generates open contours whenever the contour
>>>>>>>>>>> reaches the bounds of the image... that might be the cause of the
>>>>>>>>>>> failures that you are seeing.  Because of this problem, I've written
>>>>>>>>>>> my own version of marching squares that always produces closed
>>>>>>>>>>> contours, you can find the code here:
>>>>>>>>>>> https://github.com/dgobbi/ToolCursor/blob/master/vtkImageToROIContourData.cxx
>>>>>>>>>>>
>>>>>>>>>>>  - David
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Feb 29, 2012 at 4:43 PM, Mark Roden <mmroden at gmail.com> wrote:
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> After a length conversation over on the developer list, I've now got a
>>>>>>>>>>>> very fast way to convert 2D contours from DICOM rtstructs into binary
>>>>>>>>>>>> data.  Now I need to do the reverse.  I already have a method, but
>>>>>>>>>>>> this approach is failing for large images-- and by 'failing', I mean
>>>>>>>>>>>> producing contours that do not look like the binary data.
>>>>>>>>>>>>
>>>>>>>>>>>> I need contours in the xy, xz, and yz planes.  It's also possible to
>>>>>>>>>>>> have multiple contours in any given plane.
>>>>>>>>>>>>
>>>>>>>>>>>> Right now, I'm using vtkMarchingSquares, but as I said, this is not
>>>>>>>>>>>> working for larger contours, and produces spurious results.
>>>>>>>>>>>>
>>>>>>>>>>>> I note that there's also vtkContourFilter, vtkMarchingContourFilter,
>>>>>>>>>>>> vtkSliceCubes, vtkImageMarchingCubes, etc.  Is there any reason to
>>>>>>>>>>>> choose one of these over the other?  What would I need for my
>>>>>>>>>>>> particular case?
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Mark
>>> _______________________________________________
>>> 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
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.vtk.org/mailman/listinfo/vtkusers
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com



-- 
Unpaid intern in BillsBasement at noware dot com

More information about the vtkusers mailing list