The direct answer
Is DepthAI Core 3.8.0 a real, fixed release? Yes. Luxonis publishes an official non-prerelease, an annotated v3.8.0 tag, three GitHub assets, five PyPI wheels and versioned release notes. The source tree declares project(depthai VERSION 3.8.0).
Did the public assets arrive intact? Yes. RCI independently downloaded all three GitHub assets—75,688,003 bytes in total—and matched every publisher byte count and SHA-256 digest. The ZIP and tar source archives expose identical normalized 2,488-entry path sets.
Does that verify OAK4 Lite depth accuracy, latency, power or stability? No. The release surfaces name features and three integration-tested Luxonis OS versions, but disclose no exact test devices, pipelines, durations, pass criteria, failures, raw logs or numerical device results. RCI did not run the software or touch a camera.
DepthAI Core v3.8.0 is a precisely identifiable, openly licensed software release with three independently hash-matched GitHub assets, five publisher-indexed PyPI wheels, inspectable test/example source and an issuer-stated RVC4 OS compatibility boundary. The public release surfaces do not provide the device identities, protocol, execution logs or numerical results needed to turn new depth, ToF, calibration, timestamp, health-check or GPU-backend features into independently validated camera performance.
Three publisher digests, independently matched
| Asset | Role | Bytes | Entries | SHA-256 result |
|---|---|---|---|---|
| depthai-core-v3.8.0-win64.zip | Windows prebuilt SDK bundle | 67,086,673 | 641 | matched7973570d9a9ebcbd… |
| depthai-core-v3.8.0.tar.gz | Source archive (tar.gz) | 3,760,215 | 2,488 | matchede03cd70da0d2e172… |
| depthai-core-v3.8.0.zip | Source archive (ZIP) | 4,841,115 | 2,488 | matched29d0321f848b7703… |
Three matching SHA-256 values establish byte identity with GitHub's published digests only. They do not establish software safety, absence of vulnerabilities, successful installation or correct device output.
The annotated tag resolves to commit 1aba5e372326. GitHub reports the tag and commit as unsigned, so RCI records a precise object identity without claiming a verified signer.
What v3.8.0 says it adds
| Field | Release statement | Evidence role | RCI boundary |
|---|---|---|---|
| unified depth sources | StereoDepth; GPUStereo; NeuralDepth; NeuralAssistedStereo; ToF | issuer feature statement | Unified API support does not make the five methods equivalent in accuracy, latency, power or operating range. |
| depth source selection | Automatic selection based on connected-device features and requested FPS/resolution | issuer feature statement | The public release note does not publish the complete selection rules, tie-breaking behavior or validation matrix. |
| device health check scope | status; connection; bandwidth; power supply; calibration; camera/IR functionality; reported issues | issuer feature statement | A diagnostic surface is not proof that every reported field has calibrated thresholds or detects every failure mode. |
| tof api boundary | RVC4 Lite with ToF support; unified RVC2/RVC4 API; confidence output | issuer feature statement | No ToF accuracy, confidence calibration, ambient-light, range or latency result is published in the release note. |
| oak4 lite support | OAK4 Lite and OAK4 Lite ToF recognition; STMicro VD55H1 ToF driver and processing | issuer hardware-support statement | The release statement is not an exact device-order-code matrix, sensor characterization or independent interoperability test. |
| image manip gpu default | RVC4 GPU backend becomes default; qualitative performance and power improvement claim | issuer software and qualitative performance statement | No workload, device, latency, throughput, wattage, temperature or uncertainty value is published for the comparison. |
| message timestamps | Unix system timestamps added to all RVC4 messages | issuer interface statement | Timestamp presence does not establish clock source, synchronization error, transport latency, monotonicity or cross-device alignment. |
| multisensor dynamic calibration | Dynamic calibration between multiple sensors | issuer feature statement | No public v3.8.0 result table defines initial error, final residual, motion, temperature, duration or failure rate. |
| luxonis os integration tested versions | 1.27.1; 1.30.1; 1.33.0 | issuer compatibility statement | The note gives no exact devices, host OS, firmware, pipelines, sample count, duration, pass criteria, failures or raw logs. |
The five depth-source classes are API options, not interchangeable sensors or algorithms. A unified interface can reduce integration work while preserving different accuracy, range, compute, latency and power behavior beneath it.
The RVC4 GPU backend performance/power statement is qualitative and configuration-free. RCI does not convert it into a speedup, watt reduction or efficiency ratio.
Three OS versions, but no exact compatibility matrix
The official notes say RVC4 integration was tested with Luxonis OS 1.27.1, 1.30.1 and 1.33.0. That is a useful, responsibility-source boundary. It is not a minimum supported version, an exhaustive list, or proof across every OAK4 Lite sensor and host.
Integration tested with Luxonis OS 1.27.1, 1.30.1 and 1.33.0 remains an issuer statement. It does not prove every OAK4 Lite variant, sensor, host OS, pipeline or long-duration workload.
PyPI independently exposes five publisher-indexed wheels for macOS arm64/x86_64, manylinux aarch64/x86_64 and Windows amd64, with Python >=3.9. RCI records that distribution metadata but did not download, import or execute the wheels.
Test source is public; execution evidence is not
The source archives contain 311 test-related paths and 34 benchmark-example paths under RCI's path heuristic. That is materially better engineering disclosure than a binary-only release.
But source files do not record which tests passed on which device. RCI found no separately uploaded validation asset and no execution-result file using common CSV, TSV, Parquet, ROS bag, DB3, PCAP or log extensions. Fourteen NPY files are vendored xtensor format fixtures, not Luxonis camera-validation results.
Public test and benchmark code makes future reproduction possible. Until the environment, exact device, command, run log and result are published or independently rerun, it cannot be counted as a v3.8.0 device pass.
Twenty disclosure checks
| Field | Status | Public evidence | Why it matters |
|---|---|---|---|
| versioned release and date | disclosed | GitHub and Luxonis documentation identify v3.8.0 and July 11, 2026. | The software release can be cited and time-bounded. |
| tag and commit identity | disclosed-unsigned | Annotated tag b08a074afd58 resolves to commit 1aba5e372326; GitHub reports no verified signature. | The source snapshot is fixed, but cryptographic signer identity is not established. |
| release asset sizes and sha256 | disclosed-and-rci-matched | GitHub publishes three asset sizes and SHA-256 digests; RCI independently matched all three. | Byte-identical assets can be identified without RCI redistributing them. |
| source license | disclosed | The v3.8.0 root LICENSE contains the MIT License for Luxonis software. | Core source reuse has a clear root license; dependency and non-code rights still require item checks. |
| installation package and python floor | disclosed | Official notes specify depthai==3.8.0; PyPI lists five wheels and Python >=3.9. | A package/version floor is available, but host and device compatibility remain conditional. |
| supported hardware generations | partial | Release notes distinguish RVC2/RVC4 and name OAK4 Lite/OAK4 Lite ToF. | No complete device order-code, sensor, firmware and feature matrix is published in the release surface. |
| luxonis os versions | disclosed | Integration tested with Luxonis OS 1.27.1, 1.30.1 and 1.33.0. | Provides an issuer compatibility boundary, not a universal minimum/maximum support range. |
| integration test device identity | not-disclosed | No exact OAK device SKU, sensor configuration or unit revision is attached to the three OS-version statement. | The compatibility statement cannot be mapped to an exact purchasable configuration. |
| integration test protocol and pipeline | not-disclosed | No command, pipeline graph, input, stream configuration, workload or acceptance criteria is published with the compatibility sentence. | Another lab cannot repeat the stated integration test as written. |
| integration test sample duration and failures | not-disclosed | No device count, run count, duration, failure, retry or excluded result is given. | The breadth and stability meaning of 'integration tested' remain unknown. |
| depth accuracy and precision | not-disclosed | The v3.8.0 release surfaces publish no ground-truth depth error, precision, fill-rate or confidence-calibration result. | Feature availability cannot be converted into a depth-performance claim. |
| latency and throughput | not-disclosed | No exact end-to-end latency, FPS result, frame-drop rate or host/device utilization is published for the new paths. | Real-time suitability cannot be inferred from node availability. |
| power and energy | qualitative-only | The GPU backend is said to improve performance and lower power versus CPU, without wattage, workload or device conditions. | No numeric power or efficiency comparison is possible. |
| thermal and throttling | not-disclosed | No temperature, thermal state, throttling threshold or ambient condition accompanies the feature claims. | Sustained behavior and deployment envelope remain unknown. |
| device health thresholds and ground truth | not-disclosed | The diagnostic categories are named, but thresholds, calibration, fault injection, sensitivity and false-alarm results are absent. | The health check cannot be treated as a validated safety monitor. |
| dynamic calibration method and metrics | partial-code-no-results | Source and examples are present, but the release surface has no exact test scene, reference, residual or failure distribution. | Calibration functionality is inspectable; calibration performance is not independently comparable. |
| timestamp clock and synchronization error | not-disclosed | Unix timestamps are announced, but clock source, synchronization method, drift, skew and latency are not quantified. | Timestamp presence is insufficient for multi-sensor timing validation. |
| public test source | disclosed | The source archive exposes 311 test-related paths and 34 benchmark-example paths under RCI's path heuristic. | Public code enables follow-up inspection and execution, but does not itself prove a pass. |
| public execution logs and results | not-released | No separately uploaded validation asset or common CSV/TSV/Parquet/ROS bag/DB3/PCAP/log result file was found; fourteen NPY files are vendored xtensor format fixtures. | RCI cannot confirm what test set ran, on which hardware, with what outcomes. |
| independent device reproduction | not-performed | RCI verified distribution integrity and package structure only; no OAK device or host environment was tested. | All hardware behavior, compatibility and performance statements remain issuer-reported. |
14 of 20 checks are partial, qualitative, unsigned, not released or not independently performed. The missing core is an exact device/configuration matrix plus test protocol and output—not another marketing feature list.
MIT source, narrower item boundaries
The v3.8.0 root LICENSE grants the MIT License for the Luxonis software and associated documentation covered by that file. RCI does not stretch that root notice across every bundled dependency, firmware image, model, hardware design, documentation surface or trademark.
RCI links the official GitHub release, Luxonis release notes and PyPI record. It publishes its own hashes, counts and analysis and does not mirror the three release assets or five wheels.
What RCI independently checked
- Resolved the official release, annotated tag, commit, documentation, repository license and PyPI version.
- Downloaded all three GitHub assets and independently matched 3/3 publisher sizes and SHA-256 digests.
- Listed the 641-entry Windows bundle and both 2,488-entry source archives without executing their contents.
- Compared normalized ZIP/TAR source paths and confirmed identical path sets, source version 3.8.0 and the root MIT license.
- Counted test/benchmark source surfaces and distinguished code/fixtures from separately published execution results.
- Separated twenty release observations from twenty reproducibility-disclosure checks; all device behavior remains issuer-reported.
Limits that stay attached
- RCI did not connect or identify a physical OAK, OAK4 Lite or OAK4 Lite ToF device.
- RCI did not build, install, import or execute DepthAI Core or any included test/benchmark source.
- The five PyPI wheel records and hashes are publisher metadata; RCI did not download or independently hash those wheels.
- Archive path counts and hash matches are software-distribution evidence, not depth accuracy, latency, throughput, power, thermal or reliability evidence.
- The official compatibility sentence lacks exact device SKUs, firmware, host environment, pipelines, duration, pass criteria, failures and raw logs.
- The MIT root license does not automatically cover every third-party dependency, firmware image, model, documentation page, hardware design or trademark.
- The current audit is bounded to public v3.8.0 release surfaces verified on 2026-08-10; living documentation and package indexes may later change.
Download the release audit
Download the immutable JSON release and record-level CSV. Stable aliases are current JSON and current CSV.
Suggested citation: Robot Component Index. “DepthAI Core 3.8.0 Evidence: 3 Assets, 3 Hash Matches, 0 Device Benchmarks.” RCI 031, version 0.1.0, 2026-08-10. https://robotcomponentindex.com/research/depthai-3-8-release-evidence-audit/