Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

custom object detection - possible bug on decode_netout function #338

Closed
rola93 opened this issue Sep 5, 2019 · 2 comments
Closed

custom object detection - possible bug on decode_netout function #338

rola93 opened this issue Sep 5, 2019 · 2 comments

Comments

@rola93
Copy link
Contributor

rola93 commented Sep 5, 2019

Hello, I have been reading the code multiple times trying to make it faster. However, the first step is to understand it properly before proposing any change.

In particular, this line 1239 seems to contain a bug. I'll copy above the current code to exaplain why is it wrong, from my point of view:

 def decode_netout(self, netout, anchors, obj_thresh, net_h, net_w):
        grid_h, grid_w = netout.shape[:2]
        nb_box = 3
        # (1): From this line, netout is a numpy array of 4 dimentions
        netout = netout.reshape((grid_h, grid_w, nb_box, -1))  
        nb_class = netout.shape[-1] - 5
        boxes = []
        netout[..., :2] = self._sigmoid(netout[..., :2])
        netout[..., 4:] = self._sigmoid(netout[..., 4:])
        netout[..., 5:] = netout[..., 4][..., np.newaxis] * netout[..., 5:]
        netout[..., 5:] *= netout[..., 5:] > obj_thresh

        for i in range(grid_h * grid_w):
            row = i / grid_w  # small comment: using '//' instead of '/' makes it unnecesary to cast results to int every time in the future (just replace float operation by its int version) 
            col = i % grid_w
            for b in range(nb_box):
                # 4th element is objectness score
                # (2): because of (1), the nextline will let objectness as a single np.float value
                objectness = netout[int(row)][int(col)][b][4]
                # (3): the following line contains the error
                if (objectness.all() <= obj_thresh): continue

             # Do more things
             pass
        return boxes

Here goes the long explanation on the error of (3):

because of (2) objectness.all() will return always True, except for the case where objectness is 0, (exactly zero) in which case it will return False.

Then, when <= operator is applied, when .all() evaluates to False, it is casted to integers as 0, as obj_thresh usually is a value in range (0..1) (0.5 by default), so this evaluates to if 1 <= 0.3: continue, and therefore, every single value is being taken.

basically what is happening is that we are only skipping those cases in which objectness is exactly zero, and keep al the others.

In addition to this, I refer to the original implementation provided by @OlafenwaMoses and it is a little bit different (and correct) from my point of view.

question: is there a reason for such strange behavior? may the same issue be replicated in other methods?

I'll write a PR soon to change it, but would like to know @OlafenwaMoses view on the issue

Thanks

@OlafenwaMoses
Copy link
Owner

OlafenwaMoses commented Sep 10, 2019

Thanks very much for this thorough review @rola93 . During the implementation for training custom YOLOv3 models, there were so many things to figure out as I raise against the time I promised in #8 , which was the 2nd deadline for delivery. Some of this things were:

  • providing a seamless, simple experience for the training
  • providing sufficient methods to evaluate trained models
  • compatibility in previous and new YOLOv3 code.

I admit code optimization wasn't fully implemented at the time, and even after the release, documentation and tutorials took a lot of time as well.

I will review the PR and evaluate the changes. Thanks very much once again @rola93

@rola93
Copy link
Contributor Author

rola93 commented Sep 19, 2019

Will close this issue since the imain point was solved & merged and the related/still open points are being talked on #352

@rola93 rola93 closed this as completed Sep 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants