SeparatrixFunctionMin/Max fields returned from TTKMorseSmaleComplex aren't correct #79

zoharl3 · 2018-01-06T00:44:32Z

TTKMorseSmaleComplex returns a 1-Separatrices object (output port 1). It has the fields
SeparatrixFunctionMaximum, SeparatrixFunctionMinimum, SeparatrixFunctionDifference
which suppose to reflect the scalar field values. They seem to be wrong. For example, my function is \in [-1,1], and the returned values are integers \in [1,25].
For more details:
https://groups.google.com/forum/#!topic/ttk-users/ms6nAKAbTgQ

julien-tierny · 2018-01-07T14:37:31Z

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

julien-tierny · 2018-01-09T05:32:41Z

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!

zoharl3 · 2018-01-09T10:55:34Z

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>.

julien-tierny · 2018-01-09T11:50:28Z

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>.

zoharl3 · 2018-01-09T12:44:40Z

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.

julien-tierny · 2018-01-09T13:06:32Z

Thanks. I close the issue then.
Cheers

julien-tierny closed this as completed Jan 9, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SeparatrixFunctionMin/Max fields returned from TTKMorseSmaleComplex aren't correct #79

SeparatrixFunctionMin/Max fields returned from TTKMorseSmaleComplex aren't correct #79

zoharl3 commented Jan 6, 2018

julien-tierny commented Jan 7, 2018

julien-tierny commented Jan 9, 2018 •

edited

zoharl3 commented Jan 9, 2018 via email

julien-tierny commented Jan 9, 2018 via email •

edited

zoharl3 commented Jan 9, 2018 via email

julien-tierny commented Jan 9, 2018

SeparatrixFunctionMin/Max fields returned from TTKMorseSmaleComplex aren't correct #79

SeparatrixFunctionMin/Max fields returned from TTKMorseSmaleComplex aren't correct #79

Comments

zoharl3 commented Jan 6, 2018

julien-tierny commented Jan 7, 2018

julien-tierny commented Jan 9, 2018 • edited

zoharl3 commented Jan 9, 2018 via email

julien-tierny commented Jan 9, 2018 via email • edited

zoharl3 commented Jan 9, 2018 via email

julien-tierny commented Jan 9, 2018

julien-tierny commented Jan 9, 2018 •

edited

julien-tierny commented Jan 9, 2018 via email •

edited