NMM-HD

akiduki 写了：1. 你看清楚，我说的是8->16没有问题。
2. 8->10的转换确实有问题，但和dither_plane没有关系。请你再读一遍dither_plane里面你应用的那句注释。
3. 我不知道avs变相输出16-bit给x264会是什么样的路径，看上去会走dither_plane吧。avs输出16-bit的那个trick我没仔细研究过。再者，16-bit的limited range YUV是什么样的nominal peak可没标准定义。所以这里本身就是个问号。
4. madshi用的是full range RGB，不是YUV，别看错了。
5. madshi提出的banding问题，本身的问题提出就是错的。而且在他推崇的直接左移两位的方法（也是MSDN的方法）中也存在，你自己算下就知道了。
这不奇怪，原本8-bit的unit（1） value差，转换成>8bit后差值应该大于1，而大于1并不等于出现了gradient的增加（banding）。8bit原有的dynamic，提高bitdepth后应该保持（不可能增加，这样就违背信息论了。dithering另当别论。）才对。
就像你考试得了10分中的9分，我得了8.5分；换成百分制后你是90我是85，那你能说换了百分制后我和你之间的分差增大了么？

When 8-bit words are treated in 10-bit system, two LSBs of zeros are to be appended
to the 8-bit words.

For 1125/60/2:1 – For 10-bit coding two LSBs are added to the 8-bit code words.

06_taro 写了： 摘自R-REC-BT.709-5-200204-I!!PDF-E.pdf的6 Digital representation中注释(3)
For 1125/60/2:1 – For 10-bit coding two LSBs are added to the 8-bit code words.

06_taro 写了：我认为low bit depth->high bit depth就是应该简单地按位左移，即使是以后实现Hi444P里的14bit也不例外。dither应该在high bit depth的源输入而输出要求是low bit depth时做，或者至少给个参数去控制是否做。low->high从编码是尽量保留源信息的角度上看没必要也不应该转到16再降，除非在内部有16bit的为了提高编码质量的运算

如果我们假定“x264里左移8位再加上原数值，将8bit转换到16bit”是正确的，正如aki巨巨说的“1. 你看清楚，我说的是8->16没有问题。”，那么按照一般的dither方法进行16bit到10bit的转换，最初8bit数值235最终结果是10bit下943，不符合BT.709标准，我们需要寻找另一种16bit->10bit的dither方法。

在关于madshi提出有关banding的问题上，aki巨巨说“原本8-bit的unit（1） value差，转换成>8bit后差值应该大于1，而大于1并不等于出现了gradient的增加（banding）”，我觉得aki巨巨并没有真正理解madshi想说的，首先aki巨巨说的这句话是对的，但是madshi想表达的是“The gradient isn't smooth”，也就是说他是指(257-252)=5，而(269-265)=(265-261)=(261-257)=(252-248)=(248-244)=(244-240)=4，所以产生了banding。

akiduki 写了：我自始至终都怀疑从dither_plane的这个函数实际使用时没有调用，这个函数是为了降回输入bitdepth用的（注释上也说了）。如果直接输出10bit，用的就是我早先贴的那句。

akiduki 写了：在前面的帖子里你自己也比较了这两种方法，说了x264的方法conversion后出现gradient不smooth的情况，这就是exactly x264输入8bit后做的事啊-_-然后怎么就又冒出dither来了呢。

8-bit is converted to 16-bit through left shifting the orginal value with 8 and then adding the original value to that

It has been written in such a way so that if the source has been upconverted using the same algorithm as used in scale_image, dithering down to the source bit depth again is lossless.

histamine 写了：第二点我认同，我说的是“16bit输入x264时的16bit->10bit的dither”和“8bit输入时发生在x264内部的8bit->16bit->10bit转换，无涉及dither路径”

static int get_frame( hnd_t handle, cli_pic_t *output, int frame )
{
    depth_hnd_t *h = handle;

    if( h->prev_filter.get_frame( h->prev_hnd, output, frame ) )
        return -1;

    if( h->bit_depth < 16 && output->img.csp & X264_CSP_HIGH_DEPTH )
    {
        dither_image( &h->buffer.img, &output->img, h->error_buf );
        output->img = h->buffer.img;
    }
    else if( h->bit_depth > 8 && !(output->img.csp & X264_CSP_HIGH_DEPTH) )
    {
        scale_image( &h->buffer.img, &output->img );
        output->img = h->buffer.img;
    }
    return 0;
}

    char args[20];
    sprintf( args, "bit_depth=%d", x264_bit_depth );

    if( x264_init_vid_filter( "depth", handle, &filter, info, param, args ) )
        return -1;

extern const int x264_bit_depth;

const int x264_bit_depth = BIT_DEPTH;

#define BIT_DEPTH X264_BIT_DEPTH

akiduki 写了： 这句话好歧义啊，到底是add 8-bit的低2位到shift了2位的10-bit值上成为最终值呢，还是直接shift 2位？
601的说法看上去像是很明确的等同于shift 2位。