Chronological Thread 

< Chronological >      < Thread >

---

Hi Brett,
I see now, you meant the isolated surfaces in image space. In fact I
was using the .solo.nrrd from stage1 as input to Cleaver.
Will try your workflow, might have questions :)

About testing the numerical accuracy, I will try doing it very soon and
report.

Thanks,
Petar



On Mon, Jun 2, 2014 at 8:30 PM, Brett Burton <bburton@sci.utah.edu> wrote:
> 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
>



--
All the best,
Petar Petrov
http://ppetrov.net

---

• Re: [SCIRUN-USERS] Biomesh3D resulting mesh shifted, Petar Petrov, 05/31/2014
  • Message not available
    • Message not available
      • Re: [SCIRUN-USERS] Biomesh3D resulting mesh shifted, Petar Petrov, 06/01/2014
        • Re: [SCIRUN-USERS] Biomesh3D resulting mesh shifted, Brett Burton, 06/01/2014
          • Re: [SCIRUN-USERS] Biomesh3D resulting mesh shifted, Petar Petrov, 06/02/2014
            • Re: [SCIRUN-USERS] Biomesh3D resulting mesh shifted, Brett Burton, 06/02/2014
              • Re: [SCIRUN-USERS] Biomesh3D resulting mesh shifted, Petar Petrov, 06/03/2014

---

Archive powered by MHonArc 2.6.18.