Fix: --crop-bottom for equirect data

[kevinddchen]

I am trying to process an equirect video using --crop-bottom=0.2 to remove myself from the bottom portion of the frames.

ns-process-data video \
    --camera-type equirectangular \
    --images-per-equirect 8 \
    --crop-bottom 0.2 \
    ...

Example frame:

However, I get training images that include my body:

I was able to identify an error in this function:

nerfstudio/nerfstudio/process_data/equirect_utils.py

Lines 213 to 230 in 6b60855

	def _crop_bound_arr_vertical(
	bound_arr: list, fov: int, crop_factor: Tuple[float, float, float, float] = (0.0, 0.0, 0.0, 0.0)
	) -> list:
	"""Returns a list of vertical bounds adjusted for cropping.
	Args:
	bound_arr (list): Original list of vertical bounds in ascending order.
	fov (int): Field of view of the camera.
	crop_factor (Tuple[float, float, float, float]): Crop arr (top, bottom, left, right).
	Returns:
	list: Cropped bound arr
	"""
	if crop_factor[1] > 0:
	bound_arr = _crop_bottom(bound_arr, fov, crop_factor[1])
	if crop_factor[0] > 0:
	bound_arr = _crop_top(bound_arr, fov, crop_factor[0])
	return bound_arr

bound_arr is initially the array [-45, 0, 45], which means that it will generate perspective training images using 120 deg FoV cameras pointed at altitudes -45, 0, and 45 degrees. However, with --crop-bottom=0.2 we end up with bound_arr == [-57.75, -25.5, -6.0] at the end of the function, which is not what we want.

Doing the math a little bit, I discovered that it is likely that the implementations for _crop_top() and _crop_bottom() were accidentally swapped, as once i made this change, I ended up with bound_arr == [6.0, 25.5, 57.75] which is more correct. Indeed, a +6 degree altitude is the minimum value for excluding the bottom 20% of the equirect for a 120 deg FoV perspective camera. This is the new training image created:

Additional notes:

• Using --crop-factor 0.2 0 0 0 (i.e. crop top 20%) now correctly gives bound_arr == [-57.75, -25.5, -6.0]
• I think the implementation is inherently incorrect, since using --crop-factor 0.1 0.1 0 0 (i.e. crop top and bottom 10%) gives bound_arr == [-22.3125, -4.125, 12.0], where all altitudes should actually be between -12 and 12 degrees. But that is work for another PR (which I am happy to do!)