|

楼主 |
发表于 2017-9-20 02:30:28
|
显示全部楼层
楼上的这位是真敢说啊,本来不想太费时间,毕竟不是一个专业,而且也已经决定汉化最新版了,感觉没必要再费劲回复了。但说我敷衍大伙,那这个有点信口开河了,只好回应一下了。那就看代码吧。
- <div> {
- .name = "Data format",
- .priv = &output_format,
- .max = 5,
- .update = output_format_update,
- .choices = CHOICES(
- "14-bit",
- "12-bit",
- "10-bit",
- "14-bit lossless",
- "12-bit lossless",
- "11...8-bit lossless",
- ),
- .help = "Choose the output format (bit depth, compression) for the raw stream:",
- .help2 = "14-bit: native uncompressed format used in Canon firmware.\n"
- "12-bit: uncompressed, 2 LSB trimmed (nearly lossless on current sensor).\n"
- "10-bit: uncompressed, 4 LSB trimmed (small loss of detail in shadows).\n"
- "14-bit compressed with Canon's Lossless JPEG. Recommended ISO < 100.\n"
- "Signal divided by 4 before compression. Recommended ISO 100-1600.\n"
- "Signal divided by 8/16/32/64 before compression, depending on ISO.\n"
- },</div>
复制代码
这段代码的来源看截图,明白的不需要我解释,不明白的,我犯不着跟你解释。
然后我跟大家说说源码中选项的含义
"14-bit: native uncompressed format used in Canon firmware.\n"
14BIt位深无压缩格式,就是现在大家用的格式。
"12-bit: uncompressed, 2 LSB trimmed (nearly lossless on current sensor).\n"
12Bit位深无压缩格式,最低位2位消除(近似于无损)
"10-bit: uncompressed, 4 LSB trimmed (small loss of detail in shadows).\n"
10Bit位深,最低位4位消除(开始丢失暗部细节)
"14-bit compressed with Canon's Lossless JPEG. Recommended ISO < 100.\n"
14Bit位深JPEG无损算法,适用于ISO小于100的场景。(JPEG无损是什么呢?大家可以自己百度一下,就是前位预测,下边两种算法都是这个算法的变种,原理一样,具体压缩量我下面具体解释)
"Signal divided by 4 before compression. Recommended ISO 100-1600.\n"
靠前4位采样预测压缩算法,适用于ISO100-1600。
"Signal divided by 8/16/32/64 before compression, depending on ISO.\n"
靠前8/16/32/64位跳步采样预测压缩算法,步长根据所设置的ISO值而变化。
好了,下面来说说后两个的具体压缩率。
第一:压缩率不是固定的,由场景的繁杂程度决定,越繁杂的画面,压缩率越低,超级复杂的场景会出现预测失败,负压缩的情况,这是由编码决定的,不熟悉的朋友去了解一下霍夫曼编码。
第二:为什么三种压缩算法都对ISO有要求呢,因为ISO的大小决定了噪点的大小,而噪点会影响预测的准确率,这个我不用解释了吧,而很低的准确率会出现负压缩,这个我上边也解释过了。
第三:在最简单场景下,最大压缩率能达到多少呢,也就缩减10%左右。依据是什么呢,程序里写着呢,我贴在下面大家自己看。
- /**
- * RAW recording. Similar to lv_rec, with some different internals:
- *
- * - buffering strategy:
- * - group the frames in contiguous chunks, up to 32MB, to maximize writing speed
- * (speed profile depends on buffer size: http://www.magiclantern.fm/forum/index.php?topic=5471 )
- * - always write if there's something to write, even if that means using a small buffer
- * (this minimizes idle time for the writing task, keeps memory free in the startup phase,
- * and has no impact on the sustained write speeds
- * - always choose the largest unused chunk => this maximizes the sustained writing speed
- * (small chunks will only be used in extreme situations, to squeeze the last few frames)
- * - use any memory chunks that can contain at least one video frame
- * (they will only be used when recording is about to stop, so no negative impact in sustained write speed)
- *
- * - edmac_copy_rectangle: we can crop the image and trim the black borders!
- * - edmac operation done outside the LV task (in background, synchronized)
- * - on buffer overflow, it stops or skips frames (user-selected)
- * - using generic raw routines, no hardcoded stuff (should be easier to port)
- * - only for RAW in a single file (do one thing and do it well)
- * - goal #1: 1920x1080 on 1000x cards (achieved and exceeded, reports say 1920x1280 continuous!)
- * - goal #2: maximize number of frames for any given resolution + buffer + card speed configuration
- * (see buffering strategy; I believe it's close to optimal, though I have no idea how to write a mathematical proof for it)
- */
- /*
- * Copyright (C) 2013 Magic Lantern Team
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version 2
- * of the License, or (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the
- * Free Software Foundation, Inc.,
- * 51 Franklin Street, Fifth Floor,
- * Boston, MA 02110-1301, USA.
- */
复制代码 这段话我不翻译了,相信举着英文官网旗号提出疑问朋友绝对是看的懂得,否则他的疑问我也是太当真了。
这个压缩率录制4K的结果是什么,大家应该心知肚明了?但是新版我还是决定汉化,因为我发现了一个比压缩更实用的功能,先小小的保留一下。
好了,说的够多的了,我希望大伙讨论问题一定要真刀真枪的用,不要捕风捉影,更不能误导群众,你痛快了一下嘴,别人可能就得跑断腿,珍惜这个圈子。
|
本帖子中包含更多资源
您需要 登录 才可以下载或查看,没有帐号?立即注册
x
|