Bounding Boxes

[littlerob84]

The bounding boxes are way too small and difficult to see. I found blue was the easiest colour with the width of the line 15px and sitting about 70 px of the flower. See attached image showing an output from mine. This can group over and cover flowers, but it looks like the bounding box automatically re-sizes around clumps, so probably less of an issue. If it does obscure flowers, we can go to the original image to see what they were. The boxes need to be very obvious as if there are multiple detections, in different parts of the image, you dont want to miss any.

[NicoMandel]

These are all visualisation fixes. Mark wanted colour coding like a traffic light according to the confidence that something as OHW or not, so that's what's implemented here

I'll try address these one by one, with an estimate of what priority (1,2 or 3, 1 being highest) I think they are and how much time (S, M, L, XL) I think these'll need so you can help me decide what to work on. My current estimate would be as follows:

1. Box Colour blue - S - 3 - mark wanted traffic light... But I could do different shades of Blue?
2. line width - S - 2 - can do easily
3. Grouping and clustering flowers - L - 3. The model outputs label files. I can use the label files to calculate distances and group objects which centers are close together... If the model should output something different, it would have to be retrained.
4. Making boxes obvious -? - ? - Not sure what the best way is. Can put a cross through them, can overlay something, can pretty much do anything that you think is useful...

Can explore this. Please provide an indicator of what priority (1, 2 or 3) you would like this to be, 1 being most urgent.

[littlerob84]

Box Colours - Priority 1 - The traffic light colours is a good idea, it's what I did originally on my one as well to show confidence. I ended up going to a single, easy to see colour as at the end of the day, if there was a detection, we looked at it, so the traffic lights were good for testing, but operationally, it made no difference to what we did with the data, we still visually looked at it and made the determination to ground truth from there. I found Blue was the easiest to see.

Line With - Priority 1 - Great

Grouping and clustering flowers - Sorry, I probably wasn't clear, grouping or clustering is nice, but not required at all. What makes the boxes easier to see (remember we are looking at 9568 x 6376 images) is instead of having the bounding boxes fit tight around the detections, just apply a 70px buffer in all 4 directions around them. So you end up being able to easily pick up the detection when looking at the whole image, you zoom into the large bounding box and the actual flower/detection is in the middle and very easy to see at that point. Is it as simple and increasing padh and padw on line 25?

With those 3 implementations, that should be well and truley obvious enough. Attached is an example visualisation output from a flight this year that shows how hard it is to find the detection box at the moment. I had to downscale it as it was 100mb file originally, but it still demonstrates what we're working with.

[NicoMandel]

Hi Rob

1. Box Colours Makes sense. Since this is a scaling based on single input value, we can modify this to be anything. e.g. different shading of blue, see this line. Just let me know what you need
2. Line width will do
3. Padding: Yes that's the lines. There needs to be some check on image boundaries though (so a rectangle in a 9568 x 6376 image cannot go beyond those values). Not too cumbersome, just sth to be aware of for me.

I see your point in the image. This is good and really nicely implementable feedback, as it turns back to single parts of the code. If next you could split this into 3 issues, I can assign and treat them separately, just in case something goes wrong with one of those things, I can still consider the other ones fixed and close them with a specific commit.