Michio JP

Michio JP

1629910086

Conditional DETR | Encode and Decode Transformer for Object Detection

Conditional DETR

This repository is an official implementation of the ICCV 2021 paper "Conditional DETR for Fast Training Convergence".

Introduction

The DETR approach applies the transformer encoder and decoder architecture to object detection and achieves promising performance. In this paper, we handle the critical issue, slow training convergence, and present a conditional cross-attention mechanism for fast DETR training. Our approach is motivated by that the cross-attention in DETR relies highly on the content embeddings and that the spatial embeddings make minor contributions, increasing the need for high-quality content embeddings and thus increasing the training difficulty.

 

Our conditional DETR learns a conditional spatial query from the decoder embedding for decoder multi-head cross-attention. The benefit is that through the conditional spatial query, each cross-attention head is able to attend to a band containing a distinct region, e.g., one object extremity or a region inside the object box (Figure 1). This narrows down the spatial range for localizing the distinct regions for object classification and box regression, thus relaxing the dependence on the content embeddings and easing the training. Empirical results show that conditional DETR converges 6.7x faster for the backbones R50 and R101 and 10x faster for stronger backbones DC5-R50 and DC5-R101.

Model Zoo

We provide conditional DETR and conditional DETR-DC5 models. AP is computed on COCO 2017 val.

MethodEpochsParams (M)FLOPs (G)APAPSAPMAPLURL
DETR-R50500418642.020.545.861.1model 
log
DETR-R5050418634.813.937.354.4model 
log
DETR-DC5-R505004118743.322.547.361.1model 
log
DETR-R1015006015243.521.048.061.8model 
log
DETR-R101506015236.915.540.655.6model 
log
DETR-DC5-R1015006025344.923.749.562.3model 
log
Conditional DETR-R5050449041.020.644.359.3model 
log
Conditional DETR-DC5-R50504419543.723.947.660.1model 
log
Conditional DETR-R101506315642.821.746.660.9model 
log
Conditional DETR-DC5-R101506326245.026.148.962.8model 
log

Note:

  1. The numbers in the table are slightly differently from the numbers in the paper. We re-ran some experiments when releasing the codes.
  2. "DC5" means removing the stride in C5 stage of ResNet and add a dilation of 2 instead.

Installation

Requirements

  • Python >= 3.7, CUDA >= 10.1
  • PyTorch >= 1.7.0, torchvision >= 0.6.1
  • Cython, COCOAPI, scipy, termcolor

The code is developed using Python 3.8 with PyTorch 1.7.0. First, clone the repository locally:

git clone https://github.com/Atten4Vis/ConditionalDETR.git

Then, install PyTorch and torchvision:

conda install pytorch=1.7.0 torchvision=0.6.1 cudatoolkit=10.1 -c pytorch

Install other requirements:

cd ConditionalDETR
pip install -r requirements.txt

Usage

Data preparation

Download and extract COCO 2017 train and val images with annotations from http://cocodataset.org. We expect the directory structure to be the following:

path/to/coco/
├── annotations/  # annotation json files
└── images/
    ├── train2017/    # train images
    ├── val2017/      # val images
    └── test2017/     # test images

Training

To train conditional DETR-R50 on a single node with 8 gpus for 50 epochs run:

bash scripts/conddetr_r50_epoch50.sh

or

python -m torch.distributed.launch \
    --nproc_per_node=8 \
    --use_env \
    main.py \
    --resume auto \
    --coco_path /path/to/coco \
    --output_dir output/conddetr_r50_epoch50

The training process takes around 30 hours on a single machine with 8 V100 cards.

Same as DETR training setting, we train conditional DETR with AdamW setting learning rate in the transformer to 1e-4 and 1e-5 in the backbone. Horizontal flips, scales and crops are used for augmentation. Images are rescaled to have min size 800 and max size 1333. The transformer is trained with dropout of 0.1, and the whole model is trained with grad clip of 0.1.

Evaluation

To evaluate conditional DETR-R50 on COCO val with 8 GPUs run:

python -m torch.distributed.launch \
    --nproc_per_node=8 \
    --use_env \
    main.py \
    --batch_size 2 \
    --eval \
    --resume <checkpoint.pth> \
    --coco_path /path/to/coco \
    --output_dir output/<output_path>

Note that numbers vary depending on batch size (number of images) per GPU. Non-DC5 models were trained with batch size 2, and DC5 with 1, so DC5 models show a significant drop in AP if evaluated with more than 1 image per GPU.

License

Conditional DETR is released under the Apache 2.0 license. Please see the LICENSE file for more information.

Citation

@inproceedings{meng2021-CondDETR,
  title       = {Conditional DETR for Fast Training Convergence},
  author      = {Meng, Depu and Chen, Xiaokang and Fan, Zejia and Zeng, Gang and Li, Houqiang and Yuan, Yuhui and Sun, Lei and Wang, Jingdong},
  booktitle   = {Proceedings of the IEEE International Conference on Computer Vision (ICCV)},
  year        = {2021}
}

Download Details: 

Author: Atten4Vis

Download The Source Code : https://github.com/Atten4Vis/ConditionalDETR/archive/refs/heads/main.zip 

GITHUB: https://github.com/Atten4Vis/ConditionalDETR 

What is GEEK

Buddha Community

Arvel  Parker

Arvel Parker

1591611780

How to Find Ulimit For user on Linux

How can I find the correct ulimit values for a user account or process on Linux systems?

For proper operation, we must ensure that the correct ulimit values set after installing various software. The Linux system provides means of restricting the number of resources that can be used. Limits set for each Linux user account. However, system limits are applied separately to each process that is running for that user too. For example, if certain thresholds are too low, the system might not be able to server web pages using Nginx/Apache or PHP/Python app. System resource limits viewed or set with the NA command. Let us see how to use the ulimit that provides control over the resources available to the shell and processes.

#[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object]

MEAN Stack Tutorial MongoDB ExpressJS AngularJS NodeJS

We are going to build a full stack Todo App using the MEAN (MongoDB, ExpressJS, AngularJS and NodeJS). This is the last part of three-post series tutorial.

MEAN Stack tutorial series:

AngularJS tutorial for beginners (Part I)
Creating RESTful APIs with NodeJS and MongoDB Tutorial (Part II)
MEAN Stack Tutorial: MongoDB, ExpressJS, AngularJS and NodeJS (Part III) 👈 you are here
Before completing the app, let’s cover some background about the this stack. If you rather jump to the hands-on part click here to get started.

#[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object]

CentOS Linux 8.2 Released and Here is How to Upgrade it

CentOS Linux 8.2 (2004) released. It is a Linux distribution derived from RHEL (Red Hat Enterprise Linux) 8.2 source code. CentOS was created when Red Hat stopped providing RHEL free. CentOS 8.2 gives complete control of its open-source software packages and is fully customized for research needs or for running a high-performance website without the need for license fees. Let us see what’s new in CentOS 8.2 (2004) and how to upgrade existing CentOS 8.1.1199 server to 8.2.2004 using the command line.

#[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object]

systemctl List All Failed Units/Services on Linux

Is there is a command to print list all failed units or services when using systemd on Linux? Can you tell me the systemctl command to list all failed services on Linux?

This quick tutorial explains how to find/list all failed systemd services/units on Linux operating systems using the systemctl command.

#[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object]

Brain  Crist

Brain Crist

1595434320

Docker Applikationen mit Visual Studio Code debuggen

Mit dem integrierten Debugger von Visual Studio Code lassen sich ASP.NET Core bzw. .NET Core Applikationen einfach und problemlos debuggen. Der Debugger unterstützt auch Remote Debugging, somit lassen sich zum Beispiel .NET Core Programme, die in einem Docker-Container laufen, debuggen.

Als Beispiel Applikation reicht das Default-Template für MVC Applikationen dotnet new mvc

$ md docker-core-debugger
$ cd docker-core-debugger
$ dotnet new mvc

Mit dotnet run prüfen wir kurz, ob die Applikation läuft und unter der Adresse http://localhost:5000 erreichbar ist.

$ dotnet run
$ Hosting environment: Production
$ Content root path: D:\Temp\docker-aspnetcore
$ Now listening on: http://localhost:5000

Die .NET Core Applikation builden wir mit dotnet build und publishen alles mit Hilfe von dotnet publish

$ dotnet build
$ dotnet publish -c Debug -o out --runtime linux-x64

Dabei gilt es zu beachten, dass die Build Configuration mit -c Debug gesetzt ist und das Output Directory auf -o out. Sonst findet Docker die nötigen Binaries nicht. Für den Docker Container brauchen wir nun ein Dockerfile, dass beim Start vorgängig den .NET Core command line debugger (VSDBG) installiert. Das Installations-Script für VSDBG ist unter https://aka.ms/getvsdbgsh abfrufbar.

FROM microsoft/aspnetcore:latest
WORKDIR /app

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
       unzip procps \
    && rm -rf /var/lib/apt/lists/* \
    && curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l /vsdbg

COPY ./out .
ENTRYPOINT ["dotnet", "docker-core-debugger.dll"]

Den Docker Container erstellen wir mit dem docker build Kommando

$ docker build -t coreapp .

und starten die Applikation mit docker run.

$ docker run -d -p 8080:80 --name coreapp coreapp

Jetzt muss Visual Studio Code nur noch wissen, wo unsere Applikation läuft. Dazu definieren wir eine launch.json vom Typ attach und konfigurieren die nötigen Parameter für den Debugger.

{
    "version": "0.2.0",
    "configurations": [
         {
            "name": ".NET Core Remote Attach",
            "type": "coreclr",
            "request": "attach",
            "processId": "${command:pickRemoteProcess}",
            "pipeTransport": {
                "pipeProgram": "docker",
                "pipeArgs": ["exec", "-i coreapp ${debuggerCommand}"],
                "quoteArgs": false,
                "debuggerPath": "/vsdbg/vsdbg",
                "pipeCwd": "${workspaceRoot}"
            },

            "logging": {
                "engineLogging": true,
                "exceptions": true,
                "moduleLoad": true,
                "programOutput": true
            },
        }
    ]
}

Mit F5 starten wir den Debugger. Wenn alles klappt, sollte eine Auswahl der Prozesse des Docker-Containers sichtbar sein.

vscode

Nun muss der dotnet Prozess ausgewählt werden. Der Visual Studio Code Debugger verbindet sich darauf mit VSDBG und wir können wie gewohnt unseren Code debuggen. Dazu setzen wir einen Breakpoint in der Index-Action des HomeControllers und rufen mit dem Browser die URL http://localhost:8080/ auf.

vscode

#[object object] #[object object] #[object object] #[object object] #[object object] #[object object] #[object object]