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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

layer.scale and Image [indices] #640

Open
tlambert03 opened this issue Oct 28, 2019 · 4 comments
Open

layer.scale and Image [indices] #640

tlambert03 opened this issue Oct 28, 2019 · 4 comments
Labels
Milestone

Comments

@tlambert03
Copy link
Member

@tlambert03 tlambert03 commented Oct 28, 2019

馃悰?

not sure if this is a feature request or a bug. but I was confused by the behavior of the sliders when layer.scale != [1, 1, 1] ... I haven't had time to look at the appropriate code yet, but here was the behavior I was "expecting" to happen from, I guess, previous experience:

  • when in "2D" mode (with a 3D image), the dims slider should have as many "stops" as there are planes in the image. That is: I shouldn't be able to move the slider without updating either the Image index or the visual. And regardless of any voxel anisotropy, the min/max bounds of the Image [index] status at the bottom left should reflect the image dimensions as sampled/captured.
  • when in "3D" mode, I expect it to work like it currently does, wherein the image is resampled according to the scale factor I have set to maintain the proper "realspace" proportions.

however, these two things seem to be at odds. If I set layer.scale[0] != 1, then the 3D image looks correct, but the max slider range becomes nz * layer.scale[0]. Relatedly, the first time I set the parameter, I used my physical pixel sizes (something like [0.25, 0.1, 0.1]) and was similarly surprised by what it did to the apparent image shape. Is this just something that still needs to be ironed out? or was there a "long-view" vision for layer.scale that I'm not yet appreciating?

@sofroniewn

This comment has been minimized.

Copy link
Contributor

@sofroniewn sofroniewn commented Oct 29, 2019

I'd say this is something that needs more thought, right now we have the concept of a "step size" in our range, which will influence the indices that we slice at - see here

p = np.round(p / self.range[axis][2]).astype(int)

part of the motivation for this was to handle image pyramids where an axis has been downsampled but you still want the slider to have the same total range as the base of the pyramid, the code that was added at that time might be causing any counter intuitive behavior that you are noting.

I'm quite open to improving this, but we need to make sure the right thing still happens in the pyramid layer, the normal 2D case, and the 3D case as you note.

In general we also havn't thought too much about physical coordinates, units, and how they might get incorporated, so now might be a good time to think about some of that too

@sofroniewn sofroniewn added this to the 0.2.0 milestone Oct 29, 2019
@sofroniewn

This comment has been minimized.

Copy link
Contributor

@sofroniewn sofroniewn commented Oct 29, 2019

So testing this out more now. I can see how the current implementation might be undesirable, especially for the case where scale < 1 and you are looking in 2D, as your slider now will not give you the ability to look at every slice - on the other hand if you are applying a scale I think it makes sense that the indices in the bottom left status bar contain the values after the scale.

We should keep discussing this, but I don't want it to hold up #607. I'll post this over on #607 too, but for now I think you should add that scale factor so the fps is accurate and then we can revisit if we change the scale usage

@tlambert03

This comment has been minimized.

Copy link
Member Author

@tlambert03 tlambert03 commented Oct 29, 2019

sounds good. I will also try to familiarize myself with the handling of pyramids and scale soon too. It may well be that the current implementation is already optimal for the internal handling... and perhaps all that will be necessary is to change the presentation slightly to the user in the GUI?.
I'll update #607 accordingly for now. thanks!

@sofroniewn

This comment has been minimized.

Copy link
Contributor

@sofroniewn sofroniewn commented Oct 29, 2019

if you look at the pyramid code, you'll actually see an additional _scale_view parameter on the layer gets used to enable rescaling of the downsample levels to the base level, and still give you the option for a global scale too

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can鈥檛 perform that action at this time.