代码之家  ›  专栏  ›  技术社区  ›  Kyle Simek

太阳光栅图像:为什么宽度为奇数时使用1字节行填充?

  •  2
  • Kyle Simek  · 技术社区  · 15 年前

    这可能是waaay的具体原因,但似乎缺乏关于太阳光栅标准的信息。( Even JWZ is frustrated by this !)

    简介 : Sun raster standard 表示一行像素的末尾有填充,这样一行中的位数是16的系数(即偶数字节)。例如,如果您有一个7像素宽的24位图像,一行通常需要7*3=21个字节,但Sun Raster会将其填充到22个字节,以便位数可以被16整除。下面的代码实现了任意宽度的24位图像:

    row_byte_length = num_cols * 3;
    row_byte_length += width_in_bytes % 2;
    

    这是我的问题 :对于24位图像,imagemagick和gimp都遵循这个规则,但是对于32位图像,它做了一些我不理解的奇怪的事情。因为位深度提供4字节像素,所以任何图像宽度每行需要偶数个字节,这始终符合“16位对齐”规则。但是,当计算行长时,它们会为宽度为奇数的图像添加一个额外的字节,使行长为奇数(即行的位数不能被16整除)。下面的代码描述了它们对32位图像所做的操作:

    row_byte_length = num_cols * 4 + num_cols % 2;
    

    添加一个似乎违背了Sun格式指定的“16位对齐”规则,并且没有明显的目的。但是,我确信如果Gimp和ImageMagick这样做,我一定是误读了Sun光栅规范。

    有没有太阳光栅专家知道为什么要这样做?

    编辑 我的错误,gimp只输出高达24位的太阳光栅。看起来这只是一个ImageMagick问题,所以可能是一个bug。我把这个贴上了闭幕的标签;最好在ImageMagick论坛上讨论。

    2 回复  |  直到 15 年前
        1
  •  2
  •   Nils Pipenbrinck    15 年前

    我想说gimp和imagemagick中的图像加载代码有一个bug。很简单。

    请记住,太阳光栅格式并没有被广泛使用。很有可能你是第一个真正尝试使用这种格式的人,发现这种格式不能按预期工作,并且没有忽略它。

    如果规格说明中规定了以下内容: 不管宽度如何,存储的扫描线都被四舍五入为16位的倍数。 那么就没有太多的解释空间了。

        2
  •  2
  •   Wim ten Brink    15 年前

    我也觉得这是个错误。我甚至想知道Sun是否支持32位的RAS文件。基本上,32位图像很可能会添加一个alpha通道作为“第四”颜色,以支持透明度。但是像许多图像文件格式一样,它有点旧,其他的已经对格式进行了调整以支持32位图像。所以我认为任何添加了32位支持的人都是错误地实现了它,自从我们不得不接受这个决定以来。

    把它和 referer 已成为HTTP标准一部分的拼写错误。:-)已成为新标准一部分的错误。