Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add possibility to edit min and max of intensity range #4630

Merged
merged 13 commits into from
Jul 8, 2020

Conversation

MichaelBuessemeyer
Copy link
Contributor

@MichaelBuessemeyer MichaelBuessemeyer commented May 27, 2020

This PR adds the possibility for the user to edit the minimum and maximum possible value for the intensity range.
The use case is described in #4526.

URL of deployed dev instance (used for testing):

Steps to test:

  • Open a dataset (view mode is enough)

  • Toggle the edit function for min and max. The button is on the left of the reload-layer button.

  • enter some desired values

  • the histogram and the intensityRange slider's range should adjust to the entered values.

  • then adjust the intensityRange and you should be able to see something again :)

  • please try breaking the feature by entering some random and uncommon values

Issues:


@MichaelBuessemeyer MichaelBuessemeyer marked this pull request as ready for review June 5, 2020 13:45
@MichaelBuessemeyer MichaelBuessemeyer changed the title added possibility to edit min and max of intensity range Add possibility to edit min and max of intensity range Jun 11, 2020
Copy link
Member

@daniel-wer daniel-wer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cool PR, looks really good and the functionality is there, but I encountered some issues during testing that I wanted to note down:

  • I'm not sure about the scientific notation feature. Try entering a large max value like 400123 by hand - you end up with 4.0012e+43 which is not what you wanted to type. It's confusing that the value changes while you type. If we still want the scientific notation feature to avoid overly long numbers, I would suggest to add a mechanism to confirm the entered number by clicking on a button. Then, the number could change to scientific notation. However, I don't think this is very important.
  • Somehow, I ended up with NaN in the min field, but I can't reproduce now :/ Disregard if you also can't reproduce.
  • I tried to delete the whole min value, which crashed the site. Aftwerwards, I couldn't reopen the histogram without webKnossos crashing. I checked the store state and a min value of "" was persisted which I had to fix through the dev console.
  • Not very high priority, but there is a light blue area (triangular shape) to the right of the largest histogram value when the configured max is even larger. See the picture:
    max_range_float

@MichaelBuessemeyer
Copy link
Contributor Author

Thanks a lot for finding those bugs 🐛. Hopefully, I fixed them all. Could you please check that again?

I'm not sure about the scientific notation feature. Try entering a large max value like 400123 by hand - you end up with 4.0012e+43 which is not what you wanted to type. It's confusing that the value changes while you type. If we still want the scientific notation feature to avoid overly long numbers, I would suggest to add a mechanism to confirm the entered number by clicking on a button. Then, the number could change to scientific notation. However, I don't think this is very important.

Thus we should not support displying in scientific notation? Is that what you meant?

@daniel-wer
Copy link
Member

Thus we should not support displying in scientific notation? Is that what you meant?

Yes, I don't think it is very important, and I don't see an easy way to implement it with good UX, so I wouldn't add it for now.

Comment on lines +141 to +144
const activeRegionRightLimit = Math.min(histogramMax, intensityRangeMax);
const activeRegionLeftLimit = Math.max(histogramMin, intensityRangeMin);
activeRegion.lineTo(((activeRegionRightLimit - minRange) / fullLength) * canvasWidth, 0);
activeRegion.lineTo(((activeRegionLeftLimit - minRange) / fullLength) * canvasWidth, 0);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MichaelBuessemeyer My assumption would be that histogramMax is always <= intensityRangeMax and therefore, it should be sufficient to simply use histogramMax in the activeRegion.lineTo call. Is that assumption correct?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe I was confusing the histogramMax and intensityRangeMax. Hmm, could you distinguish what each of those is again for me? Maybe we can find more descriptive names that make the difference more clear.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you really confused both of them:

  • histogramMax is the maximum color value that is included in the histogram data send by the backend.
  • intensityRangeMax is the maximum color value of the displayed color range and is equal to the higher value of the slide. What's new now is that this value can be greater than histogramMax as you can see it in your example:
    max_range_float

To be honest I think the names are pretty good as the intensityRange is the range given by the slider and thus intensityRangeMax as the upper limit of that range is not far-fetched (in my opinion) -> Feel free to argue about that.

The same goes for histogramMax as this is the highest color value included in the histogram data.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah understood, that makes sense, sorry for the confusion :)

Copy link
Member

@daniel-wer daniel-wer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your fixes @MichaelBuessemeyer, I tested again and noticed some more small things, but we're getting there 👍

  • The behavior when entering an entirely new number is kind of weird. For example, the max value is set to 100, now you enter 255 instead. When entering the 2, the max slider of the histogram is automatically set to 2, and when entering the 55 afterwards, the max slider remains at 2. However, the max slider was set to 100 before and it's a little unexpected that this changed (although I understand why it happened). A possible solution for this could be to debounce the onChange of the input field, so that the histogram only changes after a second of no change or so. What do you think?
  • The edit histogram button should not be available for segmentation layers (or layers without a histogram if there are any others?)
  • [Low Pri] Maybe it's an easy fix, if not nevermind: The two vertical side lines of the active area are not vertical, but slightly angled to the middle. To see this enter 100 and 102 for min and max and look at the active area.

@MichaelBuessemeyer
Copy link
Contributor Author

The behavior when entering an entirely new number is kind of weird. For example, the max value is set to 100, now you enter 255 instead. When entering the 2, the max slider of the histogram is automatically set to 2, and when entering the 55 afterwards, the max slider remains at 2. However, the max slider was set to 100 before and it's a little unexpected that this changed (although I understand why it happened). A possible solution for this could be to debounce the onChange of the input field so that the histogram only changes after a second of no change or so. What do you think?

I tried to tackle this by only updating when the events onPressEnter and onBlur are executed but apparently onPressEnter is not available for NumberInput in our antd version. 😖 Thus I choose to just debounce the update. I tested this and it feels pretty smooth 👍

[Low Pri] Maybe it's an easy fix, if not nevermind: The two vertical side lines of the active area are not vertical, but slightly angled to the middle. To see this enter 100 and 102 for min and max and look at the active area.

I cannot find the cause for this 😕

@daniel-wer Could you please check the small updates I just pushed?

Copy link
Member

@daniel-wer daniel-wer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, some final small suggestions, but basically LGTM 👍

@MichaelBuessemeyer
Copy link
Contributor Author

@daniel-wer Thanks for the suggestions. I just applied them.

Copy link
Member

@daniel-wer daniel-wer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome, thanks for the quick iterations 👍

@bulldozer-boy bulldozer-boy bot merged commit 8897c5e into master Jul 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Expose min/max for float layers
3 participants