Bytedeco通过提供使用共同开发的JavaCPP技术生成的即用型绑定，使本地库可用于Java平台。 我们希望这是Java与C / C ++之间缺少的桥梁，它将计算密集型科学，多媒体，计算机视觉，深度学习等带入Java平台。
核心技术
JavaCPP [API] –一种工具，它不仅可以生成JNI代码，还可以从完全用Java编写的适当接口文件中构建本机包装库文件。 它还可以自动解析C / C ++头文件以生成所需的Java接口文件。
构建Java绑定到C / C ++库
这些是我们称为JavaCPP Presets的项目的一部分。 许多人共存于同一个GitHub存储库中，并且所有人都使用JavaCPP从开放源代码领域包装预定义的C / C ++库。 绑定公开了几乎所有相关的API，并使它们以可移植且用户友好的方式可用于任何Java虚拟机（包括Android），就像它们与其他任何普通Java库一样。 我们为以下C / C ++库提供了预设：
-
FlyCapture – [示例用法] [API] – PGR的图像采集和相机控制软件
-
OpenKinect – [sample usage] [API] [API 2] – 开源库，用于Xbox和Windows传感器使用Kinect
-
librealsense – [示例用法] [API] [API 2] – 英特尔实感深度和跟踪摄像头的跨平台库
-
videoInput – [示例用法] [API] – 免费的Windows视频捕获库
-
ARToolKitPlus – [示例用法] [API] –基于标记的增强现实跟踪库
-
OpenBLAS – [示例用法] [API] – 基于GotoBLAS2 1.13 BSD版本以及LAPACK的优化BLAS库
-
Leptonica – [sample usage] [API] – 对图像处理和图像分析应用程序有用的软件
-
TensorFlow – [示例用法] [API] – 使用数据流图进行计算以实现可扩展的机器学习
-
ONNX Runtime – [示例用法] [API] – ML模型的跨平台高性能评分引擎
-
cpu_features – [示例用法] [API] – 跨平台C99库，用于在运行时获取cpu功能
-
在此处添加您喜欢的C / C ++库，例如：Caffe2，OpenNI，OpenMesh，PCL等。了解有关如何执行此操作的信息。
制作完成后，我们将在此列表中添加更多内容，包括来自bytedeco/javacpp-presets存储库外部的内容。
利用预设绑定的项目
-
JavaCV [API] – 基于JavaCPP预设的库，该库依赖于计算机视觉领域中常用的本机库来促进在Java平台上开发这些应用程序。 它提供了易于使用的界面，可从摄像机和音频/视频流中抓取帧，对其进行处理，并将其记录回磁盘或通过网络发送。
-
JavaCV示例 – RobertLaganière为题为《 OpenCV 2计算机视觉应用程序编程手册》的书最初用C ++编写的示例集合，但移植到JavaCV并用Scala编写。
-
ProCamCalib – JavaCV示例应用程序，可以对一组视频投影仪和彩色相机执行几何和光度校准。
-
ProCamTracker – 另一个示例JavaCV应用程序，它使用ProCamCalib的校准来实现一种视觉方法，该方法跟踪带纹理的平面并通过投影映射实现无标记的交互式增强现实。
更多项目信息
请参阅贡献和下载页面，以获取有关如何帮助或获取此软件的更多信息。
有关Bytedeco项目的更多常规信息，请参见GitHub上的开发人员网站。
最新消息
我们很高兴地宣布，在这个新的时代，Bytedeco首次发布！ 1.5版适用于JavaCPP，JavaCPP预设，JavaCV，ProCamCalib和ProCamTracker。 此版本带有针对NumPy（是的，Python库，更多内容在下文），NCCL，nGraph，Qt（提供了AWT，Swing和JavaFX的替代）和cpu_features的新预设，以及FFmpeg的更新（现在 还包括ffmpeg和ffprobe程序本身），libfreenect，HDF5，MKL，MKL-DNN，LLVM，Leptonica，ARPACK-NG，CUDA，cuDNN，MXNet，TensorFlow，TensorRT，ONNX，LiquidFun和Skia。 非常感谢所有贡献者！ 根据git shortlog 1.4.4..1.5 --summary的报道，自三个月前发布以来，它们是：
亚历克斯·梅里特（Alex Merritt），
阿诺·让森（Arnaud Jeansen），
格雷格·哈特（Greg Hart），
HGuillemet，k3rnL，
塞缪尔·奥德（Samuel Audet），
西蒙·哈里斯（Simon Harris）
但是，像往常一样，该列表中没有任何人非常慷慨地帮助修复CI设置，测试版本，调试代码，文件建议，进行更正，报告错误，提出想法，更新Wiki页面等。您可以找到有关以下内容的详细信息： 所有这些更改和修复以及以上在CHANGELOG.md文件中上面列出的存储库上。
但是，如前所述，最重要的更新涉及所有工件的模块化，以符合Java平台模块系统（JPMS）。从理论上讲，我们只需要到处添加刺激性的module-info.java文件（我们非常感谢ModiTect的帮助），但是JPMS的一个主要限制是我们不能将Java包拆分为多个模块，因此我们不得不更新所有预设的软件包以使其合规，因此次要版本从1.4.x升至1.5.x。在很大程度上要归功于HervéGuillemet，我们最终提出了一个令人满意的命名方案，该方案不仅符合JPMS，而且还产生了与典型Java API更为接近的顶级类，并且Javadoc可以更清晰地呈现为HTML 。现在，不是将所有类都放在org.bytedeco.javacpp包中，而是所有模块都根据其工件的名称拥有自己的包，例如，对于OpenCV，则为org.bytedeco.opencv。在这样的包中，我们有顶级类，当工件包含多个本机库时，这些顶级类又分为子包，以及一个全局子包，您猜到了，该子包包含带有全局C / C ++函数和变量的本机声明的类。对于大多数下游项目，升级仅需要修改导入语句。例如，对于OpenCV和TensorFlow，我们通常会具有以下语句：
import static org.bytedeco.javacpp.opencv_core.*;
import static org.bytedeco.javacpp.opencv_imgproc.*;
import static org.bytedeco.javacpp.opencv_calib3d.*;
import static org.bytedeco.javacpp.opencv_objdetect.*
import static org.bytedeco.javacpp.tensorflow.*;
有了这些确切的语句，要迁移到新的API，唯一需要做的更改就是将它们替换为以下内容：
import org.bytedeco.opencv.opencv_core.*;
import org.bytedeco.opencv.opencv_imgproc.*;
import org.bytedeco.opencv.opencv_calib3d.*;
import org.bytedeco.opencv.opencv_objdetect.*;
import org.bytedeco.tensorflow.*;
import static org.bytedeco.opencv.global.opencv_core.*;
import static org.bytedeco.opencv.global.opencv_imgproc.*;
import static org.bytedeco.opencv.global.opencv_calib3d.*;
import static org.bytedeco.opencv.global.opencv_objdetect.*;
import static org.bytedeco.tensorflow.global.tensorflow.*;
为避免与旧API发生冲突，我们还将所有工件的groupId更改为org.bytedeco，因此不再包含org.bytedeco.javacpp-presets的烦人的长名称，这也反映了我们对JVM无法解决的世界的不断发展的技术理解 统治他们。
Java能够抽象化底层操作系统，并与诸如Maven和现在的jlink之类的工具一起，根据opencv-stitching-jlink示例项目创建紧凑的自包含独立应用程序，并具有管理软件复杂性的能力。生态系统无与伦比。但是，JVM本身在支持其他现有编程语言方面却惨败。我们显然需要访问用C / C ++编写的用于计算密集型算法的本机库，但是即使流行的脚本语言（如JavaScript和Python）也无法在JVM上感到宾至如归，尽管它们本身的劣等本机运行时也是如此。 Jython停留在Python 2.7上，而Nashorn甚至在其拟议的继任者Graal JavaScript准备好取代之前就已过时。同样，Graal Python确实是一种了不起的技术，但它仍然是“早期实验实现”，几乎没有任何用处，更不用说CUDA或对GPU的任何形式的支持，在任何路线图上都找不到。不管是什么原因导致缺乏通用虚拟机的外观，大多数用户都会对此感到满意，相反，有可能在同一进程中执行多个运行时以有效共享数据，这种方法也是永不过时的考虑到Graal无论如何仍需要实现JNI和Python的C API才能与JNA，JNR或JavaCPP等工具以及NumPy或TensorFlow之类的库兼容。我们证明，对于CPython和当前的JDK，今天可以很容易地实现初始实现，从NumPy的JavaCPP预设开始，它将所有高级依赖项管理留给Java和Maven，JavaCPP会自动提取Python包并以可移植和可重复的方式将其与支持平台上的MKL一起缓存到其缓存中，而无需使用其他任何不那么可移植的工具，包括Docker。实际上，这使得Python和NumPy作为Java开发人员可以使用的一种特定于域的脚本语言。我们计划以这种方式提供更多Python软件包，接下来继续进行TensorFlow的JavaCPP预设。
网友评论