-
Notifications
You must be signed in to change notification settings - Fork 233
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
Comments
Hi Igor, thanks for your nice words.
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 |
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 gifsExpected aspect ratioThis is how the data is supposed to look like with the correct aspect ratio enforced by Data stretched to the boxThis 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. As for what you ask towards the end:
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. |
Ok, we're getting closer I think :)
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. |
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. |
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? |
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 As for the data. It comes from here: http://www.mrt.kit.edu/z/publ/download/velodyneslam/dataset.html |
Hmm, so you mean, when doing scatter/plot/quiver you don't want the limits to change?
|
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() |
Great, so I'll keep this open until we have an option to not auto grow the bounding box limits. |
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:
The output looks like this:
![ipyvolume](https://user-images.githubusercontent.com/1893598/47441833-59c3fd80-d7b1-11e8-9597-a76fcb454572.png)
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
![ipyvolume 1](https://user-images.githubusercontent.com/1893598/47441951-ae677880-d7b1-11e8-824f-0f8f01b2f8dc.png)
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):UPD:
For now I've kinda solved it by moving the camera:
The text was updated successfully, but these errors were encountered: