roboflow/rf-detr

Context Currently, our PyTorch DataLoader is bottlenecked by CPU image decoding during the __getitem__ loop. When training RF-DETR on datasets like COCO 2017 (118k images), using standard PIL.Image.open or default OpenCV backends causes heavy CPU contention. Profiling shows high system RAM usage and low CPU compute utilization, indicating that the workers are stalling on single-threaded decoding overhead. This leaves our GPU (e.g., RTX 6000) underutilized due to data starvation. Proposed Solution Replace the default JPEG decoder in the dataset class with turbojpeg (or jpeg4py, wrapping libjpeg-turbo). The implementation should: Read bytes directly and decode to a NumPy array (RGB). Pass the decoded array seamlessly into our existing Albumentations CPU pipeline. Fall back gracefully to cv2 or PIL if the image format is not JPEG or if libjpeg-turbo is not installed on the host machine. Impact Throughput: libjpeg-turbo is generally 2x to 3x faster than PIL for decoding JPEGs to NumPy a

I struggle a lot reading the current code because of some intrinsic coding conventions or lack thereof. Would it possible to get something instated that gives some guidelines on how to write things? Some examples: Reveal intent — name should say what it holds/does without needing a comment (elapsed_time_in_days, not d) No disinformation — name should match the actual type/behavior (don't call a dict a _list) Meaningful distinctions — if two vars differ, the name should say why (raw_data vs normalized_data, not data vs data2) Pronounceable & searchable — avoid cryptic abbreviations and magic numbers; use MAX_RETRIES, not 5 No mental mapping — avoid i, x, tmp outside tiny local scopes Nouns for classes, verbs for methods — Customer, not DataManager; save(), not data() One word per concept — pick fetch or get, not both, across the codebase No puns — don't reuse the same word for different meanings Use domain vocabulary — match terms your team already uses in conversatio

Search before asking I have searched the RF-DETR issues and found no similar feature requests. Description I suggest we remove them from the docstrings and rely solely on the signature. Here is the breakdown of why the Python ecosystem has shifted this way: 1. The Modern Approach (Signature as Truth) Since PEP 484, the standard is to treat the function signature as the Single Source of Truth. Tools like mypy, Pyright, and our IDEs rely entirely on the signature to validate our code. By keeping the focus there, we ensure that the types we document are the actual types being enforced by the interpreter. 2. The Legacy Approach (Why to avoid duplication) Writing types in the docstring was necessary before Python 3.5, but today it is considered a violation of DRY (Don't Repeat Yourself). Maintenance Burden: It creates a "split truth." If we change a variable from int to float in the code but forget to update the English text in the docstring, our documentation becomes factually incorrec