Experimental small-batch CUDA baseline JPEG decoding core

Open
  • Is something wrong?
#60 0 comments 0 reactions 0 assignees View on GitHub

@970334745 is already working on this.

Since Nov 2, 2026.

  • #61 by @970334745 — open

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
8/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
cpp, python, pytorch
Domain
data-engineering

Research direction

This is a proposal for an opt-in experimental CUDA baseline JPEG decoder core, and the author is asking whether the direction fits the project rather than asking for a specific change. Read the issue to see the planned split between Huffman decoding, IDCT, color conversion and host parsing, then wait for maintainer direction before touching any code. Done would mean the maintainers have answered the scope question and a draft review has been agreed.

Written by the indexing model from the issue text.

Description

Proposal

Introduce an opt-in experimental native CUDA baseline JPEG decoding core as a
step toward a low-host-work decoder backend for small batches.

nvJPEG and nvImageCodec already provide GPU-assisted Huffman decoding. This
proposal concerns host work and small-batch scheduling, not missing JPEG support.

Existing implementation and evidence

The prototype moves entropy decoding onto CUDA using overlapping speculative
Huffman decoding, exact chunk-state reconciliation, coefficient decoding, and
DC prefix scans, followed by dequantization, IDCT, and color conversion.
Host work is marker/table parsing, lookup-table construction, input staging,
and stream submission.

On 2026-10-22, the original Torch-bound implementation was checked on an RTX 5090
with PyTorch 2.8.0+cu128 and torchvision 0.23.0+cu128: 5000/5000 decoded images and
5000/5000 preprocessing tensors were bit-identical to that reference. The corpus
contained 4990 baseline 4:4:4 images and 10 grayscale images. A 200-image sequential
load benchmark changed from 2335.05 to 425.75 microseconds/image, while GPU busy
time increased from 57.79 to 335.80 microseconds/image. These are historical
prototype/load-path measurements rather than current nvImageCodec or model
end-to-end performance claims.

Scope of the proposed draft

  • Separate the algorithm from Torch into C++/CUDA parsing, kernels, resource
    ownership, stream submission, and explicit completion/error checking.
  • Initial scope: baseline 8-bit, single scan, grayscale/YCbCr 4:4:4, no restart
    intervals; caller-owned pitched planar RGB output.
  • Keep the component disabled by default, without changing codec selection.
  • Retain NVIDIA CUDA samples attribution for the IDCT butterfly.
  • Include malformed-header tests, sanitizer checks, and a GPU contract test.

I will submit the native core as a draft for architecture/kernel review. The
framework decoder adapter and matched current nvJPEG comparisons are separate
follow-up work. Is an optional backend with this initial scope a useful direction
for the project?

Dominant language
Jupyter Notebook
Stars
164
Forks
26
Avg merge
27m
Merged PRs (30d)
1

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from NVIDIA/nvImageCodec

All issues in NVIDIA/nvImageCodec

Similar issues

More Data Engineering issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.