X, Y, Z dimensions for shifts in motion correction

[ethanbb]

I just realized, using a simple test case and then verifying by looking through the code a bit, that the shifts returned from motion correction are in (Y, X, Z) order, i.e. the indexing order assuming a properly constructed movie object or mmap file is passed in, rather than (X, Y, Z) order. In places where variables have x, y, or z in the name, e.g. {x,y,z}_shifts_els, it seems that X actually refers to Y and vice versa.

Is this intentional? It's not causing any bugs because it's used consistently that way within the file, but if someone wants to do something else with the shifts they could get confused. I know at least one mesmerize docstring needs to change based on this.

[kushalkolar]

they probably mixed up how cartesian coordinates are usually written in xy order but matrices are rows, cols which becomes y, x if you put an image on a cartesian plane

[ethanbb]

Right, of course...but we have to be careful to keep track of this

[ethanbb]

I realized that tile_and_correct and tile_and_correct_3d contain some code with X and Y labeled correctly, mixing conventions (seemingly in a correct way, though it would be easy to get confused):

CaImAn/caiman/motion_correction.py

Lines 2194 to 2207 in bb55800

	shift_img_x = np.reshape(np.array(shfts)[:, 0], dim_grid)
	shift_img_y = np.reshape(np.array(shfts)[:, 1], dim_grid)
	diffs_phase_grid = np.reshape(np.array(diffs_phase), dim_grid)
	if shifts_opencv:
	if gSig_filt is not None:
	img = img_orig
	dims = img.shape
	x_grid, y_grid = np.meshgrid(np.arange(0., dims[1]).astype(
	np.float32), np.arange(0., dims[0]).astype(np.float32))
	m_reg = cv2.remap(img, cv2.resize(shift_img_y.astype(np.float32), dims[::-1]) + x_grid,
	cv2.resize(shift_img_x.astype(np.float32), dims[::-1]) + y_grid,
	cv2.INTER_CUBIC, borderMode=cv2.BORDER_REPLICATE)

Here, shift_img_x and shift_img_y are swapped, but x_grid and y_grid actually refer to X and Y respectively, so you have shift_img_y added to x_grid and vice versa.