shapeworks-dev-support

Text archives Help


Re: [shapeworks-dev-support] VTK File


Chronological Thread 
  • From: Shireen Elhabian <shireen@sci.utah.edu>
  • To: Alan Morris <amorris@sci.utah.edu>
  • Cc: Shireen Elhabian <shireen@sci.utah.edu>, Jadie Adams <jadieraeadams@gmail.com>, Allen Sanderson <allen@sci.utah.edu>, shapeworks-dev-support@sci.utah.edu, Cameron Christensen <cam@sci.utah.edu>
  • Subject: Re: [shapeworks-dev-support] VTK File
  • Date: Wed, 3 Jun 2020 09:47:36 -0600
  • Ironport-sdr: Ea3QVSEK82mNpNizZ6GrNZ9vFewAE7j+yKd/9tK99VeGnKq3+vQ0AZZZhPlEro9R3R6gwz2cUw EXQBS14DxdO0bOk7YxyD0PgBLR2rKtRx54C8JOdsmP9WaAzJoM+ldhbIXRi2XcBB29YRubAlQx ylbZPRblTL24IrXe95JVp0On1oXCq+v7AZtYmFu38q9cXVt0ZrmTdZlf0bmNdaOsxKyj11Obmb fukfkBcq4LtkOmrnm0GF5EgJhnPcjn7a6u0dv1NkJrxJLwUg6bXfBXuqMxB3ertKu37Ia8Kgid 1kA=
Hi Alan,

Is this related to Allen’s issue with converting mesh to binary image
(rasterization)?

> Shireen, do you know of a tool to better visualize a 3D image
> gradient?

itk-snap can visualize vector valued images as RBG.

thanks and best regards
Shireen


------------------------------------------
Shireen Elhabian, M.Sc., Ph.D.
Research Assistant Professor
School of Computing
Scientific Computing and Imaging Institute
University of Utah
WEB 2815
72 Central Campus Drive, Salt Lake City, UT, 84112
Phone (801) 587-3206
Fax (801) 585-6513
Home Page: http://www.sci.utah.edu/~shireen

> On Jun 3, 2020, at 8:57 AM, Alan Morris <amorris@sci.utah.edu> wrote:
>
> I'm working with the data that Jadie sent me. I'm not quite sure what
> the problem is yet. Somehow it seems the image gradient is wrong and
> the initial point placement is driven off the image. This is the case
> for both OpenVDB's (1e10 narrow band) and ITK's gradient computation.
>
> Shireen, do you know of a tool to better visualize a 3D image
> gradient? At the moment, I'm looking at the X, Y, and Z components
> separately in Paraview. In any case, I don't see anything obviously
> wrong with it for these images. Yet the "ApplyVectorConstraints"
> takes the gradient from the position starting at the zero crossing and
> follows it away from the surface and off the image.
>
> Alan
>
> On Tue, Jun 2, 2020 at 3:01 PM Jadie Adams <jadieraeadams@gmail.com> wrote:
>>
>> Hi Allen,
>>
>> Sounds like you figured it out before I got to trouble shooting. Please
>> let me know if the distance transform isn't as expected or if you could
>> use any more help.
>>
>> @Shireen Would you like me to make a github issue to address Allen
>> suggestions? I agree that min and max may be more clear than origin and
>> size,. But origin and size are used in commands across ShapeWorks, not
>> just in rastorization so we will have to be careful about making such
>> changes.
>>
>> Thanks,
>> Jadie
>>
>> On Tue, Jun 2, 2020 at 2:25 PM Allen Sanderson <allen@sci.utah.edu> wrote:
>>>
>>> Hi Shireen,
>>>
>>> I figured out the issue. The help message is not clear.
>>>
>>> % /Projects/ShapeWorks/ShapeWorks/bin/GenerateBinaryAndDTImagesFromMeshes
>>> -------------------------------
>>> GenerateBinaryAndDTImagesFromMeshes
>>> -------------------------------
>>> Compute binary images (i.e. segmentation) and their distance transforms
>>> of a given set of meshes (ply format)
>>> It uses a parameter file with the following tags
>>> - mesh: a list of ply file names for meshes to be processed
>>> - origin_x, origin_y, origin_z: the origin in physical units of the
>>> resulting distance transform
>>> - spacing_x, spacing_y, spacing_z: voxel spacing of the resulting
>>> distance transform
>>> - size_x, size_y, size_z: the size (rows,cols,slices) of the resulting
>>> distance transform
>>>
>>> When I read size I think measurement, as in the bounding box size
>>> (physical units). Which is what I was providing, 11,6,16. Especially
>>> because the other two inputs are in physical units. However, what is
>>> wanted the number of rows, cols, slices in the resulting image, 1100,
>>> 600, 1600. So there is a clarity issue.
>>>
>>> I think because the other inputs are physical units it would be better to
>>> have one supply everything in physical units. It could be either relative:
>>>
>>> origin_x, origin_y, origin_z
>>> size_x, size_y, size_z
>>>
>>> absolute:
>>>
>>> min_x, min_y, min_z
>>> max_x, max_y, max_z
>>>
>>> But for both is physical units (and in reality the origin and min are
>>> interchangeable). This does a couple of things, assures that all of the
>>> geometry is included as one typically knows the extents. Then internally
>>> the number of rows, columns, and slices are determined based on the
>>> spacing. Further, one can change the spacing and not need to calculate
>>> the number of rows, columns, and slices (and risk missing some geometry
>>> cause they were off by a decimal place).
>>>
>>> The other part that is confusing is stating “of the resulting distance
>>> transform” so it is for the output which if true then really the user has
>>> the ability to subsample a specific area of the mesh. Which is a nice
>>> feature but here again is not clear because at least for me I want all of
>>> the mesh sampled. Perhaps having something to this affect in the help but
>>> also the output message would be helpful.
>>>
>>> I have one rasterized image and waiting the DT to finish as my resulting
>>> image is 1100 x 600 x 1600.
>>>
>>> Cheers,
>>>
>>>
>>> Allen
>>>
>>>
>>>
>>> Allen Sanderson
>>>
>>> SCI Institute
>>>
>>> University of Utah
>>>
>>>
>>>
>>>
>>> On Jun 2, 2020, at 9:47 AM, Shireen Elhabian <shireen@sci.utah.edu> wrote:
>>>
>>> Hi Jadie,
>>>
>>> Could you help out with trouble shooting converting the attached mesh to
>>> distance transform / binary segmentation? In principle, should be similar
>>> to rasterizing femur meshes but it is not obvious what is different about
>>> this mesh expect not having triangular faces.
>>>
>>> thanks and best regards
>>> Shireen
>>>
>>>
>>> ------------------------------------------
>>> Shireen Elhabian, M.Sc., Ph.D.
>>> Research Assistant Professor
>>> School of Computing
>>> Scientific Computing and Imaging Institute
>>> University of Utah
>>> WEB 2815
>>> 72 Central Campus Drive, Salt Lake City, UT, 84112
>>> Phone (801) 587-3206
>>> Fax (801) 585-6513
>>> Home Page: http://www.sci.utah.edu/~shireen
>>>
>>> <example_surface_1_00.ply>
>>> <example_surface_1_00.vtk>
>>>
>>> On Jun 1, 2020, at 3:17 PM, Allen Sanderson <allen@sci.utah.edu> wrote:
>>>
>>> Hi Shireen,
>>>
>>> I did not use the center of mass to determine the origin as I know the
>>> bounding box. I even tried to make the BB slightly larger a some of the
>>> polygons are likely on the boundary. That resulted in no voxels.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> Allen
>>>
>>>
>>>
>>>
>>> On May 30, 2020, at 10:38 PM, Shireen Elhabian <shireen@sci.utah.edu>
>>> wrote:
>>>
>>> Hi Allen,
>>>
>>> The rasterization uses the vtkPolyDataToImageStencil filter. I don’t an
>>> obvious reason to restricting it to triangular mesh. How about the
>>> origin? Did you use the mesh’s center of mass to determine it?
>>>
>>> Regards
>>> Shireen
>>>
>>>
>>> ------------------------------------------
>>> Shireen Elhabian, M.Sc., Ph.D.
>>> Research Assistant Professor
>>> School of Computing
>>> Scientific Computing and Imaging Institute
>>> University of Utah
>>> WEB 2815
>>> 72 Central Campus Drive, Salt Lake City, UT, 84112
>>> Phone (801) 587-3206
>>> Fax (801) 585-6513
>>> Home Page: http://www.sci.utah.edu/~shireen
>>>
>>> On May 29, 2020, at 2:54 PM, Allen Sanderson <allen@sci.utah.edu> wrote:
>>>
>>> Attached are the original vtk and ply file if anyone wants to look at
>>> them.
>>>
>>> <example_surface_1_00.ply>
>>> <example_surface_1_00.vtk>
>>>
>>> On May 29, 2020, at 2:41 PM, Allen Sanderson <allen@sci.utah.edu> wrote:
>>>
>>> Hi Shireen,
>>>
>>> My VTK files contains polydata which I have converted over to ply files.
>>> See the image below from VIsIt of the ply data. However, the
>>> rasterization does not seen to be working correctly. I created an xml
>>> file based on the extents of the data :
>>>
>>> <?xml version="1.0" ?>
>>> <mesh>
>>> example_surface_1_00.ply
>>> </mesh>
>>> <origin_x> -5.2</origin_x>
>>> <origin_y> 0.0</origin_y>
>>> <origin_z>-15.0</origin_z>
>>> <size_x>10.4</size_x>
>>> <size_y> 5.2</size_y>
>>> <size_z>15.0</size_z>
>>> <spacing_x>0.01</spacing_x>
>>> <spacing_y>0.01</spacing_y>
>>> <spacing_z>0.01</spacing_z>
>>>
>>> I have tried different spacings, but that did not really change anything.
>>> I checked all of the surface normals and they are correct (pointing out
>>> of the volume). Does the rasterization strictly want triangles??? There
>>> were no complaints.
>>>
>>> Cheers,
>>>
>>> Allen
>>>
>>> <Screen Shot 2020-05-29 at 2.17.06 PM.png>
>>>
>>> <Screen Shot 2020-05-29 at 2.33.02 PM.png>
>>>
>>> On May 28, 2020, at 3:58 PM, Shireen Elhabian <shireen@sci.utah.edu>
>>> wrote:
>>>
>>> Hi Allen,
>>>
>>> Are your VTK files contain surface (triangular) meshes? Or volumetric
>>> meshes? As of now, ShapeWorks tools only support surface meshes. The
>>> femur use case (links below) should be a good starting point to see how
>>> you could groom/prep surface meshes to compute signed distance transforms
>>> as input to the Optimize phase.
>>>
>>> https://github.com/SCIInstitute/ShapeWorks/blob/master/Examples/Python/femur.py
>>> https://github.com/SCIInstitute/ShapeWorks/blob/master/Documentation/UseCases.md#Femur-Use-Case
>>>
>>> Though a bit late, happy Eid-ul-Fitr. Years ago I was in Egypt for
>>> Eid-ul-Fitr, then spent three weeks traveling around. I had a great time
>>> as it was the start of a three month tour around the Mediterranean Sea.
>>>
>>>
>>> Thanks for your greeting! Hope you and your family are safe and healthy.
>>>
>>> thanks and best regards
>>> Shireen
>>>
>>>
>>> ------------------------------------------
>>> Shireen Elhabian, M.Sc., Ph.D.
>>> Research Assistant Professor
>>> School of Computing
>>> Scientific Computing and Imaging Institute
>>> University of Utah
>>> WEB 2815
>>> 72 Central Campus Drive, Salt Lake City, UT, 84112
>>> Phone (801) 587-3206
>>> Fax (801) 585-6513
>>> Home Page: http://www.sci.utah.edu/~shireen
>>>
>>> On May 28, 2020, at 3:13 PM, Allen Sanderson <allen@sci.utah.edu> wrote:
>>>
>>> Hi,
>>>
>>> It seems this script will process VTK data.
>>>
>>> ShapeWorks/Examples/Scripts/FullPrepPipeline/FullPipelinePrepRunMeshtoDT.sh
>>>
>>> However this sub script:
>>>
>>> RasterizationVolumeOriginAndSize.sh
>>>
>>> Does not spit out the two files needed next:
>>>
>>> # convert meshes to distance transforms
>>> if [ $doMeshesToVolumes -eq 1 ]
>>> then
>>>
>>> origin_filename=${parentDir}origin_size/origin_sp${spacing}_nb${narrow_band}.txt
>>>
>>> size_filename=${parentDir}origin_size/size_sp${spacing}_nb${narrow_band}.txt
>>>
>>> I see the names in an xml file but not sure what to make of that.
>>>
>>> So at this point I am pretty lost. As such it would be really good to
>>> have a zoom chat so I can understand the pipeline. Especially as parts of
>>> the pipeline are not going to be needed - the data is located and
>>> oriented. But the bounding box is different. But for now I would just
>>> like to have and understand a working pipeline.
>>>
>>> I can supply two VTK files that can be used for the initial setup. I have
>>> time tomorrow anytime to meet.
>>>
>>>
>>> Cheers,
>>>
>>> Allen
>>>
>>>
>>> Allen Sanderson
>>> SCI Institute
>>> University of Utah
>>>
>>>
>>>
>>> On May 27, 2020, at 2:49 PM, Allen Sanderson <allen@sci.utah.edu> wrote:
>>>
>>> Hi Shireen,
>>>
>>> Though a bit late, happy Eid-ul-Fitr. Years ago I was in Egypt for
>>> Eid-ul-Fitr, then spent three weeks traveling around. I had a great time
>>> as it was the start of a three month tour around the Mediterranean Sea.
>>>
>>> I am finally working through all of the parts of ShapeWorks. I went
>>> through the ellipse example and now working with some of my VTK data. But
>>> I am not seeing documentation on starting with VTK files. Just nrrd
>>> data. I have files that describe a closed surface (and as a volume
>>> elements) that I wanted to use for some initial testing and to
>>> familiarize myself with all the tools and steps.
>>>
>>> I pinged Cam and Alan but they did not reply or did not know. Any
>>> pointers??
>>>
>>>
>>> Cheers,
>>>
>>> Allen
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>


Archive powered by MHonArc 2.6.18.

Top of page