太阳光栅图像：为什么宽度为奇数时1字节行填充？

Question

这可能是特定的SO，但似乎缺乏关于太阳光栅标准的信息。 （Even JWZ is frustrated by this！）

简介：Sun raster standard表示像素行在末尾有填充，这样一行中的位数就是16（即偶数个字节） 。例如，如果你有一个7像素宽的24位图像，一行通常需要7 * 3 = 21个字节，但是太阳光栅会将它填充到22个字节，因此位数可以被16整除。代码以下是对任意宽度的24位图像实现此目的：

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

这是我的问题：Imagemagick和Gimp都遵循24位图像的规则，但对于32位图像，我做了一些奇怪的事情，我不明白。由于位深度为4字节像素，因此任何图像宽度每行将占用偶数个字节，这始终符合“16位对齐”规则。但是当他们计算行长度时，他们为具有奇数宽度的图像添加额外的字节，使得行长度为奇数（即，行的位数不能被16整除）。下面的代码描述了他们为32位图像做了什么：

row_byte_length = num_cols * 4 + num_cols % 2;

添加一个似乎违反太阳格式指定的“16位对齐”规则，并且没有明显的目的。但是，我敢肯定，如果Gimp和Imagemagick这样做，我必须误读太阳光栅规范。

是否有任何太阳光栅专家知道为什么这样做？

修改 我的错误，Gimp只输出24位太阳光栅。看起来这只是一个Imagemagick问题，所以可能是一个bug。我将此标记为封闭;最好在ImageMagick论坛上讨论。

Answer 1

我会说Gimp和ImageMagick中的图像加载代码有一个错误。就这么简单。

请记住，SUN-Raster格式并未广泛使用。您很可能是第一个真正尝试使用此格式的人之一，发现它无法按预期工作而不会被忽略。

如果规格。顺便提一下：无论宽度如何，存储的扫描线都会向上舍入到16位的倍数，然后没有太多的解释空间。

Answer 2

对我来说似乎也是个错误。我甚至怀疑Sun是否支持32位RAS文件。基本上，32位图像很可能将alpha通道添加为“第四”颜色，以支持透明度。但是，与许多图像文件格式一样，它有点旧，而其他人则对格式进行了调整以支持32位图像。所以我认为，任何添加32位支持的人都错误地执行了它，因为我们必须忍受这个决定。

将其与已成为HTTP标准一部分的referer拼写错误进行比较。 :-)一个错误已成为新标准的一部分。