Inconsistent expected image_size [width, height] / [height, width] order in code.

[Adamusen]

Describe the bug

So far the expected way, in which one provided the image_size in general.config was in [width, height] order, as all the code in the implementation was expecting it to be provided that way. In the recent changes in commit main@aba5422 with the title "[Add] dynamic image size loader" however, Line 125 in ‎yolo/utils/bounding_box_utils.py got changed from:

W, H = image_size to H, W = image_size in the generate_anchors function.

In the entire input pipeline however, including the dataloader and data_augmentation, the order is still expected to be in [width, height]. This leads to the bug, when using a non-quadratic image_size, that the input image and the generated anchors (used during training in the loss function and in post-processing during inference) do not match, yielding incorrect results.

To Reproduce

Steps to reproduce the behavior:

1. Run lazy.py with the following arguments:

task=inference
model=v9-s
use_wandb=False
image_size=[1024,768]

2. Check the resulting detections in runs/inference/v9-dev/frame000.png

Screenshots

Current state:

If I change H, W = image_size back to W, H = image_size at Line125 in ‎yolo/utils/bounding_box_utils.py:

Expected behavior

Consistent handling of provided non-quadratic image_size.

My Recommendation

1. Revert Line 125 in ‎yolo/utils/bounding_box_utils.py back to W, H = image_size to solve the issue and keep consistent with the up to this point used [width, height] order definition in config.yaml, as changing everything to [height, width] at this point would require a lot more work.
2. Change the default image_size in config.yaml and in all the tests to some non-quadratic resolution, so that in the future such bugs do not go unnoticed before merging to main (the default is [640, 640] now, with which everything works properly of course)

[Adamusen]

Made a pull request with proposed consistency fixes in bounding_box_utils.py