FCam - 低光/HDR 照片
我正在使用 FCam 拍照，现在无需修改，照片与智能手机相机的水平相当。 FCam 宣传 HDR 和低光性能，但我没有看到任何在拍照时如何使用它的示例。
如何拍摄 HDR 照片？根据我使用单反相机的经验，您通常会拍摄 3 张照片，一张在下方，一张在上方，一张针对场景正确曝光。
由于我将拍摄很多照片，我应该如何将这些像素融合在一起？平均数？
沃尔特
I am using FCam to take pictures and right now without modification, the pictures are par for a smartphone camera. FCam advertises HDR and low-light performance, but I don't see any examples of how to use that when taking pictures.
How do I take HDR pictures? From my experience with SLRs, you normally take 3 pictures, 1 under, 1 over, and 1 exposed properly for the scene.
Since I will be taking many pictures, how should I blend those pixels together? An average?
Walter
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
FCam 项目页面包括一个完整的相机应用程序 - FCamera，请检查 FCam 下载页面，最后一项，对于“HDR 取景器”，它只是将长/短曝光图像平均在一起，对于“HDR 捕获”，它会自动记录一系列适当曝光的镜头。请参阅源代码中的 src/CameraThread.cpp，我不确定引用该内容是否合适，但您会在
CameraThread::run()中找到这两部分>。它不会为您平均 HDR 图像，而是将它们记录为序列。我想这是故意的 - 您通过在平均过程后仔细调整色调映射来实现大部分“HDR”吸引力，即调整动态范围压缩回 8 位的精确执行方式。如果您在相机上以硬编码方式执行此操作，则会限制摄影师在实现最佳输出方面的选择。 MPI 有一个关于 HDR 成像技术的研究小组，该研究小组为此提供了源代码。
简而言之，“穷人的 HDR”只是一个平均值。 “正确的 HDR”永远不会是 8 位 JPEG，因为这会丢弃“高动态范围”中的“高”位 - 因此，从 HDR（将具有 16 位/颜色或什至更多）到 JPEG 的转换通常作为 HDR 图像序列的后处理（离机）步骤完成。
关于 HDR 视频的注意事项
对于 HDR 视频，如果您在手持设备上使用单个传感器进行录制，通常会在形成“HDR 序列”的图像之间引入运动（总曝光时间等于所有子曝光的总和，加上传感器数据读取和相机控制器重新编程的延迟）。
这意味着还应该在实际叠加和最终色调映射操作之前尝试图像配准，除非您对模糊感到满意。注册在某种程度上是计算密集型的，也是首先记录图像流并稍后执行 HDR 视频创建（提供一些手动调整）的另一个充分理由。 OpenCV库提供注册/匹配功能。
上述MPI软件是PFSTools，特别是色调映射操作符(PFStmo)库。其中一位作者的研究论文提供了一个很好的起点；至于您关于如何执行后处理的问题，PFSTools 是通过 UNIX 管道互操作/传递数据的命令行实用程序；在 Maemo / N900 上，由于完整的 Linux 环境，它们的使用非常简单；只需通过
system()生成一个 shell 脚本。The FCam project page includes a complete camera app - FCamera, check the FCam Download Page, last item, which for "HDR Viewfinder" simply averages a long/short exposure image together, and for "HDR Capture" automatically records a burst of suitably-exposed shots. See
src/CameraThread.cppin the sources, I'm not sure how appropriate it is to quote from that but you'll find both pieces inCameraThread::run().It doesn't average the HDR images for you, it records them as sequence. I guess that's by intent - much of the "HDR" appeal you achieve by carefully tuning the tone mapping after the averaging process, i.e. adjust how exactly the dynamic range compression back to 8bit is performed. If you'd do that in a hardcoded way on camera, you'll restrict the photographer's options with respect to achieving the optimal output. The MPI has a research group on HDR imaging techniques that provides sourcecode for this purpose.
In short, a "poor man's HDR" would just be an average. A "proper HDR" will never be 8-bit JPEG because that throws away the "high" bit in "high dynamic range" - for that reason, the conversion from HDR (which will have 16bit/color or even more) to e.g. JPEG is usually done as postprocessing (off-camera) step, from the HDR image sequence.
Note on HDR video
For HDR video, if you're recording with a single sensor on a hand-held you'll normally introduce motion between the images that form the "HDR sequence" (your total exposure time equals the sum of all subexposures, plus latency from sensor data reads and camera controller reprogramming).
That means image registration should be attempted before the actual overlay and final tone mapping operation as well, unless you're ok with the blur. Registration is somewhat compute intensive and another good reason to record the image stream first and perform the HDR video creation later (with some manual adjustment offered). The OpenCV library provides registration / matching functions.
The abovementioned MPI software is PFSTools, particularly the Tone Mapping operators (PFStmo) library. The research papers by one of the authors provide a good starting point; as to your question on how to perform the postprocessing, PFSTools are command-line utilities that interoperate/pass data via UNIX pipes; on Maemo / the N900, their use is straightforward thanks to the full Linux environment; just spawn a shell script via
system().