@rwightman Thanks
I kind of get this after digging into the code.

1. confirming what you said
   say

net= model_from_config()
net(image,target) ->  xyxy    (post processing results into xyxy) 
net.model(image) - >yxyx  -> post processing in detbranch-> xyxy ?

Please let me know if I got you correct

2. If i have to compute the IOU/maP between GT and Predictions , do i have to convert GT back to xyxy for pascal voc format?

3. Box Loss computation would be still using yxyx format
   loss, class_loss, box_loss = self.loss_fn(class_out, box_out, cls_targets, box_targets, num_positives)

4. on a other note about class setting , Do i have to set No finding class inside dataset to -1 ?

5. Lastly , which is confusing .
   Num_class passed to model , if suppose i have 1 no finding class and 3 finding class
   then the num classes passed to model is 4 or 3

Last i used effdet for a problem which had no No finding class, this time both are there, model results are below par so that is why so many question.. Please bear with me :)

@jaideep11061982 many of the defaults were adopted from the original TF impl...

The 'background' class (no finding as you call it), is 0 from the perspective of your dataset, so the first valid class label your dataset should produce is '1', generally you don't need to explicitly provide background labels but I suppose you could in some cases. You can see the demo datasets add the 1 offset when returning the target labels.

Internally the anchor labelling code subtracts that offset so the background ends up being -1 and -2 is used as a sentinel for some other things, the non-processed output of the model does not include the background (it's used in the anchor labelling/matching) so the num_classes you build the model with should NOT include the background class, ie in the Pascal VOC demo in README you pass in 20 classes, not 20 1.

And yes, you are correct, the bench(input, target) outputs xyxy, the bench.model -> yxyx, and there is a step in the post processing that the bench does right before NMS where it's switched to xyxy and left that way. Losses are not calculated on the post-process output so they all remain in yxyx.

What format you need for your evaluation depends on the evaluation code you use, as I mentioned the included generic TF based evaluators that are used for the built in VOC support expect yxyx internally (https://github.com/rwightman/efficientdet-pytorch/blob/master/effdet/evaluator.py#L121-L175), the pred_yxyx= arg specifies whether you will pass yxyx coords to the evalutor (instead of xyxy) and it adjusts.