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: Mon, 2 Jun 2014 12:30:47 -0600
Petar,

I have not tested the jittery interfaces, though I know that the primary
developer was working on this problem before he left. I believe the team
that are still on the project are working on this problem.

As for reading in the tight surfaces, you can perform this call after stage 2
of Biomesh. If you run Biomesh with the flag -s1:2, it will run the first
two phases and produce files labeled [labelName].tight.nrrd. These files
have indicator properties needed for Cleaver (positive inside the volume,
negative outside), and they have smooth, tightened surfaces. The only
problem with them is that they have been transformed into a different
coordinate space, which can be re-aligned in SCIRun. My meshing pipeline
goes something like this:

Run Biomesh -s1:2
open Output directory and copy all .tight.nrrd files into a new
directory
Run Cleaver on .tight.nrrd files
save output in matlab format
Open SCIRun
read in original .nrrd file
read in Cleaver output
Match dimensions of the two files by padding the original .nrrd file
(Biomesh pads the file)
Align the mesh bounding boxes

So you can see, it is a little more manual labor, but with the Cleaver speed
up in meshing it saves time. If you need a more thorough description, I can
provide one. I'd be interested to see, however, if with the tight surfaces
you get the same amount of error due to the jitter interfaces.

Brett



On Jun 2, 2014, at 4:08 AM, Petar Petrov <pip010@gmail.com> wrote:

> Hi Brett,
> combining best of both world sounds exciting. "These tight surfaces
> can then be read into cleaver", not sure how you do, care to shred
> some light?
> But the boundary surfaces are only fully defined after stage6 of
> Biomesh3D, which is the big bottleneck !??
>
> " 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. "
>
> It is true with Biomesh you can and often end up with some degenerate
> tets here and there! But those are trivial to post process and fix.
> FixMesh module inside scirun always did the job for me! On the other
> hand the jitter-like interfaces in Cleaver will introduce HUGE!?
> numerical error. I have compared structured vs unstructured vs
> analytic solution for perfect sphere and dipole as a source. adaptive
> mesh error ~ 5-10%, structured ~30-40%. Will do a test and compare
> this time a cleaver mesh!
>
> What do you think? and do you have any idea how accurate is the mesh you
> use?
>
>
> On Mon, Jun 2, 2014 at 2:19 AM, Brett Burton <bburton@sci.utah.edu> wrote:
>> 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>
>>
>
>
>
> --
> All the best,
> Petar Petrov
> http://ppetrov.net


Archive powered by MHonArc 2.6.18.

Top of page