shapeworks-dev-support

Text archives Help


Re: [shapeworks-dev-support] VTK File


Chronological Thread 
  • From: Alan Morris <amorris@sci.utah.edu>
  • To: Shireen Elhabian <shireen@sci.utah.edu>
  • Cc: 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:59:42 -0600
  • Ironport-sdr: sntNXEoqgKt7+xEggcus2lTYh6bWXOrPeHb3AuWWU9rJiDcP7NH+H3kILfGtRBkjvsF5FUczG0 eJWuQ6GlpqtHDMlqvgpXSAOPxks0eA9v4ymzgi1JwIFst/er6eRQYEmLWwwT2o55NERrjtNC1g hZEUtBxtNEdQ0gm5i0wx/KKMefeyOXErM+iJD3ILDDpQ3rvEfDAb5QoluGAfUDysyVUAUtY7Tt +arbue/LiT4west8P4iCL9i2nssnHGFr2BZCibx4VjN2Owl/slfQt2ug2wvxFO9KxYpalCG7ng LnQ=
Hi Shireen,

It seems that they've been successfully rasterized, but there was a
problem when running the optimization.

I've dug into it and it appears that the structures are just too
(physically) thin, regardless of the number of pixels wide. By
fiddling with the spacing, it seems to be happy to run just fine. I'm
not sure I understand the sensitivity to the spacing. Of course some
filters and operations are probably operating in physical coordinates.
But it seems like everything should just scale appropriately.

Alan

On Wed, Jun 3, 2020 at 9:51 AM Shireen Elhabian <shireen@sci.utah.edu> wrote:
>
> 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
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
>

Attachment: studio.png
Description: PNG image


Archive powered by MHonArc 2.6.18.

Top of page