TTKMorseSmaleComplex returns a 1-Separatrices object (output port 1). It has the field

Thanks for the issue. <a class="user-mention notranslate" data-hovercard-type="use

hi Zohar,thanks for your message. <div class="email-quoted-reply

Thanks for the explanation, this resolved the issue. <span class="

SeparatrixFunctionMin/Max fields returned from TTKMorseSmaleComplex aren't correct,about topology-tool-kit/ttk

julien-tierny commented on May 17, 2024

Thanks for the issue.
@GuillaumeFavelier can you have a look at that?

from ttk.

julien-tierny commented on May 17, 2024

hi Zohar,
I am not able to replicate the issue. I was afraid this could be a problem with our recent windows port, but it does not seem to be the case either.
see the attached image below.

even under windows, these fields have the correct type (in this example double) and the correct value range (the pipeline is executed on your input data).

you can verify this by clicking in ParaView on the "1-Separatrices" output of the Morse-Smale complex filter and then clicking on the "Information" tab, that provides the stats shown in the screenshot (where the cursor is).

can you try to replicate this in ParaView?
thanks!

from ttk.

zoharl3 commented on May 17, 2024

I think this is from the time I used linux. In any case, if there's a need, I can check this on linux as well. If I create only an MSC object, then the values are fine. If I simplify the data beforehand, then they aren't. More specifically, it seems that the OutputOffsetScalarField from the simplification is different than sfield. I'm probably missing something here, because the simplification filters the persistence. Maybe these values should make sense in this case. They look like the VertexIdentifier from the PersistenceDiagram. Coming to think of it, I'm not too sure how the pipeline works with simplification. I attached .pvsm, but let me know if you need more details on how to reproduce the scene.

On 9/01/18 18:32, Julien Tierny wrote: hi Zohar, I am not able to replicate the issue. I was afraid this could be a problem with our recent windows port, but it does not seem to be the case either. see the attached image below. even under windows, these fields have the correct type (in this example double) and the correct value range (the pipeline is executed on your input data). you can verify this by clicking in ParaView on the "1-Separatrices" output of the Morse-Smale complex filter and then clicking on the "Information" tab, that provides the stats shown in the screenshot. can you try to replicate this in ParaView? thanks! — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#79 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEOjv6-8sT9ItTLN6VCMvcBnPdsQF31Lks5tIvn5gaJpZM4RVHTf>.

from ttk.

julien-tierny commented on May 17, 2024

hi Zohar, thanks for your message.

If I create only an MSC object, then the values are fine. If I simplify the data beforehand, then they aren't. More specifically, it seems that the OutputOffsetScalarField from the simplification is different than sfield. I'm probably missing something here, because the simplification filters the persistence. Maybe these values should make sense in this case. They look like the VertexIdentifier from the PersistenceDiagram. Coming to think of it, I'm not too sure how the pipeline works with simplification.

I see now. I don't believe this is a bug then. By default, the MS complex is computed on the first scalar field that is available on the selected object (alphabetical order). The module TopologicalSimplification indeed produces a field of integers (named "OutputOffsetScalarField") that is used by the rest of TTK to disambiguate flat plateaus. In ParaView, this field appears first in the list (see the attached image) so by default, the Morse-Smale complex will be computed on this field (which is of integer type). Then the statistics on the separatrices will be integer values indeed. ![pipeline](https://user-images.githubusercontent.com/3018628/34719718-1cb73b9e-f53c-11e7-85c7-d5f460e5bc6c.png) Here, when computing the MS complex, you should: 1) select the field "sField" (see the attached screenshot) and 2) check the box "Use Input Offset Field" (see the attached screenshot too) The field "sField" contains the simplified data values (in double, float, whatever type). Checking the box "Use Input Offset Field" informs the MS complex that some simplification happened and that the field "OutputOffsetScalarField" should be used to disambiguate flat plateaus. Note that again, users need to select the appropriate field to be used as offset field (in this example, there's only one integer field, so there's no ambiguity and the corresponding rolling list should be shaded). If you carefully select the two above items, the MS complex will be computed on the simplified floating point data values and the stats on the separatrices will be of the proper type. Note that this MS complex itself is identical to what you obtained before ("OutputOffsetScalarField" is an injective integer field that captures exactly the simplified topology of the data). Thanks for confirming that applying the two steps above solves your issue. Cheers, -- Dr Julien Tierny CNRS Researcher Sorbonne Universites UPMC - LIP6 http://lip6.fr/Julien.Tierny

…

On Tuesday, 9 January 2018 11:55:37 CET zoharl3 wrote: I think this is from the time I used linux. In any case, if there's a need, I can check this on linux as well. If I create only an MSC object, then the values are fine. If I simplify the data beforehand, then they aren't. More specifically, it seems that the OutputOffsetScalarField from the simplification is different than sfield. I'm probably missing something here, because the simplification filters the persistence. Maybe these values should make sense in this case. They look like the VertexIdentifier from the PersistenceDiagram. Coming to think of it, I'm not too sure how the pipeline works with simplification. I attached .pvsm, but let me know if you need more details on how to reproduce the scene. On 9/01/18 18:32, Julien Tierny wrote: > hi Zohar, > I am not able to replicate the issue. I was afraid this could be a > problem with our recent windows port, but it does not seem to be the > case either. > see the attached image below. > > even under windows, these fields have the correct type (in this > example double) and the correct value range (the pipeline is executed > on your input data). > > you can verify this by clicking in ParaView on the "1-Separatrices" > output of the Morse-Smale complex filter and then clicking on the > "Information" tab, that provides the stats shown in the screenshot. > > can you try to replicate this in ParaView? > thanks! > > ? > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#79 (comment) > >, or mute the thread > <https://github.com/notifications/unsubscribe-auth/AEOjv6-8sT9ItTLN6VCMvcB > nPdsQF31Lks5tIvn5gaJpZM4RVHTf>.

from ttk.

zoharl3 commented on May 17, 2024

Thanks for the explanation, this resolved the issue.

…

On 10/01/18 00:50, Julien Tierny wrote: hi Zohar, thanks for your message. > If I create only an MSC object, then the values are fine. If I simplify > the data beforehand, then they aren't. More specifically, it seems that > the OutputOffsetScalarField from the simplification is different than > sfield. I'm probably missing something here, because the simplification > filters the persistence. Maybe these values should make sense in this > case. They look like the VertexIdentifier from the PersistenceDiagram. > Coming to think of it, I'm not too sure how the pipeline works with > simplification. I see now. I don't believe this is a bug then. By default, the MS complex is computed on the first scalar field that is available on the selected object (alphabetical order). The module TopologicalSimplification indeed produces a field of integers (named "OutputOffsetScalarField") that is used by the rest of TTK to disambiguate flat plateaus. In ParaView, this field appears first in the list (see the attached image) so by default, the Morse-Smale complex will be computed on this field (which is of integer type). Then the statistics on the separatrices will be integer values indeed. Here, when computing the MS complex, you should: 1) select the field "sField" (see the attached screenshot) and 2) check the box "Use Input Offset Field" (see the attached screenshot too) The field "sField" contains the simplified data values (in double, float, whatever type). Checking the box "Use Input Offset Field" informs the MS complex that some simplification happened and that the field "OutputOffsetScalarField" should be used to disambiguate flat plateaus. Note that again, users need to select the appropriate field to be used as offset field (in this example, there's only one integer field, so there's no ambiguity and the corresponding rolling list should be shaded). If you carefully select the two above items, the MS complex will be computed on the simplified floating point data values and the stats on the separatrices will be of the proper type. Note that this MS complex itself is identical to what you obtained before ("OutputOffsetScalarField" is an injective integer field that captures exactly the simplified topology of the data). Thanks for confirming that applying the two steps above solves your issue.

from ttk.

julien-tierny commented on May 17, 2024

Thanks. I close the issue then.
Cheers

from ttk.

SeparatrixFunctionMin/Max fields returned from TTKMorseSmaleComplex aren't correct about ttk HOT 6 CLOSED

Comments (6)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent