SCIRun User Mailing List

Text archives Help


Re: [SCIRUN-USERS] Biomesh3D resulting mesh shifted


Chronological Thread 
  • From: Brett Burton <bburton@sci.utah.edu>
  • To: Petar Petrov <pip010@gmail.com>
  • Cc: Hon Fai Choi <honfai.choi@gmail.com>, Jess Tate <jess@sci.utah.edu>, "scirun-users@sci.utah.edu" <scirun-users@sci.utah.edu>
  • Subject: Re: [SCIRUN-USERS] Biomesh3D resulting mesh shifted
  • Date: Sun, 1 Jun 2014 18:19:33 -0600
The blockiness of the Cleaver mesh is actually the reason that I use BioMesh
and Cleaver together. BioMesh can create those smooth, tight surfaces that
look more realistic. These tight surfaces can then be read into cleaver. If
you are using the api version of Cleaver, you cannot control the sizing field
information, but the GUI version (which has not officially been released yet
- give it a few weeks) allows for the sizing fields. So, even though its a
little more manual labor, it gets the best of both worlds. Smooth surfaces
and quick mesh generation with a structured grid work.

Also, Cleaver meshes generally produce meshes with more consistent angles
than BioMesh. Element optimization in BioMesh relies on a Delaunay
triangulation, while Cleaver splits hexahedra to fit the background indicator
functions with a constraint on how small the smallest angle can be.

Brett

On Jun 1, 2014, at 5:27 AM, Petar Petrov <pip010@gmail.com> wrote:

> I looked into Cleaver too. In fact was planning to send a msg on their
> mailing list. (for explanation of the 2 params I can change)
> For me the experience with Biomesh3D and Cleaver :
> with Biomesh3D it takes alot of time to produce a mesh but it is more
> optimal,
> with Cleaver it takes seconds for a mesh, but the mesh is far from
> optimal (it looks more like structured mesh and boundaries are rough)
> my initial test and screens of the model (cross cut)
>
> =========================
> pipeline #nodes #elements
> ------------------------
> Cleaver 127K 725K
> BioMesh3D 36K 170K
> ------------------------
> Factor x3.5 x4.25
> =========================
>
>
> On Sat, May 31, 2014 at 5:48 PM, Hon Fai Choi <honfai.choi@gmail.com> wrote:
>> Thanks all very much for the input! I actually already subsample the
>> image, but I have to subsample a lot before obtaining a reasonable
>> computation time.
>> Brett, it would be great if you could forward some descriptions of
>> your workflow combining BioMesh and Cleaver. I wasn't aware of
>> Cleaver, but it looks like a nice tool. I don't seem to get your
>> attachments though; I didn't get the SCIRun network you attached in
>> your previous email.
>>
>> thanks again for all the feedback,
>>
>> Hon Fai
>>
>>
>>
>> On Sat, May 31, 2014 at 5:15 PM, Brett Burton <brett.m.burton@gmail.com>
>> wrote:
>>> I actually use a combination of BioMesh and Cleaver (also available
>>> through SCI). It is a much more complicated pathway and requires both a
>>> SCIRun change in the sizing field as well as a transformation after the
>>> mesh is complete (also in SCIRun), but it reduces the length of meshing
>>> by quite a bit (though you will need a machine with a lot of RAM for big
>>> meshes) and it provides a more structured mesh - which makes it faster to
>>> read once it's done. If you're interested, I can forward some
>>> instructions to you on this method.
>>>
>>> Brett
>>>
>>>
>>> On May 31, 2014, at 3:55 AM, Petar Petrov <pip010@gmail.com> wrote:
>>>
>>>> "
>>>> There are two parameters in the model_config.py parameter file that
>>>> control the sizing field
>>>> "
>>>> if you are referring to MAX_SIZING_FIELD and SIZING_SCALE_VAR, only
>>>> the first one is accepted !
>>>> So in practice there is one parameter, which is: MAX_SIZING_FIELD.
>>>> I'm working on my own version of BioMesh3D and planning to introduce
>>>> MAX_SIZING_FIELD not as a scalar but as a gradient to better control
>>>> adaptive nature of the mesh.
>>>>
>>>> As it stands it is barely useful for my meshes (human/rat brain) as
>>>> Stage6 is a huge!!! bottleneck ... it takes week for 1process to
>>>> finish!!!
>>>>
>>>> On Fri, May 30, 2014 at 8:31 PM, Jess Tate <jess@sci.utah.edu> wrote:
>>>>> Hi,
>>>>>
>>>>> There are two parameters in the model_config.py parameter file that
>>>>> control the sizing field, which influences the size of the mesh
>>>>> elements. Increasing either of these should increase the size of the
>>>>> elements. However, there is an additional consideration, since the
>>>>> smallest elements are supposed to be there to represent small features.
>>>>> If you want to increase the minimum size of the elements, you will
>>>>> lose some of these features. If you are ok with that, the easiest way
>>>>> to increase the element size is to smooth the original segmentation or
>>>>> downsample it. downsampling will also speed up the entire pipeline.
>>>>>
>>>>> cheers,
>>>>> Jess
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On May 30, 2014, at 10:27 AM, Brett Burton <zaracay@gmail.com> wrote:
>>>>>
>>>>>> Hon,
>>>>>>
>>>>>> There is a .tf parser in the C++ code that runs in the background of
>>>>>> the python scripts. About 2 weeks ago, I also tried to figure this
>>>>>> out, but I am much more skilled in SCIRun, so I gave up and
>>>>>> transformed it using SCIRun. We could probably figure this out in a
>>>>>> day or two and it would also probably be better, let me talk to Jess
>>>>>> about it.
>>>>>>
>>>>>> Sizing field min value scaling:
>>>>>> The parameters in the BioMesh config file does not allow for a minimum
>>>>>> size restriction, but you can control this by altering your sizing
>>>>>> field files ([YourFile]_sf.nrrd]). You can use SCIRun to open this
>>>>>> sizing field file (ReadField module with the nrrd filetype selected).
>>>>>> Then use the CalculateFieldData module. In the UI of this module you
>>>>>> can scale and translate the sizing field data. For example, lets say
>>>>>> your sizing field goes from 0.5 to 12. You can use a statement like
>>>>>> DATA = DATA+2; to get your new sizing field to run from 2.5 to 14. You
>>>>>> can then save this file out again as a nrrd and replace the sizing
>>>>>> field in your BioMesh output folder. I've attached a network as an
>>>>>> example. If you have multiple materials, you may want to run this
>>>>>> network multiple times, or duplicate the modules within the network.
>>>>>>
>>>>>> Brett
>>>>>>
>>>>>> <ChangeSizingField.srn><Heart_sf.nrrd>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On May 30, 2014, at 2:19 AM, Hon Fai Choi <honfai.choi@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Jess and Brett,
>>>>>>>
>>>>>>> thank you very much for the suggestions. The shift that I have is
>>>>>>> quite large, I have attached a picture as illustration. Could you also
>>>>>>> tell me how I can read the .tf file? I tried to open it with Wordpad,
>>>>>>> but it seems to be a binary file.
>>>>>>>
>>>>>>> I have also an additional question regarding BioMesh3D. Is there a way
>>>>>>> that I can put a threshold on the minimal size of the mesh elements? I
>>>>>>> have followed the user documentation and the input parameter for the
>>>>>>> element size seems to only limit the maximal size of the elements.
>>>>>>>
>>>>>>> thanks,
>>>>>>> Hon Fai
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 29, 2014 at 8:51 PM, Brett Burton <zaracay@gmail.com>
>>>>>>> wrote:
>>>>>>>> Like Jess implied, Biomesh transforms the original segmentation into
>>>>>>>> a different coordinate space in order to generate the original mesh.
>>>>>>>> during this first transformation, it creates a transformation file
>>>>>>>> ([FileName]_pad_transform.tf). It uses this transform to shift the
>>>>>>>> heart back, but as you may notice by the name of the .tf file,
>>>>>>>> Biomesh also pads your data. If you are finding that this shift is
>>>>>>>> very slight, it is probably due to the padding. Jess's approach
>>>>>>>> will work, in both cases, to get you aligned again.
>>>>>>>>
>>>>>>>> Let us know if you have further questions
>>>>>>>>
>>>>>>>> Brett
>>>>>>>>
>>>>>>>> On May 29, 2014, at 12:38 PM, Jess Tate <jess@sci.utah.edu> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> BioMesh should transform the final mesh back into the original
>>>>>>>>> space. Look for the particle-union.tets-labeled_transformed.fld
>>>>>>>>> file. If it is not there, then the last step didn't finish. If
>>>>>>>>> the file is not there or is still the wrong size or origin, you can
>>>>>>>>> fix it pretty easily in SCIRun. Load in the mesh and original
>>>>>>>>> segmentation. extract the surface of one of the regions in the
>>>>>>>>> segmentation (or all of them) with GetDomainBoundary. Then use
>>>>>>>>> SplitFieldByConnectedRegion or SplitFieldByDomain to remove any
>>>>>>>>> excess space around the tet mesh from BioMesh. Then use
>>>>>>>>> AlignMeshBoundingBox to align the tet mesh to the segmentation
>>>>>>>>> surface. This module will also give you the transformation used if
>>>>>>>>> need for other meshes.
>>>>>>>>>
>>>>>>>>> cheers,
>>>>>>>>> Jess
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On May 29, 2014, at 2:55 AM, Hon Fai Choi wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I have a question regarding Biomesh3D. I use Seg3D to create the
>>>>>>>>>> segmentations and save them as .nrrd files as input to Biomesh3D.
>>>>>>>>>> When
>>>>>>>>>> I export the resulting mesh with SciRun as a .vtk file and compare
>>>>>>>>>> it
>>>>>>>>>> with the original image, then the mesh is not in the right
>>>>>>>>>> location.
>>>>>>>>>> It's somehow shifted relative to where it should be. Has anyone
>>>>>>>>>> encountered the same problem and knows how to fix this?
>>>>>>>>>>
>>>>>>>>>> thanks,
>>>>>>>>>> Hon Fai
>>>>>>>>>
>>>>>>>>
>>>>>>> <shifted_mesh.png>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> All the best,
>>>> Petar Petrov
>>>> http://ppetrov.net
>>>
>
>
>
> --
> All the best,
> Petar Petrov
> http://ppetrov.net
> <OUTPUT_biomesh.png><OUTPUT_cleaver.png>


Archive powered by MHonArc 2.6.18.

Top of page