yolo layer : missing scale_x_y parameter

[pfeatherstone]

yolo layers optionally have scale_x_y parameter. This is not an issue for yolov3 since it is always 1, but since it would seem you are experimenting with yolov4, i assume you intend to support it. yolov4 uses scale_x_y 1.2 1.1 and 1.05 i think

[glenn-jocher]

@pfeatherstone yes I know. I was actually the one that brought up the idea to alexeyab after my testing revealed dark regions (no detections) near the grid edges in iDetection videos:
AlexeyAB/darknet#3293

I've tested it a lot and found it to have a slight impact, but the topic is much more complicated. You can see this effect in 'blinking' objects sometimes when using iDetection. The code to modify is quite simple, it's just near the end of a long list of tasks I've got at the moment.

[pfeatherstone]

Fair enough. I saw in his paper he acknowledged this repo so I assumed you’d contributed to the overall yolov4 effort. In the original yolov2 or yolov3 paper pjreddie says that you need to use sigmoid function to ensure a well defined system, i.e a detection doesn’t leak into a neighbouring grid cell. So I don’t know if using scale > 1 theoretically impacts the stability of the model... I don’t know. I can’t take theorems relating to neural networks particularly seriously though

[glenn-jocher]

@pfeatherstone theory doesn't go very far here. Typically what you see if people get empirical results and then try to write a storyline to explain the results. In the end its mostly just a lot of trial and error.

About sigmoid, yes, I'm aiming to move the entire detection layer output to sigmoid to increase stability and remove nan errors that people sometimes experience on custom datasets. The current wh exp() output is a bit of a problem in that sense as it is unbounded and unstable.

I think the handoff from one grid point to another is a real problem, especially for smaller objects, which do not have redundant output layers. In any case, inference with the --augment flag should minimize this problem currently, though of course it uses a lot more flops. It would be nice to find a partial overlap implementation that minimizes the issue with a single forward pass.

Yes alexeyab and I and a few others contribute ideas back and forth, but I am only loosely affiliated with yolov4, and am actually aiming to launch an improved version which is largely unrelated to it. I've got a bit of a naming problem now :)

[pfeatherstone]

yes i noticed people were fighting for the yolov4 title :)

[pfeatherstone]

Regarding the use of exp(), you would have thought using tailor made anchors for your dataset would allow you to use a more slowly diverging function.

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove Stale label or comment or this will be closed in 5 days.

[glenn-jocher]

@pfeatherstone Definitely, tailor-made anchors would help. It might also be beneficial to introduce more complex activations for better convergence. However, this is something that requires careful experimentation and validation.

The competition for the YOLOv4 title is indeed interesting. It's a testament to the strong community and continuous development in the YOLO ecosystem.