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

Surface actor colormap fix #430

Merged
merged 4 commits into from
Jul 9, 2021

Conversation

amit-chaudhari1
Copy link
Contributor

Hi!
This is a fix for issue #429 .
@SunTzunami and I hopped on a call and fixed it together.

Earlier

Now

Screenshot 2021-05-01 at 6 42 31 PM

I think, this is exactly how It should look...
I've also changed the documentation to include the range of the Individual color values.
In case someone else is confused due to this.

@codecov
Copy link

codecov bot commented May 1, 2021

Codecov Report

Merging #430 (5e56a7d) into master (b7f09ab) will increase coverage by 0.00%.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #430   +/-   ##
=======================================
  Coverage   88.87%   88.88%           
=======================================
  Files          23       23           
  Lines        5393     5396    +3     
  Branches      696      697    +1     
=======================================
+ Hits         4793     4796    +3     
  Misses        415      415           
  Partials      185      185           
Impacted Files Coverage Δ
fury/actor.py 92.95% <ø> (ø)
fury/shaders/base.py 91.37% <0.00%> (+0.47%) ⬆️

@SunTzunami
Copy link
Member

@amitchaudhari9121 Thanks for the PR.
And yes that's how it's supposed to look!!

Copy link
Contributor

@skoudoro skoudoro left a comment

Choose a reason for hiding this comment

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

Hi @amitchaudhari9121,

Thank you for this fix. As usual, it needs tests to avoid reproducing this issue.

Furthermore, we need to check what is the rules. Are the other actors expecting 0-1 or 0-255. we should make sure that is uniform everywhere.

@amit-chaudhari1
Copy link
Contributor Author

Furthermore, we need to check what is the rules. Are the other actors expecting 0-1 or 0-255. we should make sure that is uniform everywhere.

I've skimmed actor.py through all mentions of color, and yes.
It is the norm in all of actor.py.

As usual, it needs tests to avoid reproducing this issue.

I'm not sure on how do i go about testing it.
I'd like suggestions about this.

Do we need to test it?
Like nothing stops working if you don't give it a proper input. ( I tried giving it 255, thinking it would crash, but it just rendered with a wrong colormap )
Even If I go above the limit of 1, It seems to work fine, Just not display color properly.

@SunTzunami
Copy link
Member

I think you could raise an error when the user inputs a color that's out of bounds. @skoudoro will be able to guide better.

@skoudoro
Copy link
Contributor

skoudoro commented May 6, 2021

We might let pass this PR and create a specific PR for all actors to raise an error if a color is out of bounds. Still thinking about it 🤔 ...

@amit-chaudhari1
Copy link
Contributor Author

Ok 👌
Thank you!

@guaje
Copy link
Contributor

guaje commented Jul 8, 2021

@amitchaudhari9121, @skoudoro, and @SunTzunami.

This is blocking #362. Is any of you working on the "check out of bounds" PR or what are the steps to merge/close this and #362?

@SunTzunami
Copy link
Member

@guaje once this is done, #362 will work as intended and I'll update it to be merged.
As for the out of bounds, I did a quick scan of actor.py. The following functions seem to take input range from 0 to 255 -

  1. slicer
  2. odf_slicer

Unsure about -

  1. tensor_slicer as the range of acceptable colors is not clearly mentioned but the docstring mentions RGB input.
  2. _tensor_slicer_mapper as the range of acceptable colors is not clearly mentioned but the docstring mentions RGB input.

@skoudoro and @amitchaudhari9121

@amit-chaudhari1
Copy link
Contributor Author

@guaje I can't find the time to work for fury for the moment, I'm busy with my intern at Linux foundation,
Could you please explain how this is blocking #362 ?

As far as i remember (its been weeks since those commits), going out of bounds just messes up the colormap displayed.
which is hard to notice at times.

Personally, I don't think we need to add tests for it, it's mentioned clearly in the doc for that function, and any wrong input does not crash anything. We could merge this as is, and not have any problems.

@skoudoro @SunTzunami your thoughts?

@SunTzunami
Copy link
Member

SunTzunami commented Jul 9, 2021

@amitchaudhari9121 for #362 to work optimally, colormaps need to work with surface actor (which was not the case before this PR). Once this PR is merged, colormaps will work with surface actor and #362 will work.

@skoudoro
Copy link
Contributor

skoudoro commented Jul 9, 2021

Hi All,

This PR can be merged so I will go ahead. However, we need to clarify the rules concerning the color ([0-1], vs [0-255]).

Let's create an issue to remember that we need to handle the color in all actors. I suppose, there is a function for that in utils.py or we need to create it.

@skoudoro
Copy link
Contributor

skoudoro commented Jul 9, 2021

Thanks @amitchaudhari9121 for this. Merging!

@skoudoro skoudoro merged commit 5ddd888 into fury-gl:master Jul 9, 2021
@skoudoro skoudoro added this to the v0.8.0 milestone Jul 9, 2021
@skoudoro skoudoro added the type:Bug Fix Something isn't working label Jul 9, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:Bug Fix Something isn't working
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants