Kornia earns its place when vision operations must stay in PyTorch
If your training loss needs to change a camera pose through an image warp, the choice of vision library affects what you can train. Kornia supplies image processing and geometry operations on PyTorch tensors, with gradients through many of them. That is a persuasive reason to add it to a learning pipeline. Replacing an existing resize call, by itself, is a weaker reason.
The useful distinction is where your data already lives and what must remain differentiable. Kornia's README describes batched operations without a NumPy round trip. It also explicitly excludes some operations from gradient support, including RANSAC and extraction methods in some learned feature pipelines. Choose the operation you need before assuming that the library's differentiable label covers every stage.
What happened when we ran it
Our sandbox installed Kornia in 81 seconds and built it in 5 seconds, but the tests timed out after 900 seconds. The November 1, 2026 run used commit d9e934b and recorded 81 dependencies occupying 5,472 MB. That's a substantial environment for someone evaluating a library, although it isn't a measured minimum footprint for every deployment route.
The final test-log lines contain passing dots and skipped markers. They contain no final summary or exception explaining the timeout. We cannot give a completed pass count, identify a failing case or diagnose a package or environment cause from that tail. The finding is an incomplete test run under our limit. It doesn't establish that Kornia's vision operators are broken.
The recorded pip-audit result was zero known vulnerabilities. This is a dated dependency-check result, not proof that the package has no security defects. We measured no image-processing throughput, gradient accuracy or GPU workload. In particular, the install and build timings say nothing about how quickly a warp will execute inside your training loop.
The sandbox configuration specified 3 CPUs and 8 GB RAM, with image label ghcr.io/astral-sh/uv:python3.12-bookworm. Actual runtime versions require logs we don't have here. The checkout contained 1,473 files, about 376,623 source lines and 29.3 MB. The scan found 15 CI workflow files and a tests directory, with no Dockerfile. Workflow count doesn't establish platform coverage or passing CI.
Coordinate conventions can change a result without raising an error
Kornia's conventions guide distinguishes point order (x,y) from output-size order (h,w). It also documents different rotation directions between APIs. A shape-correct tensor can still mean the wrong transformation if those conventions don't match the rest of your pipeline.
For integration, I'd use an image with a clearly marked corner and known points, then check the transformed image against those points. That is a proposed acceptance check, not an experiment we performed. It resolves a more useful question than whether the operator returned a tensor: did the coordinates move where your application expected?
The v0.9.0 release notes, published October 23, 2026, warn that corrected behavior can change numerical baselines for warps, resizing and other operations without raising errors. They also say the latest documentation follows development. Match documentation to the installed version, and retain representative outputs when upgrading. A passing import won't catch a change in your coordinate assumptions.
Joint annotation transforms have documented boundaries
The README describes AugmentationSequential applying sampled transformations to images and registered annotations together in two dimensions. For segmentation or detection training, that is a useful reason to evaluate Kornia: the image and its labels need to stay aligned. The same README says three-dimensional augmentations transform volumes without annotations or an inverse.
That boundary matters if your work involves labelled medical volumes or another three-dimensional dataset. Don't carry the two-dimensional workflow into that setting by assumption. Even in two dimensions, check the specific augmentation: the conventions guide names transforms that don't move boxes and keypoints with the image. An augmentation container doesn't erase per-operation limits.
Likewise, half precision needs an operation-level decision. The release notes say some calculations use wider internal types and that forward execution doesn't establish gradient accuracy or native-half speed. Our sandbox provides no evidence to resolve those questions. Check the dtype, device and backward path you'll actually use rather than treating half-precision support as one switch for the whole library.
Model downloads are separate from the measured environment
The release notes warn that several feature constructors download pretrained weights by default. For an offline or restricted deployment, select the documented constructor option and make a deliberate plan for weights. Our recorded dependency footprint doesn't establish the size or availability of those model assets.
The current README also says model-zoo expansion is frozen while maintenance concentrates on the core. Existing shipped models remain available, but new integrations require a maintainer sponsor. That makes Kornia a poor bet if your main adoption reason is expecting an unlisted model to arrive. Use the geometry and models it documents today.
The last push was November 1, 2026, and recent issue and pull-request activity concerns filter padding and geometry corrections. Together with the October release, this shows active maintenance. It doesn't establish support capacity, numerical correctness for your workload or completion of our timed-out suite.
Keep torchvision or OpenCV when they already cover the task
torchvision supplies datasets, model architectures and common image transformations. If those are the operations your PyTorch application needs, check that existing toolbox before adding Kornia. We have no comparative benchmark showing that either choice is faster for your shapes and device.
OpenCV is another computer-vision library to consider when your existing processing pipeline lives outside PyTorch. Its presence doesn't rule out using Kornia for a differentiable stage. Start the Kornia trial with the exact warp or geometry operation you need, including its backward path and annotation checks, and keep the expected output as an upgrade reference.