classification directory for classifier

[pure-rgb]

I see that there are separate folder for each category. But the imagenet models are placed outside arbitrary. They should be placed under classification directory.

https://github.com/keras-team/keras-cv/tree/master/keras_cv/models

[LukeWood]

@tanzhenyu @ianstenbit @qlzh727 what do you think about this?

On one hand, these are more than classification models. They're modular backbones.

Perhaps we throw them in a backbones directory? the line between classification model and backbone model is very rough.

[ianstenbit]

Since this won't affect our exported API (these should be exported as e.g. keras_cv.models.ResNet50V2), I don't think it's particularly important how we structure the folder. I think given that they are foundational and re-used in addition to being a user API on their own as classification models, they ought to stay where they are now, but I could be convinced otherwise.

[tanzhenyu]

I'm completely fine with it under models/backbone directory.

[qlzh727]

I think all the current classification models are mostly backbone plus a classification head. If we split the backbone from the head, then it will be a more split of directory, where backbone will be most of the model body, and classification can be light weighted.

[tanzhenyu]

I think all the current classification models are mostly backbone plus a classification head. If we split the backbone from the head, then it will be a more split of directory, where backbone will be most of the model body, and classification can be light weighted.

So my take here is that in the long run, classification head will be history. So our backbones taking "include_top" is just a very thin wrapper to include the head, which is fine and shouldn't confuse users, I guess?

[bhack]

As we have now also transformers doing these tasks is backbone definition mainly valid for pure CNN networks?

[tanzhenyu]

As we have now also transformers doing these tasks is backbone definition mainly valid for pure CNN networks?

IIUC, some of them are still backbones -- MaxVit, Swin, etc. Some of them are not. Putting those plug-and-play transformer-based backbones into models/backbone is fine with me

[bhack]

If we stretch the backbone concept we are little bit really at the limit for them. But let see how it will happen...

[tanzhenyu]

Summary: Let's move to models/backbone while not impacting APIs

[LukeWood]

This is done