Hi, find rects will not find child rects inside of a larger rect. The method is based on the quad detector from apriltags. We just extracted it and used it by itself for finding rectangle. As for the threshold. After we find a rect (which there could be MANY), we walk the edges of the rect defined by it's four points and perform the sobel operation to get the edge strength of the rect. Then we discard rects with too low of an edge strength. The threshold part is our own custom logic. So, if you lower the threshold you'll get basically what apriltags code considers are rects. Since there's no tag to look at however the method tends to find a lot of candidates.

Have you thought of using find_blobs()??? You can determine if a blob underneath is a rect based on how high the density() of a blob is along with if w()/h() are close to 1.

Have you thought of using find_blobs()??? You can determine if a blob underneath is a rect based on how high the density() of a blob is along with if w()/h() are close to 1.

Some food for though and I will have a play with it. I think running 6 find blobs to detect all the colours then extract from there what I am looking for will greatly lower frame rates to probably lower than usable. The find_blobs or find_rects is what is slow. If I threah out all the colors into binary the join them all with b_or then I only have to run find_rects once compared to find_blobs 6 times.

I think the big problem is that when it finds a large rect then it doesn't look for child rect inside. I notice that when ever a big rect is detected this is what stops it finding my squares that I am looking for. I will play with higher threaholds to try to stop the find_rects seeing big rects. Is it maybe possible to add more args to the find_rects to give min and max width and hight and also aspect ratio.

Once it finds all the rects including the ones that I am looking for then it is easy for me to reject the ones that I don't want like ones to big and ones too small and any aren't in a 3x3 grid of similar size.