-
Notifications
You must be signed in to change notification settings - Fork 21
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
biased shift of cube2equi and equi2cube #8
Comments
Thanks for submitting an issue. Yeah, I've been struggling to make Would you mind testing this in your notebook to see if a cubemap will transform the same way it did for me? import os.path as osp
import matplotlib.pyplot as plt
import numpy as np
from PIL import Image
import equilib
cubestrip = Image.open(osp.join('other_data', 'Cubestrip.jpg'))
cubemap = np.array(cubestrip)
plt.imshow(cubemap)
chw_cubemap = cubemap.transpose(2, 0, 1)
equi = equilib.cube2equi(
cubemap=chw_cubemap,
cube_format="horizon",
height=200,
width=400,
mode="bilinear",
)
plt.imshow(equi.transpose(1, 2, 0))
out_cubemap = equilib.equi2cube(
equi=equi,
rots={"roll": 0, "pitch": 0, "yaw": 0},
w_face=100,
cube_format="horizon",
mode="bilinear",
)
plt.imshow(out_cubemap.transpose(1, 2, 0)) Unfortunately, converting back to cubemaps adds noise and distortion due to grid sampling, interpolation, rescaling, etc..., but rotational bias should be minimal. BTW, I noticed that |
Oh, nvm. I misunderstood your question, you looped this 10 times. When iterating the same transform on the same data many times, it does seem the shifts increase quite a bit. I will take a look in the internals when I have time, but it seems really hard to make the transform robust since this transform is irreversible. |
@haruishi43 Thanks for your reply. I find large |
@qsh-zh I will document each algorithm in the future. I haven't got around to it yet :/ All algorithms (
For
For
|
I'm suspecting that the sampling could be offset by half a pixel, though I'm new to the library so I'd hope for someone more familiar to review my reasoning. I looked at the numpy implementation of nearest sampling, and it rounds the sample location to the nearest integer. However, pixel centers are offset by 0.5 from the integer coordinates of pixels. So I think correct rounding for the coordinates would be Similarly in bilinear filtering, the code currently reads:
whereas I believe the correct implementation would be:
|
@Oletus Thanks for investigating! Does it remove the biased shift? |
…angular There were multiple sources of half-pixel offsets, which caused small inaccuracies when converting between cube maps and equirectangular images. These are now fixed. Fixes issue haruishi43#8
…angular There were multiple sources of half-pixel offsets, which caused small inaccuracies when converting between cube maps and equirectangular images. These are now fixed. Fixes issue haruishi43#8
closing this! thanks to @Oletus |
I find there are shifts if we run cube2equi and equi2cube. How can we avoid or decrease such shifts
The text was updated successfully, but these errors were encountered: