设想一家小型档案馆正在翻拍一盒明信片。相机固定在支架上，操作员逐张更换下方的明信片，再释放快门。每张照片都应传到电脑上，供人检查。快门声让人安心，软件却还要找到拍摄生成的文件，再把它取回来。gPhoto2 的架构把这些步骤分得很清楚：相机控制、拍摄通知和文件传输各有分工。[1][2]

这种分工解释了项目的用处，也解释了联机拍摄中常见的困惑：电脑识别出了相机，摄影者期待的功能却仍有缺项。顺着一张照片在系统中的流转过程，可以看清各个环节究竟负责什么。

拍摄按钮之下

几个名称分别对应不同的组件。gphoto2 是命令行客户端，libgphoto2 是应用程序与相机通信时使用的库。在库的架构中，名为 camlibs 的相机驱动负责处理各款相机的特定行为，libgphoto2_port 则负责通信端口的抽象。前端调用库就能请求操作，各款设备的协议由库内相应组件处理。[1][3]

项目的架构文档介绍了两种扩展方式：接入新相机时，实现必需的驱动回调函数；增加通信方式时，扩展端口层。维护者由此能找到处理硬件特例的具体位置。应用开发者也有了一套共用接口，可以据此编写图像浏览器、拍摄窗口或脚本。[1]

这层分工对应着具体工作。档案馆下一张明信片该用什么名称，由应用程序决定；为了取得照片，需要执行哪些受支持的相机操作，则由驱动负责。接口得到统一，各款相机自身的差异依然存在。

检测到相机，只过了第一关

darktable 依赖这套软件与相机协作，它的用户手册从应用端展示了该怎样检查。排查过程依次验证相机检测、驱动能力、远程发起拍摄，最后再检查由相机本身触发的拍摄。各项测试分开进行，因为前一步成功，后一步仍待验证。[4]

例如，gphoto2 --auto-detect 用于识别已连接的相机，gphoto2 --abilities 则报告驱动声明的能力。后一个命令读取库中的信息，各项功能的实际表现还需另行测试。[3] darktable 文档要求先检查是否支持图像拍摄和配置，然后再进入实拍测试。[4]

一个独立的亲历案例让这种区别更具体。Carla Schroder 在 2013 年发表于 Linux.com 的操作指南中，展示了自己使用的 Canon EOS 7D 和较早款 EOS 400D 的能力列表：两台相机都支持图像拍摄，较早款相机的列表中则缺少预览支持。[6] 这项历史记录描述的是当时受测的配置，适用范围止于那些配置；今天的硬件兼容性还需另行判断。

对明信片翻拍工作台而言，检测到相机之后，还要验证预定流程能否运转。测试应覆盖操作员实际采用的动作，包括按下机身快门之后，图像能否传到电脑。

事件带来文件地址

在库这一层，gp_camera_capture() 调用成功后，会填入一个 CameraFilePath 输出参数，标明相机中新文件的位置。随后需要单独调用 gp_camera_file_get()，将文件取回。这个路径指向的文件仍在相机上，要得到本地照片，还需完成下载。[2]

异步拍摄流程还区分了另外几件事。gp_camera_trigger_capture() 发起拍摄后立即返回，应用程序接着调用 gp_camera_wait_for_event() 等待事件。GP_EVENT_FILE_ADDED 事件带来文件路径，GP_EVENT_CAPTURE_COMPLETE 则报告拍摄完成。超时也是一种事件，它本身没有附带新图像。[2]

看看这些消息分别允许档案馆的软件记录什么。“快门已触发”记录的是一次请求；“已添加文件”标明了待获取的文件；“下载已完成”才确认本地文件已经到达。若把三者都记成同一种成功状态，照片缺失时就难以查出问题所在。

命令行前端针对不同用途组合了这些操作。--capture-image-and-download 请求拍摄图像并将其取回；--capture-tethered 等待新文件通知，让摄影者可以按相机上的快门拍摄。后者等同于 --wait-event-and-download。[3] 事件通知需要相机和驱动的共同支持，图形界面上的拍摄按钮也受这一条件约束。[4]

照片暂存在哪里，同样重要

相机内部还涉及存储位置的选择。项目的远程控制指南介绍了 Canon 和部分 Nikon 相机上的 capturetarget 设置，可以选择把照片存入相机 RAM（内存）或存储卡。按照文档描述的 RAM 行为，图像必须在同一次 gphoto2 调用期间下载：连接一旦关闭，图像就有消失的风险。[5]

“现在拍照，稍后取回”因此对存储提出了要求：照片需要在这段间隔中持续保留。成功曝光并写入相机的临时内存，只能确认拍摄这一步；稍后的进程能否找到文件，还取决于它是否留存下来。

可用配置可以用 --list-config 查看；在支持相应设置的设备上，--get-config capturetarget 会列出当前值和可选项。远程控制指南本身也提醒读者，其中的相机列表存在遗漏或错误的风险。[5] 测试时，应把具体相机、所用模式和已安装的驱动看作一个整体。

传输完成后是否保留照片，是另一项选择。对于 --capture-image-and-download 和间隔拍摄，--keep 会将图像保留在相机存储卡上；文档所述的默认行为是在下载后删除它们。[3] 拍摄时把照片存在哪里，以及下载后是否保留相机上的原件，是两个各自独立的问题。

把可用的文件交给下一个程序

客户端留出了一个方便的衔接点：文件下载完成后，钩子脚本会收到 ACTION=download，本地文件名则放在 ARGUMENT 中。[3] 此时适合把照片交给检查或编目程序。

对于只有一台工作站、且有人维护的小型档案馆，我建议把这一步交接保持简单：记下文件名及其应对应的明信片标识，再让一个独立的工作进程生成预览并检查结果。任何失败都记录在对应文件名下。工作日志中，图像已下载和图像已成功编目应当是两种可区分的状态。

以上是应用设计建议，所述效果超出了 gPhoto2 本身的保证范围。如果工作台要无人值守，还需要有人规定恢复办法：连接线断开、目标磁盘已满，或者拍摄尚未完成时操作员就换了明信片，系统该如何继续工作。库明确区分了各个阶段，便于定位这些问题；具体处置仍由应用完成。

一轮拍摄结束后，真正有用的凭据是一组能够打开、能够与明信片逐一对应的照片。快门声开启了这份记录，之后的每一步也都属于这项工作。

资料来源

1. gPhoto，〈libgphoto2, the core〉——库的架构、相机驱动与通信端口抽象。
2. gPhoto，libgphoto2 API 参考文档，〈gphoto2/gphoto2-camera.h〉——拍摄、文件获取、事件类型与异步触发；生成的参考文档标注版本为 2.5.10.1。
3. gPhoto，〈gphoto2〉命令行手册——驱动能力、拍摄模式、文件保留与下载钩子。
4. darktable 4.6 版用户手册，〈Troubleshooting〉——分别测试相机检测、驱动能力、远程拍摄与相机事件。
5. gPhoto，〈Remote controlling cameras〉——配置查询、拍摄存储位置、相机临时内存与支持限制。
6. Carla Schroder，〈How to Remote Control Your Camera with Darktable on Linux〉，Linux.com，2013 年 11 月 26 日——独立撰写的操作指南，附有实测的能力列表。
7. Elja Trum，〈Je laptop als een groot cameradisplay gebruiken〉，Photofacts，2008 年 3 月 23 日——照片原始出处，以及使用 MacBook 联机拍摄的配置记录；荷兰语资料。