docs: image

[Pwhsky]

• Added __future__ type hints to now use Image instead of 'Image'
• Changed relative imports to absolute imports.

[cmanzo]

Replace all instances of Union[...] with |
Ensure all classes support both Image and np.ndarray, including lists of each (list[Image] and list[np.ndarray]). Update type hints in method signatures accordingly as well as in the Methods section of the docstring.

[cmanzo]

Remove imports of List, Dict, and other generics from typing, using built-in list, dict, etc., instead.

[cmanzo]

Ensure that "Examples" is always used in the plural form, consistent with "Methods" and "Parameters".

Additionally, all example code should follow the standard of importing deeptrack as dt and referencing dt.Image, etc.
@giovannivolpe please confirm that you like the latter choice

[Pwhsky]

Implemented feedback except for examples import statements.

I think in the examples of the image module the context is clearer if we have from deeptrack imports.

[cmanzo]

Implemented feedback except for examples import statements.

I think in the examples of the image module the context is clearer if we have from deeptrack imports.

@giovannivolpe what do you think?
In most of the examples we import deeptrack as dt. Should we always use that of in some cases (like here) we can make an exception?

[giovannivolpe]

Ensure that "Examples" is always used in the plural form, consistent with "Methods" and "Parameters".

Additionally, all example code should follow the standard of importing deeptrack as dt and referencing dt.Image, etc. @giovannivolpe please confirm that you like the latter choice

Yes, I think it makes sense, so that readers can just cut and paste and it's clearly identified what is part of DeepTrack2.
Of course, exceptions are possible when it makes the code clearer.

[giovannivolpe]

Implemented feedback except for examples import statements.
I think in the examples of the image module the context is clearer if we have from deeptrack imports.

@giovannivolpe what do you think? In most of the examples we import deeptrack as dt. Should we always use that of in some cases (like here) we can make an exception?

Yes, I think we can make exceptions if this makes the code clearer, especially when we have long names or we refer to the class being commented itself.

[cmanzo]

ready to merge