Fix ONNXRuntime dll path mismatch #29309
**1. C2664 build error in `net_impl_backend.cpp`**
`EnableProfiling()` expects `const wchar_t*` on Windows (`ORTCHAR_T`), but was passed `const char*`.
Fixed by converting to `std::wstring`, as suggested in #29278
---
**2. Wrong ORT DLL loaded at runtime (`modules/dnn/CMakeLists.txt`)**
With `DOWNLOAD_ONNXRUNTIME=ON`, the DLL glob only searched `bin/` but the downloaded package places DLLs in `lib/`. This left the build tree with no ORT DLL, causing Windows to fall back to the stale `System32\onnxruntime.dll` (1.17.1), crashing against the ORT 1.25.1 API.
Fixed by adding `lib/` as fallback and staging DLLs into the build bin directory at configure time.
Closes : #29278
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
dnn: fix new-engine block layout for RVV when VLEN > 128 #29304
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
<!-- Note!!! If you are an automated agent, we have a special process for you: add 🤖🤖🤖 to the end of the PR title. -->
#### Problem
Fixes#28852. The new DNN engine packs activations in a blocked NCHWc layout with a fixed channel-block size `C0 = 8`. The blocked-layout kernels (MaxPool, AveragePool, BatchNorm, depthwise Conv, ConvTranspose, generic Conv) load one block into a SIMD vector and assert: `C0 == nlanes || C0 == nlanes*2 || C0 % (nlanes*4) == 0`
On RISC-V the universal intrinsics are **scalable with LMUL=2**, so `nlanes = (VLEN/32)*2` — **16 at VLEN=256, 64 at VLEN=1024** — which exceeds the fixed `C0=8`. The assertion fails with `-215` and the ONNX pooling/conv conformance tests abort. #29180 worked around it by disabling the RVV SIMD path in those kernels.
#### Fix
Make the block size track the hardware vector width on RVV instead of assuming 8:
- `net_impl.cpp`: `defaultC0 = max(8, VTraits<v_float32>::vlanes())` (16/64 on RVV).
- The fp32 blocked kernels read `C0` at runtime and size scratch buffers by `max_nlanes` (bounded by the compile-time `CV_RVV_MAX_VLEN`, default 1024).
- All changes are guarded by `CV_SIMD_SCALABLE`, so **x86/NEON are unchanged**.
- The int8 quantized kernels are hardwired to `C0=8` (VNNI/NEON packing + per-channel quant) and are scalar on RVV, so quantized graphs are pinned to `C0=8` in `prepareForInference()` (detected via a `CV_8S` arg); only fp32 graphs use the wider block.
#### Validation (native RISC-V)
I have already conducted tests on the Spacemit K3, covering both the X100 (VLEN=256) and the A100 (VLEN=1024).
`opencv_test_dnn`, ENGINE_AUTO (new engine), no assertions:
| VLEN | Test_ONNX_conformance | Test_ONNX_layers (conv/pool/depthwise/quantized/MobileNet_v4) |
|------|-----------------------|--------------------------------------------------------------|
| 256 | 1641 / 1641 | all pass (incl. `Quantized_Convolution`) |
| 1024 | 1641 / 1641 | all pass (incl. `Quantized_Convolution`) |
Added harfbuzz; use it instead of STB to render text #29300
Merge with https://github.com/opencv/opencv_extra/pull/1378.
This is the next big step to improve font rendering in OpenCV 5.x. See #18760, #26301. See also OpenCV 5.0 release notes, where it was pointed out that complex scripts are not rendered correctly, and HarfBuzz integration is needed to fix it. So, here it is — HarfBuzz integration:
* Removed tweaked STB engine. STB truetype rendering engine was included into OpenCV 5.0-pre/5.0 and it was extended to instantiate and render variable fonts, but the support was incomplete and immature.
* Instead, we now use [HarfBuzz](https://github.com/harfbuzz/harfbuzz) — famous font shaping library and now also font rendering library, used by many big companies and organizations.
* As a result, we now correctly render complex scripts, such as arabic or devanagari, correctly handle font ligatures (ff, fi, ft etc.)
<img width="1300" height="600" alt="text_test" src="https://github.com/user-attachments/assets/a7d2c754-0fcf-40f8-8104-578f3a14850b" />
* Potentially, we could also support color emoji, but that would be a next step.
* As with STB-based engine, glyphs are cached (the same glyph from the same font is not rendered twice), so the performance should be on par with the previous engine.
* When OpenCV is built with `-DWITH_HARFBUZZ=ON`, which is set by default, it tries to detect HarfBuzz in the system and use it. If it's not detected, OpenCV builds our own small subset of HarfBuzz.
The following table compares size of libopencv_imgproc.dylib.5.0.0 (Release mode) in different configurations:
| Configuration | libopencv_imgproc (stripped) | delta vs 5.0 |
|----------------------------------------|------------------------------|----------|
| imgproc without text rendering (`-DWITH_HARFBUZZ=OFF`) | 4.27 MB | −2.35 MB |
| imgproc with stb-based engine (5.0) | 6.62 MB | 0.0 Mb |
| imgproc with HarfBuzz-based engine (this PR) | 7.07 MB | +0.45 MB |
The biggest source of the size increase when OpenCV is built with text rendering support (STB- or Harfbuzz-based) is that imgproc in this case includes .ttf fonts (Rubik and 'Wen Quan Yi Micro Hei'), which are gzip-compressed, but still have noticeable size, especially 'Wen Quan Yi' (~2Mb). HarfBuzz itself, compared to STB engine, adds just 0.45Mb, or ~7% to imgproc size. On other platforms (Linux x64, Windows), where IPP or other acceleration libraries are linked into libopencv_imgproc, the harfbuzz footprint is even less noticeable.
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
fix: include ptcloud header and dependency for opengl_testdata_generator sample #29293
## Summary
Fixes the build failure in samples/opengl/opengl_testdata_generator.cpp on the 5.x
branch when building with BUILD_EXAMPLES=ON.
## Root cause
The sample uses `loadMesh`, `TriangleShadingType`, and `TriangleCullingMode`, all
declared in `modules/ptcloud/include/opencv2/ptcloud.hpp`. The sample did not
include this header, and `samples/opengl/CMakeLists.txt` did not list
`opencv_ptcloud` as a required dependency, so the ptcloud module headers/libs
were not available when compiling this sample.
## Changes
- Added `#include "opencv2/ptcloud.hpp"` to opengl_testdata_generator.cpp
- Added `opencv_ptcloud` to `OPENCV_OPENGL_SAMPLES_REQUIRED_DEPS` in
samples/opengl/CMakeLists.txt
## Acceptance criteria
- [x] opengl_testdata_generator.cpp compiles with BUILD_EXAMPLES=ON
- [x] ptcloud module dependency declared so build system links it correctly
Closes#29292
objc: Fix VolumeType enum name clash on MacOS #29262
### Pull Request Readiness Checklist
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
- [ ] The feature is well documented and sample code can be built with the project CMake
**Problem**
When the ObjC wrapper is generated, the global enum `cv::VolumeType` from the ptcloud module is emitted as `typedef NS_ENUM(int, VolumeType)`. macOS defines `typedef OSType VolumeType` in CoreServices, which leads to a typedef-redefinition error during the framework build.
**Fix**
`add_enum()` in `gen_objc.py` now handles namespace-global enums by falling back to a module-level lookup (`self.Module`) when the enum has no enclosing class. A new `gen_dict.json` entry maps `VolumeType` -> `PtcloudVolumeType`, and the import generation automatically uses the renamed enum.
Fixes#29260
doc: remove duplicated bib #29298
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
objc: fix conflicting Swift name for LightGlueMatcher.create #29257Fixes#29256
`cv::LightGlueMatcher` (a `DescriptorMatcher` subclass) declares a static
`create(const String& modelPath, ...)` overload. The Objective-C bindings
generator emits it as the selector `+create:`, which is the same selector as
the inherited `DescriptorMatcher::create(MatcherType)` but carries a different
`swift_name`, so clang refuses to build the `opencv2` Objective-C module:
```
LightGlueMatcher.h: error: 'swift_name' and 'swift_name' attributes are not compatible
```
Wrap the file-path overload with `CV_WRAP_AS(createFromFile)` so it gets a
distinct selector, mirroring the sibling `createFromMemory` overload, while
keeping the Swift name `create(modelPath:...)`.
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
On 5.x branch, commit c3ca3f4f was accidentally reverted, so the
external KleidiCV will be silently disabled. Revert these changes to
support external KleidiCV builds.
Signed-off-by: Weizhao Ouyang <o451686892@gmail.com>
OpenCV requires C++17, and bundled 3rdparty libraries such as KleidiCV
explicitly request CXX_STANDARD 17. With the CMake Xcode generator,
however, neither the global CMAKE_CXX_STANDARD nor per-target
CXX_STANDARD is emitted as CLANG_CXX_LANGUAGE_STANDARD in the generated
project, so those sources are compiled at the toolchain default
(pre-C++17) and fail, e.g.:
kleidicv/include/kleidicv/traits.h: error: no template named
'is_base_of_v' in namespace 'std'; did you mean 'is_base_of'?
Set CLANG_CXX_LANGUAGE_STANDARD=gnu++17 at the project level via
CMAKE_XCODE_ATTRIBUTE_* in the shared getCMakeArgs(), so every target in
the generated Xcode project (including 3rdparty subprojects) builds with
C++17.
imgproc: fix INTER_NEAREST_EXACT to match Pillow (5.x retarget of #28661) #28873
## Summary
Fixes `INTER_NEAREST_EXACT` producing different results from Pillow for images with dimensions that are multiples of 64 (e.g., 128, 192).
Retargets #28661 to 5.x per core team request.
## Root cause
The old 16-bit fixed-point arithmetic (`ifx`, `ifx0`, `>> 16`) rounds differently from Pillow's pixel-center coordinate mapping. At exact pixel boundaries (e.g., y=7 with 128 to 160: `0.4 + 7*0.8 = 5.999999999999999`), Pillow's truncation drops to 5 while the old opencv formula rounds to 6.
## Changes
- `resize.cpp`: Replace `ifx/ifx0/ify/ify0` 16-bit fixed-point with an int64 arithmetic formula equivalent to `floor((i + 0.5) * src / dst)`, computed as `((int64_t)(i * 2 + 1) * src) / (dst * 2)`. This matches Pillow's pixel-center mapping exactly, is deterministic across platforms, and avoids FP rounding divergence entirely.
- `test_resize_bitexact.cpp`: Add `NearestExact_PillowCompat` covering 4 dimension pairs including the reproducer from #28429.
## Testing
- All 3 `Resize_Bitexact` tests pass (Linear8U, Nearest8U, NearestExact_PillowCompat) on this branch built against 5.x
- Verified bit-exact match to PIL output (Python 3.14, Pillow) on 49 dimension combinations including random pairs
- Built on macOS ARM64 with HAL (carotene/KleidiCV) active
Fixes#28429
[GSOC] feat: Add ALIKED feature extractor and LightGlue matcher with DNN integration #28986
## PR Description
### Summary
Integrate ALIKED and LightGlue into OpenCV's `features` module as native`Feature2D` and `DescriptorMatcher` implementations, enabling end-to-end neural feature matching within OpenCV's ecosystem.
---
### What's included
#### New classes
- **`cv::ALIKED`** extends `Feature2D`
- CNN-based keypoint detection
- 128-D descriptor extraction via ONNX Runtime
- **`cv::LightGlueMatcher`** extends `DescriptorMatcher`
- Deep feature matching with spatial context
- Uses keypoints and image sizes during matching
---
#### API design
- Standard OpenCV patterns:
- `detectAndCompute()`
- `match()`
- `knnMatch()`
- Multiple factory methods:
- ONNX model path
- In-memory model buffer
- Pre-loaded `dnn::Net`
- `Params` structs use `CV_EXPORTS_W_SIMPLE`
for Python/Java bindings support
- Optional DNN dependency:
- `HAVE_OPENCV_DNN` guards
- Stub implementations throw `StsNotImplemented`
---
### Files added
| File | Description |
|------|-------------|
| `src/feature2d_aliked.cpp` | ALIKED implementation |
| `src/matchers_lightglue.cpp` | LightGlueMatcher implementation |
| `src/aliked_context.hpp` | Shared internal context struct |
| `test/test_aliked_lightglue.cpp` | Unit tests (9 test cases) |
| `samples/cpp/example_features_aliked_lightglue.cpp` | Demo application |
---
### Files modified
- `CMakeLists.txt`
- Add `opencv_dnn` as optional dependency
- `features.hpp`
- Add ALIKED and LightGlueMatcher declarations
- `precomp.hpp`
- Add DNN include guard
---
### Usage
```cpp
// Feature extraction
Ptr<ALIKED> aliked =
ALIKED::create("aliked-n16rot-top1k-640.onnx");
vector<KeyPoint> kpts;
Mat descs;
aliked->detectAndCompute(image, Mat(), kpts, descs);
// Feature matching
Ptr<LightGlueMatcher> lg =
LightGlueMatcher::create("aliked_lightglue.onnx");
lg->setPairInfo(
kpts1Mat,
kpts2Mat,
img1.size(),
img2.size()
);
vector<DMatch> matches;
lg->match(descs1, descs2, matches);
````
please refer to samples/cpp/example_features_aliked_lightglue.cpp
---
### Test plan
* Build with `BUILD_LIST=features,dnn`
* Build without DNN:
* Verify stubs compile
* Verify `StsNotImplemented` is thrown
* Run:
* `ctest -R Features2d_ALIKED`
* `ctest -R Features2d_LightGlueMatcher`
* Run sample application with:
* Real images
* Real ONNX models
* Verify Python/Java bindings compile and work
---
### Related
Phase 1 of the
"End-to-End AI Feature Extraction and LightGlue Matching Pipeline"
GSoC project.
Designed to be extensible to:
* XFeat
* SuperPoint
* Other neural feature extractors
### test dependency
Depends on the opencv_extra PR adding ALIKED and LightGlue test models:
- [opencv_extra PR](https://github.com/opencv/opencv_extra/pull/1366)
This PR adds the following ONNX models to `download_models.py`:
- `aliked-n16rot-top1k-640.onnx`
- `aliked_lightglue.onnx`
These models are required for the `features2d` tests in the main OpenCV repository to validate the ALIKED and LightGlue feature extraction and matching pipeline.
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
[FOLLOW UP] : Documentation optimizations for the new Sphinx structure #29220
### Pull Request Readiness Checklist
This PR serves as a follow-up to the new documentation system introduced in [#29206](https://github.com/opencv/opencv/pull/29206)
Co-authored by: @abhishek-gola @kirtijindal14 @Akansha-977 @Prasadayus @varun-jaiswal17
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
Inverted imgproc-geometry dependency and moved more functions to geometry #29230
Fixes: https://github.com/opencv/opencv/issues/20267
Continues: https://github.com/opencv/opencv/pull/29175
OpenCV Contrib: https://github.com/opencv/opencv_contrib/pull/4137
OpenCV Extra: https://github.com/opencv/opencv_extra/pull/1377
Summary:
- LSD returned back to imgproc
- drawing functions moved to imgproc
- undistort image and related perf-pixel functions moved to imgproc
- moments moved to geometry
- estimateXXXtransform moved to geometry
After the patch the geometry module depends on code and Flann and may be used everywhere without potential circular dependencies
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [ ] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
Update BarcodeDetector super-resolution API to use single-file ONNX #29227
### Pull Request Readiness Checklist
This PR updates the `BarcodeDetector` super-resolution API to support and utilize a single-file ONNX model format.
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
little but important fix in bicubic warping 1-channel case #29229
merge together with https://github.com/opencv/opencv_contrib/pull/4136
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
Fix MLAS 32-bit x86 build by integrating missing upstream assembly files #29226
### Pull Request Readiness Checklist
This resolves the 32-bit x86 build failure for MLAS. Related to: https://github.com/opencv/opencv/pull/29218
* Added the required `x86` assembly files and headers from upstream.
* Added `__x86_64__` guards around the AMX `syscall` and the FMA3/AVX512F kernel assignments to prevent 32-bit compilation crashes.
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [x] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
[OpenCV 5] Fix apriltag corners order and update the doc #28823
I have updated documentation for the AprilTag dictionaries.
Corresponding issues:
- https://github.com/opencv/opencv-python/issues/1195
- https://stackoverflow.com/questions/79044142/why-is-the-order-of-the-incoming-corners-different-between-apriltag-and-aruco-ma
This is a breaking change and is targeted only for OpenCV 5.
---
I have updated the ArUco doc with more information about fiducial markers detection.
I have tried to add some recommendations, best practices:
- `DICT_ARUCO_MIP_36h12` should be the recommended family, [see](https://stackoverflow.com/a/51511558)
- link to download pregenerated markers for `MIP_36h12` is [here](https://sourceforge.net/projects/aruco/files/. I have not found some other official links for the other ArUco family, but since `MIP_36h12` should be used, I guess it is fined.
- recommendation to have a white border when printing the marker
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [x] The PR is proposed to the proper branch
- [x] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [x] The feature is well documented and sample code can be built with the project CMake
Dedicated pointcloud module #29224
OpenCV contrib: https://github.com/opencv/opencv_contrib/pull/4134
### Pull Request Readiness Checklist
See details at https://github.com/opencv/opencv/wiki/How_to_contribute#making-a-good-pull-request
- [x] I agree to contribute to the project under Apache 2 License.
- [x] To the best of my knowledge, the proposed patch is not based on a code under GPL or another license that is incompatible with OpenCV
- [ ] The PR is proposed to the proper branch
- [ ] There is a reference to the original bug report and related work
- [ ] There is accuracy test, performance test and test data in opencv_extra repository, if applicable
Patch to opencv_extra has the same branch name.
- [ ] The feature is well documented and sample code can be built with the project CMake
Varun Jaiswal
velonica0
Vadim Pisarevsky
Alexander Smorkalov
Maitreyee Deshmukh
Haris shakeel
Kumataro
Vincent Rabaud
Peter Rekdal Khan-Sunde
Yang Chao
Weizhao Ouyang
Yang Chao
Alexander Smorkalov
Matt Van Horn
Abhishek Gola
Vibhor
Yang Guanyuhan
omrope79
s-trinh