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

Shrink box after ipv.squarelim() #193

Open
niosus opened this issue Oct 24, 2018 · 9 comments
Open

Shrink box after ipv.squarelim() #193

niosus opened this issue Oct 24, 2018 · 9 comments

Comments

@niosus
Copy link

niosus commented Oct 24, 2018

Hello and thanks so much for ipyvolume! This is great to visualize the LiDAR data that I work with.

The data I work with is very non-square, so I was browsing the issues with respect to how to make the box being not square. In the #35 (comment) you say, that it was not possible at the moment. Are there any changes since then?

To illustrate the problem.
I generate the data as follows:

import ipyvolume as ipv
ipv.figure(height=400, width=800)
ipv.scatter(np.array(x), np.array(y), np.array(z), size=0.2, marker="sphere")
ipv.squarelim()
ipv.show()

The output looks like this:
ipyvolume

The issue with this is that the data in XY direction spans approx. 60 meters, while in Z direction just 2 or 3. So when the data is padded by ipv.squarelim() the camera moves far away. It is already quite good as it is, but I would prefer to be able to not stick to a square box, which would enable the default view approx. like this (much closer):
ipyvolume 1

UPD:

For now I've kinda solved it by moving the camera:

f = ipv.figure(width=1000)
ipv.scatter(np.array(x), np.array(y), np.array(z), size=0.1, marker="sphere")
ipv.squarelim()
f.camera.up = (0, 0, 1)
f.camera.position = (0, 0, 10)
f.camera.fov = 10
f.camera.lookAt([0,0,0])
ipv.show()
@maartenbreddels
Copy link
Collaborator

Hi Igor,

thanks for your nice words.
Until this day I have yet to find out what the issue is with the non-squareness. Many people complain about it, but I haven't found the clear description what exactly the issue is. The bounding box is square, that is currently a limitation, but that does not limit you from making a nonsquare xyzlim. For instance:

ipv.xlim(-20, 80)
ipv.ylim(-10, 90)
ipv.zlim(-1, 5)

Would this solve the issue, or, as you give in the update, you want the data to be kept 'square' (as in equal aspect), but simply zoom in?

cheers,

Maarten

@niosus
Copy link
Author

niosus commented Oct 30, 2018

Hey Maarten! Thanks for your reply. Yeah, I've seen that there seems to be some confusion as to the squareness of the box. It is something that is relatively hard to explain. Let me try to give a go at it.

In short, the issue with the solution you propose with the limits is that this is not solving the problem of aspect ratio. I think it's clear at this point that we seem to be having issues with non-square data. For the sake of example, let's consider that I have the data that spans 100 meters in x and y directions but only 5 meters in z directions (just like the limits suggested by you). The issue is that the sides of the bounding box (viewport) are always equal, while the data span is not. That results in stretching the data, making 5 meters in z direction look exactly as long as 100 meters in x and y in our example.

Let me try to illustrate this on my data.

Example gifs

Expected aspect ratio

This is how the data is supposed to look like with the correct aspect ratio enforced by ipv.squarelim():

velodyneactual

Data stretched to the box

This is how the data looks when using limits.

ipv.xlim(-20, 80)
ipv.ylim(-10, 90)
ipv.zlim(-1, 5)

You can see that it gets stretched and looks nothing like it should.

velodyneskewed

As for what you ask towards the end:

Would this solve the issue, or, as you give in the update, you want the data to be kept 'square' (as in equal aspect), but simply zoom in?

Ultimately I would want a non-square box, but it seems that this is not possible, right? The non-square box would ensure my data kept 'square' (equal aspect), while not being very far from the camera looking at it by default and having axis near it.

I hope I could explain the issue at least to some degree... Anyway, at this point my solution of moving the camera seems to do what I want and the only thing I am missing is axis being close to the data, but that is a minor issue. So this issue is definitely not high priority one.

@maartenbreddels
Copy link
Collaborator

Ok, we're getting closer I think :)
How would this work?

ipv.xlim(-20, 15)
ipv.ylim(-10, -5)
ipv.zlim(-1, 5)

I mean, you can forget about the bounding box, you can consider it eye candy right? Or is there something really important about the bounding box that you need, or the axes?

Also, which may be good to know, you can zoom in the data (not the camera) if you scroll while keeping Cmd (osx) pressed. You can also toggle this option from the toolbar, let me know if you find this feature useful.

@niosus
Copy link
Author

niosus commented Oct 30, 2018

Ah, ok! It was not clear to me that the data is not cut by the box! Nice!

Setting small limits shows exactly what I need. I can just disable the drawing of the box to make is look cleaner.

ipv.xlim(-10, 10)
ipv.ylim(-10, 10)
ipv.zlim(-10, 10)

This makes me able to control the camera by the size of the bounding (not really bounding anymore, though 😆 ) box. This is probably not very intuitive, but is easier than playing with the camera.

Anyway, the main idea here is that I was needing a way to look at my data closeup while ensuring that the data aspect ratio is preserved.

How it looks like now (note the box is fully in view)

velodynesmallbox

@maartenbreddels
Copy link
Collaborator

It is a really pretty viz btw. Is the data public, or can you share it?

I agree it is a bit weird that the bounding box does not bound :) It's more a bug than a feature, but I kind of like it.

So are all issues solved now?

@niosus
Copy link
Author

niosus commented Oct 30, 2018

Actually, not completely. While my original way of solving this is ugly because of all the camera controls this one suffers when plotting to an existing figure with ipv.plot. This messes up with limits and they have to be reset. Is there a way to keep them fixed?

As for the data. It comes from here: http://www.mrt.kit.edu/z/publ/download/velodyneslam/dataset.html
It comes in the form of range images, which I unproject to get point clouds. I will probably make the notebook open when I'm done with what I want to test.

@maartenbreddels
Copy link
Collaborator

Hmm, so you mean, when doing scatter/plot/quiver you don't want the limits to change?
A hack would be:

ipv.pylab._grow_limits = lambda *ignore: None

@niosus
Copy link
Author

niosus commented Oct 30, 2018

Cool! This works. Thanks so much!

So the fully working workaround for not having a rectangular bounding vox for my usecase is to shrink the box to be smaller than data and to stop it from growing when adding new data as follows:

import ipyvolume as ipv
ipv.pylab._grow_limits = lambda *ignore: None
ipv.figure(height=400, width=800)
ipv.scatter(np.array(x), np.array(y), np.array(z), size=0.2, marker="sphere")
ipv.xlim(-10, 10)
ipv.ylim(-10, 10)
ipv.zlim(-10, 10)
ipv.show()

@maartenbreddels
Copy link
Collaborator

Great, so I'll keep this open until we have an option to not auto grow the bounding box limits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants